Initial build planning starts with a clear inventory of the data, processes, and record architecture that Student Success teams need in Slate. Before importing legacy data or recreating existing workflows, review what your team uses today, what already exists in a shared Slate database, and what should be built in Slate for future use.
This article outlines the main planning stages for a Student Success implementation. Use it to identify the decisions that should be made before building fields, importing records, creating record displays, or testing import mappings.
Stage 1: Audit data and processes
Start by reviewing the data and processes currently used by your office. If your institution shares a Slate database with Admissions or another office, coordinate with those teams before creating new fields, prompts, forms, interactions, or other objects. Existing Slate objects may already support part of the Student Success process, and duplicating them can create reporting and maintenance issues later.
📖 Stage 1: Initial Data and Process Considerations
Questions to ask about data
When reviewing stored data points, ask stakeholders these questions:
Is this data point accurate?
Where is the data created, such as the SIS, LMS, or another system?
Is this data necessary for current work, reporting, or decision-making?
Who uses this information, and how do they use it?
Can this value change, or is it historical?
Questions to ask about processes
After reviewing data, document the purpose of each process that might move into Slate:
Why does the office collect this information?
What should this form, event, report, or communication help the office accomplish?
How should students interact with the office in the ideal process?
Which outcomes matter most, and what information is required to support those outcomes?
Translate legacy elements into Slate
After the audit, list the legacy elements that need a Slate destination. Depending on how each element is used, it might become a single-value field, multi-value field, interaction, entity, standard field, dashboard element, form, or other Slate object.
Discuss these decisions with your Technolutions team before building at scale. The goal is to choose destinations that support current work while leaving room for future reporting, integrations, and process changes.
Stage 2: Import core data
Before the Student Success office becomes operational in Slate, the relevant person records should be populated with core data from the legacy system, SIS, or another Slate database. Currently enrolled students may already exist in a shared Slate database because they moved through an Admissions process before enrolling. Coordinate with the Admissions team before importing records or creating duplicate destinations.
Use the Upload Dataset tool to import records. For a full walkthrough of the core person import process, see Importing Current Person Data.
The first import should focus on core data elements, such as:
Unique field, such as Colleague ID, EMPLID, Banner ID, or another institutional identifier.
Name.
Date of birth.
Email.
Address.
Phone.
This first upload establishes the person record in Slate. If you include a unique field configured for matching, later imports can use that value to update the existing record rather than creating duplicates.
📖 Stage 2: Populate Student Success Core Data
Stage 3: Build record and process architecture
After the initial import, build the record structure and process objects that users need for daily work. Record architecture determines where information appears on a record and how users interact with that information. Process architecture determines how users collect information, communicate, and complete recurring work.
Design records
Use record design to decide which information should appear directly on the person record and which information should remain available through queries, reports, or related objects.
Custom tabs can display custom fields and forms on person or dataset records. Permissions can determine which users can read or update tab content.
Tags and watch flags can make high-priority record information visible to staff. For example, a homesick watch flag can prompt an advisor to follow up with a student.
Entities can capture repeated or grouped information, such as advising notes, scholarships, involvements, or class schedule details.
Dashboards can summarize important record information in one place. Although the linked dashboard overview uses Advancement examples, the same dashboard concepts apply to record summaries across Slate.
Standard tabs continue to display standard record elements, such as interactions, contact information, education history, jobs, and materials.
Design process objects
After record architecture is in place, identify the objects that support recurring Student Success work:
Event and Scheduler templates for repeatable student meetings, appointments, or programs.
Event, form, and mailing communications that should be created before the office starts using the process.
Deliver templates for consistent message structure and branding.
Forms that students or staff submit regularly.
📖 Stage 3: Build Record and Process Architecture
Stage 4: Import secondary data
After core data and record architecture are in place, import additional data that supports Student Success work. Secondary data can be mapped to the custom fields, entities, or other objects created during the earlier stages.
Include the same unique identifier used during the core data import so the secondary data can match to existing records. A secondary data file might include columns like these:
Unique ID | Residence hall | Advisor | Class standing | First-year GPA | Total credits |
|---|---|---|---|---|---|
| Roosevelt Commons | Matt Burris | Sophomore | 3.23 | 30 |
📖 Stage 4: Populate Secondary Data
Test import mappings before running in production
Test secondary imports before running them against production records. Use this process to confirm that mapped values land in the expected destinations:
Upload the file in production.
Map the file columns to the appropriate Slate destinations, including field value mappings and static mappings.
Do not run the import in production.
Refresh the test environment.
Run the import in test.
Review the imported data and confirm that it appears as expected.
If changes are needed, update the mappings in production, refresh test, and run the import in test again.
Repeat the process until the data imports correctly in test.
Run the import in production only after the test results are correct.
Testing imports this way reduces the risk of creating duplicate records, overwriting data, or storing values in the wrong destination.