✋ Don't Panic - Solutions to Slate Things That Induce Panic

Slate still knows it’s you when you administratively impersonate an app, so it’s going to show you all rounds that exists in your instance, even when they’re inactive. If you go into incognito mode in your browser and actually sign in as a test applicant (not impersonating) you’ll see only the active rounds that are available for your application. Whew!

Creating a test record? Use youremail+test@school.edu instead of youremail@school.edu to make Gateway Inbox matching easier. Most email servers will deliver mail for both addresses to your inbox!

There can be a number of issues going on here, but the fastest way to check is to visit the applicant’s record and select the In Progress link to see any hard fails preventing them from submitting their application.

You can then navigate to Application Logic to review the hard fails and determine whether they are working as intended.

If the hard fails aren’t the issue preventing the applicant from submitting, you’ll want to check the Application Periods module in the Database to ensure the application period it is active. Applicants can submit applications in inactive rounds, but not in inactive periods.

If the period is active, check the Application Rounds module to ensure there isn’t a deadline on the application round preventing application submission.

If only one applicant is reporting the issue, you may want to check if their application deadline has been extended. Slate will prioritize the extended deadline on an individual application over the round deadline or deadlines configured in hard fails. If a staff member mistakenly extends an application deadline for an individual to be earlier than a round deadline or other deadline, the applicant may be unexpectedly held to that individual deadline.

If the issue still isn’t resolved, now’s the time to impersonate the application. I strongly recommend doing this in a test or time warp environment if possible, but it can be done in production if necessary. When impersonating:

• Check for special characters or code entered into fields on the application that Slate might not like.

• Check for values to make sense. For instance, Slate may resist efforts to provide mailing addresses that have already expired.

• Confirm that the hard fails for this application make sense given what is actually appearing on this application. Are the application pages that should show up for this applicant actually appearing as expected and giving them the opportunity to fill out those fields?

It is especially important to be certain about this if you have multiple forms in your application with the same name. Is the hard fail pointing to the correct “Program Details” section if you have more than one. How can you be certain? Check the GUID.

This is most likely due to conditions on the form. Access the form and select Edit Form.

Once in the editing view, select Edit Conditions.

You will then see filters on either the Access Conditions or Submission Conditions or both.

Review the filters and determine if they are met, if so, they may need to be updated in order for the staff member to be able to submit the form. If you’re unsure if the filter conditions are met, rebuild the filters in a query and use the Check Logic tool to determine if the person or application meets the criteria for the filters. Typically, the query environment will allow you to discover the problem, determine how to adjust the filters and then update the filters on the form to resolve the issue.

If you’ve been searching for a prompt or prompt key within the prompts module, Slate will retain the search string in the search box even after a prompt key has been selected. Removing the search string will cause your prompts to appear.

If prompts aren’t appearing as expected for use in a form, check the following:

• Refresh the prompt cache within the prompt module

• Check the prompt conditions within the form field

• Confirm that the prompts are connected to system prompts within the form field

If prompts aren’t appearing as expected for use as query filters, refresh the configurable joins library via the Database.

Inbox is a great resource, but when emails suddenly stop showing up it is alarming. When you start your troubleshooting, the place you need to look isn’t in Inbox itself, but over in Rules. Check your Rules Health to see how long your rules queue is. If it’s over 60 minutes, that may be the cause of the issue you’re seeing in Inbox.

You’ll need to resolve whatever is causing the hangup in your rule processing in order to get your Inbox emails flowing freely.

If you’re making rule updates that will have a lot of records going through the rules, it can be wise to run retroactive refreshes in batch or make the updates over a weekend so as to avoid Inbox being impacted during a high traffic season.