Workflows

Turn a request that needs more than one person—an approval, a review, a hand-off—into a repeatable process that NIM tracks from start to finish.

A NIM workflow coordinates work between people and the NIM service. One person starts a request in a NIM App, other people approve, review, or complete their part in their own Apps, and the NIM service performs the automated steps in between. NIM keeps track of every request as a case: where it stands, who it is waiting for, what data it carries, and what happened so far.

Start with Workflows and Approvals to plan the identity use case. Use the BPMN reference to learn the drawing notation and see common process patterns.

Choose your next stepDirect link to Choose your next step

Design and configure

Draw the process, connect Apps and data, then bind the people who perform it.

Design a workflow →

Build the Apps

Create request forms, approval screens, task lists, and case overviews.

Build workflow Apps →

Publish and test

Release a version for new requests and follow a test case from start to finish.

Publish a configuration →

Operate and support

Inspect case history, recover failed steps, and arrange cover while users are away.

Manage cases →

Build your first workflowDirect link to Build your first workflow

Draw the definition. On the Definitions tab, add a definition and draw the process. Name a participant on every user task. Use Workflow → Validate and Workflow → Simulate until the process is sound. See Workflow definitions.
Build the Apps. Create a start form, plus one App per user task. Give each App the variables it exchanges with the case. Variables that a step must receive from the case need the type input. See Workflows in Apps.
Configure. On the Configurations tab, add a configuration for the definition. Choose the Apps, tick the variables that go into the case, bind the participants to users or groups, and decide the permissions. See Workflow configurations and Participants and permissions.
Validate and publish. Solve every finding on the Validation tab, then select Publish. See Publish and unpublish.
Notify. Couple mail templates to the workflow's events. See Workflow notifications.
Give people a task list. Add a grid on the workflow.my_tasks table to an App, with actions to open and complete steps. See Workflows in Apps.
Test. Start a case from the start form and follow it on the Cases tab.

Start small

Begin with a start form, one approval step, and one service task. Add timers, parallel approvals, and delegations once the basic path works end to end.

What you can use workflows forDirect link to What you can use workflows for

Use a workflow whenever an identity task should not be completed by the person who asks for it, or needs several people in a fixed order.

Process	How a workflow handles it
Access requests	An employee requests membership of a group or access to an application. The manager approves, then the resource owner approves, and a service task adds the membership.
Onboarding and changes	HR or a service desk files a new hire or a job change. A manager completes missing details, a fulfiller performs the manual steps, and service tasks create or update the accounts.
Recertification and review	A reviewer confirms or revokes existing access. The outcome of each review decides which branch the case follows.
Parallel approvals	Two approvers decide at the same time. With a cancelling join, the first refusal withdraws the other approval immediately.
Deadlines and escalation	A timer on an approval step moves the case on when nobody acts in time—for example, to the approver's manager.
Withdrawn requests	The person who started a request withdraws it while it is waiting for approval.
Status mail	NIM mails the next performer when a step is waiting, and tells the initiator when a step is done and how the case ended.

The three layers of a workflowDirect link to The three layers of a workflow

A workflow is built in three layers. Keeping them apart lets you reuse one process drawing for several situations, and change a running process without disturbing the requests already under way.

Model

DefinitionThe drawing: steps, order, branches, and participant names

Configure

ConfigurationApps, case variables, routing, people, and permissions PublishFreeze a version that new cases run on

Run

CasesOne request each, with its own data and history

A definition says what the process is; a configuration says who does it with which data; a case is one request running on a published version.

DefinitionDirect link to Definition

The workflow definition is the drawing of the process, made in a BPMN-style designer. It holds the steps (user tasks, service tasks, send tasks), the events (start, end, timer, message), the gateways that branch and merge the flow, and the participant names on the steps, such as Manager or Approver. A definition says nothing about data, Apps, or which people are meant: an Approver in the drawing is a role, not a person.

ConfigurationDirect link to Configuration

A workflow configuration is a separately edited layer on top of one definition. It holds:

The case variables: the data a case carries from step to step.
The App in which each user task is performed, and which App variables are exchanged with the case.
The actions that each service task runs.
How each gateway routes, and when each timer goes off.
Which NIM users or groups each participant stands for.
The permissions: which participant may read or write which case variable, and who supervises the cases.

One definition can have several configurations. A single leave request drawing can, for example, be configured as Leave NL and Leave BE, each with its own Apps and approvers.

A case is always started on a published configuration. Publishing freezes the definition and the configuration together as a numbered version, so every case keeps running on the version it was started on.

CaseDirect link to Case

A case is one request running through the process—for example, Access request for Jane Doe to Finance Share. A case carries:

Case data: the values of the case variables.
Steps under way: the work items that wait for a person, the NIM service, a message, or a moment in time.
History: every step that was handed out, started, completed, withdrawn, failed, or run again, every data correction, and every mail that was sent, with the person who did it.
Status: running, completed, stuck, or cancelled. A running case can also be blocked, for example when a gateway finds no branch for the case data. A step can fail, for example when a service task action returns an error. The reason is shown with the case, and a supervisor can correct the data or run the step again.

Each case also records who started it. The initiator is stored on the case, so it survives a later rename or removal of that account.

How a case runsDirect link to How a case runs

A user opens the start form: the App configured on the start event. The App's Start workflow case action starts a case on the published configuration. The ticked App variables become case data.
The case advances on its own until it reaches a step that needs someone or something:
- A user task is handed to the users and groups behind its participant. It appears in their task list (the workflow.my_tasks table in an App), and optionally NIM mails them.
- A service task runs its actions on the NIM service, such as creating an account or adding a group membership.
- A send task mails the participant and continues.
- A timer event waits for a duration or a date.
- A message event waits until its participant sends the message, for example to withdraw a request.
A performer opens the step in its App, fills in what is needed, and completes the step with an outcome such as Approved or Rejected. Depending on the configuration, a task list can also complete a step directly with an approve or reject button.
A gateway after the step routes the case on that outcome, on a case variable, or on conditions.
The case ends when every path reaches an end event. The initiator can be told how it ended.

Where to find workflows in StudioDirect link to Where to find workflows in Studio

Go to Configuration → Workflows. The page has four tabs:

Tab	Use it to	Guide
Definitions	Draw, import, export, copy, rename, and delete workflow definitions.	Workflow definitions
Configurations	Configure a definition, then publish or unpublish it.	Workflow configurations
Cases	Start, inspect, correct, and delete cases.	Manage workflow cases
Delegations	Hand a user's steps to someone else for a period.	Workflow delegations

Workflow screens in Studio are available to NIM administrators. End users work with workflows only through NIM Apps.