User Management and Authorization

Authorization in QDMS Now works on two independent levels, and understanding the difference resolves most "why can't this person do that?" questions.

Level	Question it answers	Where it is configured
Permissions	Is this user allowed to use this feature at all?	Roles and users, in the permission management screen
Record-level authorization	Is this user allowed to act on this specific record?	Matrices on the parent record — a document folder, a risk main form, a process

A user needs both. Holding the document read permission does not let you read a document whose folder's authorization matrix excludes you; being on the matrix does not help if your role lacks the permission.

Identity types

Responsibilities and authorizations accept five identity types:

Type	Use it for
User	A specific named person.
Role	Everyone holding a functional role.
User group	An explicitly maintained set of people.
Position	Whoever currently holds a position in the org chart.
Organization unit	Everyone in a department or site.

tip

Prefer positions, roles and groups over named users. Membership is resolved when work is read, not when it is assigned — so a task routed to a position keeps reaching the right person after a handover, while a task routed to a named user follows that person out of the role.

Permissions

Permissions are organized per module and per function, typically as:

• Default — see the screen and read records.
• Create — open new records.
• Update — edit records and move them through their lifecycle.
• Delete — remove records.

Some actions carry their own dedicated permission because they are materially different from an ordinary edit — deactivating a published process, starting a revision, editing module settings.

Permissions are granted to roles, and users inherit them from the roles they hold. Granting permissions directly to a user is possible but makes the model harder to reason about later.

Who may grant permissions

Granting is itself gated. Opening a Permissions dialog — on a role, a user or a user group — needs the matching Manage permissions right, and that right alone decides who may open the screen.

What may be granted there is a separate question. A user in the built-in admin role may grant anything. Everyone else may grant any business-module permission — Document Management, CAPA, work orders, risk assessments and the rest — whether or not they hold it themselves. The administration surface stays reserved for admin and appears greyed out:

• Users, roles, claim types, organisation units, security logs and sessions
• Customers (tenants) and editions
• Administration → Settings, including features, e-mail, time zone and chat settings
• Audit logs, languages and text templates
• OpenID clients and scopes
• Modules, Function Designer and the Background Job Execution Log
• Managing a user group's own permissions

Greyed rows cannot be ticked or cleared, and Select all skips them. If a reserved permission reaches the server anyway, the whole save is refused and the refused permissions are named — nothing is applied in part.

Because the identity branch is reserved, a permission manager cannot pass the permission-management right on to anyone, itself included. Only an admin can widen that circle.

Record-level authorization

Several modules add a matrix on a parent record that governs the records beneath it:

Module	Matrix lives on	Governs
Document Management	Document folder	Read, print controlled/uncontrolled, download, revise, delete
Health, Safety & Risk	Risk main form	View, create, assess
Process Management	The process record itself	Who may act on this process

Matrices are inherited down a hierarchy where one exists — a document folder can take its matrices from its parent.

Tasks are not permissions

A third thing gates many actions: holding an open task.

Several approval actions check that the current user has an in-progress task for the record, rather than checking a role. This is deliberate — it means an administrator can retarget who approves what through the state configuration, without a code change and without handing out extra permissions.

note

The practical consequence: a user with full permissions may still be unable to approve a record, simply because the task went to somebody else. That is the system working as designed, not a misconfiguration.

Setting up a new user

1. Create the user and assign them to their organization unit and position.
2. Assign the roles that carry the permissions they need.
3. Add them to any user groups used for distribution or task routing.
4. Add them — or better, their role or position — to the record-level matrices of the folders, registers and processes they work with.
5. Have them log in and confirm they can see what they should and cannot see what they should not.

caution

Step 4 is the one most often forgotten. A new user with correct roles who "can't see any documents" is almost always missing from the folder authorization matrices.

Reviewing access

Access review is a standard audit requirement. Two habits keep it manageable:

• Grant permissions through roles, never one-off per user, so a review reads a handful of roles rather than every user.
• Put positions and groups in the record-level matrices, so a matrix stays correct as people move.