System Health & Troubleshooting
Apply a repeatable troubleshooting framework, distinguish symptoms from root causes, trace problems from the affected record through data and process dependencies, test safely, verify fixes, and document what changed.
Good troubleshooting starts with expected behavior, follows the data and process path, tests one hypothesis at a time, and verifies the result before declaring the problem solved.
System Health & Troubleshooting: Where Did the Expected Path Break?
Eventually every Slate Admin hears some version of: “Slate isn't working.” But that isn't a diagnosis. It is a symptom.
A student says their Portal is wrong. A counselor cannot see something. A Rule did not appear to run. A Workflow stopped moving. An import completed but data did not update. A communication went to the wrong audience. A checklist item is still missing.
The Admin's job is not to guess. The Admin's job is to trace.
Start with one question: What should have happened? Then compare that expectation with what actually happened. From there, trace the record, the data, the trigger, the process, and the dependencies until you find where the expected path broke.
Expected → Actual → Trace → Test → Verify → Document
What should have happened?
What happened instead?
Where did the path differ?
Can the issue be reproduced safely?
Did the fix resolve the issue without creating another one?
What changed and why?
Troubleshooting is not random clicking. It is structured comparison.
Core principle: Diagnose Before You Change. Changing configuration before understanding the problem can hide the real cause, create a new problem, make the issue harder to reproduce, affect unrelated records, and introduce new dependencies.
When possible, observe and trace before modifying production behavior.
Remember these
What the system should do when the process works correctly.
What happened instead.
The underlying reason the problem occurred.
Another piece of data, logic, process, or system that influences the behavior.
A problem that can be observed consistently under known conditions.
A safe test using known records or conditions to validate a hypothesis.
Confirming that the fix worked and did not create unintended effects.
Recording what happened, what changed, and why.
The Troubleshooting Framework
Define expected behavior in plain language before touching anything.
Describe the observed result for one concrete record.
Identify the specific record and the values that matter.
Name the Rule, Workflow, import, form, or permission responsible.
Move forward through the path until expected behavior stops.
Reproduce the issue safely with a known record or condition.
Confirm expected behavior returns across representative cases.
Record what was wrong, what changed, and why.
This framework should work across Rules, Workflows, Portals, permissions, imports, checklists, queries, and other Slate processes.
Symptom vs. Root Cause
“The student sees the wrong checklist.”
- Visible to the user
- Where the report starts
- Often downstream of the real problem
“Which upstream condition produced that result?”
- Wrong field value
- Rule did not evaluate
- Material did not match
- Checklist logic is incorrect
- Portal visibility is wrong
- Integration data is stale
- User is on the wrong record
The visible problem is often downstream from the real problem. A strong Admin learns to trace backward.
Check your understanding
One question at a time. Wrong answers are just practice.
A user says “Slate isn't working.” What should the Admin ask first?
Trace a Known Issue
Use the troubleshooting framework on a real or previously resolved Slate issue.
Open your institution's Slate environment in another tab. Choose a low-risk issue you understand or a previously resolved issue you can review. Do not make production changes for this activity. Trace the issue using the framework.
- What should have happened?
- What actually happened?
- Which record or records were affected?
- Which field values or data mattered?
- What process should have acted?
- What Rules, Workflows, permissions, integrations, or Portal logic were involved?
- Where did the expected path break?
- How could the issue be tested safely?
- How would you verify the fix?
Can you summarize the issue without saying “Slate broke”? Use this template — no institution-specific record details needed.
“Expected: __________. Actual: __________. The issue appears to occur at __________ because __________.”
Troubleshooting tools, permissions, logging, processes, and available diagnostics vary by institution. Focus on tracing expected behavior through the system rather than matching a specific screen.
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
A student Portal is showing the wrong campus. You discover the Portal condition is correct, but the Preferred Campus field contains the wrong value. Where is the root cause most likely?
“Slate Is Broken”
A staff member says: “Slate isn't working. The student didn't get the checklist.” What is the best first Admin response?
What is the best first Admin response?
Compare a Good Record
One student processed correctly. Another similar student did not. What is a useful next step?
What is a useful next step?
Don't Change Three Things at Once
You suspect a Rule criterion, a field value, and a Workflow step may all be involved. What is the strongest troubleshooting approach?
What is the strongest troubleshooting approach?
It Worked Once
You change a configuration and one test record behaves correctly. Are you finished?
Are you finished?
The Import Completed Successfully
An import shows as completed, but some records did not update. What should the Admin investigate?
What should the Admin investigate?
The Fix Created Another Problem
You update a field to solve a Portal issue, but a communication Query now targets the wrong audience. What does this demonstrate?
What does this demonstrate?
Trace the Failure
A student submits an enrollment form. Expected: the form updates Intent to Enroll = Yes, a Rule assigns an enrollment checklist, the Portal displays the checklist, and a nightly export sends the status to the SIS. Actual: the form was submitted, but the Portal does not show the checklist and the SIS does not receive the status. What is the best investigation order?
Which investigation sequence is strongest?
Think Like the Person Responsible for Slate
A department asks for a new automated process: “When this file comes in, update the student, assign a checklist, show the checklist in the Portal, and send the data to the SIS.” Before building, what should the Admin think through?
Which set of questions maps correctly to the Admin pathway stages?
Think Like a Slate Admin
What should have happened?
What actually happened?
What is different about the affected record?
What data or process should have created the expected result?
Where did the path break?
What is the smallest safe test?
Did the fix work?
What else could the fix affect?
Troubleshooting is systems thinking in reverse. Instead of designing the path forward, you trace backward from the unexpected result.
Understand the Impact Before You Make the Change. A troubleshooting change can affect more records than the one reported, existing Rules, workflow movement, portal content, checklist status, queries, communications, integrations, and reporting. Before making a fix, understand whether you're changing the root cause or simply masking the symptom.
Watch for these troubleshooting traps: random clicking (changing settings without a hypothesis); fixing the symptom (adjusting the visible result without correcting the underlying cause); changing too many variables (multiple edits make it impossible to identify the true cause); testing only one perfect case (the fix works on one record but fails on other realistic cases); assuming user error (the report is dismissed before the process is traced); assuming system error (Slate is blamed before the data and configuration are checked); no documentation (the issue is fixed, but no one records what happened); no post-fix review (the original issue is solved but downstream effects are never checked).
System Health Is More Than Fixing Problems. A healthy Slate environment is one where the Admin can explain what the important processes are, who owns them, what data they depend on, how records move through them, how integrations feed them, what automation affects them, what the user experiences, and how the team knows when something fails. DOCUMENTED + UNDERSTOOD + TESTABLE = MAINTAINABLE.
System health is not the absence of problems. It is the ability to understand and recover when problems occur.
Diagnose before you change. Strong troubleshooting creates understanding, not just temporary relief.
Put It Together
The complete Slate Admin pathway is now: GOVERN → DESIGN → AUTOMATE → EXPERIENCE → CONNECT → CONTROL → MONITOR. Users & Permissions determines who should be able to see and do what. Data Architecture determines where information should live. Workflows determine how processes move. Portals determine what users see and do. Integrations & Data Movement determines how data moves between systems. Rules & Automation determines when Slate should act automatically. System Health & Troubleshooting determines whether the system is behaving as intended—and how to find the break when it isn't.
Who can access and affect the system?
Where does information live?
How do records move?
What do users see and do?
How does data enter and leave?
What happens without human action?
How do we know it's working?
This is the shift from using Slate to stewarding Slate.
You are responsible for understanding how the pieces work together.
Before You Change Anything
The Admin change framework, applied to diagnosing a problem.
What should happen?
What actually happened?
Which record, data, or process is different?
Which path should have produced the expected result?
Where is the likely failure point?
Can you test the hypothesis safely?
Make the smallest justified change.
Did the expected behavior return?
Did anything else change unexpectedly?
What was wrong, what changed, and why?
A strong Slate Admin does not need to know every configuration from memory. A strong Slate Admin knows how to ask the right questions, trace the system, understand dependencies, test carefully, make intentional changes, verify outcomes, and document decisions.
Understand the Impact Before You Make the Change.
Keep Learning
Users & Permissions
Review how access can affect behavior.
Data Architecture
Review the data that processes depend on.
Workflows
Review how records move.
Portals
Review how backend behavior becomes user experience.
Integrations & Data Movement
Review where data enters and leaves.
Rules & Automation
Review automated actions and dependencies.
Finished the lesson?
Mark it complete to track your progress. Progress is saved in this browser.