Learn 05 · Access · roles · permissions
They can see the record. Can they do the work?
Turn an access request into a specific business need.
Describe the job
Who needs to do which action, on which records, for which business reason and for how long? “More access” leaves too much unspecified.
Locate the failure
Record not visible, field missing, edit blocked and an action failing are different observations. Keep the exact message and an anonymized example.
Compare like with like
Can another person doing the same job complete the same action on the same test record? A comparison narrows the investigation; it does not prove the cause.
Two findings, two next checks
The field cannot be edited: ask an authorised admin to inspect the effective permissions and the record context. Do not prescribe a permission change from the symptom alone.
The action runs but fails: inspect the reported error and the action’s rules or data requirements as well as permissions. Giving more access may leave the actual problem untouched.
Write an access agreement
Role → record scope → permitted action → business reason → approving role → duration → review date. Mark unknowns rather than granting a broad shortcut.
Test the boundary too
In a suitable test environment, check an allowed example and an example that must remain blocked. Completing the task is only half of acceptance.
What would make you stop?
If a proposed change exposes unrelated records or lets an unintended role act, stop and reverse it. If the original failure remains, reopen the explanation rather than adding more permissions.
Take this to your next conversation
What did we observe? What else could explain it? Which one check would separate the explanations? Who can check it? What result would make us change our plan?
Fictional learning example. No systems are inspected, no configuration is changed, and no business outcome is verified.