Workflows and Approvals
Identity solution
Turn an identity request into a tracked process: collect the details, obtain the required decisions, perform the work, and follow the outcome.
At a glanceDirect link to At a glance
NIM Workflows coordinate user tasks, approval decisions, manual handoffs, and automated service actions. Users submit requests and complete steps in NIM Apps. Each request becomes a case, with its data, current work items, and history. The Workflow Designer models the process; the configuration binds its participants to users or groups and connects Apps, data, and actions.
Use a workflow when a request needs decisions or work from several people before a change can be completed. An approval is one possible step; workflows can also coordinate reviews, additional information, and manual fulfillment. For routine changes determined entirely by trusted source data, start with lifecycle automation or role-based access.
Verify success: Test approved and rejected requests, verify the target change, inspect the case history, and confirm that each participant sees only the case data they need.
From request to verified outcomeDirect link to From request to verified outcome
Choose a practical use caseDirect link to Choose a practical use case
Access requests
An employee requests access. A manager or resource owner decides, and an approved branch runs the configured provisioning action.
See the approval pattern →Onboarding handoffs
Collect missing information, assign manual tasks to a fulfiller, and run service actions when the required steps are complete.
Build the request and step Apps →Parallel approvals
Ask two owners to decide at the same time. Use a cancelling join when one refusal should withdraw the other open approvals.
Coordinate parallel decisions →Reminders and escalation
Remind a performer while their task stays open, or use a deadline to withdraw it and continue along an escalation path.
Choose a timer pattern →Choose the right mechanismDirect link to Choose the right mechanism
| Need | Use | Control to verify |
|---|---|---|
| Keep routine account changes aligned with authoritative data | Filters, mappings, jobs, and sync tasks | The eligible population and target operation are correct. |
| Maintain baseline group membership from identity attributes | Roles and role models | Eligibility is explainable and membership stays aligned with the source data. |
| Let an authorized operator perform one focused task | A NIM App with configured form actions | App access and exposed actions match the operator's responsibility. |
| Wait for a decision, review, or handoff before continuing | A NIM workflow with user tasks and routing | Assigned participants, exchanged data, and every outcome are explicit. |
A workflow can complement role-based access, but approval does not change a role model's eligibility rules by itself. Define how the approved action interacts with existing automation so a later job does not unintentionally reverse the requested change.
Plan the process before buildingDirect link to Plan the process before building
| Question | Decide before configuration |
|---|---|
| Who is requesting, and who is the request about? | Distinguish the initiator from the subject, especially for service-desk requests on another person's behalf. |
| Who may decide or fulfill the request? | Name the participants and identify their user/group bindings, dynamic lookup, or rules. |
| Which data is needed? | Collect the minimum useful data and decide which participants may read or write it. |
| What happens after approval or refusal? | Define the target action, manual fulfillment, and a clear end for each path. |
| What happens when nobody responds? | Choose reminders, deadlines, fallback performers, and delegations appropriate to the process. |
| Who can resolve an operational failure? | Assign supervisors deliberately and decide which rights they need to inspect, correct, retry, or cancel cases. |
Do not let a request form appoint its own approver. When a participant is resolved from a case variable, NIM requires that variable to be filled by a service task or start-event session mapping. See Participants and permissions.
Build and test the solutionDirect link to Build and test the solution
Draw and simulate
Model the steps, participants, branches, and end events. Validate the drawing and simulate every path.
Build the Apps
Create the start form, step Apps, and task list. Use the Form Builder and Table Builder for the user experience.
Configure and publish
Map data, bind people, enforce the intended permissions, configure actions and notifications, and publish a validated version.
Test with safe records and representative user accounts:
- Submit a request and confirm that it appears in the intended performer's task list.
- Approve it, verify the target change, and inspect the recorded performer and case history.
- Submit another request and reject it. Confirm that the provisioning branch does not run.
- Test any configured withdrawal, reminder, deadline, and delegation paths.
- Check access to case variables with the actual participant accounts. Test failure recovery before offering the process broadly.
Operate the processDirect link to Operate the process
- Manage cases to see what a request waits for, inspect history, correct blocked data, or retry a failed step.
- Configure notifications to tell performers about waiting tasks and initiators about progress.
- Manage delegations to cover personal steps while someone is away.
- Publish changes to release a new version for new cases. Running cases retain their published version; the Apps themselves remain live.
Related guidesDirect link to Related guides
- Workflows overview — understand definitions, configurations, and cases.
- BPMN reference — learn the notation and common process patterns.
- Apps and Identity Requests — choose focused forms for delegated administration.
- Access and Roles — maintain baseline role-based access and provisioning.