Decide what each person can see and do.

Every box does something.

For a while, ten of these boxes did nothing. They sat in the editor, could be ticked and unticked, and nothing on the server checked them: unticking “Send SMS” for a role changed nothing, and anybody signed in could read the whole company’s message history or delete any voicemail in it. That was never one customer seeing another’s data; it was the gap between what the editor promised and what the server did, which is a hard defect to notice.

So every box now has a test that gives a role only that one box and checks both directions: the screen it should reach, and the neighbouring one it should not. Checking only the refusal would pass just as well against a server that refuses everything, which is the sort of test that makes a gap feel closed.

Three ready-made roles, and as many of your own as you like.

Every company starts with the three below, and nobody can change or delete them, not even you. The reason is narrow and real: editing them would let somebody untick, on the role they hold themselves, the boxes that let them into the role screen, and there is no way back in from there.

A role of your own that people still hold cannot be deleted from under them. You are told how many hold it and asked to move them first, because deleting it would change what those people can do without anybody deciding that it should.

One thing a role does not decide: which teams somebody answers for. A role says whether you may create a team and choose who is in it. Being in one belongs to the person, not to their role, so two people with identical roles can be answering completely different calls.

You cannot lock yourself out.

Take away, from the role your only administrator holds, the two boxes that let somebody invite people and edit roles, and nobody in the company could administer anything again: not invite an administrator back, not edit a role, not reach billing. Getting out of that would mean us going into the database for you. So the product refuses to do it, on every path that could get there.

The refusal tells you the way out rather than just saying no: give somebody else an administrator role first, or keep one of those two boxes on this one.

Your company’s records are yours alone.

Every customer’s records sit in the same database, and every row carries the company it belongs to. Which company you are is worked out from your signed-in session, never from anything a request says, so there is nothing to tamper with. And a suite of automated checks exists only to try one company’s session against every other company’s records and prove that all of it fails.

Some things are company settings, not role settings.

Two questions do not fit a role, and forcing them into one is how the answer ends up depending on which screen you opened.

Recording is the clear case. Whether calls are recorded at all is one setting for the whole company (always, the person’s choice, or never), with a second switch for whether the person on the call may stop one that is already running. The role decides who may press record and, separately, who may play a recording back afterwards. The company setting decides whether pressing it was ever on the table.

How it works underneath

The catalogue is 35 permission keys in 7 groups, owned by source code rather than by a table, served to the role editor by the same server that enforces it, and resolved into effective permissions on every request, in the same query as the account check.

What a system role grants is read from the code at the moment of the decision; the copy stored beside it in the database is kept in step but never gets a vote, so a stale or hand-edited row cannot widen Supervisor or narrow the Agent role. A custom role is validated against the catalogue when it is saved, and an unknown key is a validation failure rather than a string stored and ignored.

The ten unenforced permissions were never a cross-tenant leak: every query was already scoped to its tenant, and a separate suite proves that. Before their routes began refusing anybody, a read-only report ran over the roles that actually existed to say which of them would lose access the moment enforcement started. A refusal now names the missing keys rather than only that something was missing, since anyone who can edit roles can read the whole list anyway.

The last-administrator guard lives in the service that every path goes through, not on a form: demotion, deactivation, role reassignment, role deletion and permission edits. The permission-edit variant looks for an administrator somewhere other than the role being edited, because unticking a box demotes every holder of that role at the same moment. When an edit does go through, every holder’s credentials are invalidated and they sign in again; authorization itself changed the instant the row was written.

The tenant id on a request comes from the verified session token and from nowhere else; no route handler reads one out of a body or a query string. A second guard turns a request with no tenant on it into a refusal, because the data layer treats a missing filter as no filter. The isolation suite runs one tenant’s session against every tenant-scoped router in one pass and asserts that each fails as not found rather than not allowed, so the response never confirms the record exists. Customer sessions and operator sessions are signed with different keys, and the second is derived from the first by HMAC over a domain string rather than set as a second secret, so a token missing its claims fails at the signature and there is no way to deploy without the separation.

Questions people ask

How do I remove somebody’s access when they leave?

An administrator, or anybody whose role can manage people, deactivates their account. Their live sessions are ended there and then, and every pass already issued stops working the next time it is used rather than running out on its own clock. Their name stays on the calls they handled, because a call record has to say who answered it. Nothing outside Ringfully will do this for you, so it belongs on the list you work through on somebody’s last day.

Can I stop somebody listening to recordings?

Yes. Playing a recording back is its own box, separate from the one that lets somebody press record during a call, so a person can be able to record and not able to listen afterwards, or the other way round. Untick it on their role and the change is in force on their very next click.

What recording looks like during a call

Who can see the call history?

Whoever you tick it for. Your own calls and the whole company’s are two separate boxes, which is one of the few places the list draws a line between mine and everyone’s. Everything else is company-wide: a role that can see contacts sees the whole book rather than one team’s corner of it.

Can two people share a role?

Yes, and that is the ordinary case. A role is a list of ticked boxes and as many people as you like can hold the same one, which is why editing it changes what all of them can do at the same moment. A role people still hold cannot be deleted from under them either: you are told how many hold it and asked to move them first.

What happens to their number when somebody leaves?

Numbers belong to your company rather than to the person, so nothing about them changes when an account is deactivated. If a number rang that person directly it keeps pointing at them until somebody reassigns it, and their short internal number stays taken until you clear it. Both are worth doing the same afternoon as the deactivation.

What this does not do

People sign in with an address and a password kept here. There is nothing to connect to whatever your company already uses to let people in, so an account on Ringfully is one somebody creates here and removes here. And removing it is a thing to remember when a person leaves, because nothing outside will do it for you.

A permission means the same thing everywhere it applies. Apart from your own call history against the organization’s, there is no narrower slice of the data to hand out: a role that can see contacts sees the whole book, not one team’s corner of it. If what you need is a role that only reaches part of the company, that is a real gap rather than a setting we have hidden.

Nothing here is temporary. A permission stays granted until somebody unticks it; there is no grant that lapses on its own on Friday, and nothing asks a second administrator to approve the change before it takes effect.

And roles belong to one organization. There is no group directory somewhere else to take membership from, and no role written once and pushed to several accounts: who holds what is set in the portal, by a person, per company.

If one of those is the thing your review will actually stop on, say which in the first email. We would rather tell you where it really stands than have you find out on the second call.