Users & Permissions
Explain why user access is a governance responsibility, evaluate whether access aligns with a person's role, recognize the risks of excessive permissions, review an existing user's access, and apply a least-privilege mindset when responding to access requests.
Access should follow responsibility, not convenience. A Slate Admin should give users the access they need to do their work—without creating unnecessary risk.
Users & Permissions: Access Is Governance
One of the first responsibilities a Slate Admin may inherit is managing user access.
At first, this can seem simple: a new staff member needs Slate. A colleague says they can't see something. Someone asks for the same access their coworker has. A manager asks you to “just make them an admin.”
But permissions are not only a technical setting. They are a governance decision.
Access determines what someone can see, what they can change, what data they can export, and what parts of the system they can affect.
That means every access decision should answer a larger question: What does this person actually need to do their job safely and effectively?
Role → Responsibility → Required Access
What is this person responsible for?
What do they need to see or do?
What is the minimum access that supports that work?
Grant → Test → Review
What is this person responsible for?
What do they need to see or do?
What is the minimum access that supports that work?
Grant → Test → Review
Permissions should be driven by responsibility.
The goal is not to give someone the most access possible. The goal is to give them the right access.
Access Should Follow Responsibility, Not Convenience. Requests such as “Give me the same access as Jamie,” “Make me an admin so I don't run into issues,” or “I might need this later” are not permission strategies. Start with the person's responsibilities, then determine the access required to support them.
Remember these
A person who has access to the Slate environment.
Access that determines what a user can see, use, change, or manage.
The work a user is expected to perform.
The practice of giving a user only the access required to perform their responsibilities.
A periodic check that confirms a user's permissions still match their current responsibilities.
Avoid Permission Creep
New responsibilities are added, but old access is never removed.
Short-term access quietly becomes permanent.
One user's access is duplicated—including its mistakes.
A single exception becomes the new normal.
Access granted for a need that never materialized.
Permission creep happens when users gradually accumulate access over time without older access being reviewed or removed. Regular access review helps keep permissions aligned with current responsibility.
Can They Do It? vs. Should They Be Able To?
Can this permission give them access?
- Does a setting exist that unblocks the task today?
Should this role have that access?
- Does the person's responsibility actually require it?
Just because you can grant access doesn't mean you should. A Slate Admin has to think beyond whether a permission solves today's immediate problem. Also consider: What data becomes visible? What can the user change? Could this affect other records or processes? Could they export sensitive information? What happens if their job changes? Would you be comfortable explaining why this access was granted?
Check your understanding
One question at a time. Wrong answers are just practice.
What is the strongest basis for deciding which permissions a user should receive?
Review an Existing User's Access
Evaluate whether a user's permissions appear aligned with their responsibilities.
Open your institution's Slate environment in another tab. Locate a user account you are permitted to review. Do not add, remove, or change permissions for this activity unless that is part of your normal authorized work. Choose a user whose role you understand and review the access available to them.
- Identify the user's role or responsibilities
- Identify the major areas of Slate they can access
- Look for any elevated or broad permissions
- Ask whether each major permission supports a real job responsibility
- Identify any access that may deserve clarification
- Consider what would need to change if the user's role changed
Can you explain the access in plain language? Use this template (no real staff names or institution-specific details needed here).
This user is responsible for __________.
Their Slate access allows them to __________.
The access appears appropriate because __________.
One permission I would want to understand more clearly is __________ because __________.
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 counselor needs to view student records and respond to messages but has full system administration access. What is the best Admin question?
“Just Give Me What Jamie Has”
A new employee says: “Jamie does the same job I do. Can you just copy all of Jamie's permissions?” What is the best response?
What is the best response?
“I Might Need It Later”
A staff member requests permission to export large amounts of student data. They say: “I don't need it right now, but I might later.” What is the best Admin approach?
What is the best Admin approach?
Role Change
A staff member moves from Admissions Operations into Communications. What should happen?
What should happen?
Temporary Access
A staff member needs temporary access to help with a short-term project. What is the strongest Admin approach?
What is the strongest Admin approach?
Think Like a Slate Admin
What does this person do?
What do they need to see?
What do they need to change or manage?
What is the minimum access that supports that work?
How will I test it?
When should it be reviewed again?
When someone asks for access, don't start with: “Which permission should I check?” Start with: “What responsibility are we trying to support?” That question leads to better permission decisions.
Understand the Impact Before You Make the Change. Permissions affect more than whether someone can open a screen. Access may determine whether someone can view sensitive data, modify records, export information, change system configuration, trigger processes, or manage other users.
Before granting access, understand what that permission actually enables.
Put It Together
The Slate Admin pathway begins with GOVERN — determine who should be able to see and do what.
What is this person accountable for?
What must they be able to do in Slate?
The minimum access that supports that work.
Confirm they can complete the task—and nothing unintended.
Confirm access still matches current responsibility.
Governance begins with intentional access.
Before you design data, automate processes, or connect systems, you need confidence that the people using Slate have access that matches their responsibilities.
Before You Grant Access
The Admin change framework, applied to access.
What responsibility requires access?
What access does the user already have?
What is the minimum change needed?
Can the user complete the intended task?
Did the change expose anything unintended?
Why was the access granted?
Your Slate may look different: user roles, permission names, access models, authentication practices, and governance processes vary by institution. Focus on the relationship between responsibility and access rather than finding an identical permission structure.
Once People Have Access, What Are They Accessing?
Good administration isn't only about controlling who can reach the system. You also need to make thoughtful decisions about how information itself is structured.
When someone says “We need a new field,” the Admin's job isn't to immediately create one. The first question is: Where should this information actually live?
That's where Data Architecture comes in.
Keep Learning
Records
Review the types of records users may interact with.
Fields
Review how information is stored.
Data Architecture
Learn how Admins decide where information should live.
Portals
Learn how access and visibility affect the user experience.
System Health & Troubleshooting
Learn how permissions can become part of diagnosing unexpected behavior.
Finished the lesson?
Mark it complete to track your progress. Progress is saved in this browser.
Data Architecture
Learn how to decide where information belongs in Slate before creating new fields, datasets, records, or structures.