This article helps you identify deprecated XSLT (Extensible Stylesheet Language Transformation) build files in your database, interpret their contents, and transition to custom application pages.

How to approach your migration:

• Identify XSLT build files in the Application Editor. The presence of build files is often indicated in the Application Editor. They will appear as follows:

  • As a modification to a standard page (part ID: per, aca, act, job, ref, tes)

  • As a Custom App Page (special use only)

• Locate XSLT build files. XSLT build files are stored in Database > Files.

• Build equivalent custom application page forms and add them to your application bases. Nearly all XSLT functionality can be replicated in Custom application pages. To replace a standard page, save time by starting with a suitcase.

• Test your application. Impersonate applicants, review any reader tab materials displaying application data, and ensure that application logic is correct.

• Delete the XSLT build files that have been replaced with forms.

If you need additional clarification, you can review this thread in the Community Forums and post additional questions.

Determine what needs to be migrated

To begin identifying XSLT build files in your database, you can navigate to the Application Editor. In nearly all cases, evidence of custom XSLT build files can be found here.

Can remain as-is:

• Custom Form pages beginning with frm?. These pages are already forms, which are the best practice for building your Slate Hosted application.

• upl?portfolio, upl?video, certify, and review pages

Must be recreated as a form:

• All Custom App Pages, beginning with app?. They are also labeled as Custom App Page (special use only) in the Module Description column

Can remain without build.xslt file:

• Standard Application Pages (per, aca, act, job, ref, tes). Click on each standard page to view its settings see if a build file exists. If so, this page will need to be rebuilt as a Slate-hosted-application page scoped form.

  • If the build.xslt file has values listed below it, these items represent the custom fields added to that application page via the build.xslt file. You will add these fields to the Slate-hosted-application-scoped form that replaces this standard application page.

  • In some circumstances, a build.xslt file will display with no fields listed below it. This means that a build.xslt file does exist, but may be displaying static text or controlling logic. You will add this text and form logic to the Slate-hosted application-scoped form that replaces the page.

If you have a page in your database that does not meet any of the above criteria, it can remain at this time unless someone at Technolutions reaches out to you directly.

A note on the tes page

Among the standard application pages, tes is somewhat unique: the widget on this page that lets applicants choose a test type and enter their scores cannot currently be replaced by a Slate-hosted-application-scoped form.

If your tes page is associated with an XSLT build file, the file modifies the tes page in one of two ways, which determines your course of action:

• The XSLT build files include person- or application-scoped fields: These must be recreated in Slate-hosted-application-scoped forms, either on an existing page in the application or by creating a new page and adding them there.

• The XSLT build files modifies the test widget itself: In this case, Technolutions staff will review your case and reach out to your team to collaborate on a migration plan.

Locating build files for Standard Application Pages in Files

Now that we have a sense for which of our application pages have XSLT build files, we can work toward replacing them.

In Database → Files, select the /apply/ directory, then enter build in the search bar.

All build files follow the naming convention /apply/YOUR-APPLICATION-PATH/APPLICATION-PART-build.xslt.

Build files located in the /apply/ directory apply to the corresponding module in all application bases, unless a more specific file exists.

Some of your build files may already be inactive, and can be deleted immediately if any of the following are true:

• Although a build file exists in Files (i.e. per-build.xslt), the corresponding standard module is not used in the Application Editor (i.e. per does not appear in the application menu).

• The file contains only hidden fields (set to “Invisible to Applicants” in the Application Editor UI).

• The file contents are commented out.

• The file is a template only and contains no mapped fields.

• The file exists on an invalid path.

  • It was once a common practice to assign an invalid name or path to a build file as a way to deactivate it. For example: /apply/per-build-ThisFileIsInactive.xslt, or /apply/INACTIVE/per-build.xslt, where no application base uses the path INACTIVE. Files with these invalid conventions aren’t accessed by the application.

▶️ Action Items

1. For each standard application page with a build.xslt file, use the following chart to recreate the page as a Slate-hosted-application-page-scoped form. Include the custom fields you found listed in the Application Editor and any static content or logic from the build.xslt files in the new forms. If you are not sure how to interpret the fields and logic in the build.xslt section or file, impersonate a record and model your replacement form after the page as it appears for an applicant.

   Part ID	Module Description	Build File Name	Instructions to replace
   per	Personal Information	per-build.xslt	Custom personal background page
   aca	School History	aca-build.xslt	Custom school history page
   act	Activities	act-build.xslt	Custom interest page
   job	Employment History	job-build.xslt	Custom employment history page
   ref	Recommendations	ref-build.xslt	Custom reference page
   tes	Test Scores	tes-build.xslt	See A Note on the tes Page

2. After migrating those custom fields to the custom form, go to the Application Editor and remove the standard page, replacing it with the newly built custom form. Review step 4 within the articles listed above for more details adding your custom form to the application base.

3. Be sure to adjust submission requirements in Application logic, changing ‘Section’ to point to the new custom form page.

4. After implementing the form page, open the file in Files and select Delete. All inactive files can be deleted as well, if you have not already done so.

Locating Custom App Page files in Files

You may find files that use the deprecated configuration Custom App Page (special use only). This configuration, which was deprecated over ten years ago, predates the ability to add custom forms to the application as pages. All XSLT-based application pages with this configuration must migrate to custom application pages made with forms.

In Database → Files, select the /apply/ directory. All custom app page XSLT build files follow the naming convention app_, and have a file type .xslt.

To narrow the list to only custom app page files:

1. Select the Customize View icon.

2. Select Copy.

3. Enter a name for the view, like XSLT file search.

4. Select Subquery Filter.

5. Configure the following settings:

   • Name: Enter a name

   • Type: Dependent subquery

   • Aggregate: Formula

   • Formula: Enter @File-Path LIKE '/apply/%app[_]%.xslt'

     

6. Select Save.

This search returns XSLT files on any path that follows the app_ naming convention. For example:

To determine where a particular build file is in use within your application base and where to insert the replacement form, you can navigate back into the Application Editor to compare file names:

▶️ Action Items

1. For each Custom App Page (special use only) page you identify, recreate that page as a form, making sure to include custom fields you found associated with the page in the Application Editor. If you are not sure how to interpret the content in the files you have identified, impersonate a record and model your replacement form after the page as it appears for an applicant.

2. Once all pages have been migrated to forms, select the file and delete.

Frequently Asked Questions

1. Do I need to make these changes in the test environment first or can I just make them in production?

   1. It is recommended to suitcase the forms into production and customize them there. You can reprovision a test environment once your forms are built and ready to test.

2. What if the page in the Application Editor lists an XSLT file but does not show any custom questions?

   1. Even if the page(s) in the Application Editor do not show custom questions, you will still want to review them in the Files section of your database. It is best to do a complete review in both locations (Application Editor and Files section) to ensure the file is not being utilized.

3. Can I keep my build file even if it is not in use?

   1. No. You will need to remove the build file once everything is migrated to a custom form.

4. How do I know I am ready to delete my file?

   1. If you have migrated your custom questions from the build file to a custom form and the form page is live for applicants, you can now delete the XSLT file from the Files section of your database. Similarly if you have confirmed that your file is not being used in the live application, those files can be deleted.

5. Will this migration impact how my data is being stored?

   1. No, this migration will not impact how the data is being stored. By suitcasing in the custom application forms, you are essentially mapping to the the same system fields.

6. Will this migration impact how my data is being displayed in the Reader?

   1. You will want to revisit your Reader tabs to ensure the information is displaying as expected. You may need to make updates for the custom forms to display.

7. What impact will it have on my Application Logic?

   1. You will want to review soft/hard fails and page keys to make sure that the logic is pointing to the custom form.

8. What impact does this have when our application is live?

   1. Since the questions are being mapped to the same system fields, swapping the page(s) out of the application and inserting the custom form will not have an impact on the data.

9. Will this migration impact Application Creation forms?

   1. No, the build.xslt files only apply to items in the Slate-Hosted Application.