Lifecycle workflows can disable a leaver at the minute their contract ends, but only if the HR dates feeding them are right and the workflows themselves are governed like the privileged automation they are. Lifecycle workflows are the joiner, mover and leaver automation in Microsoft Entra ID Governance: scheduled or on-demand workflows that run built-in tasks such as generating a Temporary Access Pass, removing group and access package assignments, revoking refresh tokens and deleting accounts. This guide covers how the workflows are triggered from HR attributes, the templates and tasks and their limits, custom task extensions through Azure Logic Apps, the roles and permissions that control the feature, logging, and a hardening baseline. It is written for identity engineers and IGA owners running Entra ID. Access packages themselves are covered in the Entra ID Entitlement Management and Access Packages Guide, and the process design behind joiner, mover and leaver events in the Joiner-Mover-Leaver Guide.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
Key takeaways
- Dates drive everything. Time based workflows fire from employeeHireDate, employeeLeaveDateTime or the last successful sign-in, so the HR or sync mapping that writes those attributes is part of your security boundary.
- Privileged users are skipped by account tasks. Microsoft documents that the enable, disable and delete user tasks do not support users with Entra role assignments or members of role-assignable groups, so admin leavers need a separate, tested process.
- Disable is not revoke. Pair account disablement with the Revoke all refresh tokens task, and remember it excludes external user sign-in sessions.
- Custom task extensions are machine identities. The Logic App behind each extension runs with a managed identity or app registration and can hold powerful permissions; scope and monitor it.
- Licensing and limits shape design. The feature needs Microsoft Entra ID Governance or Microsoft Entra Suite, and a tenant is limited to 100 workflows and 100 custom task extensions.
How identity and access work in lifecycle workflows
Each workflow has general information, a set of tasks and execution conditions. The execution conditions define the trigger (when the workflow runs) and the scope (which users it applies to, using user and extension attributes such as department or company). Microsoft positions lifecycle workflows as an extension of HR-driven provisioning: inbound provisioning creates accounts and updates attributes, and workflows run the tasks around those events.
Triggers
| Trigger | Fires on | Typical use |
|---|---|---|
| Time based attribute | A point in time relative to employeeHireDate, employeeLeaveDateTime or createdDateTime | Pre-hire, day one, last day, post-offboarding |
| Attribute changes | A change to a scoped attribute such as department or job title | Mover workflows |
| Group membership change | A user added to or removed from a group | Movers where the HR change lands as a group |
| Sign-in inactivity | lastSuccessfulSignInDateTime older than a threshold | Inactive user disablement |
| On-demand | An administrator runs it for selected users | Immediate termination, testing |
Scheduled workflows are evaluated at the tenant interval, three hours by default, and scheduling must be switched on after a workflow is created. For time based triggers, Microsoft documents a catch-up window: if the account or workflow is configured up to three days after the intended processing time, the user is still processed (this does not apply to the preview Time based attribute V2). On-demand runs apply tasks whether or not the user meets the execution conditions, which makes on-demand a powerful, and therefore sensitive, action.
Choosing a mover trigger: use Attribute changes when HR reliably updates department, job title or cost centre in Entra ID, because the trigger follows the system of record. Use Group membership change when movers are expressed through dynamic or HR managed groups, accepting that the workflow then depends on whoever controls that group. For leavers, prefer the time based trigger on employeeLeaveDateTime for planned exits and keep an on-demand Real-time employee termination workflow ready for dismissals, where waiting up to three hours for the next evaluation is not acceptable. Write down which trigger owns each event so two workflows do not act on the same user with conflicting tasks.
Templates
| Template | Category | Default tasks (summary) |
|---|---|---|
| Onboard pre-hire employee | Joiner | Generate a Temporary Access Pass and email it to the manager, shortly before the hire date (check the template for the default offset) |
| Onboard new hire employee | Joiner | Add to group, enable account, send welcome email on the hire date |
| Employee job profile change | Mover | Notify manager, remove access package assignments after 15 days, remove from selected groups and teams, request a new access package |
| Real-time employee termination | Leaver (on-demand) | Remove from all groups and teams, delete user account |
| Offboard an employee | Leaver | Disable account, remove from all groups and teams on the leave date |
| Post-Offboarding of an employee | Leaver | Remove all licences, remove from teams, delete account |
| Pre-Offboard / Offboard inactive users | Leaver | Disable account and notify, at 90 and 120 days of inactivity by default |
| Transition agent sponsorships | Leaver, Mover | Notify manager and co-sponsors, transfer agent identity sponsorships to the manager (needs a Microsoft Agent 365 licence) |
The sponsorship templates matter for non-human identities: when a sponsor leaves, agent identities should not be left ownerless. See the Microsoft Entra Agent ID Guide.
Feeding the dates
employeeHireDate and employeeLeaveDateTime can be populated by HR inbound provisioning (Workday and SAP SuccessFactors are documented), Entra Connect cloud sync or Entra Connect Sync. For on-premises Active Directory, the Microsoft docs describe using a string attribute and a FormatDateTime expression, with the AD string in yyyyMMddHHmmss.fZ format and the Graph value in YYYY-MM-DDThh:mm:ssZ. Microsoft recommends setting hire times early in the day and leave times late in the day, and allowing for the schedule interval: a workflow never runs before the attribute time but can run up to one interval after it. Check whether your HR source carries time zone information. The Identity Lifecycle Event Design Guide covers the HR side.
Admin roles and privileged access
- Lifecycle Workflows Administrator: the minimum Entra role Microsoft names for managing workflows in delegated scenarios. Holders can change tasks, scope and schedules, and run workflows on demand, so they can disable or delete any user in scope. Make it eligible through PIM, not standing.
- Leave date writers: setting employeeLeaveDateTime through Microsoft Graph needs User.Read.All plus User-LifeCycleInfo.ReadWrite.All, and Microsoft's Graph tutorial states that in delegated scenarios the admin must also hold Global Administrator. Anyone who can write this attribute can schedule a leaver workflow against a user, so treat the permission as privileged.
- Privileged user gap: the enable, disable and delete user tasks do not support users with Entra role assignments or users who are members or owners of role-assignable groups. Build a manual or PIM driven leaver step for administrators, and test it.
- Temporary Access Pass: the Generate TAP task needs the TAP policy enabled, a lifetime within policy (10 to 43,200 minutes) and a user with no other authentication methods, sign-ins or role assignments. Microsoft suggests a 24 hour maximum lifetime so the pass does not expire across time zones. The pass goes to the manager by email, so mailbox security for managers is part of onboarding security.
- Break-glass accounts: exclude emergency access accounts from every workflow scope, including inactivity workflows. See the Break-Glass Account Guide.
Integrations, API tokens and service accounts
Custom task extensions call an Azure Logic App (consumption plan) from a workflow. Setting one up needs Logic App Contributor, Contributor or Owner on the Logic App; Logic App Operator is not enough. Two execution modes exist: launch and continue, where the task succeeds once the Logic App starts, and launch and wait, where the workflow waits for a response within a configured window and fails the task if none arrives. A third party system can send that response through the Graph taskProcessingResult resume API.
| Response authorisation option | What it means | Guidance |
|---|---|---|
| System-assigned managed identity (default) | The Logic App's own managed identity sends the response | Preferred: no stored secret, lifecycle tied to the Logic App |
| Existing application | An app registration or user-assigned managed identity responds | Use when a downstream system responds; prefer certificates over client secrets |
| No authorisation | No permission is granted automatically; you assign LifecycleWorkflows.ReadWrite.All or the Lifecycle Workflows Administrator role separately | Microsoft notes this is not least privilege for applications; avoid |
- Logic App permissions: the Logic App often needs Graph or downstream system permissions to do its job (for example granting a manager access to a leaver's mailbox). Review those grants as you would any privileged service principal. See the Azure Logic Apps Security and Azure Managed Identities Security Guide.
- Automation accounts: scripts that create or update workflows through Graph need LifecycleWorkflows.ReadWrite.All; keep that permission on as few identities as possible.
- On-premises reach: the account tasks take optional enableOnPremisesAccount, disableOnPremisesAccount and deleteOnPremisesAccount arguments, and group tasks only affect on-premises resources through group writeback. Without those, a disabled cloud account can leave a working AD account behind.
Logging and detection
Lifecycle workflow actions appear in the Entra audit log under the categories WorkflowManagement (changes to workflows), TaskManagement (task events) and Other (custom task events), with status, failure reason, target object ID and the initiating actor. The portal view covers up to 30 days, so export audit logs to a SIEM or Log Analytics workspace through diagnostic settings for longer retention. Workflow history adds per user, per run and per task results. Correlate both with the Entra ID Sign-In and Audit Log Detection Guide.
- Alert on: workflow scope or task changes outside change windows, on-demand runs of leaver templates, new custom task extensions, and writes to employeeLeaveDateTime that did not come from the HR provisioning identity.
- Watch failures: a failed disable or revoke task is a live access gap; route task failures to a queue with an owner.
- Verify outcomes: sign-ins by users after their employeeLeaveDateTime should be zero.
| Metric | What it shows |
|---|---|
| Median time from employeeLeaveDateTime to account disabled | Leaver latency (expect at most one schedule interval) |
| Successful sign-ins after leave date | Leaver control failures (target zero) |
| Task failure rate per workflow | Data quality or permission problems |
| Users in scope with no hire or leave date | Coverage gaps in HR data |
| Privileged leavers handled outside workflows within SLA | Coverage of the documented role gap |
Hardening baseline
- Fix the data first: map hire and leave dates from the HR system of record, set the time portions deliberately and reconcile users with empty dates.
- Pilot with narrow scope: create workflows with a scope rule matching a test department, enable scheduling only after reviewing history for test users, then widen scope.
- Build the leaver chain: disable account, revoke all refresh tokens, remove access package assignments and cancel pending requests, remove licences later, delete last. Use the on-premises arguments where AD accounts exist.
- Handle movers: use the 15 day delayed removal of access package assignments to allow handover, then request new packages; do not leave movers accumulating access.
- Close the privileged gap: document and test a separate leaver step for users with role assignments or role-assignable group membership.
- Govern the automation: Lifecycle Workflows Administrator through PIM, managed identities for custom extensions, and change review for scope rules.
- Roll back safely: disable scheduling on a workflow to stop it; because delete is the final task, keep a gap of days between disable and delete so a wrongly scoped run can be reversed by re-enabling accounts. Deleted users remain restorable for 30 days in Entra ID.
Small tenants can start with the Offboard an employee and Onboard new hire templates. Large enterprises with several HR sources should standardise scope rules per source and assign a named owner per workflow, keeping well inside the 100 workflow limit.
Common misconfigurations
- Disable without revoke: existing refresh tokens and browser sessions keep working after the account is disabled unless the revoke task runs. See the Employee Offboarding Security Guide.
- Assuming admins are covered: privileged leavers silently fall outside the account tasks.
- Unsupported group types: group tasks only handle cloud security and Microsoft 365 groups; mail-enabled, distribution, dynamic and role-assignable groups are not supported, so access granted through them persists.
- Time zone drift: a midnight UTC leave date for a user in a different time zone disables them early or late.
- Over-privileged extensions: a Logic App with broad Graph permissions and no owner becomes a standing privileged identity.
- Inactivity workflows hitting service and break-glass accounts: scope by user type and exclude emergency accounts.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2, AC-2(3) | Account management and disabling accounts |
| NIST SP 800-53 Rev. 5 | PS-4, PS-5 | Personnel termination and transfer |
| NIST SP 800-53 Rev. 5 | AC-6 | Least privilege for workflow admins and extensions |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, GV.RR-04 | Identity management, access permissions, security in HR practices |
| MITRE ATT&CK | T1078.004 Cloud Accounts | Leaver accounts left active are valid accounts for an attacker |
Practitioner checklist
- Confirm Entra ID Governance or Entra Suite licensing for every user in workflow scope.
- Map employeeHireDate and employeeLeaveDateTime from HR with deliberate times and time zone handling.
- Restrict who can write employeeLeaveDateTime and alert on writes not made by the provisioning identity.
- Pair disable user with revoke all refresh tokens in every leaver workflow.
- Run a separate, tested leaver process for users with role assignments or role-assignable group membership.
- Make Lifecycle Workflows Administrator PIM eligible and review on-demand runs.
- Use managed identities for custom task extensions and review the Logic App's permissions.
- Exclude break-glass and service accounts from inactivity and leaver scopes.
- Export audit logs beyond 30 days and alert on task failures.
Standards and references
- Microsoft Learn: What are lifecycle workflows?
- Microsoft Learn: Understanding lifecycle workflows
- Microsoft Learn: Lifecycle workflow templates and categories
- Microsoft Learn: Lifecycle workflow built-in tasks
- Microsoft Learn: Lifecycle workflow extensibility
- Microsoft Learn: How to synchronise attributes for lifecycle workflows
- Microsoft Learn: Lifecycle workflows audits
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Entra ID Entitlement Management and Access Packages Guide · Joiner-Mover-Leaver Guide · Employee Offboarding Security Guide · Entra ID Security Guide