Portals
Explain the role of Portals in Slate, evaluate what information and actions a user should see, recognize how permissions and conditional content shape the experience, review an existing Portal from the user's perspective, and design around clear next steps rather than exposing everything Slate knows.
Portals should show the right person the right information and actions at the right time. Good Portal design is about experience, not just display.
Portals: What Does the User Need Right Now?
Slate can hold a lot of information. That does not mean the user should see all of it.
A student may need to see a status, a checklist, a decision letter, a form, an event registration, a next step, or a personalized message. A staff member may need a completely different view.
Portals give Slate Admins a way to shape an experience around what a user needs to know or do. That makes Portals more than pages — they are an experience layer between Slate's data and the person using it.
The Admin question is not “What can I put on this page?” It is “What does this person need to see or do right now?”
User → Context → Information → Action
WHO IS THIS PERSON?
WHERE ARE THEY IN THE PROCESS?
WHAT DO THEY NEED TO KNOW?
WHAT DO THEY NEED TO DO?
WHAT SHOULD HAPPEN NEXT?
A Portal should reflect the user's current context. The best Portal is not the one with the most information. It is the one that makes the next step clear.
Core principle: Just Because Slate Has the Data Doesn't Mean the User Needs to See It. Admins should be intentional about visibility. Ask: Is this information useful to the user? Is it understandable without staff explanation? Is it appropriate for this audience? Could it expose sensitive or confusing information? Does the user need to act on it? Does showing it help the process move forward?
Remember these
A user-facing Slate experience that can display information and support actions.
The logic that determines who can see a piece of content.
Information that appears only when specific criteria are met.
The next action the user is expected to take.
A Portal experience tailored to a known user or record.
The user's current status, stage, role, or situation that should shape what they see.
The Portal Experience Loop
Where am I?
Why am I seeing this?
What do I need to do?
Did it work?
What happens now?
A strong Portal helps users understand both their current state and the next meaningful action.
Displaying Data vs. Designing an Experience
“What information can Slate show?”
- Starts from what is available in the system
- Measures success by how much is on the page
- Leaves interpretation to the user
“What information will help this person understand what to do next?”
- Starts from the user's context and need
- Measures success by clarity and completed next steps
- Translates system information into plain language
A Portal is not a data dump. Showing more information does not automatically create clarity. Good Portal design prioritizes relevance, timing, visibility, action, sequence, and plain language.
Check your understanding
One question at a time. Wrong answers are just practice.
What is the strongest question for a Slate Admin to ask when designing Portal content?
Review a Portal From the User's Perspective
Evaluate whether an existing Portal provides clear information and next steps.
Open a Portal experience in your Slate environment that you are permitted to review. Do not change configuration. Look at it as if you were the intended user.
- Who is the intended user?
- What status or context is visible?
- What information is most prominent?
- What action is the user expected to take?
- Is the next step obvious?
- Is anything visible that seems unnecessary or confusing?
- Is anything important missing?
- Does the experience change based on status or criteria?
Can you summarize the experience? Use this template — no institution-specific student data needed.
“This Portal is designed for __________. It shows __________ because __________. The primary next step is __________.”
Portal structure, authentication, branding, navigation, content logic, and permissions vary widely by institution. Focus on the user's experience rather than matching an exact layout.
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 Portal shows a student 15 pieces of information, but the student cannot tell what to do next. What is the primary design problem?
“Can You Put This on the Portal?”
A department asks: “Can you put this field on the student Portal?” What is the best first Admin response?
What is the best first Admin response?
Right Information, Wrong Time
A deposit reminder appears to students before they have received an admission decision. What is the main problem?
What is the main problem?
Sensitive Internal Information
A staff-only review rating is stored in Slate. Should it automatically appear in the student Portal because Slate has the value?
Should it automatically appear in the student Portal?
No Clear Next Step
A student Portal says: “Your application is incomplete.” No additional explanation or action is shown. What should the Admin ask?
What should the Admin ask?
One Portal, Different Users
Two students are at different stages: Student A has just applied. Student B has been admitted and needs to submit a deposit. Should they necessarily see identical Portal content?
Should they necessarily see identical Portal content?
Which Portal Is Better?
Portal A shows: Application Status: Complete · Decision: Admitted · Deposit Status: Awaiting · Internal Application Code: ADM-14 · Reader Bin: Final Review · Staff Rating: 3 · Person GUID: 009483. Portal B shows: “Congratulations — You've Been Admitted.” Your next step: Submit your enrollment deposit by May 1. Deposit Status: Awaiting. Button: Submit Deposit.
Which Portal better supports the student's current need?
Think Like a Slate Admin
Who is the user?
Where are they in the process?
What do they need to understand?
What do they need to do?
What should they not see?
How will they know the action worked?
When someone says “Put this on the Portal,” don't start with the page editor. Start with “What problem are we solving for the user?”
Understand the Impact Before You Make the Change. A Portal change may affect students at multiple stages, staff expectations, checklist visibility, decision display, forms and actions, authentication, conditional logic, communications that direct users to the Portal, and support volume. Before changing the experience, understand who will see the change and when.
Watch for these Portal traps: the data dump (everything Slate knows is displayed because it is available); no next step (the user sees status but doesn't know what to do); wrong-time content (information appears before it is relevant); staff language (internal terminology is exposed to users who do not understand it); hidden dependencies (Portal content depends on fields, Rules, Decisions, or Checklists that were not considered); one experience for everyone (all users see identical content regardless of stage or context).
The goal is not to create the busiest Portal. The goal is to create the clearest one.
Just because Slate has the data doesn't mean the user needs to see it.
Put It Together
The Slate Admin pathway now builds: GOVERN → DESIGN → AUTOMATE → EXPERIENCE. Users & Permissions determines who should be able to see and do what. Data Architecture determines where information should live. Workflows determine how the process should move. Portals determine what the user should see and do along the way.
work with…
…that moves through…
…and the user experiences…
…the Portal.
Good administration connects backend architecture to frontend experience.
A process is not truly well designed if the system works but the user is confused.
Before You Build the Portal Experience
The Admin change framework, applied to user experience.
Who is the user?
Where are they in the process?
What do they need to know right now?
What should they do next?
What should not be visible?
Does the experience make sense from the user's perspective?
Does the correct content appear for the correct users and stages?
Why does this content appear and under what conditions?
Design the experience on paper before opening the Portal editor: name the audience, name their stage, name the one thing they must understand, and name the single action you want them to take.
Then verify the experience the way a user would encounter it — not the way the configuration is organized.
But Where Did the Data Come From?
Portal experiences depend on reliable information. Some of that information is created inside Slate. Some comes from other systems. Some leaves Slate and becomes part of another process.
- Where is this data coming from?
- Where is it going?
- Which system owns it?
That's where Integrations & Data Movement comes in.
Keep Learning
Data Architecture
Review the data that powers Portal experiences.
Workflows
Review how Portal actions may connect to process movement.
Checklists
Review how requirements may be displayed.
Decisions
Review how outcomes may be communicated.
Forms
Review how users can take action.
Integrations & Data Movement
Learn where Portal data may originate.
Finished the lesson?
Mark it complete to track your progress. Progress is saved in this browser.
Integrations & Data Movement
Understand how data enters Slate, leaves Slate, and moves between Slate and other systems.