Two questions, separately
Roles and permissions
Three or four roles, named in your own words, and sensitivity used only where you genuinely need it. That covers almost every organisation under fifty people.
The model
Two questions, answered separately
Most systems give each person a single level, and every organisation eventually hits a requirement that a single level cannot express. Reception needs to book and should not read correspondence. A volunteer needs the donor list and not the safeguarding notes. A salesperson sees their own accounts and a manager sees everything.
Consonas separates two questions that a single level conflates, and understanding the split is most of what you need to configure this well.
What kind of work does this person do? That is the role. You define it in your own words and scope it to everything, to a team, or to what they own. It changes when their job changes.
Which restricted records may they see? That is a sensitivity grant, given to named people for records marked sensitive. It does not arrive with a promotion, and removing it does not disturb anybody's ability to work.
Why this matters practically
Because the common case stays simple. Most organisations use roles and ownership and never touch sensitivity at all. The ones that need it usually need it for a handful of records rather than for a whole category, which is exactly what a separate grant is good at and what a permission level is bad at.
Where to start
A configuration that works for most organisations
Name them in your own words. These are shapes rather than names to copy.
- Owner
- One or two people. Can change anything including billing, plans, members and the organisation itself. Not a role for convenience: it is the role that can end the organisation.
- Administrator
- Runs the system day to day. Adds members, changes types and stages, manages views. Cannot change the plan or close the organisation.
- Everybody
- Does the work. Sees and edits records according to scope. This is the role most people should have and the one worth spending the most time getting right.
- Own records only
- Scoped to what they own, for organisations with allocated accounts. Optional, and most small organisations do not need it on day one.
- Read only
- Sees without changing. Useful for an accountant, a non executive or somebody joining who should look before touching. Rarer than people expect.
- The sensitivity grant
- Not a role. A separate permission, given to named people, for records marked sensitive. Add it only if you genuinely have records that need restricting from people who can otherwise see records like them.
Choosing
Six things people want, and how to achieve each
The third column is the mistake that gets made when the model is not clear.
| What you want | How to do it | How not to |
|---|---|---|
| Somebody sees only their own accounts | A role scoped to what they own. | Marking every other record sensitive, which makes the mark meaningless. |
| One client file is confidential | Mark that record sensitive and grant access to the specific people. | Creating a role for the people allowed to see it, which does not scale past one file. |
| Reception books but does not read correspondence | A role that permits the work, without the sensitivity grant. | Giving reception read only access, which stops them doing their job. |
| A new starter looks before touching | Read only for a fortnight, then their real role. | Full access on day one because it is quicker. |
| An accountant sees the money | Read only, or a role scoped to what they need. | Sharing someone's sign in, which destroys the audit trail entirely. |
| Someone leaves | Remove them as a member. Access ends immediately, history stays attributed. | Changing their password and keeping the account, which is how a shared account is born. |
Every action is attributed to whoever the account belongs to. Share one and the audit trail becomes fiction, discovered at the moment you first need it.
Which is why a shared sign in is the single worst thing you can do to this product, and why we would rather raise your limit than have you do it.
Three roles first
Setting it up, and keeping it right
Start with fewer roles than you think
Three is usually right on the first afternoon: someone who runs it, someone who does the work, and possibly someone who sees only their own. Add more when a real requirement appears rather than in anticipation of one.
The test for whether two roles should be one is whether they need different access. Two people with different job titles and identical access should share a role, because a role per job title is a configuration that grows without ever being simplified.
Keep owners to one or two people
An owner can change anything, including billing, membership and the existence of the organisation itself. It is not a seniority marker and it should not be given for convenience. Someone who needs to add members should be an administrator.
Give everybody their own account
Always, without exception. A shared sign in destroys the audit trail, because every action is attributed to the account instead of the person. If the reason for sharing is the person limit on your plan, write to us and ask, because we would considerably rather raise a limit than have someone run a business on a shared password.
Two factor sign in is on every plan, and an owner can require it for the whole organisation. Check occasionally that it still is, and that nobody has been given an exception that outlived its reason. The National Cyber Security Centre publishes the plain version of why, which is more persuasive to a reluctant colleague than anything a supplier says about its own product.
Review it when someone changes job, not annually
The moment permissions drift is when someone moves department and keeps everything they had plus everything they need. An annual review catches that eleven months late. Changing the role at the same time as the job takes a minute and is the only reliable moment.
Use sensitivity sparingly, and deliberately
If more than a small fraction of your records are marked sensitive, the mark has stopped carrying information and people will stop treating it as meaningful. Sensitivity is for the records that genuinely need restricting from people who can otherwise see records like them, and for most organisations that is a handful.
The trades where it earns its keep from the first week are the ones holding health, safeguarding or other special category data, which the Information Commissioner's Office treats differently from ordinary records. Healthcare administration, charities and solicitors and law firms each say where the line falls in that trade.
Five permission choices
Five choices, and what each one costs you afterwards
None of these has a right answer. Each has a consequence you live inside for as long as the configuration lasts, so it is worth making them on purpose.
Scope by what someone owns, or by the team they sit in
A role can reach everything, a team, or what the person owns. The choice between the middle and the narrow one is the one people rush, and it is the one that shapes what the system feels like to use.
Ownership is precise and unforgiving. A record with no one as its owner falls outside every ownership scoped role, which is exactly right in principle and startling in practice the first time a record arrives from a web form and no one can find it. If you scope by ownership, the person who assigns owners is doing permissions work whether they know it or not.
Team scope trades precision for a working office. It costs you a second thing to keep current, because from that day on adding somebody to a team is a permission change and deserves the same care as changing a role. It also resolves quietly in the safe direction: someone who is in no team at all reaches their own records rather than everything, which will look like a broken account to them and is the system refusing to guess.
Whether there is a second owner, and who it is
The last owner cannot be removed or reduced, deliberately, because an organisation locked out of its own billing and membership is a problem with no clean answer. That guarantee is doing nothing for you if there is only ever one owner and they are on annual leave, in hospital, or leaving on bad terms.
The cost of a second owner is real and worth saying plainly: two people can then change the plan, remove members, and end the organisation. That is the price of not depending on one person being reachable. Most organisations of this size should pay it, choose somebody who would still be there after a difficult month, and write down who it is somewhere that is not inside the product.
Whether a read only role exists at all
It sounds obviously useful and it is used less than people expect. The question to ask is who, concretely, in your organisation, should see everything and change nothing. An accountant is the usual honest answer. A non executive is the second.
The cost of not having one is that those people get a working role instead, and from then on their edits sit in the audit trail looking exactly like staff edits, which is the thing you were trying to avoid. The cost of having one is smaller but not nothing: someone will eventually be parked in it because nobody had time to think, and a person who cannot do their job quietly stops trying to.
Sensitivity or a denial, for the one awkward record
These look interchangeable and are opposites. Sensitivity is a property of the record: it subtracts from everyone who does not hold the grant, including people who need to work on it. A denial is a statement about one person and one record, it carries a reason, and it beats every grant that person holds.
So the test is who the problem is about. If the file itself is confidential, it is sensitive. If the file is ordinary and one particular person should be nowhere near it, usually a conflict of interest or a family relationship, that is a denial, and marking the record sensitive instead would hide it from the colleague who has to do the work. Getting this backwards is the most expensive small mistake on this page, because it looks solved from the administrator's chair.
Whether to start from the roles supplied or write your own
Both are supported and the difference is not effort. Starting from an existing role gives you a copy taken at that moment. Roles do not inherit, so nothing you change on the original later reaches the copy, and two roles that began as one will drift apart without anyone deciding that they should.
Writing your own in your own words costs an afternoon and buys recognition: people look for the word their business already uses, and a role called something no one says out loud is a role no one identifies with. Either way, the words are yours per organisation rather than chosen from a fixed list, so the drifting copies problem is the one to plan for and the naming is the one to enjoy.
What people ask for
Requests arrive as symptoms, and rarely as what is needed
Nobody asks for a grant at a scope. They tell you what they could not do, and the translation is the part of this job that takes judgement.
I cannot see the Fowler file
The most common request, and the one with four different causes. It may never have been in their scope. It may have an owner who left. It may be marked sensitive. It may carry a denial that somebody set for a good reason nine months ago and no one remembers.
Ask which record, not which permission. A refusal names the rule that produced it, so the person in front of you is usually holding the answer without recognising it, and the plain list of what their role allows settles the rest. Widening the role because someone could not open one file is how an organisation ends up with three roles that all mean everything.
Can you make me an administrator
Almost never what is wanted. Underneath it is a single action they were refused, and it is usually an export, an import, or changing something in the settings that they needed once. Ask what they were doing when they hit it.
The right answer is to grant that action at the narrowest scope that solves it, or to do the thing for them if it happens twice a year. Administrators accumulate by exactly this route: a reasonable request, a busy afternoon, and a permanent change made to avoid a five minute conversation. A year later everyone is an administrator and the role has stopped meaning anything.
The whole team needs to see everything
Occasionally true, usually a generalisation from one bad morning. Someone could not cover for a colleague, so the request arrives as a policy rather than as an incident.
Ask which record, and when. If the answer is a specific account during a specific absence, that is a share or a change of owner for a fortnight, not a permanent widening of six people's access. If the answer really is that this team works on everything together, then scope them to the team and say so out loud, because a deliberate wide scope is fine and an accidental one is how a leaver walks out with a customer list.
Can I use Sam's sign in while she is away
This one is not a permissions request at all. It is a cover request wearing a permissions costume, and the answer is no, without exception, because every action would be attributed to Sam and the audit trail would record her doing things during a week she was in another country.
Answer the underlying question instead. Share the specific records for the fortnight, or move ownership and move it back. Both take a minute, both are recorded, and both leave you able to say afterwards who did what. If the reason for asking is that your plan has run out of people, write to us about the limit rather than solving it with a shared password.
Why can the new starter see that conversation
A request about somebody else's access, and the only one that arrives with an accusation attached. It is almost always a scope that is wider than anybody realised instead of anything anybody did wrong.
Resist explaining from memory. Read the effective permissions of the role the new starter holds, which is a plain list instead of something to reconstruct in your head, and answer from that. If the list surprises you, it will surprise everyone else who holds that role too, and you have just found your next configuration change.
Give her the same access as Priya
The friendliest request on the list and the one that quietly does the most damage. Priya's access is not a role. It is a role plus whatever has been shared with her plus whatever grant she picked up during the year she covered reception, and copying the person copies all of it including the parts no one would grant deliberately today.
Copy the role and stop there. If the new starter then cannot do something Priya can, you have learned something useful about what has accumulated on Priya, and the right response is usually to take it off Priya rather than to add it to someone else. This is also the moment people discover that two roles which began as one copy have drifted, because roles do not inherit and nothing was ever going to keep them in step.
We need a role for the apprentice
Sometimes true. Far more often it is a request for one or two actions, arriving as a request for a job title, because the person asking is describing an organisation chart rather than a set of permissions.
Ask what the apprentice will be doing that nobody else does. If the honest answer is that they do what everybody else does with fewer records, that is an existing role at a narrower scope and not a new role at all. A role per person is how an organisation of fifteen ends up with eleven roles, none of which anybody dares change, because every one of them is somebody's name in disguise and changing it feels personal.
It says this is not included
Not a permissions request, and the wording is doing you a favour by saying so. Not allowed means a role forbids it and an administrator can change that. Not included means the plan does not carry that module and only a decision about money changes it.
The reason this matters to you specifically is that adding permissions will not fix it, and half an hour spent trying is half an hour spent proving the message was right the first time. Send it to whoever decides what the organisation pays for, which on this page is probably you wearing a different hat.
Scope is silent. Someone scoped to their own accounts does not see a locked row where a colleague's account should be. They see a shorter list, and nobody asks about what was never there.
Which is why five minutes of briefing beats a fortnight of someone quietly assuming the system is broken.
Not built
Five things permissions cannot do, and why that is a position
Each of these has been asked for. Each is absent for a reason we are willing to state rather than because no one got round to it.
Access that expires on Friday
There is no grant, share or denial with an end date on it. You give access and you take it away, both as deliberate acts, both recorded.
The reason is that expiring access is mostly a way of avoiding the second conversation. A date set six weeks out is a decision no one will remember making, and it either lapses at an inconvenient moment for somebody mid task or it gets extended without anybody rereading why it was granted. Removing a share takes about as long as setting an expiry would, and it happens at a moment when someone is actually thinking about the question. The cost is honest: it means someone has to look, and an organisation that never reviews will carry access longer than it meant to.
An approval step before a permission changes
No one has to countersign a role change. The person with administrative access makes it, and the audit trail records who made it, when, and what it was before.
For an organisation of two to two hundred people, an approval queue for permissions would be theatre. The approver is nearly always the person sitting next to the requester, the requests are nearly all reasonable, and a queue that is always approved trains everyone to approve without reading. A record of what changed, readable afterwards by anybody who can see the audit trail, does more real work than a gate that becomes a formality in a fortnight. Where a second person genuinely is the control, it is the approval of a contract or of our own access, both of which have one.
Signing in as someone else
An administrator cannot become another member to see what they see. It is a common feature elsewhere and it is deliberately absent here.
The reason is attribution. The audit trail is only worth having because every entry names a person, and the moment one person can act as another the trail carries a question mark on every line instead of a name. Our own support access is the exception that proves the shape of the rule: it needs a stated reason and a second approver, it writes into your audit trail, and everything done under it is attributed to the support member rather than to the person whose view was borrowed. If you want to know what someone sees, read their effective permissions.
A customer login that is a small staff role
A customer who reaches their own matters and documents is not a member with fewer permissions. They are a different kind of user entirely, entitled to specific records by their relationship to them, with no scope that means everything and no role that could be widened into one.
Building it as a cut down staff role is the obvious shortcut and it is how portals leak. One misconfigured role, one permission added for a reason that made sense on the day, and a customer is looking at another customer's file. Keeping the two kinds of user apart in the model means the mistake is not available to be made, at the cost that you cannot express customer access by handing someone a role, which occasionally reads as a missing feature and is a wall on purpose.
An emergency override
There is no button that grants everything for an hour because something has gone wrong. The way to widen access during an incident is to change a role or grant the access, which is a change with a name and a time against it.
An override used once a year is a control nobody has tested, and it is the first thing looked for by anyone who should not have it. The honest alternative is what an owner already holds: full access, in one or two hands, ready at four in the morning without any special mechanism. That is a smaller and more visible surface than a break glass feature, and it is the reason the advice on this page is to keep owners few rather than to keep them for ceremony.
Role questions
Asked about roles
How many roles should we create?
Three or four for most organisations under fifty people. If you have eleven, you are almost certainly modelling job titles rather than permissions, and the result is a configuration no one can reason about and therefore nobody maintains. Two people with different job titles who need the same access should share a role.
What is the difference between scope and sensitivity?
Scope is about allocation: which records this person deals with, usually the ones they own. Sensitivity is about confidentiality: this specific record should not be visible to people who can otherwise see records like it. Using one to do the other's job is the most common configuration mistake.
Should we use sensitivity from day one?
Only if you genuinely have records that need restricting. Most organisations do not, and marking things sensitive when you do not need to means the mark stops meaning anything. The trades where it matters immediately are healthcare administration, legal, charities and anywhere holding safeguarding information, and their sector pages say so.
Can two people share an account?
Technically nothing stops you and it is the worst thing you can do to this system. Every action is attributed to whoever the account belongs to, so the audit trail becomes fiction, and the first time you need to know who changed something you cannot. If cost is the reason, ask us about the limit instead of sharing a sign in.
What happens to somebody's work when they leave?
Their access ends the moment you remove them. Everything they did stays attributed to them in the timeline and the audit trail, permanently, because a record of who did what that can be emptied by an offboarding is worth nothing at exactly the moment someone needs it. Records they owned can be reassigned to somebody else.
Can somebody be an owner and still be scoped?
An owner can change anything, including their own permissions, so scoping an owner is not a security control. If you want somebody to see only their own records, they should not be an owner. Keep owners to one or two people who genuinely need to change billing and membership.
Why does the product distinguish not allowed from not included?
Because they are different problems with different solutions. Not allowed means your role forbids it and an administrator can change that. Not included means your plan does not carry that module and only a decision about money changes it. A system that says permission denied for both trains everyone to ask an administrator first, and the administrator to shrug.
Can I see who changed something?
Yes, in the audit trail, which records who and when for every change and cannot be edited by anybody including us. Reading is almost never recorded, deliberately: a trail that logged every record opened would be unreadable within a week and would turn the customer history into a surveillance log of your own staff. There is one exception, and because it is the sort of thing a data protection officer would rather be told than discover, here it is. Opening a record that is marked sensitive writes a line saying it was opened. That applies to relationships, matters, quotations and custom records, and it is one line for the record rather than one for every note and file on the page. Nothing else about reading is kept: not a list, not a search, and not a record with no sensitivity mark on it.
Somebody says a record has disappeared. Where do I start?
With their scope, because scope is quiet. A person scoped to what they own does not see a locked row where a colleague's account used to be, they see a shorter list, so the first question is whether that record was ever inside their scope at all. If it was, the next two candidates are an explicit denial on that record and a sensitivity mark, in that order, because a denial beats every grant and sensitivity is asked before the role is.
Can I give one person access to one record without changing their role?
Yes. A record can be shared with a named person at view, edit or full, and the share reaches that record and nothing else. It is the right answer to covering an absence and to the one file somebody outside the usual scope has to work on. It is the wrong answer to a pattern: if you have shared the same kind of record with the same person four times, their role is wrong and the shares are you avoiding a five minute conversation.
What is a denial for, when I could take the permission away instead?
Taking the permission away changes what someone can do everywhere, which punishes their whole job for one record. A denial refuses one record to one person, carries a reason, and beats every grant they hold including one that reaches everything. It is for the single file somebody must not be near, usually a conflict or a relationship, while the rest of their work carries on untouched.
Can the last owner be removed?
No. Every organisation must have at least one owner, and the last one cannot be removed or reduced, because an organisation locked out of its own billing and membership is a problem with no clean answer. It is also the reason to appoint a second owner before you need one instead of during the week you discover you do.
Do roles inherit from one another?
No. You can build a role starting from an existing one, but what you get is a copy taken at that moment instead of a link, so later changes to the original do not follow it. That is deliberate. Inheritance chains make the effective permissions of a role hard to predict, and a model nobody can predict is a model that gets configured wrongly by careful people.
There are two of us. Do we need roles at all?
Not yet, and we would rather say so than sell you a configuration exercise. Two owners who both do everything is an honest description of a two person business, and any further structure is work done for an organisation you do not have. The moment to think again is the third person, particularly if that person is part time, a contractor or a bookkeeper.
Who should hold the sensitivity grant?
The smallest number of named people who genuinely need to read restricted records, which is rarely the same list as everybody senior. Keeping it separate from the role is the whole point: seniority and confidentiality are different questions, and a promotion should not quietly hand someone the safeguarding notes as a side effect of a new job title.
The person asking me for more access is my manager. What do I do?
Turn it into a question of fact rather than of standing. Read what their role allows as a plain list, ask which record they could not reach, and grant the narrower thing that answers it. If the answer genuinely is everything, that is an owner decision and it should be made as one, visibly, rather than settled as a favour between two people in a corridor.
Can I see what a role allows before I give it to anybody?
Yes. What a member may actually do is readable as a plain list of actions and the records each one reaches, rather than as a set of assignments you hold in your head and add up. Read it before you assign a role and again at a review, because the list is the truth and the name of the role is only a label someone chose on a Tuesday.
Set up three roles before you invite anyone
Ten minutes at the start, in your own words, is considerably easier than retrofitting it once eight people are using the system.
Three people, a thousand relationships, no card and no time limit.