Data Architecture
Evaluate where information should live in Slate, distinguish between common storage approaches, identify the record that should own a piece of data, recognize the importance of source of truth and repeatability, and assess downstream impacts before creating new fields or structures.
Good Slate architecture starts by deciding what the information represents, who or what it belongs to, and how it will be used before choosing where to store it.
Data Architecture: Where Should This Information Live?
One of the most common requests a Slate Admin receives sounds simple: “Can you add a field for this?”
Sometimes a field is exactly the right answer. Sometimes it isn't.
The job of the Admin is not simply to create the requested configuration. The job is to understand the information first.
Before deciding where something should live, ask: What does this information represent? Who or what does it belong to? Can there be one value or many? Where does the information originate? Who is responsible for maintaining it? How long should it remain valid? How will other parts of Slate use it? Does similar information already exist? What happens downstream if the value changes?
These questions help prevent a Slate environment from becoming a collection of disconnected fields created one request at a time.
Information → Owner → Structure → Use
What does this value represent?
Who or what does it belong to?
How should it be structured?
Who will use it?
What depends on it?
Data architecture is the practice of giving information the right home. When information has a clear owner and structure, everything built on top of it becomes easier to maintain.
Design the Data Before You Build the Field. The moment someone asks for a new field, pause. The real request may be: we need to collect something, report something, maintain a reusable list, track something over time, or connect one record to another. Those needs may require different architectural solutions.
Remember these
The record or structure that logically owns a piece of information.
The authoritative place a value should be maintained.
Information where one current value belongs to the record.
Information that may occur more than once and may require multiple related records or entries.
Information organized consistently so it can be reused reliably.
A process, report, communication, integration, or automation that relies on the data.
Not Everything Should Be a Field
Use when a defined piece of information belongs to a record and should be stored as a value. Example: Preferred Name.
Use when your institution needs to maintain a reusable structured collection of records. Example: Academic Programs.
Use when the same type of information may occur multiple times and each occurrence needs its own context. Example: multiple interactions, records, or related entries depending on institutional design.
Use when the information belongs to a particular application, enrollment, or process rather than permanently to the Person record. Example: program choice for a specific application.
Use when the submitted response itself has value as part of an interaction or process, even if some values also update other fields.
Choose the structure based on the meaning of the data—not the easiest place to put it.
Person-Level vs. Process-Level Information
Does this describe the person generally?
- One current value that stays true across processes
- Example: Preferred Name
- Stored permanently on the Person record
Does this describe this particular process?
- A value that belongs to one application, enrollment, or interaction
- Example: Fall 2027 — Nursing, then Spring 2028 — Radiologic Technology
- Stored with the application or related process record
Should “Program” always live as one permanent value on the Person record? Maybe not. If the value belongs to a specific application or process, storing only one person-level value could overwrite important history or create ambiguity. Context determines ownership.
Check your understanding
One question at a time. Wrong answers are just practice.
Leadership says: “We need to track each student's application program.” What should the Admin ask first?
Trace a Piece of Data
Understand where one important value lives, where it comes from, and what depends on it.
Open your institution's Slate environment in another tab. Choose one piece of information you understand well — for example Academic Interest, Preferred Campus, Student Type, Residency Status, Application Program, Enrollment Term, or Counselor Assignment. Do not change anything. Trace the value through the system.
- What does the value represent?
- Which record owns it?
- Is it single-value or repeatable?
- Where does it originate?
- Who or what updates it?
- Where is it displayed?
- Which queries, forms, rules, communications, portals, or integrations may rely on it?
- What might happen if the value were changed?
Can you explain the architecture? Use this template (no institution-specific configuration details needed here).
__________ is stored on __________ because __________. It originates from __________ and is used by __________.
Preferred Campus is stored on the Person record because it represents the student's current campus preference. It originates from an interest form and is used by communications and counselor assignment logic.
Institutions make different architectural decisions based on their processes, integrations, and data models. Focus on understanding why information lives where it does and what depends on it.
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
You discover a field is used by a form, three Queries, a Rule, and a Portal. What should that tell you before modifying the field?
“Can You Add a Field?”
A department asks: “Can you add a field called Preferred Campus?” What is the best first response?
What is the best first response?
One Value or Many?
Your institution wants to track every campus a student has expressed interest in over time. Would one single-value Person field necessarily preserve that history?
Would one single-value Person field necessarily preserve that history?
Where Does This Belong?
A student can select a different academic program on each application they submit. Where should the Admin first consider whether that information belongs?
Where should the Admin first consider whether that information belongs?
Two Systems, One Value
Slate and the SIS both store an official student ID. Before changing how the value is maintained, what should the Admin determine?
What should the Admin determine?
It Already Exists
A department asks for a new field. You discover that almost identical information already exists elsewhere in Slate. What is the best Admin response?
What is the best Admin response?
Think Like a Slate Admin
What does this data represent?
Who or what owns it?
Can it repeat?
Where does it come from?
Who uses it?
What depends on it?
What is the simplest sustainable structure?
When someone asks “Where should I put this?” don't start with the configuration menu. Start with the meaning of the information.
Understand the Impact Before You Make the Change. A small data change can affect forms that collect the value, queries that filter on it, Deliver communications that personalize with it, rules that act on it, portals that display it, integrations that import or export it, and reports that rely on it.
Watch for these architecture traps: duplicate sources of truth (two fields represent the same concept but contain different values); everything on the Person record (process-specific information stored permanently at the person level without context); giant text fields (structured information stored in free text, making it difficult to query or reuse); no history (a current-value field overwrites information the institution actually needed to preserve); build first, ask later (configuration created before anyone understands how the information will be used).
Good architecture reduces ambiguity. The goal isn't to build the most complicated data model. It's to create the simplest structure that accurately represents the information and supports the process.
Before changing the architecture, trace the dependencies.
Put It Together
The Slate Admin pathway now builds: GOVERN → DESIGN. Users & Permissions determines who should be able to see and do what. Data Architecture determines where information should live and how it should relate.
Governance decides who can reach the system.
The work happens against institutional information.
Who can access it, where it lives, what owns it, how it is structured, and what depends on it.
Administration is already becoming systems thinking.
You're not just managing users or creating fields. You're defining how people interact with institutional information.
Before You Build the Data
The Admin change framework, applied to data architecture.
What information are we trying to store?
Does this information already exist?
Which record or system should own it?
Is it single-value, repeatable, process-specific, or a reusable collection?
Who needs it and what processes depend on it?
Will the structure support the intended use without creating unintended consequences?
Why was this architecture chosen?
Your Slate may look different: institutions make different architectural decisions based on their processes, integrations, and data models. Focus on understanding why information lives where it does and what depends on it.
Once the Data Has a Home, How Does the Process Move?
Good data architecture gives information a reliable place to live. But institutional work is rarely static.
Information arrives. Conditions change. Records need to move through steps. People need to take action.
That's where Workflows come in. The next Admin question is: How should this process move?
Keep Learning
Records
Review the records that can own institutional information.
Fields
Review how information is stored as values on a record.
Datasets
Review reusable, structured collections of records.
Workflows
Learn how data and actions move through a process.
Integrations & Data Movement
Learn how values enter and leave Slate.
Rules & Automation
Learn how Slate can act on stored information.
Portals
Learn how structured data supports user experiences.
Finished the lesson?
Mark it complete to track your progress. Progress is saved in this browser.
Workflows
Learn how to translate a real-world process into a structured workflow in Slate.