Product

Permissions and the audit trail

Permission is about records rather than about screens, and the difference between not allowed and not included is one the product is careful to keep.

Administrator, standard, read only

One permission level per person cannot describe a real organisation

Most systems give each person a level: administrator, standard, read only. It is simple, it is easy to explain, and it fails on the first real requirement any organisation has.

Reception needs to book appointments and should probably not read clinical correspondence. A fundraising volunteer needs the donor database and must not have the safeguarding notes. A salesperson should see their own accounts and a manager should see everything. A firm needs an information barrier around one client while everyone continues working normally on the rest.

None of those is exotic. All four are ordinary and all four are impossible to express with a single level, so organisations resolve them the same way: they give people more access than intended and rely on everybody behaving, or they build a second system for the sensitive things. The second system is almost always a spreadsheet, and it is almost always more sensitive than the CRM it was created to protect.

Two decisions instead of one

The design here separates two questions that a single level conflates. What kind of work does this person do, and which restricted records may they see. Those are answered independently, by different people, at different times.

The role answers the first. It is defined by you, in your own words, and scoped to everything, to a team, or to what someone owns. It changes when their job changes.

Sensitivity answers the second. It is a grant on specific records, given deliberately to specific people. It does not arrive as a side effect of a promotion, and it can be removed without dismantling anybody's ability to work.

The practical effect is that the common case stays simple. Most organisations use roles and ownership and never touch sensitivity, and the ones that need sensitivity usually need it for a handful of records rather than for a category.

One level, six needs

Six ordinary requirements

None of these is unusual, and none can be expressed with a single permission level.

The need	One permission level per person	Roles plus a separate grant
Reception books but does not read correspondence	Either reception sees everything or cannot do the job. Most organisations choose the first and stop thinking about it.	A role that permits booking, and sensitivity as a grant they do not hold. Two decisions instead of one.
A salesperson sees their own accounts	Everything, or nothing, or a second system.	A role scoped to what they own, with managers scoped to everything.
One client file is confidential	A locked folder, or an agreement between people not to look.	That record marked sensitive, with the grant given to the specific people who should have it.
Somebody is promoted	They inherit access to everything the new level carries, including things no one intended.	Their role changes. Sensitivity grants do not follow automatically, because they are a separate decision.
Somebody leaves	Access removed, and often the history is reassigned or lost.	Access ends immediately. Everything they did stays attributed to them in the audit trail.
Proving who saw what	Server logs, if anyone kept them, readable by whoever has the server.	An audit trail nobody can rewrite, including us, on every plan including the free one.

Roles

Your words, and fewer of them than you think

Roles are defined per organisation. If your business has partners, associates and support staff, those are your roles. If it has engineers and a coordinator, those are. Nobody has to translate their own job title into somebody else's vocabulary in order to reason about who can do what.

Scope is the second half. A role scoped to everything suits a manager. Scoped to a team suits an organisation with more than one. Scoped to what someone owns suits a sales team with allocated accounts. That middle option is the one most small organisations actually need and the one most products do not offer.

Three or four roles covers most organisations under fifty people. Eleven roles is almost always a sign that somebody has modelled job titles rather than permissions, and the result is a configuration no one can reason about and therefore nobody maintains.

Sensitivity

A grant that does not arrive with a promotion

Marking a record sensitive means it is not visible to people who can otherwise see records like it. Access requires a grant, given to named people, held separately from their role.

Every route to the record checks it independently: search, reporting, export and the customer portal. That matters because a single gate is a single point of failure, and the failures in permission systems are almost never at the front door. They are in a report that aggregated something it should not have, or an export that included a row the interface would have hidden.

A restricted record is genuinely absent from search rather than shown as a locked row. A result announcing that there is something here you cannot see confirms the existence of the record and usually its name, and in the trades that need this most, the existence is frequently the confidential part.

How security works

Evidence

A trail no one can tidy up, including us

Who changed what and when, on every record, including any access by someone at Consonas. No entry can be rewritten or removed, by an administrator, by the owner of the organisation, or by anybody here. That single property is what makes it worth having: a trail someone can tidy is a diary.

Erasing a person is the one exception, and it takes the values rather than the entry. Who acted, what they did and when they did it all stand; the before and after they carried are blanked and the entry says it was redacted on erasure. A trail that kept the name and the note somebody was entitled to have removed would defeat the erasure it is supposed to evidence, and that is a worse trail rather than a stricter one.

It records every change, and one kind of read: opening a record marked sensitive writes a line naming the person, the record and the moment. Opening an ordinary record writes nothing, and that is a deliberate limit. A trail logging every record anybody opened becomes unreadable within a week, which means it stops being usable as evidence, and it converts the customer history into a surveillance log of your own staff, which changes behaviour and not for the better. Sensitive records are the exception because they are the ones somebody will later be asked to account for, and there are few enough of them that the trail stays readable.

It is on every plan including the free one, permanently, along with consent records and subject access tooling. Those are obligations rather than features, and the Data Protection Act 2018 does not ask less of an organisation of six than of one of six hundred. Putting them behind a price means the organisations least able to afford them are the ones running without them, and the Information Commissioner's Office asks the same questions of a charity with four staff as of anybody else.

Roles and the record

Who may do what, and the record of what they did

Each part, and the reason it works that way.

Roles: Defined in your own words per organisation rather than chosen from a fixed list. The word your business uses is the word your staff will look for, and a role called Account Executive in a firm that has partners is a role nobody identifies with.
Scope: A role can be scoped to everything, to a team, or to what somebody owns. Most small organisations need the middle one and are offered only the ends.
Ownership: Every record has an owner. Ownership is about accountability rather than secrecy: it says who is responsible, and it is what a scoped role is scoped by.
Sensitivity: A record can be marked sensitive, which requires a grant held separately from the role. Giving someone the ability to do their job does not quietly give them everything.
Not allowed against not included: Being refused because of your permissions and because of your plan are different answers to different questions, and the product says which. A system returning one message for both teaches people to stop reading messages.
The audit trail: Who changed what and when, including any access by us. No entry can be rewritten or removed by an administrator, by an owner, or by anyone here. Erasing a person blanks the values in the entries about them and leaves who, what and when standing, which is the one exception and exists so that the trail cannot defeat the erasure.
Support access: Nobody at Consonas can open your organisation without a stated reason, a second approver, and an entry in your own audit trail which you can read without asking.
Members: Added and removed by you, immediately. Somebody without an account is sent a link that makes one and takes the seat, and the invitation counts against your seats while it waits. Removing someone ends their access, asks who inherits the records they owned, and changes nothing about the history, which stays attributed to them.

A system that says permission denied both when your role forbids something and when your plan does not include it trains everybody to ask an administrator first, and the administrator to shrug. Six months of that and nobody reads the message at all.

Which is why the product uses different words for them, and why that is worth caring about.

What happens when support needs to look at your organisation

There is no console

No one at Consonas has a database client pointed at your organisation, and there is no internal screen that shows a customer's records on demand. The only route in is through the product, and it is deliberately narrow.

A reason, and a second person

Opening your organisation requires a stated reason and approval by a second operator. The second approver is the part that matters. A control one person can complete alone is a control that will eventually be completed alone, at two in the morning, by somebody meaning well and under pressure. Requiring two people is inconvenient precisely when the inconvenience is the point.

And an entry you can read

The access appears in your own audit trail, with who and when and the reason given. You do not have to ask us for it, and we cannot remove it. If you ever want to know whether anybody here has looked at your data, the answer is in your organisation rather than in a policy document.

The honest limitation

This makes support slower. Someone reporting a problem occasionally has to wait for a second person to be available, and there are questions we cannot answer instantly because we cannot simply look. That is a real cost and we think it is the right trade, and we would rather describe it than pretend the control is free.

Ten minutes now

Setting roles up once, properly

Ten minutes now against an afternoon in eighteen months. Almost every organisation gives everyone everything on day one and lives with it until something goes wrong.

Start from what people do, not from a hierarchy

The instinct is to build roles that mirror the organisation chart: director, manager, staff. It produces roles that are about status rather than about work, and the first person who does not fit the chart breaks the model.

Ask instead what someone needs to be able to do to get through their day. In most small organisations that produces three or four roles and they are usually named for jobs rather than for seniority: somebody who works the pipeline, someone who answers the enquiries, someone who does the books, somebody who runs the place.

Then decide what nobody should be able to do casually

Exporting everything. Deleting a record. Changing somebody else's role. Reading a record marked sensitive. These are the four that matter, and the honest question is not who is trusted, it is what happens on the day an account is compromised.

Every one of them is recorded in the audit trail whoever does it. That is the reason the answer can be generous where it needs to be: the protection is not only that few people can, it is that everybody who did is named.

Sensitivity is a separate decision from ownership

This is the part people get wrong most often, and it is the part that makes the product usable by trades that would otherwise need two systems.

Ownership says whose work this is. Sensitivity says who may read it at all. A role that can read everything still cannot open a sensitive record it has not been granted, and that separation is what lets a recruitment agency hold clients and candidates, or a charity hold donors and beneficiaries, in one place without the wrong half being visible to the wrong person.

Require two factor before you invite anybody

It is on every plan including the free one, an owner can require it for the whole organisation from the settings screen, which also lists whoever has not enrolled yet, and it is the single change that most reduces the chance of the story that begins with a password reused from a service that was breached. A passkey counts as the second factor, because it already is one: somebody signing in with a passkey is not asked for a code as well.

Doing it first is easier than doing it later, because requiring it retrospectively means asking eight people to stop what they are doing on the same afternoon. The National Cyber Security Centre has said the same thing for longer and more carefully than we have.

Write down why, somewhere

A note in your own records saying what each role is for. In two years somebody will ask why a role exists, and the answer will otherwise be that it was created for a person who has left.

How access quietly widens

Six ways permissions go wrong

None of these is exotic. All six are the ordinary result of decisions made quickly by people with something else to do.

Everyone is an administrator

The symptom is that no one has ever been refused anything. The cause is that the first time someone could not do something, the fastest fix was to raise their role, and it was never lowered.

The consequence is not that people misbehave. It is that a single compromised account is a compromise of everything, and that the audit trail stops being able to tell you anything useful about who could have done something, because everyone could.

Roles named after people

The symptom is a role called something like office setup or the name of someone who left in 2023. The cause is a role created to solve one person's problem rather than to describe a kind of work.

The fix is to rename it for what it does and see whether anybody else should have it. Usually two of these can be merged, and the merge is the point at which someone finally reads what they actually grant.

A leaver still has access

The symptom is an account no one has signed into for four months. The cause is that removing access is not part of anyone's leaving process, because the leaving process was written before the system existed.

Review the member list quarterly. It takes two minutes. Removing somebody asks who should inherit the records they owned, so the reassignment happens at the moment of removal rather than as a second job nobody remembers: unowned records are the ones that go quiet.

Sensitivity used as a filing system

The symptom is half the records marked sensitive. The cause is somebody using it to mean important rather than restricted.

Sensitivity should be rare enough that seeing it means something. When most things are marked, the marking carries no information and people start asking for blanket grants, which removes the protection entirely while leaving the inconvenience.

One person can do everything alone

The symptom is that the same name appears on both sides of every approval. The cause is an organisation small enough that this felt unavoidable.

The product refuses in the places where it matters most: an owner cannot remove their own ownership while they are the only one, and one person cannot approve their own contract. Those refusals are protections for the organisation against a single account rather than statements about the person.

No one has ever read the audit trail

The symptom is a question about what happened being answered from memory. The cause is that the audit trail is thought of as evidence for a dispute rather than as a working tool.

Read it once, deliberately, in a month when nothing is wrong. It is considerably more useful than people expect for ordinary questions, and knowing what it contains is worth far more before an incident than during one.

The entry itself

Eleven columns, and the two that are copied rather than looked up

What one line of the audit trail actually holds, and why each part of it is there.

When, who, and in what capacity

Every entry carries the moment it happened, the person who caused it, and the role that person held at the time. The third of those is the one no one expects and the one that matters most in an argument. Storing the role as it was means a promotion in March does not quietly turn a change made in February into something an administrator did. The trail describes the organisation as it was, not as it is now.

When somebody at Consonas is acting under an approved support grant, the person recorded is the support member and the role recorded says so. It is never written under the name of the member whose view was being used. That single choice is what stops a support session from being indistinguishable, afterwards, from your own staff working normally.

What was done, and to which record

The action is written as the thing and then the verb: a contact created, a lead captured, a role changed, a record shared, an export taken. Beside it the entry names the table and the identifier of the record concerned, which is what lets the history of one record be pulled out of the whole trail without reading the whole trail.

Some actions belong to the organisation rather than to any one record. Exporting everything is the obvious one. Those entries carry no record at all, and reading them needs administrative access instead of a scope over records, because an organisation level action is not anyone's to see by virtue of owning something.

The change itself, as before and after

Where a change altered fields, the entry carries each field with the value it had and the value it was given. Not a description of the change and not a new copy of the record, but the pair. The question asked after something has gone wrong is almost never what does this say now, it is what did this say before someone touched it.

A role is written the same way, which means the entry recording that someone widened a role holds the whole definition as it was and the whole definition as it became. Eight months later, who widened this and by how much is a question with an answer.

An update that changed nothing writes nothing. Saving a record without altering a field produces no entry, because a trail that fills with lines saying that somebody looked at a form and pressed save is a trail nobody will read when it counts.

Two facts copied from the record rather than looked up

The last two columns are the owner of the record and whether it was marked sensitive, as both stood at the moment of the change. They are copied onto the entry rather than read from the record when someone comes to look, and the reason is that the entry has to be able to stand on its own.

Visibility of the trail is decided from those two copies. A record that has since been deleted therefore does not take its own history out of reach, which is precisely the case where the history is most wanted. The uncomfortable half of that trade is the other direction: entries written whilst a record was marked sensitive stay restricted even if the mark is later removed, so the trail is slightly more cautious than the live record it describes.

Nothing outside the database can write it, and nothing writes it late

Every line is appended from inside your own organisation's database object. There is no route, no token and no support tool that adds one from outside, which is the property that makes the trail worth reading at all.

Inside, thirteen places write it, and that is worth stating rather than rounding down to one. Almost every staff action goes through a single function. The other twelve exist for the moments that carry no staff session: a visitor filling in a form, a customer replying through the portal or deciding a quotation by a signed link, an authorisation screen coming back with a mailbox connection, the platform recording that support was given access. Those are exactly the events an organisation most wants in its own trail, and they have no session to be written from.

What every one of them shares is the part the guarantee rests on. Each runs inside the same transaction as the change it describes, so a change that is rolled back cannot leave an entry claiming it happened, and an entry that fails to write takes the change down with it. No caller can forge a line, and no caller can suppress one.

The order

Denials beat roles, and a share is the last question asked

The decision is a fixed sequence rather than a calculation, which is the only reason it can be explained to someone who has just been refused.

Membership and plan first, before the record is even loaded

Two questions are answered before anything about the record is read: are you a member of this organisation, and does this organisation have the module the request belongs to. Neither needs the record, both are cheap, and answering them first is what keeps the two refusals distinguishable. Not a member and not on your plan are different sentences from your role does not allow that.

Then an explicit denial, which nothing overrides

A denial names one record and one person, carries a reason, and can only be set by somebody with administrative access. It is checked before anything else and it wins against everything, including a role that reaches the whole organisation. It is the closest thing here to an information barrier around a single file, and it is deliberately the bluntest instrument in the model.

Then sensitivity, which can only subtract

A record marked sensitive is checked next, and the check can only take access away. There is no path by which the mark grants anything to anyone. Putting it above the role in the order is what makes the sentence a role that can read everything still cannot read this true rather than aspirational.

Then the role, at the scope the grant carries

Only now is the role consulted, and it is consulted as a pair: does it carry this action at all, and does the scope on that action reach this particular record. Holding the action and not reaching the record is a different refusal from not holding the action, and the product keeps them apart because the fix is different. One is a role change. The other is a question about who owns the record.

Then a share, and only then

A record shared directly with someone is the last thing asked, which makes it a way of widening one record rather than a way round the model. Giving a share away requires more than being able to edit the record: you have to hold the level of access that could delete it. The person who can amend something is not automatically the person who may decide who else sees it.

A refusal that names the rule that made it

Four refusals come out of that sequence and they are worded differently on purpose: there is a denial on this record, this record is marked sensitive and the role does not carry the additional grant, the role does not carry this action at any scope, and the role carries this action but not for this record. An administrator can ask the product why a particular person can or cannot do a particular thing to a particular record and gets the rule that decided it instead of a yes or a no.

What was rejected

The alternative most systems reach for is additive: permissions accumulate from several places and the answer is whatever the sum comes to. It is flexible and it is impossible to reason about, because no one can hold the sum in their head, and the failure mode is an access no one granted deliberately and nobody can find the source of.

A fixed order costs expressiveness. There are arrangements you cannot describe here that an additive model would let you build. In exchange, every answer the system gives can be traced to exactly one rule, and an administrator can predict the answer before asking.

The same rule, compiled into the query

A list does not fetch everything and then hide the rows you may not see. The scope becomes part of the database query, so records outside it are never read in the first place. Filtering afterwards leaks through counts, through totals and through the paging: a page of ten that arrives with four rows tells the reader that six things exist. The two paths have to agree, so a test generates records and asserts that deciding one record at a time and querying the whole list give the same answer.

The hard cases

The person who is in two teams, and the record that has no owner

Permission models are easy to describe on the ordinary case. These are the ones that decide whether the description was worth anything.

Someone who belongs to two teams

Team scope means the records you own, plus the records owned by anyone who shares a team with you. Someone in two teams therefore reaches both, and that is intended rather than tolerated: in an organisation of this size the person who sits in two teams is usually the one who genuinely needs to see both. It is worth knowing before you put someone in a second team as a convenience.

Somebody who belongs to no team

A role scoped to a team, held by a person who is in no team, resolves to their own records and not to everything. That direction is chosen deliberately. The other reading, where an empty list of teams matches every team, is the sort of quiet failure that hands the whole database to a new starter on the day somebody forgot to add them to anything.

A record with nobody as its owner

Own and team scopes are both defined against the owner, so a record with no owner is outside both of them and only a role scoped to everything will see it. Imported records that arrived without an owner, and records left behind by someone who has gone, are the two ways an organisation ends up with them. It is the practical reason to reassign a leaver's records rather than only removing their access: the records do not become everybody's, they become no one's.

An entry about a record that no longer exists

Deleting a record does not delete its history, and the trail decides who may read that history from the owner recorded on the entry rather than from the record, which is gone. A deletion is therefore not a way to make the account of a deletion disappear along with it. A contact removed by mistake also sits in the bin for thirty days before it is purged for good, and whilst it is there it is visible to exactly the people who could see it before, so the bin is not a way round who may see whom either.

A role widened after the fact

Changing a role changes what its holders can do from that moment. It does not reach backwards: entries already written keep the role that was actually held at the time, so widening a role never rewrites the history of the people in it. The change itself is recorded with the full definition before and after, which is what makes the widening findable at all.

The administrator who cannot give away what they do not have

Writing a role is checked against the grants of the person writing it, in action and in reach. An administrator whose own access stops at their team cannot define a role that reaches the whole organisation, and cannot then assign that role to themselves. Without that rule, the ability to edit roles is quietly the ability to hold every permission, which makes every other restriction decorative.

The same person as a member and as a customer

Someone who works for you and also appears in the customer portal is two different principals, not one person with two hats. The portal is a separate boundary with its own rules, and support cannot view the platform as a portal user at all, at any level of approval, because doing so would be a way to read a third party's information with no justification anyone could write down.

A share and a denial on the same record

The denial wins, because it is asked first. Sharing a record with someone who has been explicitly denied it does not quietly reinstate them, and there is no ordering of the two actions that produces a different answer. Sharing one record of a type that your organisation defined for itself currently grants nothing instead of guessing at what it should mean, which is a real limitation and is the honest state of it.

Eight months later

A surveying practice of seven, from an awkward instruction to a question eight months later

Entirely hypothetical, and followed the whole way so that what gets written down at each step is visible.

What they set up on the first afternoon

Two directors, four surveyors and someone who runs the office. They keep the starting roles for the directors and define one of their own for the surveyors, based on the standard role and narrowed: reading everything the practice holds, changing only what they own. The office manager gets a role that can book, invoice and chase, and cannot delete a client. Three roles for seven people, and a note in their own handbook saying what each one is for.

Defining that role writes an entry naming the director who wrote it and holding the whole definition. Because a director holds everything, the guardrail that stops someone granting what they lack does not bite here, which is the ordinary case: it exists for the afternoon in three years when an office manager has been made an administrator.

The instruction that is awkward

A boundary dispute arrives between two neighbours, and the practice is already acting for one of them on something else. One surveyor is related to the other party by marriage. Nothing improper has happened and nobody wants an argument about it later.

A director sets an explicit denial on that client record naming that surveyor, with the reason written into it. From that moment the record is closed to that one person. Opening it is refused, and search does not return it either, because every hit is decided against the record itself before it is shown rather than being trusted from the index. The denial is itself an entry in the trail, with its reason, its author and its moment.

What accumulates over the following months

Ordinary work writes ordinary entries. The client's status changes twice, each time with the old value and the new. A surveyor is added to a second team so they can cover a colleague's patch, which is a permission change and is recorded as one. The office manager takes a complete export in March before a software review, and that is recorded too, because a member taking a copy of everything the practice holds is at least as worth showing as anything else in the trail.

The question, eight months later

The dispute goes to a formal complaint and the practice is asked whether anyone with a connection to the other party had access to the file. The director opens the record's own history and reads it: the denial, its stated reason, the date it was set, and no entry anywhere from that surveyor against that record.

What the trail cannot say is whether that surveyor ever read the file before the denial was set, because reading is not recorded. That limit is a deliberate one and it is worth knowing about before you need the answer rather than during. What the practice can show is who could have reached the record, from when, and that nothing was changed by anybody who should not have been there. In most complaints of this kind that is the question that was actually being asked.

The surveyors, incidentally, cannot read any of this. The audit trail is governed by the same scope as the records it describes, so a role without a grant over the trail sees none of it, and one scoped to a team sees the entries about that team's records. The history is not a second database sitting outside the permission model.

Where the model stops

What the permission model refuses to do

No field level permissions. Access is decided at the record, not at individual fields on it. A model where one person sees a record with three fields blanked out is considerably harder to reason about than one where they either see the record or do not.

No approval workflows you design. The second pair of eyes on a contract is one switch, on or off for the whole organisation. There is no interface for building your own chain of approvers, and if that is a hard requirement it is worth saying so.

No time or location restrictions. No blocking sign in outside working hours, no restriction by address range, no device management. These belong to an identity product, and organisations that need them should connect one through single sign on.

No alerting on the audit trail. It is readable and searchable. Nothing watches it and tells you that somebody exported everything at two in the morning. That is a real gap instead of a position, and it is the kind of thing worth writing to us about.

No delegated administration by team. Roles are organisation wide. There is no model where one person administers one department and cannot touch another.

The vocabulary

What these terms mean here, and what other systems call the same thing

Two people arguing about access are usually using one word for two things. This is the vocabulary, and where it differs from what you have used before.

Permission: A key of three parts, read as the module, the kind of record, and the action. Updating an opportunity is one. Nothing here is a permission over a screen: there is no key meaning access to the reporting page, because a screen is a way of reaching records instead of a thing to be protected.
Grant: A permission paired with a scope. The pairing is the whole idea. Updating opportunities owned by my team is one grant, rather than a permission plus a separate sharing rule that somebody has to remember to keep in step with it.
Scope: Which records a grant reaches: none, own, team, or all. Four words, no hierarchy and no inheritance by seniority. A manager sees more because their grants say so, not because they sit above someone on a chart.
Own: Records whose owner is you. Ownership rather than authorship: the person who typed a record in is not thereby the person accountable for it, and in most organisations those two diverge within a month of starting.
Team: You, plus anybody who shares a team with the owner of the record. Somebody in two teams reaches both. Somebody in no team reaches only their own records, never everything, which is the safe direction to resolve an empty list in.
All: Every record of that kind in the organisation, still subject to sensitivity and to any explicit denial. All is the widest scope rather than an exemption from the rest of the model.
Sensitive: A mark on a record that only ever subtracts. It is checked before the role is consulted and it grants nothing to anybody, which is what makes the sentence about a role that reads everything and still cannot read this one true rather than aspirational.
Share: An explicit level on one record for one person: view, edit, or full. It is the last question the decision asks, and giving one requires the level of access that could delete the record rather than merely edit it.
Denial: An explicit refusal of one record to one person, with a reason recorded, set by someone with administrative access. It is asked first and beats every grant. Most systems have nothing of the sort, which is why an information barrier usually ends up as a second database.
Subject owner: The owner of a record as it stood when an audit entry was written, kept on the entry itself. It is what decides who may read that entry, so the history of a deleted record does not become unreachable at the moment someone wants it.
Effective permissions: The plain list of what a role actually allows, in one place. Elsewhere this is something an administrator computes for themselves from a profile, a handful of additional permission sets and a hierarchy, and getting it wrong is the ordinary way an organisation discovers what it had granted.

Asked about roles

Asked about permissions

Why are roles defined per organisation rather than being a fixed list?

Because the word your business uses is the word your staff will look for. A fixed list forces every organisation to translate: your partners become administrators, your engineers become users, and everybody performs a small mental conversion every time they think about permissions. The people who perform it least reliably are the new ones and the busy ones, which is exactly when a permission mistake gets made.

What is the difference between ownership and sensitivity?

Ownership is about allocation and accountability: who is responsible for this record. Sensitivity is about confidentiality: this particular record should not be visible to people who can otherwise see records like it. They are separate because combining them forces a false choice, where an organisation either makes managers owners of things they do not manage, or marks half the database sensitive until the mark means nothing.

Does the audit trail record people reading records?

Records marked sensitive, yes: opening one writes a line saying who opened it and when. Everything else, no, deliberately. A trail that logs every record opened becomes unreadable within a week, and an unreadable trail is not evidence of anything. It also turns the customer history into a surveillance log of your own staff, which changes how people use the system and not for the better. Sensitive records are worth the exception because they are the ones somebody is later asked to account for.

Can an administrator edit the audit trail?

No. Nobody can rewrite an entry or remove one, including us. That is the only property that makes an audit trail worth having, because a trail someone can tidy up is a diary. The one exception is erasure, which blanks the values inside the entries about the erased person and leaves who, what and when in place, because a trail that kept what somebody was entitled to have removed would defeat the erasure. It is on every plan including the free one, for the same reason: an organisation that cannot afford a paid plan does not deserve worse evidence when something goes wrong.

What happens to somebody's history when they leave?

It stays, attributed to them. Removing them as a member ends their access immediately and changes nothing about the record of what they did. A history that can be emptied by an offboarding is worth nothing at exactly the moment somebody needs it.

Can Consonas staff see our data?

Not without opening your organisation through the product, which needs a stated reason and a second person to approve it, and which writes an entry into your own audit trail that you can read. There is no console onto a customer database and no standing access. The second approver is the part that matters: a control one person can complete alone will eventually be completed alone.

How many roles should we create?

Fewer than you think. Three or four covers most organisations of under fifty people: somebody who runs it, someone who does the work, someone who sees their own, and occasionally somebody read only. Eleven roles is usually a sign that someone is modelling job titles rather than permissions, and it produces a system nobody can reason about.

What is the difference between permission denied and not included?

Permission denied means your role does not allow 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. They are different sentences because they are different problems, and a system that returns one message for both trains everybody to ask an administrator first and the administrator to shrug.

Two populations, one database

The trades that would otherwise need a second system

Sensitivity being a separate decision from ownership is what lets one database hold two groups of people who must not be able to read each other. Solicitors and law firms need it for the information barrier around one client. Recruitment agencies need it because clients and candidates are in the same system and neither should see the other's file.

The pattern repeats with different words in healthcare administration, where reception books and does not read correspondence, in charities, where donor records and safeguarding notes sit in one place, and in financial services, where the question asked afterwards is who could have reached the file rather than who did.

The order the decision is made in, and the reason a denial beats everything else, is the same on all four.

Set up the roles before you invite anybody

Three or four roles in your own words, and sensitivity configured before the first import, is ten minutes that is difficult to retrofit later.

Start free Choosing the right role

Three people, a thousand relationships, no card and no time limit.