A translation code may be helpful for managing deadlines when the Slate-Hosted Application has some combination of the following:

• Multiple deadlines (15+)

• Frequent program-wide deadline extensions

• Deadlines are determined based on at least three prompt-based fields (program, entry term, campus, full-time/part-time status, online/in-person instruction, etc.)

• Slate-Hosted Application is live and accepting applications year-round

Translation codes recognize and transform a value into an export value, with all combinations stored in a translation key within your database. Translation codes have many use cases, including the ability to transform a string of values into a date. In this use case, the value entered in the translation code represents a concatenated string of all data points contributing to the calculation of a deadline; an export value returns the appropriate deadline date for this string.

Translation codes have many use cases, including the ability to transform a string of values into a date. In this use case, the value entered in the translation code represents a concatenated string of all data points contributing to the calculation of a deadline; an export value returns the appropriate deadline date for this string.

Translation codes can complement other deadline management methods. A round deadline might still be used as a catch-all to enforce a final deadline or closing date for that round, even if some applicants will have earlier deadlines. Prompt maintenance, with or without the use of expiration dates, will also be necessary to ensure that long-past entry terms and cancelled programs no longer offered do not appear in any context to applicant or person records.

Translation key best practices

• Limit the Number of Deadlines: How many deadlines in total must be accounted for, and can anything be done to reduce that number? If three different graduate programs have three deadlines on three different days within the same two week range, is there harm in consolidating?

• Limit the Number of Fields Determining Deadline: Consider restructuring fields so that there are fewer overall data points determining deadline.

  • Rather than selecting Business as program and MBA or DBA as degree type, these two fields might be consolidated and rely on a single prompt list—Master’s in Business Administration, Doctorate of Business Administration, etc.

  • If this field selection alone were enough to determine deadline, a prompt export value might store the deadline date and a translation table would not be necessary.

• Start Small, Scale Up Later: When building your translation key, start with a small sample of translation codes (no more than 10) when completing the rest of the setup steps in this article and testing. Once you are satisfied with the structure of your translation codes and are able to return the deadlines from the translation code as intended, translation codes can imported in batch via the Translation Code Source Format.

Build the translation key

Planning your translation codes and building a translation key means taking stock of every selectable combination of field values and designating their deadlines. To get started, follow the steps below to test out the translation code method.

1. Go to Database → Translation Codes.

2. Select New Key.

3. Name the Key something that reflects the information it stores, and specify the Type of value you are looking to translate from. In this case, we’ll use “deadline” and a Data Type of “String (Discrete Values).” For now, there is no default value.

4. Select “New Code” to create input values, and settle on a format:

   • Each row must be formatted identically, and the combined values must match the prompts exactly. Because the value represents many prompt selections being concatenated, separate them with computer-friendly characters which do not appear in any of the prompt values: term__program__degree__enrollment type__instruction plan

   • If there is a hyphen or dash in any one of your prompts (Part-Time, On-Campus), for instance, do not use this symbol. A double underscore is a good practice as it is highly unlikely to appear in any prompt value that the applicant selects: Fall 2025__Business__DBA__Full-Time__On-Campus

   • The translation key should have a row for every available combination of term, program, degree, enrollment type and instruction method. All selectable combinations of these values need to be values in the translation table, even if the deadline is the same for some permutations.

5. Enter an Export Value to represent the deadline for the combination of factors selected.

6. Select “Edit” to set a Default Export Value is entered for the deadline export. This will be returned when a value that is not listed as as a translation code is run through it, and acts as a failsafe. For a deadline translation code, entering a date that is far in the future will ensure that applicants are still able to submit an application if the combination of values they have selected has no corresponding translation code. It might also display a round deadline, if you are using one.  

b2631b54-4b21-4008-8f5a-a56481b6ff08:slate-examples

Deadlines from the translation key can be calculated and displayed on a new or existing Slate-Hosted Application Page-scoped form (or any other form where a deadline needs to be calculated) as long as the following are true:

• All prompt values that comprise the input value are selectable on the form

• Each field is on the form only once

Applicants will select or confirm the form fields that determine their deadline. These are likely already mapped fields in your database.

Create a section break

Once all values contributing to a deadline are selected, add a section break anywhere below the last one. This section break will prevent deadlines from being calculated until enough data exists to do so accurately. The section break logic repeats the Form Field Exists filter to confirm that a value exists in all deadline-determining form fields:

Concatenate data from the applicant

The values entered by the applicant must be concatenated and formatted so that they match a translation code value. A Calculation Formula in a hidden form field can perform the concatenation by combining the export keys for all deadline-determining form fields. Each export key should be appended with _text to ensure that the prompt value, as opposed to the prompt GUID, is concatenated. The translation code value has no underlying connection to the matching prompt—it is just a string, so the string value generated on the form must match it exactly:

The calculation formula in full reads:

@sys:app:app_entry_term_text + '__' + @sys:app:app_degree_text + '__' + @sys:app:app_program_text + '__' + @sys:app:app_ed_plan_text + ‘__’ + @sys:app:app_instruction_plan_text 

This hidden form field generates a value in the following format. It may be helpful to keep the form field un-hidden until testing is completed.  

Calculate and display the deadline with a translation widget

Now that values have been selected and concatenated, the resulting string can be run through the translation code via a Translation widget.

First, set up the translation widget. From the form pallet tools, select Translation. This widget will never display externally on the form. Enter a script key, then select the Translation Key and the Export. The script key will be used only on the form, and does not need to match the Translation Key.

Next, create another form field to calculate and, if desired, display the deadline to applicants. If you choose to display it, the form field should be set to “Read Only.” Use the export key from the concatenating form field in the translation, and give the form field a new export key.

Why not map the deadline?

In the application process, this is easy to answer—the deadline should always be recalculated instantly as the applicant makes changes to their selections, or as you make changes to deadlines. A translation code allows this to happen in real time, so that the deadline will always be correct for that combination. Applicants don’t need to submit the form page to map the value or wait for rules to run, so deadline validation can happen in real time.

Validate the deadline

Deadline date can be compared with the current date to conditionally display a "Deadline has passed" warning message to the applicant. This requires another hidden form field to assess the deadline’s validity through a calculation formula. The following calculation formula logic has a simple condition ? if : else structure, sometimes referred to as a ternary operator.

new Date() <= @form_export_key ? 1 : 0

The new Date() function is simple Javascript which returns today’s date. Used in this way, we'll check if today's date is before or equal to the calculated deadline, then return a binary value of 1 for true, otherwise 0 for false.

The value that populates in this hidden field will control visibility for an instruction block which displays only when the previous calculation formula returns a “0” to indicate that the deadline has passed:

Build application logic to enforce deadlines

Next, we'll use Application Logic to prevent application submission if the associated deadline has passed. While the form validation message built in the previous section is used to warn the applicant to make another selection, a Hard Fail is necessary to enforce the deadline.

In a Hard Fail, rebuild the concatenated term__program__degree__enrollment type__instruction plan value in a subquery export and pass it through the translation code again. The mapped values can be used—the applicant has navigated away from the custom form page where the deadline was initially calculated and displayed, so the field values determining deadline are now stored to their record.

1. Go to Database → Application Logic.

2. Select “Insert".

3. Select a Type of “Submission Requirement.”

4. Select a Section of whichever custom form page collects and calculates deadline information— in this example, Program of Study.

5. Enter a descriptive Name to display to applicants when they qualify for the hard fail.

6. Select a Warning of “Hard Fail.”

7. Select a Base of “Configurable Joins - Application.”

8. Select the subquery filter icon to build a subquery filter to prevent submission for anyone whose deadline is prior to the current date. This will rely on a comparison between the current date (System Current Date) and the deadline. A nested export will generate the deadline by rebuilding the translation value and run it through the translation code.
   

   

9. Save your nested filter and subquery filter. Add any additional filters needed to enforce deadline to the correct applicants, then save the hard fail. The hard fail can also be modified to allow for extensions. If applicants are eligible for individual extensions, logic can override the deadline calculated by the translation code. Extensions should be logged through an application-scoped Mapped Field.