Run joiner, mover, and leaver automation from verified identity attributes

Bottom line: Microsoft Entra Lifecycle Workflows can run joiner, mover, and leaver tasks automatically, including tasks triggered from user attributes. Automation is only as reliable as the identity data and execution scope behind it. Treat each workflow as an access-changing production process, not as a convenient set of notifications.

Source fact: what Microsoft documents

Microsoft’s Lifecycle Workflows overview describes workflows built from tasks and execution conditions. A condition defines who is in scope and when the workflow runs. Microsoft gives the example of using an employeeHireDate attribute to trigger a manager email before a start date, and documents scheduled and on-demand execution.

The service addresses joiner, mover, and leaver phases. Documented uses include managing static group membership, disabling or removing accounts, assigning or removing access packages, extending a process through Logic Apps, and reviewing workflow history and audit logs. Microsoft also states that the feature has licensing requirements and service limits; those details must be rechecked for the intended tenant before design approval.

What the source does not establish

The overview does not prove that an HR feed is accurate, that every downstream application honors an Entra change immediately, or that a template covers an organization’s complete offboarding obligations. It does not make a mistaken department, date, manager, or employment-status value safe. A successful Entra task also does not prove that local accounts, application-native permissions, physical access, shared secrets, or active sessions were closed.

Applicability questions

• Which system is authoritative for hire date, departure date, worker type, department, manager, and leave status?
• Are contractors, seasonal workers, service accounts, guests, rehires, and people with future-dated changes deliberately included or excluded?
• Which tasks change access, and which merely notify an owner?
• What is the expected delay from source change through provisioning, workflow evaluation, and downstream enforcement?
• Which licenses, supported tasks, limits, and Logic Apps dependencies apply in this tenant today?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Map each workflow condition to an owned source attribute and document acceptable values, update timing, and failure handling.
2. Test with synthetic users representing joiners, movers, leavers, rehires, missing attributes, late feeds, and conflicting changes. Confirm both intended actions and non-actions.
3. Start with a narrowly scoped pilot. Separate irreversible or high-impact tasks from low-risk notifications, and require an accountable owner for exceptions.
4. Reconcile workflow results with downstream directories, applications, groups, licenses, sessions, and any non-Entra access systems in the real departure checklist.
5. Establish an alert and work queue for failed, skipped, delayed, or partially completed executions.

Verification and evidence

• Preserve the approved workflow definition, scope expression, task list, change record, and test identities.
• Export or retain workflow history and audit events showing start time, target, task result, and failure detail.
• Sample completed joiner, mover, and leaver cases against the authoritative HR record and downstream access state.
• Record the owner, resolution, and retest for every failed or manually overridden task.

Official references

• What are lifecycle workflows? — Microsoft