Access in DOK Genius is not one list of permissions. It is four things that combine, and knowing which layer you are in is what makes "why can this person see that?" a question with an answer.
| Layer | Decides |
|---|---|
| Organisation | Whose data exists at all |
| Organisation unit | Which part of the company a case belongs to |
| Process | Which templates a person may use |
| Dossier | Who is on this particular case |
They narrow in that order.
Build the chart
Open Organisation structure. Units come in three types, and they form a tree:
| Type | What it is |
|---|---|
| Company | The top |
| Branch | A site, a region, a subsidiary |
| Department | A team inside one |
For the insurer, build this:
Acme Insurance (Company)
├── Lisbon (Branch)
│ ├── Claims (Department)
│ ├── Underwriting (Department)
│ └── Compliance (Department)
├── Porto (Branch)
│ ├── Claims (Department)
│ └── Underwriting (Department)
└── Head office (Branch)
├── Procurement (Department)
└── Broker management (Department)
Each unit also takes a code for integrations, a sort order for presentation, and can be made inactive.
The three types describe intent; the parent describes structure. Nothing stops you nesting differently if your organisation is shaped differently.
Granting access — the field that does the work
Open a person's access and add a unit. Three fields:
| Field | What it does |
|---|---|
| User | Who |
| Organisation unit | Which unit |
| Include children | Whether the grant goes down the tree |
Include children is the difference between two completely different people:
- Lisbon → Claims, without children — the claims manager for Lisbon.
- Lisbon, with children — the regional director, who sees Claims, Underwriting and Compliance.
- Acme Insurance, with children — everything.
One row, one switch.
Why this beats listing departments
You could give the regional director each department by name. It works — until somebody creates a department.
Include children grants the shape rather than the members, so a new department is covered the moment it exists. Which is exactly when nobody is thinking about permissions.
That is the whole argument for computing access rather than granting it: a list is only correct on the day it is written.
Scope and Members on a process
Two different steps on the process wizard, and they are not alternatives.
- Scope is the rule — this process applies to these parts of the organisation.
- Members is the exception — and this person as well, whatever the scope says.
When somebody needs access and the scope does not reach them, the temptation is to widen the scope. Do not. A widened scope also reaches cases nobody examined. Add them as a member instead — the exception belongs in a place with a name on it.
Who is on a case
Each dossier has its own team, with two roles:
| Role | Means |
|---|---|
| Collaborator | Works on the case |
| Watcher | Follows it without acting |
The team is created from the process's default team when the dossier is made, as a snapshot — the same principle as documents and approvers. A template changed later does not rewrite who was on last quarter's cases.
Two people are deliberately left out of that materialisation: the person who reported the case and the person it is assigned to. They are already direct participants, so a row would grant them nothing — and a Watcher row for the person who created the dossier would lock them out of their own work, which nobody configuring a template intends.
Where this shows up when you are not looking
In Genius. The assistant answers only from documents the asker may open, and that filter is applied when passages are selected. The four layers above are what it consults — which is why an access model that is merely mostly right stops being an inconvenience and becomes an incident once an assistant is reading it.
In external sharing. The unit of sharing is the whole dossier. There is deliberately no per-document permission, because per-document permissions are the feature that makes it impossible, a year later, to answer "who can see this?". A case that needs to share less is a case with less in it.
What you should have now
- An organisation tree that matches your real one.
- At least one grant using include children, and one without, so you have seen the difference.
- One process where Scope is the rule and Members carries a genuine exception.
- A clear answer, for one specific document, to the question: who can open this, and through which layer?