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 Settings → Organization — the screen is called Organization structure. Units come in three types, and they form a tree of three fixed levels:
| Type | What it is | Sits under |
|---|---|---|
| Company | The top | Nothing — a company has no unit above it |
| Branch | A site, a region, a subsidiary | A company |
| Department | A team | A branch |
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)
New unit opens a three-step wizard — General, Placement, Summary. At placement, a branch picks its company and a department picks the company and then one of its branches: the wizard only offers the right parent for the type, and the server refuses any other. In the tree, Add a branch on a company and Add a department on a branch do the same from the row.
The levels are those three and only those. There is no department inside a department, nor branch inside a branch: if your organisation has more layers, pick the three that decide who sees what and leave the others out.
Each unit also takes a Code (optional) for integrations, which cannot repeat one already in use, a Sort order for presentation, and a Description (optional). It can be made inactive with Deactivate, or removed with Delete — it leaves the structure, but the employees, dossiers and permissions that already refer to it keep identifying it.
Granting access — the switch that does the work
In Settings → Users, the row menu of a person has Manage organizations, which opens that person's Organizational scope — the parts of the organization this person can reach. Pick a Company, branch or department, decide the Include sub-units switch, press Grant unit, and at the end Save scope. Each granted row shows the Unit, its Type, the Sub-units and when it was Granted.
Include sub-units is the difference between two completely different people:
- Lisbon → Claims — the claims manager for Lisbon. A department has no sub-units.
- Lisbon, with sub-units — the regional director, who sees Claims, Underwriting and Compliance.
- Acme Insurance, with sub-units — everything.
One row, one switch. The screen lists separately the units Reached by including sub-units, so you can see what a row covers without opening it.
The scope grants no permission: effective access is the role and this scope together, as the screen itself warns. What the person may do comes from roles, in the next chapter.
Why this beats listing departments
You could give the regional director each department by name. It works — until somebody creates a department.
Include sub-units 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.
Organizational scope and Default team on a process
Two different places in the process editor, and they are not alternatives.
- The Organizational scope step is the rule — this process applies to these companies, branches and departments.
- The Default team, on the Approvers step, is the exception — and these people as well, whatever the scope says. They join the team of every dossier created from the process.
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 to the team instead — the exception belongs in a place with a name on it.
Who is on a case
Each dossier has its own Dossier Team, with two access levels:
| Level | Means |
|---|---|
| Collaborator | Works on the dossier |
| Watcher | Follows the dossier, read-only |
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. Editing that list never changes a dossier that is already open, so 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.
How a dossier's team is managed, and how somebody who cannot manage it asks for access, is in the chapter Working a Dossier.
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. Only a Public dossier leaves the company, and from inside it only the Documents whose level is Public as well; a sensitive field reaches the outside filled in but without its value. There is no third list of who sees what for sharing: the same confidentiality that decides inside decides there. The chapter Sharing outside the company tells the rest.
What you should have now
- An organisation tree that matches your real one, in companies, branches and departments.
- At least one grant using Include sub-units, and one without, so you have seen the difference.
- One process where the Organizational scope is the rule and the Default team carries a genuine exception.
- A clear answer, for one specific document, to the question: who can open this, and through which layer?