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.

  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.

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).

Mitigation steps:

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

• 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.

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.

  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.

Mitigation steps:

• Query for application submission rules using a Configurable Joins - Rule base utilizing a filter of Trigger for application.UpdateSubmitted:

• Use Suitcase to import this example query into your database:

  c13664c2-a521-4e42-9467-43880e78de26:slate-examples

• 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

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.