In this insight
Removing a person's access should change what they can do, not merely remove their name from a list. User access revocation needs to reach the places where decisions happen: new requests, open sessions, shared resources and work waiting to run.
An old browser tab is an easy way to reveal the difference. Yesterday a collaborator could approve a change. Today they have left the project, but yesterday's page is still open. Hiding the button in a fresh session does not answer whether the old one can still act.
Separate identity from authority
Signing in proves something about identity. It does not, by itself, grant access to every organization, project or document. Authority depends on the action and the resource as well as the person.
Consider a fictional designer who belongs to two organizations. They may edit a draft for one and read a specification for the other. A broad label such as collaborator cannot describe both boundaries. The question is not simply who are you, but what may you do here, now?
Write permissions around useful actions: view the source, edit this proposal, approve this version, invite another person. This makes access review understandable to the people responsible for the work. Technical enforcement should follow that model, rather than forcing the business to interpret a collection of vague role names.
Decide what leaving actually removes
Leaving one project is not always leaving an organization. Removing a login is not always deleting the work that person contributed. Before implementing revocation, decide which relationship is ending and which records must remain available to others.
For our designer, project removal might block future access to that project's documents while preserving the approved designs and their attribution. The person may still need access to their other organization. A blanket deletion would be both disruptive and a poor explanation of the intended change.
Make the visible result clear to the administrator: access removed from this project, other memberships unchanged. Avoid a success message that suggests wider action than actually occurred. Keeping history is compatible with ending access; it is not permission for the former collaborator to keep using the workspace.
Check authority when the action happens
An interface can guide behaviour, but the service handling the action must enforce the boundary. A request from an old tab, a direct API call and a mobile client should not receive different authority merely because they arrived through different screens.
The OWASP Authorization Cheat Sheet recommends validating permissions on every request. Applied to our example, the service checks current access before accepting a change, even if the page originally loaded successfully.
Long-running work needs a deliberate policy too. If a person starts an export and loses access before it runs, should it proceed? Some operations must re-check current authority; others may represent an already authorized organizational action. Define that distinction, record who owns the job and prevent output from being delivered to someone no longer entitled to receive it.
Plan for return visits and races
Re-inviting a former collaborator should not accidentally restore every old permission. The new relationship may have a different scope. Treat acceptance as a current grant, and check whether old links or sessions can regain access outside it.
Also test two actions arriving close together: one administrator removes access while another changes the person's role. The final state must follow a defined policy, not an assumption that events always arrive in the order the screen displayed them.
Repeat removal and invitation actions as well. A retried removal should not damage unrelated memberships. A repeated invitation should not create confusing parallel relationships or duplicate notices. If an invitation is cancelled, accepting an older link should not quietly resurrect it.
Give the team a usable access review
A useful review answers who can reach this work, why they can reach it and who can change that access. It should include relevant organization and project relationships, not just the last role shown in a menu.
Review the consequences too. A departing owner may have been the only person who could approve a release or manage a connection. Transfer responsibility deliberately rather than solving continuity by leaving an account active indefinitely.
No access model can guarantee that previously downloaded information disappears from another person's device. Be honest about that limit. Prevent future unauthorized retrieval, define export rules and protect sensitive material before sharing it. Revocation is essential, but it cannot undo every earlier disclosure.
Model conversion exercise
Use this exercise with a real workflow and the people accountable for its outcome. Record disagreements as modeling questions instead of silently choosing an answer.
Using an isolated test account and fictional records, open a project in two tabs. Remove its access through the normal administration path, then try reading, editing and downloading from the old tab. Repeat with queued work and a cancelled invitation. Re-invite the account with narrower access and verify that it receives only the new grant. Record expected results before testing, and include what should happen to notifications and existing contributions.