Access control in practice

How access shows itself on screen, how to design it for a subscription process, and how to diagnose a missing control without over-granting.

Overview

Knowing what each role can do is one thing. Reasoning about it when someone reports a missing button is another — and that is what this lesson is for.

What you'll learn

The two ways access shows itself on screen
Where the lines between the three levels actually fall
How to assign access for a subscription process, by task rather than by seniority
How to diagnose a report without over-granting

How access shows itself

Controls are absent, not disabled. A Viewer does not see a greyed-out Create company button; they see no button. So "the button has gone" is usually the access model working correctly rather than a fault.

Some pages show an explicit indicator. Several carry an "Unable to edit" marker — the shareholders page, the cap table, the subscription dashboard, the members page. That tells a read-only user their state is intentional rather than leaving them to infer it from absence.

Together: if a control is missing and there is no indicator, check the role. If there is an indicator, the answer is already on screen.

Where the lines fall

	Add a member	Create a company	Launch a process
Admin	Yes	Yes	Yes
Editor	No	Yes	Yes
Viewer	No	No	No

The Admin/Editor line is drawn at managing people. The Editor/Viewer line is drawn at changing anything.

An Editor can run an entire subscription process. They simply cannot decide who else joins.

Designing access for a subscription process

The useful question is not "what role does this person have" but "what does this person need to do here".

Who	What they need
Deal-team members running the process	Editor — companies, shareholders, processes
Whoever manages the team's access	Admin — usually one or two people, not everyone senior
Partners, IC members, finance who need visibility	Viewer — genuinely read-only, and better than emailing spreadsheets
Advisers who need a single document	Consider whether they need access at all
Someone working across every project	Add them to each project — membership is per project

Diagnosing a report

When someone says they cannot do something:

Check their level on that project — not on the project you happen to be thinking of. Roles are per project.
Look for an "Unable to edit" indicator on the page in question.
Confirm the control exists for anyone. Some things are unavailable because of process state rather than access — an envelope waiting on payment, a transaction not yet ready. That is not a permissions problem.
Only then change the role, and change it to the narrowest level that allows the specific thing.

That order matters. Raising someone to Admin because a button is missing is the common overreaction, and it usually grants far more than the situation needed.

Common problems

A Viewer needs to upload one document. They cannot. Either they need Editor, or the upload should be done by someone who has it. Do not grant Admin for an upload.

Everyone on the project is an Admin. Then nobody's access means anything. Admin is for managing access, not for seniority.

Someone has access they should not. Roles are per project, so removing them from one project does not remove them from another. Check each.

A person left the firm. Their access persists per project, and there is no single place in the project view that removes someone everywhere. Worth a checklist rather than memory.

A1.4 — Roles and what each can see · the roles themselves
A2.3 — Inviting your team · granting access
A5.5 — Exporting the cap table and registry · the alternative to a Viewer role, and usually the worse one