Access is the path most often done in the wrong order, and the consequence is specific: everybody arrives able to see everything, and taking it back later is a conversation nobody wants to have.
The order
1. Roles. What jobs exist. See Roles.
2. Permissions. What each role can do. See Permissions.
3. Record visibility. Whose records each role can see. See Who sees whose records.
4. Departments, which drive inbox and queue routing.
5. People, added last. See Onboarding someone.
The order matters because each step references the one before. Adding people first means editing every one of them again.
Roles
A role is a job, not a person.
Start with four or five. Administrator, manager, staff, finance, and possibly a read-only role for people who need to look and not touch. That covers most organisations of under a hundred people.
Name them for the job, not the seniority. "Finance" is understood by everybody. "Level 3" is understood by whoever invented it.
Resist one role per person. Nine roles for nine people is not access control, it is nine separate configurations that will drift apart within a quarter and that nobody can reason about.
Permissions
What a role can do. Read Permissions for the mechanics; the judgement is here.
Start closed and open up. Somebody asking for access they need is a thirty-second conversation. Discovering that everybody has been able to see payroll for a month is a different kind of conversation.
Give managers what they manage, not everything. The instinct to give a senior person broad access is understandable and produces a system where seniority and visibility are confused.
Check the finance boundary specifically. Salary, margin and cost prices are the three things organisations most regret exposing, and all three are easy to expose accidentally.
Record visibility
Separate from permissions, and the distinction matters.
Permissions decide what kinds of things somebody can do. Visibility decides whose records they can do it to.
A salesperson who can edit deals and only see their own is a completely different arrangement from one who can edit deals and see everybody's, and both are legitimate. Who sees whose records covers how to choose.
This is what people actually notice. More support questions come from this than from permissions, because "I cannot see the thing my colleague can see" is immediately visible and rarely self-explanatory.
Two people who need special thought
Whoever runs finance. They need to see numbers most people should not, and they usually do not need administrative access to do their job. Those are different things and are worth separating deliberately.
Whoever leaves. Offboarding is part of access design, not an afterthought. Decide now what happens to somebody's records when they go, because deciding it during a departure is how records end up orphaned. See Offboarding.
Departments
Departments drive routing: the department inbox, support queues, and who gets what.
Match how work actually arrives, not the org chart. If sales and support are answered by the same three people, that is one department, whatever the org chart says.
Somebody can be in two. That is normal and handled.
People
Adding a person is covered in Onboarding someone.
Add one and check it before adding thirty. Log in as them, or have them log in, and look. Ten minutes here catches a permissions mistake that would otherwise be repeated across the whole organisation.
Ask them what they cannot see. New joiners assume anything missing is intentional and do not report it, so the check has to be deliberate.
Write down what each role is for
One line each, kept where administrators can find it.
Six months from now somebody will ask whether a new joiner should be "Manager" or "Staff", and the answer should not depend on who happens to be asked. A sentence per role settles it permanently and takes five minutes.
Notifications
Once roles exist, decide what people are told about. See Notification policy.
Default to less. A product that notifies about everything trains people to dismiss notifications within a week, and the important one arrives in week three.
The mistakes that cost most
One role per person. Nine roles for nine people cannot be reasoned about, and they drift within a quarter.
Giving administrators to anybody senior. Seniority and system access are unrelated. The finance director does not need to edit permissions, and giving it to them means a mistake there is unattributable.
Leaving the founding account as the only administrator. Two administrators, minimum, or a single lost password becomes an incident.
Never revisiting it. Access set up for twelve people is wrong for forty, and nobody notices because it fails open rather than closed. Worth a look every six months.
Approvals
Approval policies reference roles, so they come after this path rather than during it. See Approval policies.
Roles and hubs together
Both narrow what somebody sees, in different directions, and the combination is what people actually experience.
A role decides what kinds of things they can do. A hub decides which part of the organisation they are acting in. Somebody with a wide role in one hub sees less than somebody with a narrow role across three.
When investigating "why can they not see this", check both. Assuming it is permissions when it is hub scope is the most common wrong first guess.
Checking it worked
Log in as a normal member of staff. Not as an administrator with a role switched. The most common access mistake is invisible to administrators by definition.
Try to see something they should not. Payroll, margins, another department's queue. If it is visible, fix it now.
Then look at the audit log to confirm the checks were recorded, which is also the moment you learn what it captures.
Next
Bringing your data in, now that there are people to own records.
Did this answer your question?
No, ask a person