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.

A brief history of XSLT build files

Before 2021, if Slate users wanted to customize standard pages of the Slate-hosted application with custom questions and static page elements, they’d create XSLT build files.

Now, creating custom application content is more user-friendly. If you need to add something to one of the standard application pages, you can recreate the page as a custom Slate-hosted-application-scoped form in the form builder.

We offer step-by-step instructions to creating these pages in the Custom Application Pages section of the Knowledge Base. Some articles feature ready-made replacements that you can import with Suitcase.

As you identify the pages in your own application that are hosted on build files, refer to these articles in this section to learn how to recreate that page as a form.

📖 Migrating to Custom Application Pages: Custom application pages overview

How XSLT build files may appear in your database

Depending on the age of your database, XSLT build files might exist in your database in one of two configurations:

• In the Application Editor as part of a standard page

• In the Application Editor as a Custom App Page (special use only)

One or both of these may be present in your database, and we show you how to identify and replace both types in this article.

XSLT build files for standard application pages

We first want to identify any active build files in a familiar context: the Application Editor.

Identifying build files in the Application Editor

In Database → Application Editor, select an application.

We focus our attention on the standard page modules, identifiable by their part ID:

• per: Personal Information

• aca: School History

• act: Activities

• job: Employment History

• ref: Recommendations

• tes: Test Scores

Select one of these pages to view its configuration.

If the page has any XSLT build files that map custom fields (more on this below), they appear in a section with a name ending in -build.xslt.

The objects that appear in this list represent the custom fields mapped to the application page’s build file. These custom fields must be recreated in the custom Slate-hosted-application-scoped form that replaces the standard application page.

📝 Note: This list is not exhaustive. Your application page may be associated with XSLT build files that include only static elements or conditional logic, which don’t appear in this list. To locate these files, we’ll head to Database → Files, covered in the next section.

Locating build files 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.

▶️ Action Items

Active files:

1. Using the following table, for each standard page with custom fields in the build.xslt section, recreate that page using a Slate-hosted-application-page-scoped form. Include the custom fields you found in the Application Editor in the new forms.

   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.

Inactive files:

If the build file is not used in the application, it can simply be deleted. Here are examples of inactive files:

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

In these cases, open the unused file in Files and select Delete.

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.

XSLT build files with Custom App Page configuration

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 adding custom forms to the application as pages. All XSLT-based application pages with this configuration must migrate to custom application pages made with forms.

Identifying custom app pages in the Application Editor

In Database → Application Editor, select an application.

From the list, identify any page with a Part ID starting with app? and a Module Description Custom App Page (special use only). For example, app?familyinfo, or app?interests.

Select one of these pages to view its configuration.

A section with a name ending in .xslt includes the build files (if any) currently associated with the page.

📝 Note: This list displays the custom fields mapped on the build file. However, this functionality has been long deprecated, and in some cases these elements will not appear even if they exist. To review contents fully, access the file directly, in Database → Files, covered in the next section.

Locating custom app page files in Files

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:

▶️ 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.

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

Frequently Asked Questions

1. How do I get started?

   1. The first step is to import the suitcase for the Custom Application Pages depending on which one(s) you need. These suitcasable forms are designed to replicate standard application pages. The article also contains suitcase links to the necessary widgets that accompany these pages. Once the form(s) is suitcased in, you can add and map your custom questions from the build files, run through testing in your test environment, and insert the page to the appropriate application base.

2. 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 and set up the forms into your Production environment first. From there you can then provision your test environment to run through testing if you feel it is necessary.

3. How do I know if my build file is being used?

   1. First you’ll want to check in the application editor and identify the standard pages by their part ID (per, aca, act, etc…). Check the standard pages to see if custom questions are listed. If you see fields listed under a -build.xslt section that is a good indicator the build file is in use.

   2. Sometimes old files will have INACTIVE or NOT IN USE in the file name within the Files section of the database. This is a good indicator that you are not using these build files, and they can be safely removed after following the steps to verify.

4. What if the page in the Application Editor 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.

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

   1. You will want to remove the build file once everything is migrated to a custom form. This will be important as future updates.

6. How do I know I am ready to delete my build.xslt files?

   1. If you have migrated your custom questions on the build files to custom forms and/or have confirmed through the steps in this article that those build files are not being utilized, you can then proceed to delete them from the Files section of your database.

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

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

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

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

11. Will this migration impact Application Creation forms?

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