Design permissions around work, not job titles

Most B2B permission systems begin with a tidy list: admin, manager, member, viewer. Real work is not tidy. A finance lead may approve a payout but not change its calculation. A project owner may invite a contractor for two weeks but not expose commercial terms. Someone covering parental leave may need authority that is legitimate today and wrong next month. Permissions should therefore model responsibilities around specific work, including when authority begins, how it ends, and what other people can see after it is used.

Start with decisions, not personas

A persona describes a type of user. A permission describes an allowed action on an object under defined conditions. Treating those as the same thing produces broad roles that age badly.

Begin with a responsibility map. For each important workflow, list the decisions people make: create a draft, submit it, approve it, return it, publish it, reverse it, export it, or change who can act. Then record the object, scope, and consequence of each decision.

“Finance manager” is too vague to authorize anything. “Approve a commission run for the EMEA workspace up to its final sign-off” is closer to a product rule. It names the action, boundary, and point of consequence.

This approach still supports roles. The NIST overview of role-based access control describes roles as collections of permissions connected to the operations required by particular jobs. The design mistake is not using roles; it is deriving them from an org chart before understanding the operations.

Cluster recurring responsibilities into roles only after mapping the work. A role becomes a maintained product concept, not a synonym for seniority.

Separate preparation, authority, and administration

Many permission problems come from treating participation in a workflow as control over the workflow. Split capabilities into three layers:

• Preparation covers drafting, importing, editing, and submitting work.
• Authority covers approval, rejection, publication, payment, or reversal.
• Administration covers changing policy, membership, roles, thresholds, and workspace settings.

The person who prepares a record does not automatically need to approve it. The person who approves a transaction does not automatically need to grant that authority to someone else. These distinctions matter even in small teams because they keep a convenient shortcut from becoming an invisible policy.

Model sensitive actions explicitly rather than hiding them behind an all-purpose edit permission. “Edit payout” might mean correcting a note, changing an input, or altering an approved amount. Those actions have different consequences and should produce different authorization checks and interface treatments.

For high-impact operations, consider two-person control: one person proposes and another confirms. NIST SP 800-53 includes dual authorization, account review, and time-bounded account management among its access-control patterns. That publication is guidance for security and privacy controls, not a universal product specification, but the underlying design questions transfer well: which actions deserve independent confirmation, how often should authority be reviewed, and when should temporary access disappear?

Make temporary authority a first-class state

Temporary access should not be a permanent role followed by a calendar reminder. Give the grant its own data and lifecycle:

• the recipient and precise capabilities;
• the workspace, project, account, or records in scope;
• the reason and granting person;
• start and expiry times;
• any approval required before activation;
• the state after expiry, including active sessions and queued work.

Show these conditions before the grant is confirmed. “Can approve invoices until 18:00 Friday” is useful. “Temporary admin” forces everyone to guess.

Expiry should be enforced by the authorization system, not merely displayed in the interface. Decide what happens when time runs out while a user has an open screen, a scheduled operation, or a pending approval. Usually, reading an already loaded page and performing a new consequential action should be treated differently; the latter requires a fresh authorization check.

Emergency authority needs the same discipline with a faster activation path. It should have a short default duration, a named reason, prominent visibility, and a mandatory review afterward. Urgency changes the route, not the need for boundaries.

Put review where responsibility changes

Quarterly access reviews can help, but they are a weak primary mechanism because responsibility changes continuously. Add review triggers where the product already knows the context changed: a project closes, a contract ends, an owner changes, a user moves team, or a temporary grant expires.

A useful review screen should answer four questions without requiring an export:

1. What can this person do now?
2. Why do they have each capability?
3. When was it last used or reviewed?
4. What work would be affected by removing it?

Reviewers should be able to retain, narrow, reassign, or revoke authority. “Approve all” is convenient but encourages ceremonial review. Group grants by responsibility and consequence so unusual combinations stand out, such as someone who can both modify inputs and give final approval.

Keep the role catalogue reviewable too. Unused roles, overlapping roles, one-person roles, and permissions with no clear owner are signals that the model no longer matches the work.

Show consequences before and after action

Authorization is not only a backend decision. The interface should make boundaries legible.

Before a sensitive action, state its scope and consequence: which workspace is affected, whether the action is reversible, who will be notified, and whether it completes a workflow stage. A disabled control should explain the missing responsibility and the route for requesting it. Hiding every unavailable action makes the product calmer, but it can also make delegation and troubleshooting opaque.

After the action, leave a visible operational record. Show who acted, under which responsibility, when, and what changed. If authority was delegated or temporary, include that context. Prefer domain language such as “Mina approved the May commission run while covering Finance Operations” over a raw permission identifier.

This is especially important when one action changes what another person may do next. Approval might lock edits, release a statement, or move an item into a dispute window. Those consequences belong in the workflow interface, not only in an audit log intended for administrators.

Operational boundaries belong in the product model

A grounded example is BackendOS, which presents commission operations as a sequence from import through payout approval, rep statements, disputes, and sign-off. Those are distinct operational boundaries with different consequences. Alfcode’s product work here supports a practical design lesson: permission modelling should begin at those boundaries rather than with a generic “finance user” role. The public product description does not establish a particular internal role scheme or compliance status, so the evidence is the separated workflow itself.

For your next permission decision, run one test: can you describe the grant as “this person may perform this action on this scope until this condition ends, with these visible consequences”? If any part is missing, the permission is probably still modelling a title instead of a responsibility.