Before automating an identity process, draw where the request begins, who makes each decision, and what happens when a step fails. A small BPMN model can expose a missing approval or unclear handoff before it becomes a production account problem.
This retrospective uses a December 31, 2024 knowledge cutoff. OMG's BPMN 2.0.2 specification was adopted in January 2014, so the notation predates that cutoff. The workflow below is an illustrative design, not a historical customer implementation.
Start with a process people can explain
Consider a hypothetical new employee. HR confirms the starter, the manager approves role-specific access, IT prepares accounts, and the employee receives an activation route. Each participant should be able to point to the part they own.
Use a start event for the triggering event, tasks for work, a gateway for a decision, and an end event for the outcome. Separate participants and responsibilities clearly. Keep the first model small enough to review together.
A numbered checklist can help prepare the discussion, but it is not automatically a formally valid BPMN diagram. Do not claim standards compliance without checking the actual model.
Model the decision rather than just the happy path
A useful approval decision has a result when approval is denied or does not arrive. A starter whose manager is missing should not silently receive a broad default role.
For the example process, ask:
- What makes a starter record complete enough to proceed?
- Who owns a missing manager or conflicting start date?
- What happens after access is denied?
- When should an unanswered request be escalated or closed?
- Who confirms account preparation actually succeeded?
These questions are design choices for the example. BPMN gives the team a notation for expressing the process; it does not decide access policy.
Add the failure that operators actually face
Suppose the directory account is created but the business application is unavailable. The process needs to represent unfinished work and assign responsibility. Returning to the first task without checking existing state might create a duplicate.
Write down the retry decision, evidence the operator needs, and the point at which a person takes over. Agree which actions are reversible and which need separate authorization.
Keep the model independent of a product demo
As of this retrospective's cutoff, the design questions do not depend on a particular vendor screen. Once participants agree on the process, use it as acceptance criteria for a product evaluation.
Use the model as a requirements document. Evaluate any proposed implementation separately, including whether it supports the decisions, exceptions, and evidence the team agreed to.
The practical deliverable is a reviewed process with named owners, explicit decisions, and a defined incomplete outcome. That is more useful than a detailed diagram nobody is prepared to maintain.