Trace permissions across roles and portals

Role testing often stops at page access. A reviewer confirms that a user cannot open an administrative page and moves on. Failures also occur inside actions and filtered data: a permitted page exposes another account's record, a staff role can change a field it should only read, or an action succeeds through an API even though its button is hidden.

For each role in the selected workflow, trace four questions:

• Which records can the role discover?
• Which fields can it read?
• Which transitions can it request?
• Which transitions can it approve or reverse?

Run these checks at the server boundary, not only in the interface. A hidden button is presentation, not authorisation. Every mutation should establish identity, tenant or account scope, current state and permission before applying a change. If a transition depends on two roles, represent each action separately so the audit record shows who requested and who approved it.

Cross-portal links are another common leak. A URL copied by an authorised operator should not become usable by a different account simply because the identifier is valid. Test direct navigation, stale browser sessions and role changes after login. If access has been removed, decide whether existing sessions lose it immediately or at their next refresh, then implement and test that decision.

Permissions also affect what absence means. A user may see no record because none exists, because it belongs to another account, or because an integration has not completed. Those cases may need the same public response for confidentiality, while support staff need enough internal evidence to tell them apart. Design both views deliberately.