Application Error Messages and Troubleshooting

Application Management Page

Error Message: The page you have requested is temporarily unavailable. Please try again later.

To confirm the behavior, impersonate an application record. Whether starting a new application or opening an in-progress application, this error message is shown: "The page you have requested is temporarily unavailable. Please try again later."

  Things to look for:

  • A page key may contain an error. Note that all active page keys are assessed to load the application menu for navigation, so an error here can cause the application to be inaccessible even if the page key hasn't yet been used on a page.

Mitigation steps:

  • Navigate to Database > Application logic
  • Inactivate page keys one by one, starting with any that are newly added or that you suspect may contain errors. After inactivating a page key in one tab, refresh the impersonation tab and retry accessing the application. Continue until the application loads.
  • When the application is accessible again, that means you have identified the page key that introduced the error. It should remain inactive.
  • If you need to experiment with new page key logic while your application is live, it is best to do this either in the Test Environment or in a query.

Application Navigation

Application menu navigation is unable to load the selected page

To confirm the behavior, impersonate an applicant record and navigate through the application using the left-hand menu. If this navigation takes significant time to load the expected page, exit the application and re-impersonate once more. This time, move from one page to the next using the “continue” button at the bottom of the page.

If using the “continue” button instead avoids the issue, this confirms that the navigation menu action is the cause of the behavior and not an error loading the pages themselves.

  Things to look for:

  • A script running in the branding files (such as Google Tag Manager or similar) may be interfering with the action of the left-hand navigation menu. Errors like these typically do not stem from updates to Slate functionality because once the code is removed, the application behaves as expected.

Mitigation steps:

  • In the test environment, navigate to Database > Files and find the /shared/build.xslt file.
  • Comment out each of the tracking scripts in the code by using this syntax:
    <!-- Anything placed here will be commented out -->
  • For example:
    <!-- <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
    new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
    j=d.createElement(s),dl=l!='dataLayer'?'%26l='+l:'';j.async=true;j.src=
    'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
    })(window,document,'script','dataLayer','GTM-XXXXXX');</script> -->
  • Allow a few minutes for this update to take effect. Then impersonate an application and retry navigation between pages using the left-hand menu. If the selected pages load as expected, then inactivating that script resolved the behavior.
  • Comment out the same script in the production instance branding file. Note: It can take upwards of 15 minutes for a branding file update to take effect. After that amount of time, impersonate a record and confirm that the behavior is resolved.
  • If you want to continue using tracking code in your application, reach out to your GTM admins or marketing team to adjust the script or find an alternate solution. We recommend using the test environment to vet any changes to branding scripts and ensure that application menu navigation performs as expected.

Application Pages

Custom application page loads slowly or times out after attempting to load

To confirm the behavior, impersonate the application with an affected application record. Confirm that other pages load without delay when accessed via the menu and that only this page is affected. Lastly, impersonate a new test record with minimal data and confirm that this single page behaves the same regardless of the data on the record.

  Things to look for:

  • This behavior is limited to a single custom application page and is most likely the result of the length and complexity of the form.

Mitigation steps:

  • Select Forms from the main navigation and navigate to the identified custom form page where the behavior occurs.
  • Temporarily remove any custom page scripts or styles to see if that resolves the behavior.
  • If the form has above-average complexity, consider breaking this single page up into multiple pages that can be conditionally displayed to the appropriate applicants.
    • For example, have the initial program selection on one page, and then conditionally display a program-specific page following that initial selection (as opposed to conditionally displaying a section of the same form based on which program is selected).

Specific applicants encounter an error loading a specific application page where the language prompt list is used

To confirm the behavior, impersonate an affected application record. Confirm that the majority of the application can be accessed, but that a specific page is inaccessible (whether navigating to it by the menu, using the continue button on the previous page, or directly by URL). This means the scope of the error is limited to this page.

Also confirm that a new test record can access this page, indicating the error is caused by malformed data on specific records when interacting with this page.

  Things to look for:

  • Language prompts must have unique index values. For example, if Turkish and Turkmen are misconfigured to both have 'TR' as an index value, then the value stored in the database for either of those selections will not uniquely return one prompt. If an applicant previously selected Turkish, that data would be saved successfully as 'TR'; upon returning to the page, Slate attempts to render that response back to the applicant but doesn't find a unique value to display. This results in an error.

Mitigation steps:

  • Navigate to Database > Prompts and find the language prompts:

language.JPG

  • All duplicate index values must be changed to new, unique values. Note that inactivating these prompts is not enough to eliminate this error, as even inactive language prompts must have unique index values.
  • It will not be possible after the fact to determine which value the applicant intended to select, as the value stored would be identical. Consider keeping the existing index value on the more common selection of the two, and changing the less common value moving forward.

Widget on an application page is not displaying data

To confirm the behavior, impersonate a test application and submit data to the widget in question. Outside of the impersonation, confirm that the data submitted can be found on the person record, just not within the application page widget.

  Things to look for:

  • Custom list exports must be configured for the widget to display results in a table format.

Mitigation steps:

  • Navigate to the widget-scoped form and select Edit Properties.
  • Add one or more custom list exports. These will appear as the columns displayed in the widget table.
  • Retry the application impersonation to confirm that data from the widget is now showing on the application page.

Review Page

Review page loads slowly or times out after attempting to load

To confirm the behavior, access an affected record and navigate to the Review page. Confirm whether the page loads slowly, for 15 seconds or more, or if it times out.

  Things to look for:

  • Inefficient filter criteria in submission requirements (both hard and soft fails) can impact load times for the Review page. Consider fails that use many OR statements, complex formulas that are computationally expensive, or joins to high-volume tables.

Mitigation steps:

  • Navigate to Database > Application Logic
  • Increase the efficiency of your submission requirements overall. Here are some things to try:
  • Remove any application logic that is no longer needed. For example, fails that refer to previous terms or inactive programs that will not be used again in the future.

  • If a single submission requirement includes many OR statements, determine if it can be divided into multiple fails, especially where the criteria are mutually exclusive. A larger number of fails with simplified filter criteria will run more efficiently than fewer, more complex fails.

  • The same best practices recommended for rule efficiency also apply here.

  Tips and tricks:

Try the same filter criteria in an application-based query to see if results are returned efficiently. The time that it takes to return a matching rows count is a good indication of the efficiency of given filter criteria.

Submit Application button results in timeout

To confirm the behavior, impersonate a test application record, navigate to the Review page and attempt to submit. Whether or not the submission times out at this time, a significant delay experienced by the end-user at the time of submission is cause for concern.

  Things to look for:

  • Misuse of Application Submission rules. Rules with the trigger of "Upon Application Submission Only" run on-demand at the moment of application submission. This trigger is appropriate primarily for application fee payment rules, and these rules should be as streamlined and efficient as possible to perform at times of peak application activity.
  • Application submission is rarely the appropriate trigger for any other kinds of rules, such as those setting checklists and field values which should run on deferred action instead. Overburdening the moment of application submission can easily lead to timeouts that affect the applicant experience directly.

Mitigation steps:

  • Navigate to Database > Rules and select the Application Submission trigger from the right-hand navigation:

mceclip0.png

  • Review all rules using the "Upon Application Submission Only" trigger. Ensure there are no rules in this group producing a functional error.
  • To the greatest extent possible, use Upon Update (deferred action) instead.
    • Note that although these rules may have performed adequately when initially created, databases grow in complexity and record volume over time. Particularly at times of peak application submission volume, the database is likely to see more frequent timeouts if the associated rules are not optimized for efficiency.
Appropriate Application Submission rules Payment rules for the application fee or waiver
Inappropriate use of Application Submission trigger

Checklist rules

Population rules

Field rules for Staff Assignment or any other custom field

Conditional Logic

Application pages controlled by page keys continue to be hidden after criteria are met for up to fifteen minutes

To confirm the behavior, impersonate an affected application and confirm that, although the application meets the criteria for a given page key, the page is not visible in the menu navigation.

  Things to look for:

  • Page keys are only refreshed when qualifying data changes, otherwise, the logic applied will persist until the cache expires.
  • This can be an issue if using filters for the current date and time, where the filter criteria were not met at the time the applicant initially loaded the page. In this case, refreshing the browser while making no data changes will not cause the page key logic to be rechecked.
  • Certain legacy pages such as academic history ('aca') and test scores ('tes') are not intended to have fields mapped on the page. Questions can be added to this page through XSLT files, however, if the value will be used in a page key it should not be mapped on a legacy page; form pages should be used instead.

Mitigation steps:

  • As much as possible, filtering page keys by the current date and time should be avoided. If this kind of filtering is critical, it will be necessary to set a hidden value on the page that is always changing, so that every time the page is submitted it qualifies as an 'update' (for example, mapping a hidden field set to the current date and time using a merge field export and a calculation formula).
  • Avoid mapping custom questions on legacy pages via XSLT; form pages should be used instead. Fields mapped in the XSLT should not be used in page keys.
Was this article helpful?
1 out of 1 found this helpful

Comments

0 comments

Please sign in to leave a comment.