Should organisations combine onboarding, offboarding and licence management in one workflow?

Why one workflow works for operations, but not for governance

The practical answer is that one workflow can handle the handoffs, notifications and audit trail, but it should not collapse distinct control decisions into a single approval path. Onboarding creates access, offboarding removes it, and licence management adjusts commercial entitlement. The workflow can be shared; the decision points should remain separable so each change is still attributable to a clear business trigger and control owner.

That separation matters because the same ticket or orchestration run can move faster than the underlying governance. If the process treats every request as one blended event, teams lose visibility into whether access was granted because a role was approved, revoked because employment ended, or modified because a licence changed.

Combining the mechanics is also where organisations can gain consistency. Shared orchestration reduces duplicate data entry, lowers the chance that HR, IT and SaaS administration drift out of sync, and gives you one place to log who requested what, when the action executed and what downstream systems were touched. The Joiner-Mover-Leaver (JML) Guide is useful here because it treats joiner, mover and leaver handling as a lifecycle pattern, while still recognising that the access outcome should be governed as a distinct decision.

What should stay separate inside the shared workflow

The first separable control is access approval. A manager or application owner may confirm that access is needed, but that approval should remain distinct from the automation that provisions accounts or updates licences. That distinction keeps entitlement decisions reviewable and prevents licence optimisation from becoming an implicit access grant.

The second separable control is role design. If onboarding uses a role catalogue, the role should already reflect the access model the organisation has approved. Licence changes may ride the same workflow, but they should not redefine the role or silently broaden what the role can do. A well-designed workflow makes it easy to see whether the change was operational, entitlement-related or both.

The third separable control is recertification. Offboarding and licence removal are event-driven, but entitlement review is periodic and exception-based. If those are merged too aggressively, organisations may think they have governance when they really only have automation. The IAM and IGA Basics guide is a good reference point for keeping provisioning, access reviews and entitlement management in the right lanes.

Where the workflow boundary gets most important in practice

The boundary matters most when a single event affects more than one control domain. For example, a leaver event may trigger account deprovisioning, token revocation, mailbox retention actions and licence reclamation, but each action has a different owner and failure mode. If the workflow hides those differences, teams can miss a stalled deprovisioning step while assuming the whole process completed successfully.

It also matters where external service credentials or shared automation are involved. Offboarding is not complete if the user interface account disappears but the associated access path remains live elsewhere. The NHI Lifecycle Management Guide is relevant because lifecycle handling only works when provisioning, rotation and offboarding are all visible as separate lifecycle events rather than one opaque transition. For teams standardising JML mechanics, the Workforce Identity Security Guide also reinforces that provisioning and deprovisioning need clear lifecycle triggers, not just a generic task queue.

Risk and Threat Considerations

When onboarding, offboarding and licence management are overcombined, the main risk is control blending: an operational convenience starts behaving like an access decision. That can create stale access, overprovisioned accounts or incomplete removal when a lifecycle event is processed only partly. It also makes investigations harder because the organisation cannot easily prove which part of the workflow changed access and which part only adjusted service entitlement.

Failure mechanism: A single workflow step bundles approval, provisioning and commercial cleanup, so a fast operational action bypasses a deliberate entitlement review or leaves one downstream access path untouched.

Impact: Organisations can end up with privilege creep, orphaned access, failed offboarding and weaker audit evidence, especially when the same automation is reused across multiple systems.

Practitioner Guidance

What to prioritise: Keep one orchestration path, but require explicit control points for approval, revocation and review. If the workflow cannot show which step granted, changed or removed access, it is too blended to trust for governance.

What to verify: The record should distinguish the business trigger, the access action, the licence action and the system of record for each. If those cannot be separated in logging and reporting, the workflow is likely doing too much with too little accountability.

Decision rule: Use a shared workflow for speed and consistency, but treat any entitlement decision, role change or exception as a governed event that must remain independently reviewable.

Practitioner takeaway: Good automation joins the mechanics, not the authority, so the workflow should accelerate execution without collapsing the controls that prove access was granted or removed for the right reason.

Related resources from NHI Mgmt Group

• What breaks when organisations do not separate onboarding and offboarding queues from general user management?
• When should organisations prioritise automated user lifecycle management over manual onboarding and offboarding processes?
• What happens when investigators can combine blockchain intelligence, case management, and wallet tracing in one workflow?
• How should organisations design an IAM workflow that covers onboarding, changes, and offboarding without creating unnecessary operational overhead?