Participants and permissions

Workflows · People and access

Decide who performs each step, and make sure every person can see and change exactly the case data their step needs.

The drawing names a participant on each user task, send task, and message event: a role such as Manager or Approver. A configuration decides which NIM users or groups stand behind each participant, and what each participant may do with the case data. Both are set on the configuration screen, on the Participants and Permissions tabs.

Keep assignment and access separate

First bind each participant to the people who perform its steps. Then use Permissions to control the case data they may read or write. Supervisor rights are managed separately on the same tab.

Bind participantsDirect link to Bind participants

Open the configuration and select the Participants tab. The Participants grid lists every participant named in the drawing. You cannot add a participant here; you name it on a step in the definition.

Show participant grid columns

Column	Meaning
Participant	The name from the drawing.
Resolved as	How NIM finds the people: Bound here, From a case variable, or By rules.
Variable / rules	The case variable that holds the IDs, or the number of rules. Click it to edit the rules.
Ids of	Whether the case variable holds User ids or Group ids.
Users	NIM users who stand for the participant, or its fallback.
Groups	NIM groups whose members stand for the participant, or its fallback.
Anyone signed in	Every signed-in NIM user stands for the participant.
Steps	The steps the participant performs, sends, or receives.
Meaning	The description of a standard participant name.

Select Clear who this participant is to remove a binding. Bindings for names the drawing no longer uses are still listed as Not named in the drawing (any more), so you can clear them.

A step is handed to every user the participant resolves to. Any one of them can perform it; the first one to complete it completes it for all. Users who reach a step through a group see it in their task list as a group task.

Bound hereDirect link to Bound here

Choose Bound here for a fixed set of people, such as a service desk group or a named resource owner.

Set Resolved as to Bound here.
Select one or more Users, one or more Groups, or tick Anyone signed in.

NIM stores the IDs of the users and groups, so renaming a user or group does not break the binding. Anonymous access is never allowed.

From a case variableDirect link to From a case variable

Choose From a case variable when the performer depends on the case, such as the manager of the person the request is about.

Make sure a case variable holds the NIM user ID or group ID. Several IDs can be separated by ;, ,, or a line break.
Set Resolved as to From a case variable and choose the Variable / rules. Only string and number variables are offered.
Set Ids of to User ids or Group ids.
Optionally, select Users, Groups, or Anyone signed in as the fallback: they perform the step when the variable names nobody.

Only a service task, or a session mapping on the start event, may fill this variable. If an App could fill it, whoever performs the step could appoint themselves, so NIM reports an error for that.

NIM checks the IDs against the NIM accounts once, when the service task that fills the variable completes or when the case starts, and records the result in the case history. When an ID names no account, or the variable names nobody and there is no fallback:

If a service task filled the variable, that service task fails. Fix the cause, then run the step again.
If a session mapping filled it, the case does not start, and the person who started it sees the reason.

Typical pattern: approval by the manager

Map a session variable such as the starter's manager ID to a case variable on the start event, or let a service task look up the manager of the subject. Then resolve Manager from that case variable, with Ids of set to User ids, and add a fallback group for employees without a manager.

By rulesDirect link to By rules

Choose By rules when the performer follows from the case data, such as an approver per department or per amount.

Set Resolved as to By rules.
Click the Variable / rules cell. The Rules for participant dialog opens.
Select Add for each rule. For each rule, choose a Variable, an Operation, and a Value, and the Users, Groups, or Anyone who perform the step when the rule holds.
Drag rules by # to change their order.
Give the last rule the operation otherwise, so a case that no other rule matches still has a performer.
Select Save.

The first rule that holds wins. NIM evaluates the rules against the case data at the moment the step is handed out. The first rule you add is an otherwise rule by default.

Switching Resolved as keeps the users and groups between Bound here and the fallback of From a case variable, but drops them when you switch to By rules.

The InitiatorDirect link to The Initiator

Initiator is resolved by NIM itself: it is whoever started the case. You cannot bind users or groups to it. Use it for steps the requester performs, such as withdrawing a request with a message event, or providing extra information.

Case data permissionsDirect link to Case data permissions

The Permissions tab controls which participant may read and write which case variable. Choose a mode under Permissions on the case data:

Open: every participant may read and write every case variable. This is the default. The grid only shows, dimmed, what the mappings use.
Enforced: a participant may only read and write what is granted below. Use this when steps must not see or change data that is not theirs, such as a salary or a reason for termination.

The access matrixDirect link to The access matrix

The Case variable access rights grid has a row per case variable and a column per participant. Initiator is the first column; it stands for the start form. Each cell shows R (read), W (write), RW, or nothing.

When enforced, click a cell to cycle through none → R → RW → W → none. Cells that a mapping uses are bold. Cells where a mapping needs more than is granted are red.

These mappings count as a use:

Mapping	Counts as
A value the start form puts into the case	Write by Initiator
A step's prefill (Variables from case to app)	Read by the step's participant
A step's result (Variables from app to case)	Write by the step's participant

Service tasks, gateways, timers, and session mappings run on the NIM service and are outside the matrix. Built-in variables can always be read.

Enforce permissionsDirect link to Enforce permissions

Select Enforced. When nothing is granted yet, NIM fills the matrix with exactly what the mappings use.
Tighten the rights. Remove what a participant does not need to see.
Check the line under the grid:
- ✓ Every mapping fits under the permissions., or
- ✖ N mapping(s) exceed the permissions; the configuration cannot be published until it is/they are granted or removed. Select Grant what the mappings use to add the missing rights, or remove the mapping.

Use Fill from the mappings to replace all rights with exactly what the mappings use. Use Remove N unused right(s) to remove rights on variables that no longer exist or for participants that perform no step.

The permissions also apply at run time:

An App opened for a step is prefilled only with what its participant may read.
A step's participant can only write what it may write.
In the workflow.case_data table, a participant sees only the variables it may read. A delegate reads what the delegator's participant may read.

The mode and the matrix are frozen with each published version. Running cases keep the permissions they started with.

SupervisorsDirect link to Supervisors

The Supervisors grid on the Permissions tab decides who may oversee the cases of this configuration from a NIM App. Select Add and choose the Kind (User, Group, or Anyone signed in) and Who. Then tick the rights:

Right	Allows
See	See every case of this configuration, with all its data and its history, in the tables `workflow.cases`, `workflow.case_data`, and `workflow.case_history`.
Manage	Amend the data of a case and run a failed step again, with the App actions Amend workflow case and Retry workflow step.
Cancel	Cancel a case, with the App action Cancel workflow case.

A supervisor sees all case variables, whatever the case data permissions.
With no entries, only NIM administrators can supervise. Administrators always have every right.
Unlike the case data permissions, supervisors are live: a change applies immediately to all cases, without publishing again.

For the supervisor Apps, see Workflows in Apps. In Studio, administrators manage cases on the Cases tab.

Workflow configurations — configure mappings and variables before reviewing rights.
Workflow delegations — hand personal steps to a colleague for a period.