Contents
There's a question that turns up in every procurement round we go through, usually from the compliance side of the table, and it's always some version of this:
If I put a case on your platform that half my staff must never see, what stops them?
The standard vendor answer is "granular role-based permissions", which sounds like a specification and lands like a shrug. Every system has roles. What matters is what a role actually gates, and what happens on the case where roles are the wrong instrument entirely.
So here's ours, as a mechanism, in the order it runs.
Five checks, each able to deny on its own
Role decides what someone can do at all. Roles bundle capabilities: standard user, team leader, internal admin, plus narrower ones for specific powers such as administering file tags or approving other people's permission requests. It's the layer everyone has and the least interesting one, because it describes somebody's job and says nothing about the case in front of them.
Workflow visibility decides which processes they see. Set per team member, per workflow, and down to individual statuses. Someone handling intake can be given the first three stages of a process and nothing after them. This is where most operations do their real segregation, because it maps onto how work is actually divided.
Restriction decides whether the task type needs more than a role. A product can be marked restricted, and holding the right role stops being sufficient. Access then depends on an active assignment on the case itself. Allow rules whitelist by case relationship, deny rules override them, and a deny always wins over an allow. Two override roles exist for the cases where somebody genuinely does need to see everything, and holding one is a deliberate, visible decision.
Case relationship decides what they see on this case. The same person can be case owner on one file, an expert on the next, and a stranger to a third. Notes and forms are made visible to relationships instead of named individuals, which is the only version of this that survives contact with staff turnover. Nobody maintains a list.
Field-level rules decide what renders once they're through. Forms, actions and note boxes each declare which user types can see them. Visibility rules hide content until named questions have been answered. Files carry their own permissions, held separately from the document templates that produce them.
A request has to satisfy all five. Any one of them refusing ends it there.
Hiding a case and forbidding a case are different settings
This is the distinction I'd most want a compliance buyer to notice, because it's the one that's usually missing.
Most systems let you stop someone opening a record. Far fewer let you stop the record advertising its own existence. If a user can see that case 24-11832 exists, that it's assigned to the head of legal, and that it moved status yesterday, you've leaked most of what mattered before anyone tried to open anything. Counts leak. Search results leak. A report with a row they can't click leaks.
So restriction and listing suppression are configured independently. A restricted task type can be kept out of listings entirely for anyone without access, which means it's absent from counts, absent from search, absent from reports. Or it can remain visible while staying unopenable, which is right for a case whose existence is fine to know about and whose contents are not.
Getting to choose is the point. An HR investigation and a high-value claim want opposite things here, and a platform with a single setting forces both into the same shape.
Asking for access, on the record
The failure mode in most operations has nothing to do with the permission model. It's that someone needed access on a Tuesday afternoon, asked an administrator who was busy, and got given a broader role because it was quicker than working out the narrow one. Six months later nobody remembers why they have it.
Permission requests exist to make that path harder than the correct one. A user requests a role. It sits pending. Only someone holding the permissions-manager role can grant or deny it, and the buttons are hidden from everyone else, so the wrong person never reaches a click that fails. The request, the decision, and who made it are all recorded.
That gives you what an access review actually needs. A list of who currently holds what describes the state. The history describes how it got there, and the history is where auditors push.
Where this bites in practice
Three situations we see repeatedly.
Contractors and outsourced teams. They need the cases assigned to them and nothing else. Restricted products with an allow rule scoped to their case relationship does exactly that, and the moment an assignment ends so does the access. No offboarding task to forget.
Investigations and complaints involving staff. A complaint about a named employee cannot be visible to that employee, who may well be a system user with a legitimate role. Deny rules on the relationship, combined with listing suppression, handle a case that a role-only model cannot express at all.
Client portal users. External users see their own cases through the same engine, gated by relationship. Worth stating plainly because a separate portal codebase is the usual answer, and a separate codebase is a separate set of access bugs.
The honest limitation
Five layers is more configuration than most operations need, and configuration is a way to get things wrong. A workflow visibility rule and a restriction rule can disagree, and the answer is that the case stays hidden, which is the correct direction to fail but can be confusing to debug at four in the afternoon.
Our advice is always to start restrictive and open up, because widening access after someone asks is a two-minute change with a record attached, while discovering that a case was visible for eight months is a conversation with your regulator. Every one of these layers has a default, and the defaults are the cautious version.
The thing worth taking from all this is that "who can see which cases" deserves a mechanical answer during evaluation. Ask any vendor to describe their layers in order and say which one handles a complaint about a member of staff. The answer tells you whether the model was designed for regulated work or assembled from whatever the framework provided.
Further reading:
- Security: certifications, hosting and the full access-control picture
- Users and permissions: roles, workflow visibility and the user log
- Tasks, notes and logs: case relationships and note visibility
- Timeline: the audit trail behind every permission change