As you prepare to go live with your application, you can use the below review list as a helpful guide to review your application. Please note that this is not an exhaustive list and there is no replacement for thorough testing, but this can help get you started and help you think of things that you hadn't thought about. 

Periods and Rounds 

Periods 

• Active Period(s) - Will only one be open at a time? 

• Naming Convention - Is the naming convention clear for the student? The Name field will be the externally facing name. 

• Allow Multiple - Does the "Allow Multiple" setting align with your business practice? This setting allows the applicant to create multiple applications within a single active period at a time.

• Custom Application Portal - Do you have a custom application portal (either status or landing page) that you want associated with a particular period. Commonly, application status portals are added to specific rounds but they can also be added here. 

Rounds 

• Period - Is your Round associated with the correct period? 

• Naming Convention - Is the naming convention clear for the student? The Name field will be the externally facing name. If there is a name that is better used for internal purposes, that should be placed in the Short Name section.

• Round Key - Is your Round Key computer friendly? Example, "GR" for Graduate.

• Deadlines - If you are using deadlines, be aware that those are set in eastern time. 

• Payments - If you require payments, do you have your payment account set up? Have you tested your payment rules? 

• Allow Multiple - Does the "Allow Multiple" setting make sense for your business practice? This setting allows the applicant to create multiple applications within a single round at a time.

• Locked - Is your application locked? This prevents students from changing their round once they've started an application within this round.  

• Rankable - Is your round set to rankable? There is seldom a time when a round should not be set to rankable. 

• Application Status Portal - Do you have an application status portal that needs to be associated with your round? 

Application Pages 

Standard Application Pages 

• Standard Pages - If you are using the standard Slate pages (Personal Background (Per), Academic History (Aca), Reference (Ref), etc.) and no updates have been made, you are good to go!  

• Custom Fields (Legacy Method) - If you have any custom fields on standard pages (per page, aca page, ref page, etc.) that were placed by the Support Desk within an XSLT page, those should all be migrated to Slate-Hosted Application pages.  

Custom Application Pages (Slate-Hosted Application Pages) 

• Form Scope - Is the form scope Slate-Hosted Application Page? 

• Field Mappings - Are all fields mapped to system, custom, or standard fields? You can use the Application Form Field Verification Query (Database > Standard Query Library) to quickly see if you have any unmapped form fields. 

• System Fields - There should be no redundant system field mappings with standard pages that are in use. Examples include Name, Citizenship, Race, etc. on the personal background page and should not be mapped elsewhere. Even if a field like Citizenship is hidden/suppressed on the personal background page, it can't be mapped elsewhere so long as the standard page is in use (e.g. the same application can have both the per page and the custom page); data collected on the custom page will be nulled when the standard page is revisited.  

• Form Field Type - Form field type selected should be consistent with field configuration. Example: a prompt-driven field shouldn't exist in a text form field. 

• Checkboxes - Keep an eye out for checkboxes (if allowing >1 selection) or multi-select lists being used with single-select fields.  

• Override System Prompts - Override system prompts must leave prompt GUID or index intact after the caret. Where possible, prompt logic should be used instead.  

• Conditional Logic - Will your conditional logic cause unintentional unsetting of field values? With conditionally hiding/showing fields with conditional logic, the underlying behavior is that under certain conditions, values should not exist for the records that do not meet those conditions. For example, if a major field that was selected was Biology and that choice conditionally displays the concentration field of Microbiology, but then the student changes their major to History, their concentration field should not still be Microbiology. The student no longer qualifies for the conditionally suppressed field of Microbiology concentration when their major changed, thus the value should not exist. This is how conditional logic is intended to be used and when it is used to simply hide certain questions, it leads to the unsetting of fields that should still have values retained. 

• Section Breaks - If conditional logic has been applied to a section break, confirm there is a second break indicating where that logic ends.  

• Internal-Only Fields - Do you have any internal-only fields? If yes, remove them. The Internal setting on the application form field will always unset the field, as that setting will suppress any value stored within when the form is being externally accessed (either organically by the student or via an impersonation). If there is a field your users should see, that should be made accessible outside of the application either in an application tab or (preferably) via the reader.

• Widgets - Does the page include a widget - Does your widget have the proper scope? i.e. School Widget, Job Widget, etc.
  
  Has that widget been placed on a Slate Hosted Application Page?  
  
  Has that application page been added to the application itself? 
  
  Have Custom list exports been added to the widget forms? Custom list exports must be added via the Edit Properties to display columns in the widget table. Custom list exports have since replaced the need for PKVs to be added to the widget table widget Config box.  
  
  All fields MUST be mapped to widget scoped fields. Widgets do not store values to the form response table so each form field must be mapped. 

Application Logic 

Submission Requirements (Hard/Soft Fails)

Any field that is necessary to have a complete application should be reinforced with a Hard Fail. Any field that might benefit from being collected, but not required should be given a warning with a Soft Fail. First name, last name, email, program, entry term, are examples of fields that require Hard Fails. It is important to note that the required setting within each field on a Slate-Hosted Application Pages is not respected.  

• When to Use - Hard fails should be something the applicant can satisfy from within the app. For example, a missing field value on the personal background page. Exceptions can be made for deadlines and eligibility requirements that should prevent submission based on certain answers and dates. 

• Filtering - Hard fails should be filtering to find applications that the fail message is intended for, i.e. the applicants that have not done what is required. These are typically filtering for those with values missing or those with fewer than a minimum number of schools, etc. 

• OR Statements - Hard fails with OR statements are often logically inverted by accident. Think of it this way: should the applicant be prevented from submitting for meeting either criteria or prevented from submitting for meeting both criteria? If it's the latter, the OR operator is incorrect. 

• The Review Page - Impersonating the review page, all fails should have two columns with the page link on the left and the fail text on the right. There shouldn't be misalignments if this is configured correctly. 
  
  If the fail text spans this whole width and has no linked page, that means the fail is showing to an application that does not have access to the linked page (therefore would be unable to satisfy the fail). 
  
  Either the incorrect page is linked to this fail, or the requirement on this page shouldn't be shown to this applicant. Add filters or a group configuration to the hard fail to associate the fail only with applications that see this page and this question. 

• Pre-Submission - Hard fails should only require what is needed before submission is allowed, as opposed to checklist items for requirements after submission. 

Page/Group Keys 

• Multiple Page Keys - If multiple page keys are applied to the same page, these should be understood as granting access to the applicant under either condition. 

• Application Impersonation - Application impersonation should load without error; an immediate error may indicate an active page key throwing an error. If trying to begin an impersonation of the app and you immediately encounter a "Resource unavailable" message, most likely their application is unable to load due to a page key error. Check out your page keys to make sure that they load properly and do not throw errors. 

• Slate Standard Pages - Do you have a page key on a Slate Standard page (aca, ref, test)? If yes, those will not behave as intended. This has to do with how Slate processes data collected on those pages to promote the efficiency of the application. Page keys can only be added to Slate-Hosted application page-scoped forms, the standard Personal background page (per page), and the review page. 

System Emails 

• Non-Automated Mailings - Did you want to/did you create an application creation and/or submission system email? These are not automatically sent to applicants and must be created and configured. 

• Merge Fields - For all system emails, are there redundant merge fields? i.e. merge fields added in the edit conditions section of the mailings that are already included as available merge fields. If yes, then this will prevent the mailing from being sent. You want to eliminate all redundant merge fields.

• Content - System emails should be fairly generic. The bulk of the content should be coming from the status portal or wherever the email is linking to.  

Upon Application Submission Rules 

• Application Payment Rules - The only rules that should have the trigger of Upon Application Submission should be application payment rules.   

• Time-Outs - If you have other rules not related to payments, those should not have the trigger of upon application submission. Those will quickly lead to time-outs and the prevention of students from submitting the application. 

Checklists 

Custom Checklist Items 

• Groups - Are your checklists in groups? If not, you should consider it. Checklist groups allow the checklist items within that group (even if it is a single item) to be dynamically added and removed to/from the student's checklist based on the filter criteria set in the checklist rule.  

• Settings - Review the checklist settings to ensure that the required ones are set to required 

• Forms - If a checklist item is a Slate form, that checklist item should be in the Form Section  

• Materials - If it is listed as a material with the URL, it will take a while for the form submission to register and mark off the checklist item. When it is in the form section, the submission of the form will automatically mark off the checklist item as received. 

• Admin-Only Checklist Items - For Admin Only checklist items, if you want those to display to the students after they have been received, be sure to include a Checklist Display Label on the material. 

• Test - Test your checklists thoroughly! Make sure that students who should get certain checklists do and when materials have been received that those do indeed check off the checklists. 

Autogenerated Checklist Items 

• Special Use Only - The "Reference (special use only)" and "School Report (special use only)" transcripts should seldom be used. If these checklists are present, a conversation as to why should be had. 

• Custom Transcripts - If you are using a custom transcript process, then the "Transcript (special use only)" checklist item should be present as this turns off the autogenerated checklist functionality  

• Recent Updates - If this was a recent update, be sure to test your new checklist assignation rules to ensure that the proper students get the correct transcript checklist items. 

• Duplicate Transcripts - If this is your first cycle without autogenerated transcripts, be sure to reach out to the Support Desk or through the Community Forums and request that the previously autogenerated transcripts be removed to prevent duplicate transcript checklist items from populating.  

Testing

Complete and thorough testing is the best way to ensure your application is ready to be published. Once the team who built the application feels good about it, have folks in a different office who have never seen the application fill out the application - they're the ones who tend to find pain points or hiccups we never thought about!
Be prepared outside of Slate for thorough testing! Create a spreadsheet with a variety of test records that represent different types of students who will be applying to your school. Keep in mind the specific conditional logic and checklist rules that should apply to these students so you know if what you have put in place is working. 

• Standard Query Library - Use the Application Form Field tool in the Standard Query Library (Database > Standard Query Library) to quickly see if any of the fields on your application are unmapped. If they are, those should be mapped. 
  Use the Field Configuration Review query in the Standard Query Library (Database > Standard Query Library) to quickly see any field misconfiguration within your database. 

• Impersonation - impersonation is vital to test your application to ensure that applicants should see everything necessary for a complete application and to ensure the data is stored properly. After your application is live though, you should seldom impersonate a real applicant. The risk of changing applicant data is incredibly high. If there is data about an applicant you need to see, that should be accessed via a query, the Reader, or an applicant dashboard.