- 09 Apr 2024
- 2 minute read
- Print
- DarkLight
- PDF
Student Success Implementation Strategies
- Updated 09 Apr 2024
- 2 minute read
- Print
- DarkLight
- PDF
Slate's clean, functional design ensures that users do not need technical expertise to maximize its powerful capabilities. The intuitive interface and straightforward systems simplify training needs and empower users to stand up their business processes quickly. It is helpful to understand a few important elements of the Slate implementation process before attending the Fundamentals of Slate training.
Best PracticesThe best way to learn about Slate is to use it. Users may provision a test environment to try out tools and build and test processes with actual data in a playground. While it may feel daunting to “go live” before every part of the admissions process is built, we recommend using certain tools in your production environment when initial work on a particular Roadmap box is completed.
The sooner staff access and use the Slate administrator interface, the sooner their comfort level with Slate will grow!
Time Commitment
The time required to implement Slate depends on the project timeframe and the resources you allocate throughout the implementation. In general, the more aggressive the timeframe, the more time Slate Captains need to devote to Slate.
Slate is process-built, allowing individual institutions to customize every step of their operations. Proper time allocation is necessary and the best way to gain knowledge of the system fundamentals. By devoting the necessary time to implementation, you ensure the success of your project.
Make a commitment to building a strong knowledge of all basic functionality in your first year. Focusing on Slate tools allows Slate Captains to move through the implementation as efficiently as possible. Many institutions start an implementation thinking that their multi-step process must be replicated precisely in Slate. However, as Captains learn more about the Slate tools, they often realize that those historical processes may be translated into Slate more simply.
When to "Go Live"
One notable difference between Slate and other systems is that Slate does not typically have one systemwide “go live” date. Slate is designed to “go live” gradually as tasks on the Slate Roadmap are accomplished. For example, when communications and person records are set, these may “go live” before the event management and appointment scheduling process is ready to launch.
A sample Slate “go live” schedule may look like this:
Tool / Process | "Go Live" Date |
---|---|
Fields and Prompts | January 1 |
Entities, Forms, Tabs | January 15 |
Rules/Automations | February 1 |
User Permissions | February 15 |
Upload Dataset | March 1 |
Event Management | March 15 |
Deliver Communications | April 1 |
Case Management Structure | April 15 |
Reader, Checklists, Materials | May 1 |
Portals | May 15 |
Data Integration | June 1 |
Test Environments
While Slate offers a fully-featured test environment, developing all business processes in the production database is best practice. Furthermore, adjusting and managing data and procedures in the production database is relatively easy and safe. Rest assured that these processes will not be available to the general public until they are ready.