Another Check-In · A06
Roles and permissions
30 minutes. · 10 slides
Lesson video coming soon. The player below contains a sample video, not this lesson. You can use the written lesson and slide guide now.
Work through the lesson
Use these explanations alongside the slide guide. Expand any section to read its full explanation.
Before the demonstration
- Your assigned responsibility
- The correct training record
- Evidence of the result
Today’s outcome
Learner can justify and verify a least-privilege role without treating menu hiding as the only control.
Read the full explanation
Before we begin, check these prerequisites: A05; approved responsibility-to-permission mapping; disposable role. The intended outcome is: Learner can justify and verify a least-privilege role without treating menu hiding as the only control. Keep a note of the training identity and date so that you can recognize the result. We will pause before any action that your role or the exercise does not authorize.
Existing role grants
- Open Admin > Roles and inspect an existing training role and permissions
In this step
Start with the responsibilities the person has been approved to perform. Read the grants on the role instead of judging access by its name. A familiar role label can hide deliberate local changes.
Read the full explanation
Open Admin > Roles and inspect an existing training role and permissions. Start with the responsibilities the person has been approved to perform. Read the grants on the role instead of judging access by its name. A familiar role label can hide deliberate local changes. I will pause here so you can identify the control or result that tells us where we are in the workflow.
A training role
- Create a named training role using the approved preset or selected grants
In this step
A preset provides a starting set of permissions for a named role. It does not mean a role with that name already exists. Use a disposable training role and document the intended responsibilities before assigning it.
Read the full explanation
Create a named training role using the approved preset or selected grants. A preset provides a starting set of permissions for a named role. It does not mean a role with that name already exists. Use a disposable training role and document the intended responsibilities before assigning it. I will pause here so you can identify the control or result that tells us where we are in the workflow.
Permission review
- Review each permission against the job responsibility and save
In this step
Match each grant to a real duty. Organization-wide visibility should not be added simply to make missing data appear. A new permission label also cannot create an application feature that the code does not implement.
Read the full explanation
Review each permission against the job responsibility and save. Match each grant to a real duty. Organization-wide visibility should not be added simply to make missing data appear. A new permission label also cannot create an application feature that the code does not implement. I will pause here so you can identify the control or result that tells us where we are in the workflow.
Effective access
- Assign the role to the fictional user through Users, then verify allowed and denied surfaces in a separate session
In this step
Verify the fictional user in a separate session. Check both an allowed report and a prohibited change. Hidden menus help navigation, while server authorization determines whether a request is allowed.
Read the full explanation
Assign the role to the fictional user through Users, then verify allowed and denied surfaces in a separate session. Verify the fictional user in a separate session. Check both an allowed report and a prohibited change. Hidden menus help navigation, while server authorization determines whether a request is allowed. I will pause here so you can identify the control or result that tells us where we are in the workflow.
Inactive roles
- Explain deactivate and restore-default behavior using a disposable role
In this step
Inactive roles stop contributing authority, but another active role may still grant the same permission. Verify the effective result on the next request. The built-in admin role is protected, and Restore Defaults can replace deliberate local choices.
Read the full explanation
Explain deactivate and restore-default behavior using a disposable role. Inactive roles are now excluded from authority resolution. Verify loss of the intended permission on the next request using an approved training account; other active roles may still grant it. Inactive roles stop contributing authority, but another active role may still grant the same permission. Verify the effective result on the next request. The built-in admin role is protected, and Restore Defaults can replace deliberate local choices. I will pause here so you can identify the control or result that tells us where we are in the workflow.
Common problems
- Assuming preset names already exist as roles
- granting organization.view_all to fix missing data
- thinking a custom permission name implements a feature
A useful support report
The task and record
The expected result
The actual message
The authorized next step
Read the full explanation
Let us consider the mistakes that can disrupt this workflow. Assuming preset names already exist as roles; granting organization.view_all to fix missing data; thinking a custom permission name implements a feature. Describe what you expected and what the application actually showed before choosing a remedy. Preserve the relevant record and error. The role responsible for a review or configuration change should make that decision. Do not borrow broader access simply to finish the exercise.
Guided practice
- Create a restricted training role from report_viewer, assign it to a fictional user and show one allowed report plus a denied mutation
Evidence to show
The correct training case
The result or permitted decision
Your explanation of the next step
Read the full explanation
Now it is your turn. Create a restricted training role from report_viewer, assign it to a fictional user and show one allowed report plus a denied mutation. Work within the assigned training role. When you finish, show the result and explain which identity and date it belongs to. If the exercise includes a restricted action, explain the decision and its authorized owner rather than carrying it out without approval.
Practice debrief
- Correct context and permitted action
- A result you can trace
- A clear next step if blocked
Expected result
Learner can justify and verify a least-privilege role without treating menu hiding as the only control.
Read the full explanation
The expected outcome is: Learner can justify and verify a least-privilege role without treating menu hiding as the only control. Walk me through the record you used and the result you found. Explain these workflow checkpoints in order: Open Admin > Roles and inspect an existing training role and permissions. Create a named training role using the approved preset or selected grants. Review each permission against the job responsibility and save. Assign the role to the fictional user through Users, then verify allowed and denied surfaces in a separate session. Explain deactivate and restore-default behavior using a disposable role. Inactive roles are now excluded from authority resolution. Verify loss of the intended permission on the next request using an approved training account; other active roles may still grant it. For an exception, name the evidence you would preserve and the person with authority to take the next action.