Integrations & Data Movement
Explain how data enters and leaves Slate, identify source and destination systems, distinguish between source, format, matching, mapping, and processing, trace an existing data flow, recognize the importance of source of truth and ownership, and identify common integration failure points.
Reliable integrations depend on understanding the full path of the data: where it comes from, how Slate interprets it, what record it belongs to, where it goes, and which system owns the authoritative value.
Integrations & Data Movement: Where Is the Data Coming From and Where Is It Going?
Slate rarely operates alone. Data may enter from application services, state systems, testing agencies, inquiry vendors, student information systems, financial aid systems, file uploads, APIs, and internal institutional systems.
And data may leave Slate for the SIS, reporting systems, data warehouses, external vendors, communication platforms, and other institutional processes.
For a Slate Admin, the important question is not simply “How do I get this file into Slate?” The larger question is “What is the full path of this data?”
Before building or changing an integration, understand: where the data originates, which system owns the authoritative value, what format the data arrives in, how Slate identifies the correct record, how incoming values map to Slate fields or structures, what happens after import, where the information goes next, how errors are detected, and who owns the integration when something goes wrong.
Source → Format → Match → Map → Import → Process
Where did the data originate?
How is the data structured when it arrives?
Which Slate record does it belong to?
Where should each incoming value go?
Bring the information into Slate.
What happens because the data is now here?
Outbound is the same thinking in reverse: Slate → Export → Destination.
Data movement is a chain. If one link is misunderstood, the information can end up on the wrong record, in the wrong field, at the wrong time, or in the wrong system.
Core principle: Know the Source. Know the Destination. Know Who Owns the Data. Before changing an integration, be able to answer: Where does this value originate? Which system is authoritative? How does Slate receive or send it? Which records are affected? What happens downstream? Who is responsible if the data fails to move?
Remember these
The system, file, or process where the data originates.
The system or process receiving the data.
The structure and instructions Slate uses to interpret incoming data.
The logic used to determine which Slate record incoming data belongs to.
The relationship between incoming values and Slate fields or structures.
The process of bringing external data into Slate.
The process of sending Slate data elsewhere.
The system responsible for maintaining the authoritative version of a value.
Before You Map It, Match It
Matching determines which Slate record receives the information — understand what identifying information is being used.
What should happen? A new record, an error, or a review queue?
Which record wins, and who reviews the ambiguity?
Email addresses and names change — does matching still hold?
Incoming data can land on the wrong copy of the same person.
GOOD DATA + WRONG RECORD = BAD DATA. Importing accurate data to the wrong record is still inaccurate.
Moving Data vs. Owning Data
“Can Slate receive or send this value?”
- Technical: is there a file, feed, or API?
- Answered by format, matching, and mapping
- Success looks like “the data arrived”
“Which system should be responsible for maintaining this value?”
- Organizational: who owns the authoritative version?
- Answered by source of truth and direction of movement
- Success looks like “the systems agree”
Just because Slate can store a value does not mean Slate should own the value. An official student ID may exist in both Slate and the SIS, but one system should usually be understood as the authoritative source. Otherwise, two systems may attempt to maintain competing versions of the same information.
Check your understanding
One question at a time. Wrong answers are just practice.
What should a Slate Admin identify first when evaluating an inbound integration?
Trace an Existing Data Flow
Follow one piece of information from its source through Slate and into any downstream process.
Open your institution's Slate environment in another tab. Choose one integration, import, Source Format, or data flow you are permitted to review and already understand at least partially. Do not change anything. Trace the movement.
- Identify the source system or file
- Identify what data is being sent
- Identify how often or when the data arrives
- Identify how records are matched
- Identify where key values are mapped
- Identify what happens after import
- Identify whether data later leaves Slate
- Identify the destination if applicable
- Identify the source of truth
- Identify who owns or supports the integration
Can you explain the data flow in plain language? Use this template — no institution-specific configuration details needed.
“Data originates in __________. It enters Slate through __________. Records are matched using __________. The values are stored in __________. The information is then used by __________ and/or sent to __________.”
Integration methods, Source Formats, APIs, files, schedules, matching logic, ownership, and downstream systems vary by institution. Focus on understanding the data path rather than reproducing an identical setup.
Slate is highly customizable. Your institution's tabs, fields, views, permissions, and processes may differ from examples used throughout Insider's Aid. Focus on understanding the concept rather than finding an identical screen.
Reflection
An import file contains the correct program code, but the mapping sends that value into the wrong Slate field. Where is the problem?
“Can We Import This File?”
A department sends you a spreadsheet and says: “Can you load this into Slate?” What is the best first Admin response?
What is the best first Admin response?
Right Data, Wrong Person
An import successfully loads hundreds of records, but some values were matched to the wrong students. What is the most important lesson?
What is the most important lesson?
Two Systems Are Updating the Same Value
Slate and the SIS both update a student's official program value. Sometimes the systems disagree. What should the Admin determine?
What should the Admin determine?
The File Arrived, But Nothing Happened
A nightly file appears to have arrived successfully, but records in Slate did not update. What should the Admin investigate?
What should the Admin investigate?
What Happens Downstream?
You are asked to change the mapping of a program code coming into Slate. Before making the change, what should you understand?
What should you understand first?
Trace the Data
A testing agency sends a nightly file containing Student Email, Birthdate, Test Score, and Test Date. Slate should find the correct student, add the score, allow counselors to see the result, use the score in a query, and send selected data to the SIS later. Identify the source, matching, mapping, uses, and destination.
Which description traces the flow correctly?
Think Like a Slate Admin
Where does the data start?
Who owns it?
How does Slate identify the record?
Where is the data mapped?
What happens after import?
Does the data leave Slate again?
Who knows if the flow breaks?
When someone says “The integration is broken,” don't start with the import screen. Start with the data path.
Understand the Impact Before You Make the Change. Integration changes can affect record matching, field values, applications, queries, communications, rules, portals, reports, SIS records, downstream systems, and historical data. Before changing a Source Format, mapping, export, or integration process, understand the full chain.
Watch for these integration traps: no source of truth (multiple systems can overwrite the same value without clear ownership); matching as an afterthought (the file is mapped carefully, but record identity is not); duplicate data structures (new fields are created for imported data even though reliable equivalents already exist); success = no error message (an import is considered successful simply because it completed); no downstream review (changes are made without checking what uses the value afterward); no owner (no person or team knows who supports the integration when it fails); mystery schedules (data moves on a schedule no one clearly understands or documents).
Reliable integrations are understandable integrations. Someone should be able to explain where the data comes from, how it moves, and what depends on it.
Know the source. Know the destination. Know who owns the data.
Put It Together
The Slate Admin pathway now builds: GOVERN → DESIGN → AUTOMATE → EXPERIENCE → CONNECT. Users & Permissions determines who can access the system. Data Architecture determines where information belongs. Workflows determine how processes move. Portals determine what users see and do. Integrations & Data Movement determines how information enters, leaves, and connects Slate to the larger institutional ecosystem.
…send data that…
…where Slate structures it…
…and users experience it…
…for the SIS, reporting, and other systems.
Slate administration isn't limited to Slate.
A good Admin understands where Slate sits within the larger institutional system.
Before You Build the Integration
The Admin change framework, applied to data movement.
What data needs to move?
Where does it originate?
Which system is authoritative?
How will Slate identify the correct record?
Where should each value live?
What should happen after the data arrives?
Does the data need to move somewhere else?
Can representative records move through the entire flow correctly?
Did the right values reach the right records and systems?
Who owns the integration and how does the data move?
Write the data path in plain language before opening a Source Format: source, owner, matching keys, mapped values, what happens next, and where the data goes afterward.
Then test with representative records — including the ones that will not match cleanly.
Once the Data Is Here, What Should Slate Do With It?
Integrations bring information into Slate. Data architecture gives it a home. Workflows move records through processes. But sometimes Slate needs to evaluate information and take action automatically.
- What should Slate do automatically?
- Under what conditions?
- What happens when the conditions change?
That's where Rules & Automation comes in.
Keep Learning
Data Architecture
Review where imported values should live.
Rules & Automation
Learn how imported data may trigger automated actions.
Workflows
Review how incoming data may start or influence a process.
System Health & Troubleshooting
Learn how to trace a broken data flow.
Finished the lesson?
Mark it complete to track your progress. Progress is saved in this browser.
Rules & Automation
Learn how to use automation intentionally and understand the consequences of automated actions.