Slate Implementation Phases
The Slate Roadmap provides the best-practices to build out all essential admissions operations in Slate, from recruitment to decision release, in a timely manner. It includes helpful strategic advice for establishing this functionality in Slate and links to pertinent documentation. Use the Roadmap in conjunction with our Implementation Checklist and your current process review to develop a step-by-step project plan for building all essential admissions operations in Slate.
A specific order of operations has been designed to foster your understanding of Slate and grow operational capacity one step at a time. More than 1,700 schools have used this standard Roadmap to successfully develop their implementation project plan, build operational capacity, and transition admissions processes into Slate.
Pick and choose
The Roadmap is customizable. You can change the suggested order of operations to reflect your priorities and processes. For instance, many graduate schools choose to focus their energies on creating an application first. We recommend that these schools still implement in the order laid out in the Roadmap, while spending less time on non-critical processes, or skipping certain components altogether if not a part of their current operation.
The goal of the implementation should be to establish only the operations necessary for go-live. Based on your review of current processes:
- Determine which operations are critical to implement in Slate before transitioning from your pre-Slate system.
- Evaluate which non-critical aspects of your process can be put on hold until critical operations are running and your team is more comfortable using Slate.
Clarify this strategic review in your own Roadmap. This prioritization process will allow you to go live quickly and effectively.
In summary, your Roadmap...
- Provides a list of essential admissions functionality in Slate.
- Allows you to prioritize which functionality should be developed first.
- Indicates which tools in Slate support different aspects of your overall process.
- Helps you understand the interdependencies between distinct aspects of Slate functionality.
- Supports collaboration when users are working on different projects simultaneously.
- Is customizable to suit your implementation goals.
- Serves as the basis for the fully developed project plan.
Stage 1: Slate essentials
The Student Record
The person or student record stands at the heart of the Slate system. Many administrative processes will be carried out from the student record. Familiarity with the the student record also provides a straightforward introduction to Slate's standard fields.
To manage any data not available among the Slate standard fields, create custom fields.
There are four types of custom fields:
- Fields that store free-text values
- Fields that store a single value from a prompt list
- Fields that store multiple values from a prompt list
- Fields that store a yes or no value
Custom fields have a scope that determines the relationship between the data it stores and the types of records in your database.
For example, giving a custom field a scope of Person tells the database it can treat data stored in the field as if it was stored on the person record.
- Enroll in the Fundamentals of Admission and Enrollment course in Learning Lab to get hands-on experience creating custom fields.
- Create two custom, person-scoped fields: Academic Interest and Anticipated Entry Term.
- Scope (article under construction)
- Fields and Prompts
Forms are used to affect change throughout your Slate database. They can create or update records one at a time, and they can collect data using both standard and custom fields. The scope of the form determines which records are created or updated.
An example of a form is an inquiry or request for information (RFI) form. To save the captured form data on a person record, this form would be scoped to person. To prevent duplicate records from being created if the same person fills out the form twice, Slate will evaluate matching criteria between the form submission and existing person data.
- Create an inquiry form. You can find a sample in the Slate Showcase environment.
The query builder is the most important tool in Slate. Among others processes, queries are involved in:
- Batch managing records
- Scheduling data exports
- Defining audience lists for communications
- Assigning populations to be affected by automations
- Releasing decisions
- Review the query section of Fundamentals of Admissions and Enrollment in Learning Lab.
Customizing the Person Record
The person record is highly customizable. At this early stage in your implementation, you'll start to become familiar with the options and functionality of the student record; you don't need to finalize the configuration until you have more experience working in Slate.
- Explore an example of a highly customized person record in Slate Showcase.
- Add important view-only data to the Dashboard
- Add custom data that may need to be updated to a custom Tab
- Create a sample custom Interaction
- Create a sample custom Tag
- Customize standard Tabs
Create automated, data-informed operations using rules. Most processes in Slate leverage the power of rules in some way. Because rules have the ability to impact thousands of records at a time, it is important to test your rules thoroughly.
- Person Status
Your database comes by default with rules that set the person status (prospect, inquiry, or applicant) on all person records. Examples of other types of rules can be found in Slate Showcase.
- Staff Assignment
Most schools begin by creating a set of staff assignment rules. A staff assignment rule uses data on a student record to automatically associate it with a staff user record. Once a staff or program contact has been associated with a student record, this information can be shared with the student in an email.
Staff Assignment Rules are established using an exclusivity group. An exclusivity group allows you to filter against the record as if you were executing multiple different queries at the same time, then prioritize exactly which action should be taken.
Advanced Data Structures
Taking advantage of advanced data structures in Slate like translation codes, entities, and custom datasets lets you broaden and deepen the contents of your database. Before diving into these tools, create custom fields and get a feel for managing record data.
- Datasets allow you to manage other primary records in your process just as you manage person records. Datasets for Organizations and Organization Contacts are already available in your admissions database.
- Translation Codes transform or combine data values.
- Entities create custom scopes.
Stage 2: Outreach
With Deliver, you can:
- Create email, SMS, print, and voice communications
- Personalize messages with merge fields and Content Blocks
- Use liquid markup to display content conditionally in messages
- Create drip marketing campaigns using populations, and much more
When you first create a communication plan in Slate, focus on your essential communications.
If your goal is to be up and running in Slate as quickly as possible, don't try and duplicate the marketing plan you've spent years developing. Slate is going to change how you conduct business, so your marketing plan is likely to evolve as well.
Can we do comms first?
It's difficult to manage records in two systems at once. If you want to communicate with prospects or new inquiries immediately using Slate, you will want to complete your communication plan and build out any other necessary functionality in Slate before publishing your inquiry form or redirecting ongoing feeds like search lists to create new records in Slate. Your communication plan will include both Deliver-based and form-based messages.
Events let you schedule both in person and online events, invite attendees, and send automated event-related emails.
Can we do events first?
It's difficult to manage records in two systems at once. If you want to invite prospects or new inquiries to an event, establish events in Slate before publishing your Inquiry Form or redirecting ongoing feeds like search lists to create new records in Slate.
Interviews and Appointments
Manage one-on-one interviews in Slate using Scheduler. With Active Scheduler, you can use a portal to offer timeslots for specific appointments based on a schedule you define.
Can we do interviews first?
It's difficult to manage records in two systems at once. If you want to invite prospects or new inquiries to an interview, you will want to establish interviews in Slate before publishing your Inquiry Form or redirecting ongoing feeds like search lists to create new records in Slate.
Stage 3: Migrating Records from Your Pre-Slate System
Slate processes all incoming data through the Upload Dataset tool. Ad hoc files can be imported using the New Spreadsheet/Data File file format.
Importing Person Records
Once essential communications and other operations are built and tested, bring in active inquiries from your pre-Slate system using Upload Dataset. To prepare, build and test the import templates thoroughly.
It is not necessary to clean up and de-dupe records in your legacy system before bringing them into Slate. However, duplicate ID records should be avoided at all costs. Record identifiers (such as a prospect or SIS ID) are used for matching records on import. Manage duplicate person records in Slate using Consolidate Records.
Importing Application Records
Complete existing applications in your legacy system, then collect new applications in Slate once you've built and tested the application process in Slate (see Stage 4 below).
To communicate with active applicants who have applied using another system or import unsubmitted applications to Slate for completion, you must first establish a Period and Round schema and create necessary application-scoped fields in Slate (see Stage 4 below).
We recommend waiting to bring in historical applications for reporting until after you have completed your implementation.
Stage 4: Application and Reader Processes
The application and reader processes builds on data, forms and rules.
Collecting Application Data
Whether you'll be using a Slate-hosted application, or importing applications from an external source, you will configure periods and rounds for your application data. Applications can collect both person- and application-scoped data.
The standard Slate-hosted application lets you to stand up an application very quickly, and additional customization is possible if you have the time. Application pages can be built using forms.
Slate features a standard applicant status portal. Use the Suitcase tool to quickly import and try out a custom applicant status portal from the Slate Showcase environment.
- Create a period and round structure
- Period and Round Structure
- Scope (article under construction)
- Building an application in Slate
- Importing Applications
- Slate Showcase
Collecting Application Materials
Enforce material submission before application submission using hard fails created in the application logic tool.
Collect materials after application submission using the checklist on the applicant status portal. To take advantage of the Slate checklist for current applications collected in another system, import school-scoped materials.
Recommendations submitted directly to Slate are fulfilled by a form submission. Imported recommendations can be managed using a PDF Material.
- Require Materials
- Getting Started with Checklists
- School-Scoped Materials
- Slate-hosted Recommendations
System emails are pre-built, automated application-related communications triggered by transactional activities such as application creation and application submission. Establish additional communications in Deliver as necessary.
Application Review Processes
Manage your application and material review processes the Reader. Reader review processes are built with Workflows.
Workflows let you manage all the different aspects of any review process in one place. To begin, concentrate on core concepts and functionality and develop one effective review process. Once you are familiar with the underlying structure and navigational tools of the Reader and Workflows, you can move on to more complex, program specific processes.
Demonstrating a single, effective reader process can also help overcome faculty reluctance to reading in a new system.
We strongly recommend releasing decisions within Slate using its tested and effective decision release tools.
The Slate decision process consists of three stages: preparation, automation, and release. Following the application review process, applicants are notified of a status update through a secure portal, where they view decision information in a controlled, password-protected environment.
Do not send Decisions via email.
Stage 5: Database Management
Slate Captains review and establish several important database settings using Configuration Keys. For example, DKIM (DomainKeys Identified Mail) configuration ensures communications from Slate are as deliverable as possible, communicating to email servers that emails originate from your school and not from a spammer.
Users and Permissions
User accounts and permissions determine who has access to Slate and what they can do with it.
Only users with the Security Administrator permission can add new users, deactivate existing users, and manage other users' access.
Tip: Trust your users!
Establishing overly restrictive permissions at the outset may impede new operations and frustrate new users. Additional restrictions can be added when they prove necessary.
Population permissions determine which records are accessible to each user. Schools managing a shared graduate-undergraduate database can restrict users to only the graduate or undergraduate populations, or to specific programs within a graduate population.
Realms determine which Slate features are accessible to each user.
Stage 6: Integrations
Sending Data to your SIS and Other Exports
Build and manage data extracts using queries. Establish the file type and export frequency using the query-schedule export palette. Combine or transform data to meet the requirements of any system using subquery exports.
Only begin work on your SIS export once you have finalized your custom data structure in Slate and have sample records with the appropriate data in place.
Technolutions recommends exporting flat files via SFTP to external systems. Flat files such as CSV or Tab Delimited can generally be managed by admissions operations staff.
Managing Ongoing Imports with a Source Format
Slate processes all incoming data through the Upload Dataset tool. Regular and ongoing imports can be brought in using standard or custom source formats, which appear under File Format-Predefined Formats in Sources/Upload Dataset.
Standard Source Formats
Slate has standard Source Formats which are pre-built import templates for many common files such as the Common App, GradCAS, SAT and GRE. The complete list of standard source formats can be found in the Source Format Library.
Custom Source Formats
If a standard source format does not exist, a custom source format can be created.
While Technolutions encourages the use of flat file integrations automated using SFTP, Slate also supports web service integrations.
Managing Duplicate Records
Once records are being created in your Slate system by forms or through an incoming data feed, you'll end up wtih some duplicate records. Manage them using the Consolidate Records tool. Familiarize yourself with this functionality before go-live and establish staff protocol for maintenance.
Stage 7: Reporting
Create reports in Slate to display aggregate data using Queries / Reports. A sample funnel report can be Suitcased into your database from Showcase and then customized to fit your institutional requirements.
Next up:Phase III: Implementation