1. Define the boundary before the workflow
Record the business objective and the populations covered: employees, contractors, partners or non-human identities. List applications in the current release separately from future candidates. Identify the accountable business owner and clarify which decisions require security, architecture or application-owner approval. Without this boundary, a simple lifecycle requirement can quietly become a much larger programme.
2. Establish identity data and matching
For each relevant attribute, identify its source, owner and expected quality. Decide how an identity is matched to an application account and how duplicates, missing identifiers, rehires and multiple accounts are handled. Include effective dates and the handling of late or corrected source events. Ask what happens if an update arrives while the target application is unavailable.
3. Describe joiners, movers and leavers separately
A joiner needs an agreed start trigger and approved access. A mover requires a decision about existing permissions as well as new ones. A leaver needs defined actions for accounts, sessions and permissions in the systems in scope. Distinguish account suspension from deletion and record any retention or operational dependency that needs a separate decision.
4. Make approvals and exceptions explicit
Specify the requester, approver, permitted delegation and escalation path. Define the information needed to make an access decision and how conflicting responsibilities are checked. Record whether access has an end date or is ongoing with review. Exceptions need an owner, reason, review point and a documented route back to the standard process.
5. Include operational and integration requirements
Capture supported interfaces, environments, connectivity, credentials and application-team responsibilities. Describe reconciliation, failed actions, retries, notifications and manual intervention. Define who monitors an integration and who resolves an issue. Non-functional requirements should state measurable expectations appropriate to the business need, rather than use words such as fast or resilient without explanation.
6. Write acceptance criteria that can fail
An acceptance test should have clear preconditions, input, expected outcome and evidence. For example: given an approved temporary reporting request, when its agreed end date is reached, the application permission is removed and the completion is recorded. Also test an unavailable application, an invalid identity match and an approval that conflicts with policy. A workflow is not fully described by its happy path alone.
Before you sign off
Check that every mandatory requirement has an owner, priority and testable outcome. Link it to a design decision and planned test where those exist. Keep unresolved decisions visible rather than writing an assumption as if it were agreed. Use the resulting catalogue to support procurement, design and testing, updating it through controlled changes.
This is a practical starting point for discussion, not a substitute for your organisation’s policies or product-specific implementation documentation.