Check permissions across roles and portals

Role testing often stops at page access. Someone confirms that a user can't open an admin page and moves on. A lot of failures happen inside actions and filtered data instead: a page the user is allowed to see shows another account's record, a staff role can change a field it should only be able to read, or an action goes through via the API even though its button is hidden.

For each role in the workflow, I'd work through four questions:

• Which records can this role find?
• Which fields can it read?
• Which transitions can it request?
• Which transitions can it approve or reverse?

Do these checks at the server boundary as well as in the interface. Hiding a button doesn't stop anyone calling the endpoint behind it. Every mutation should confirm identity, tenant or account scope, current state and permission before it changes anything. If a transition needs two roles, record each action separately so the audit record shows who requested it and who approved it.

Links between portals are another common leak. A URL an authorised operator copies shouldn't start working for a different account just because the identifier in it is valid. Test direct navigation, stale browser sessions and role changes after login. If someone's access is removed, decide whether their existing sessions lose it straight away or at the next refresh, and then build and test whichever one you picked.

Permissions also change what it means when something's missing. A user might see no record because there isn't one, because it belongs to another account, or because an integration hasn't finished yet. For confidentiality you might need all three to look the same to the user, while support staff still need enough internal evidence to tell them apart. Both of those views should be designed on purpose.