Permissions are a matrix, and the server is the one enforcing it
Roles are built in a visual editor, one tab per resource, with read, create, update and delete taken separately. Nothing is a tier, nothing needs a deploy, and none of it is enforced by hiding a button.
Three ways permissions quietly stop holding
Three plan-shaped roles, so somebody gets rights they never needed to do their job.
The button is gone but the address still works, which is not a permission at all.
One sensitive record means an entire project gets walled off from the client.
A matrix you edit in the panel, not in a deploy
The role editor gives each resource its own tab, and each tab read, create, update and delete. You can grant every read in the product with no writes, or writes on tasks and nothing else. Grant All and Revoke All exist so you can start from everything and take things away rather than clicking eighty boxes.
Three Access To boxes decide which of the three apps a role can open at all. Organisations and projects carry an extra choice between everything and only what the person is a member of. A role is Internal or External, and an External role never sees internal records.
- Seven roles are seeded so you can work before designing a permission model
- The casing you type is the casing everyone sees
- Two resources gate a whole page: the error log and access requests
Per record, and absent rather than hidden
Every record carries a privacy level, internal or external. Internal means invisible to anyone on a client role, and that holds in the records they can load, in the counts and stat tiles, in search and in the notification fan out. It is enforced on the server, so there is no address to guess and no view to reload your way around.
The level is set in the create dialog and changed from the same panel that carries status and priority. Privacy carries through triage, so an internal request becomes an internal issue. Older records with nothing set read as internal, which is the safe direction to fail in.
- A single sensitive record can be internal without walling off the project
- Tasks and subtasks default to internal
- Trackers show the level as a badge next to the title, so it is checkable at a glance
Rotate the credentials the old vendor still holds
Being able to list a project is not being able to open it
A role can be allowed to see every project in an organisation while membership still decides which ones somebody works in. Opening one they are not on shows an access screen with the project name and a way to ask, rather than an error, and a note of up to 500 characters if it helps whoever decides.
Requests reach everyone who can decide them, in the app, by push and by email. Approving adds the person to the project and to its support chat in one step. Declining asks for an optional reason, which the requester is shown along with another attempt.
- Asking is capped at twice a day for the same project and five times in total
- The queue is a project tab in both the admin panel and the team workspace
- Read decides who watches the queue, update decides who answers it, and client accounts never get either
Access requests · pending
A role change reaches a page that is already open
Permissions are re-read on every request, so a role you fix now applies on that person's next click. The team workspace and the client portal pick the change up as it happens; the admin panel applies it when you come back to the tab. Nobody signs out and back in, and there is no cache to clear.
A role people still hold cannot be deleted. The number of holders is shown instead, so it can be reassigned first. The seeded Admin role is locked outright and has no actions menu at all.
- Organisation membership is the gate for being addable to a project, not permission to see one
- Whoever creates an organisation or a project is a member of it from the start
- Every member table records who added somebody and when
Presence, files and what a meeting kept are three separate decisions
Presence is yours to show. Two switches in Settings hide whether you are online and when you were last seen, and hiding yours stops you seeing other people's, which is the only honest way round that trade. Somebody who has hidden their last seen does not have it sent to colleagues' screens at all, rather than hidden once it has arrived.
Files and meeting artefacts are decided rather than inherited. Sharing a file with a client needs the right permission, is a deliberate step rather than a consequence of uploading it, and is written into the project's activity. Any finished meeting carries a Sharing tab where anyone who can approve project access chooses, per person, what is handed over, and it reaches people who were never on the call as well as the people who were. A client opens exactly what was switched on for them: the recording, the transcript, the summary or nothing at all. A colleague gets the meeting on their calendar and, where it is switched on, the recording with it.
- Changing a link or a note the client already sees needs the same permission as sharing it
- Requests from clients land in that same tab, with the note they wrote
- Every grant can be tightened again later, and an empty set of scopes is a revoke
- A session lasts while it is being used, and ends thirty days after it began whatever happens
The things teams ask about this
Do you have to change a permission for us?
No. Roles are built and edited in the admin panel by whoever runs your deployment, with no ticket to us and no release to wait for. Permissions are re-read on every request, so a role edited now takes effect on the next click the affected person makes.
Is a permission the same thing as a hidden button?
No, and the difference is the point. A resource a role cannot read is absent rather than concealed: missing from lists, from counts and stat tiles, from search, and from the notification fan out. Because it is enforced on the server, there is no address to guess and no reload that gets around it.
How many times can somebody ask to join a project?
Twice a day for the same project, and five times in total, so a decline cannot turn into a queue of reminders. At the daily limit the screen says to ask again tomorrow; at the lifetime limit it points them at an administrator, who can add them directly. Every attempt is kept with its outcome, who decided it and when.
Can we remove a role people are still using?
Not while they hold it. The panel shows the number of holders instead of deleting, so the role can be reassigned first, and the seeded Admin role is locked outright with no actions menu. Filter the users list by role, edit each person onto a new one, and then remove it.
Can a client account ever approve access to a project?
No. The Access Requests resource is never granted to client accounts, so the queue is not something an external role can read or decide. Asking, on the other hand, needs nothing extra: anyone who can read projects can request access to one.
See it against your own work
Thirty minutes on a call, one of your real client projects on the screen, and an honest answer about whether this part of the product earns its place in how you work.
partnerships@dhcertainty.com