Automating the user lifecycle in Microsoft Entra ID: joiners, movers, and leavers

How can entry, internal changes, and exit of an employee in Microsoft Entra ID be reliably automated? The process first requires a leading data source with stable attributes and timestamps. Provisioning, group and license assignment, and Microsoft Entra Lifecycle Workflows build on this. Every automated step must have an owner, a status, an audit trail, and a manual fallback path.

Microsoft describes Lifecycle Workflows along the Joiner-Mover-Leaver model. The function can perform tasks for users at specific lifecycle events. It does not replace an HR system and does not correct incorrect entry or exit data. Automation is only as reliable as the underlying identity data.

Lifecycle Workflows typically requires Microsoft Entra ID Governance or Entra Suite. When custom extensions or external target systems are integrated, additional operational dependencies arise for connectors, permissions, monitoring, and error handling.

Define joiner, mover, and leaver

Joiner

A person enters the organization's access scope. This can be an employee, intern, external contractor, or another internal identity.

Mover

Role, department, location, manager, contract type, or area of responsibility changes. Old access must be removed and new access controlled and added.

Leaver

The person leaves the access scope. Sign-in, groups, licenses, devices, data handover, and eventual deletion must be coordinated.

A re-entry or change from external to internal can combine elements of multiple phases.

Establish leading data source

Possible sources:

  • HR system,
  • local Active Directory,
  • identity management system,
  • Microsoft Entra as the primary source in small environments,
  • controlled SharePoint/Power App input as a transitional solution.

For each attribute, it must be clear which system is leading. If department can be manually changed in the HR system, Active Directory, and Entra, conflicting values will arise.

Minimum attributes

Depending on the process:

  • unique employee or person ID,
  • first and last name,
  • primary sign-in name,
  • Employment status,
  • Start date,
  • End date,
  • Department,
  • Role or job title,
  • Location,
  • Manager,
  • Contract or employee type,
  • Cost center,
  • Target audience flag.

Avoid free text when rules depend on it.

Timing and lead time

A Joiner workflow can run tasks before the start date if the relevant date exists in Entra. A Leaver workflow can rely on end-date attributes. Microsoft documents supported execution conditions and attributes; verify these against the current feature set.

Planning questions:

  • When does HR provide the record?
  • From when can the account exist?
  • When can sign-in be allowed?
  • Which accesses are prepared before the first day of work?
  • In which time zone is the event assessed?
  • What happens with short-term date changes?

Joiner process

A possible technical flow:

  1. HR record is approved.
  2. Identity is created in the source system or Entra.
  3. Unique IDs and sign-in names are generated.
  4. Base attributes are configured.
  5. Groups and licenses are assigned based on rules.
  6. Managers and business owners receive tasks.
  7. Temporary Access Pass or first registration is carefully prepared.
  8. User confirms sign-in and authentication.
  9. Workflow history and errors are reviewed.

Early provisioning without early access

An account can be created before the start date but remain blocked until the scheduled time. This allows preparation of mailboxes, groups, or devices without granting access too early. The specific process must be tested with licensing and applications.

Group and license assignment

Groups can grant access to Teams, applications, and licenses. Rules should be based on stable attributes and avoid conflicts.

Example:

  • all internal employees → base security group,
  • Sales department → CRM access group,
  • Vienna location → local resources,
  • Manager role → additional application.

Issue: license assigned directly and via group

Direct and group-based assignments make revocation difficult. Document a preferred assignment logic and clean up exceptions.

Issue: group assignment fails

Check:

  • attribute value,
  • dynamic rule,
  • processing latency,
  • license availability,
  • conflicts in service plans,
  • audit and provisioning logs.

Mover process

Movers are often riskier than joiners because old permissions can remain. Therefore, a role change must add new access and actively remove old access.

The process requires:

  1. old and new target state,
  2. effective change at the correct date,
  3. revocation of role-based old access,
  4. retention of intentionally shared base access,
  5. handover of ongoing tasks and data,
  6. review of privileged roles,
  7. confirmation by the new manager or resource owner.

Prevent permission accumulation

"Add-only" automation creates more rights with every change. Use target state logic: the current user set is compared with the target role, not just supplemented.

Exception: transition phase

For a temporary handover, old and new rights may be necessary in parallel. The exception receives an end date, owner, and review.

Leaver process

A controlled exit can include the following steps:

  1. exit event from the leading source.
  2. block login at the defined time.
  3. revoke active sessions and refresh tokens.
  4. remove privileged roles and PIM permissions.
  5. revoke group and app assignments.
  6. handle device and remote access.
  7. Transfer mailbox, OneDrive, and domain-specific data according to policy.
  8. Remove licenses only after verifying dependent services.
  9. Account for retention, legal hold, or deletion deadlines.
  10. Delete or anonymize the account after the defined period.

Microsoft 365 has service-specific implications. Immediately deleting the user is rarely the complete offboarding process.

Use Lifecycle Workflows

Microsoft Entra Lifecycle Workflows provides templates, tasks, execution conditions, history, and audit. Examples of supported tasks can include group memberships, account deactivation, or notifications. The current task inventory is documented by Microsoft.

Workflow design

  • clear target audience and condition,
  • few, logically ordered tasks,
  • idempotent or repeatable steps,
  • error notification,
  • owner,
  • pilot group,
  • version and change documentation.

Workflow history

Check executions by user, run, and task. A workflow can run overall while individual tasks fail. Business completion must therefore not depend solely on the trigger status.

Manual and custom tasks

Every additional Logic App, webhook, and app identity becomes an operational object itself. Credentials, retry behavior, dead-letter strategy, monitoring, and costs must therefore be included in the operations documentation, not just in the workflow diagram.

Not all processes can be fully mapped natively. Lifecycle Workflows can be supplemented with Logic Apps or other integrations, depending on the supported functionality. External steps require their own authentication, error handling, and monitoring.

A manual task may be more appropriate when a decision requires business assessment, such as data transfer or hardware control.

Typical error patterns

Start date missing or incorrect

The workflow does not start or starts at the wrong time. Solution:

  • Correct the HR record,
  • Verify attribute synchronization,
  • Re-run the workflow on demand or in a controlled manner if needed,
  • Undo the effects of an early start.

User is not in the workflow scope

Check the scope expression, attributes, person type, and exclusions. Use test accounts with realistic values.

Single task fails

Possible causes:

  • Group not found,
  • Missing workflow permission,
  • User already a member or removed,
  • Target system unreachable,
  • Dependent attribute missing.

Task history and audit logs provide the starting point. After that, only the failed business step is retried, not the entire process blindly repeated.

Exit is withdrawn shortly

The rollback depends on the state reached:

  • Reactivate the account,
  • Rebuild sessions,
  • Restore groups and roles from the documented desired state,
  • Reassign licenses,
  • Stop data handover,
  • Cancel scheduled deletion.

A complete snapshot of all effective rights before exit facilitates restoration.

Former employee remains active via guest account

Internal and external identities for the same person can exist separately. Offboarding must account for known guest or partner identities and external tenants.

Tests

Joiner

  • Join in the future,
  • Join today,
  • missing manager,
  • duplicate employee ID,
  • license unavailable,
  • TAP and initial registration,
  • account remains blocked until start.

Mover

  • department transfer,
  • manager change,
  • privileged to non-privileged role,
  • transition period,
  • removal of old groups,
  • receipt of base rights.

Leaver

  • planned departure,
  • immediate security departure,
  • departure revoked,
  • mailbox/OneDrive handover,
  • legal hold or retention,
  • license revocation,
  • permanent deletion.

Manual fallback list

In case automation fails, an authorized operator must be able to execute steps from a checklist. The list includes:

  • User ID,
  • Target time,
  • Current and expected groups,
  • Roles,
  • Licenses,
  • App assignments,
  • Data transfer,
  • Authentication and session steps,
  • Completion confirmation.

After restoring automation, prevent already manually completed steps from being executed twice.

Metrics and operations

  • Joiners provided on time,
  • Failed workflow tasks,
  • Movers with outdated rights,
  • Leavers still active after the target time,
  • Direct license and group exceptions,
  • Missing manager/date attributes,
  • Manual follow-up work,
  • Time until complete revocation of privileged rights.

For the business offboarding and governance part, Access Reviews in Microsoft Entra ID are linked. A practical process example with Microsoft 365 shows onboarding and offboarding with Power Automate, Entra, and SharePoint.

How the user lifecycle remains fully traceable even with exceptions

A reliable Joiner-Mover-Leaver process begins with clear data ownership. Lifecycle workflows and group-based assignments automate recurring steps, while history, audit, target-state comparison, and manual fallback lists make exceptions manageable. Especially during role changes and departures, the process must assign new rights specifically and remove old access in a verifiable way.

When user accounts, groups, and licenses are manually provisioned for onboarding and offboarding
Then you can build a Joiner-Mover-Leaver process with reliable attributes, controlled workflows, and clear exception paths. Discuss identity lifecycle

All articles