People, roles and groups

Four screens under Settings, and they are four different questions that get confused with each other constantly:

Screen	Answers
Users	Who can sign in
Employees	Who works here, in what position
Roles	What a kind of person may do
Groups	Which people are that kind of person

Chapter 13 covered where somebody's access reaches — organisation units and scope. This chapter is what they may do and who they are. The two are genuinely separate: a permission says what, a scope says where.

Users and Employees are not the same list

This is the distinction that trips up every new administrator, so it comes first.

• A User is a login. It has an email, roles, and a state — active or deactivated.
• An Employee is a person in the organisation: a position, an organisation unit, and — for exactly one of them — the billing account.

A contractor with a login and no position is a User and not an Employee. A person on the staff list who never signs in is an Employee and not a User. Most people are both, which is why the two get confused.

Employees carries the billing account, and only one person holds it at a time. Invoices are sent to them. Deactivating that person clears the designation — the screen warns you, and it is worth reading, because "we stopped getting invoices" is a slow, quiet failure.

Users — invite, deactivate, delete

Settings → Users.

• Invite somebody by email. They accept and set their own password; you never handle it.
• Deactivate removes access immediately. The account remains and can be reactivated at any time, with the assignments it had.
• Delete cannot be undone, and the confirmation says so.

Deactivate is almost always the right one. A person who leaves and comes back, an account under investigation, a contractor between engagements — all of those keep their history attached to something that still exists. A deleted user leaves audit entries pointing at somebody who is no longer there.

Bulk actions handle the whole selection: activate, deactivate, delete. Two things about the bulk path worth knowing:

• The organisation always keeps an active administrator — somebody who can manage user roles, update roles and update the sign-in settings. Deactivating the last one is refused, individually and in bulk.
• When some rows are skipped, the result says "Deactivated 4 of 7" rather than reporting success. Read the number.

When somebody leaves

Deactivating a person who still holds work in open dossiers — as the person responsible, in an approval step, on a team — tells you how much, before you confirm. Nothing moves to anybody on its own: Reassign their work lists every item, takes a person for each one or one person for all of them, and a reason, and says for each line whether it was reassigned or refused, and why.

Guests

Invitations → Invite guests is for people from outside the organisation who work in the product for a while: a consultant, an external auditor, a partner. A guest is invited until a date, in Access until, and:

• arrives with no role and no group;
• receives roles only in a unit, a Process or an Area, and always until a date — the External Consultant template is made for this;
• never receives a critical permission, and nothing is lent to them by delegation;
• does not browse the list of the organisation's people;
• is switched off on their own when the date passes, or when their last assignment ends.

Roles — permissions, not people

Settings → Roles. A role is a named set of permissions. The roles are your organisation's own: rename them, change them, deactivate them. Nothing in the product depends on a role's name — renaming one changes nothing it allows.

A new organisation starts with six roles, made from the product's templates and named in the organisation's language:

Role	For	Typical scope
Organization Administrator	One or two people answerable for the organisation. Every permission, and the new ones the product adds.	The organisation
Process Designer	Whoever designs Areas, Processes, fields and documents. Sees no dossier.	The organisation or an Area
Case Manager	Whoever answers for a team: what the Case Worker does, plus teams, approvers, reassigning, closing, cancelling and approving.	A unit
Case Worker	The everyday operator: creates and works dossiers.	A unit or a Process
Approver	Can be named to decide, and decides only the steps they are named in.	A unit or a Process
Reader	Reads dossiers and their files, changes nothing.	A unit or a Process

New from a template offers eleven more, each the smallest set for its function: User Administrator, Security Administrator, Billing Administrator, Integration Administrator, Organization Structure Manager, Quality Reviewer, Intake Operator, Reports Reader, Auditor, External Consultant and Intake Service Account.

• Duplicate role copies a role as "{name} (copy)". Compare with the template shows what a role has more or less than the template it came from.
• Deactivate keeps the role's assignments, but its permissions stop counting until it is reactivated. Before deactivating or deleting, the screen lists who loses what.
• Role for people who arrive is the role given to whoever arrives by invitation or signup, unless the person who invites chooses another.
• When the product adds a permission to a template, the roles made from it do not receive it on their own. New permissions from the templates, at the top of the page, asks once per role: Give it or Leave aside. A role marked Receives the new permissions automatically gets them.

Build roles by subtraction, not addition. Starting from an empty role and adding permissions until somebody stops complaining produces a role nobody can describe. Starting from a role that works and removing what this person should not have produces one you can explain in a sentence.

The blunt test, from chapter 9: can the person who assembles a case approve it? If a role carries both, your approval chain records people agreeing with themselves. Approving is a different permission from editing, and the product warns about four pairs it recommends keeping apart: updating Processes and approving; the quality check and approving; managing user roles and viewing the audit trail; updating roles and viewing the audit trail. When a change joins a pair in one person, it asks you to Confirm anyway and records that you did.

Critical permissions

Eight permissions are critical, because given wrongly they expose everything: managing user roles, updating roles, updating the sign-in settings, managing SCIM provisioning, seeing and acting on every dossier, deciding a dossier one created, reopening a completed or cancelled dossier, and lowering a confidentiality level.

• Giving one asks for a session opened with two-step verification, and a reason that goes to the audit trail with your name.
• A critical permission never arrives by delegation, and never goes to a guest or to a group that comes from the directory.
• Nobody gives what they do not hold, and nobody widens their own permissions: that is asked of whoever administers the organisation.

Assignments — who, what, where, until when, why

A role reaches a person, or a group, through an assignment. Assign a role, from the person's or the group's page, asks five things:

1. Who — a person or a group.
2. What — a role, as it is.
3. Where — the whole organisation, a unit (and, if you want, the units below it), a Process or an Area.
4. Until when — no end, or a last day.
5. Why — a reason, required for a role with a critical permission.

Assignments, on each person's and group's page, lists every assignment with its scope, validity, origin and state. You can change its validity, or take it away with a reason. An assignment with an end date ends on its own.

Two scopes do not add up. A reading role in the HR unit and another reading role elsewhere each hold in their own scope; together they are not a wider reading.

Groups — so the roles stay few

Settings → Groups. A group is a set of users that carries roles.

The reason to use them is arithmetic. Forty people and six roles assigned individually is two hundred and forty decisions, each of which can be wrong and none of which is visible from anywhere. Six groups carrying six roles is six decisions, and "who has this?" becomes a list you can read.

There are three kinds:

Kind	Members are decided	Note
Manual	By hand, in Manage members	A Default group receives everyone who arrives.
Dynamic	By a rule: home unit (with or without the units below), position, kind of account, email domain	Preview says who enters and who leaves before you save. Nobody adds or removes members by hand.
External (Entra)	In your organisation's directory, through SCIM provisioning	Members change there, never in DOK Genius. Roles are given here — never a critical one.

A group can have Managers, who add and remove its members without managing every group, and only while they hold everything the group gives. Each manager finds theirs in Groups I manage.

When somebody's access is wrong, fix the group, not the person. A per-user exception is invisible six months later — it is the row nobody thinks to look at, and it is how one person ends up with access nobody intended and nobody remembers granting.

Why does this person have access?

Three screens answer it with the rule that decides, not with an estimate:

• Effective access, on each person's page: every permission they hold, in which scopes, and where it comes from — which role, through which group, by which assignment.
• Why do they have access?, on a dossier: for a person and an act — view, download the files, edit, decide — Can or Cannot, and the step that decides: permission, scope, confidentiality, participation, designation, plan.
• If you save, before saving a role, a group or an assignment: how many people change, what they gain and lose, how many dossiers they start or stop seeing, and the approval steps that would be left with nobody to decide them.

Delegations

My delegations lends a person's access to a colleague while they are away, always with a start, an end (at most 90 days) and a reason.

• Approvals lends the approval steps waiting for them, and no permission. The colleague must be able to approve in their own right.
• Chosen permissions lends permissions the person holds, in the scopes they hold them, never a critical one.

Whoever manages user roles can create one on behalf of a person who is away. Every act done by delegation is recorded under both names.

Where the boundary with chapter 13 falls

It is worth being explicit, because these two chapters are the pair people mix up:

• Roles and groups decide what somebody may do — view, create, update, delete, approve.
• The scope of an assignment, and organisation units, decide where that reaches — which branch, which department, which Process, and whether it descends the tree.

Both must be right. A person with the approval permission and no scope over the Porto branch cannot approve a Porto case, and the reason will look like a bug until you know which of the two is missing — which is what Why do they have access? is for.

Addenda follow the matrix's unit. Adding to a completed Dossier is a permission of its own, Create an addendum to a completed dossier, which the Case Worker, Case Manager and Organization Administrator templates carry. Its where is the organisation unit of the Dossier being added to — not the person's own unit, and not the unit where the addendum will be worked. Nor is it the same as adding Documents to a Dossier still in progress: that adds to a live case, while an addendum adds to one that is already closed, without reopening it.

What you should have now

• Users invited, guests invited until a date, and a rule that leaving is a deactivation followed by reassigning the work.
• The billing account set on a person who is not about to leave.
• Roles made from templates or by duplicating and subtracting, each describable in one sentence.
• Assignments in the smallest scope that does the job, with an end date where the need has one.
• Groups carrying the roles, and no per-user exceptions you cannot justify out loud.
• One person checked end to end in Effective access: what, where and until when, and all three are what you meant.