Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Workflows created using Lifecycle workflows allow you to automate common tasks for users based on where they fall in the joiner, mover, and leaver model of their lifecycle within your organization. These workflows are able to run in two ways, manually(on-demand) for specific users, or based on a schedule if a user meets the defined execution conditions of a workflow. These execution conditions are defined by two parts, a trigger, and a scope. This article describes execution conditions, the difference between the workflow triggers and scopes, and the conditions for when a scheduled workflow runs for users.
Workflow execution conditions
For a workflow to run for users based on a schedule, they must first meet its execution conditions. The execution conditions consist of:
- Trigger: Defines the conditions for when a workflow runs for users.
- Scope: Defines which users the workflow runs for.
The trigger you choose depends on what type of workflow you want to run for users, and the scope you choose is based on the trigger selected. There are currently four types of triggers supported:
- Time based attribute: The workflow is triggered on schedule when a time value is met.
- Attribute changes: The workflow is triggered on schedule when a change to an attribute happens.
- Group membership change: The workflow is triggered on schedule when a group membership change is met.
- Sign-in activity: The workflow is triggered on schedule when a minimum number of days since the user last signed in is met.
- On-demand only: The workflow is only triggered manually.
Note
The On-demand only trigger is the default trigger of workflow templates that are on-demand only. For the full list of workflow templates, and their compatible triggers, see: Lifecycle workflows templates and categories.
Time based attribute trigger
The time based attribute trigger allows you to set a trigger based on when a time value is met.
When setting a workflow where the trigger type is Time based attribute, the following details are defined:
| Trigger detail | Description |
|---|---|
| Days from Event | The days from the event user attribute for when the workflow is triggered. Value can be from 0-180. |
| Event timing | Defines when the Days from Event detail for a workflow is triggered. For example, a workflow that is scheduled to run for a user before they start working would have an event timing value of Before, while a workflow scheduled to run for a user after they leave your organization would have an event timing value of After. If selecting a template for a workflow that runs on the same day as the event user attribute, the value is On. |
| Event user attribute | The attribute defining the change that triggers the workflow. The type of workflow being used determines the attributes available. A joiner workflow can have the attribute value of "employeeHireDate" or "createdDateTime", while a leaver workflow has an attribute value of "employeeLeaveDate" or "LastSignInDateTime". For a list of templates, and their event user attributes, see: Lifecycle Workflows templates and categories. You are also able to set custom attribute triggers. For more information, see Use Custom Attribute Triggers in Lifecycle Workflows (Preview). |
Note
The event user attribute must be set within Microsoft Entra ID for users. For more information on this process, see: How to synchronize attributes for Lifecycle workflows.
Time based attribute scope
The time based attribute scope allows you to define for who the workflow runs when the time trigger is met.
When setting the scope of the time based attribute trigger, the following details are defined:
| Scope detail | Description |
|---|---|
| Scope type | Rule based. |
| Rule | Defines the rule for who meets the scope of the time based attribute trigger. |
Note
The rule evaluation is case-sensitive.
Attribute change trigger
The Attribute change trigger allows you to set a trigger based on when an attribute changes for users.
When setting a workflow where the trigger type is Attribute change, the following details are defined:
| Trigger detail | Description |
|---|---|
| Trigger Attribute | The trigger attribute defines the attribute that's being changed to trigger the workflow to run. You are also able to set custom attribute triggers. For more information, see Use Custom Attribute Triggers in Lifecycle Workflows (Preview). |
| Action/Operator | Defines the change to the attribute that triggers the workflow to run. |
| Value | The value of the trigger attribute. |
Attribute changes trigger scope
The attribute changes trigger scope allows you to define for who the workflow runs when the attribute change trigger is met.
When setting the scope of the attribute changes trigger, the following details are defined:
| Scope detail | Description |
|---|---|
| Scope type | Rule based. |
| Rule | Defines the rule for who meets the scope of the attribute changes trigger. |
Note
The rule evaluation is case-sensitive.
Group membership change trigger
For workflows that are triggered based on a group membership change, the workflow runs on a schedule when a user is added to, or removed from, a group.
When setting a workflow where the trigger type is Group membership change, the following details are defined:
| Trigger detail | Description |
|---|---|
| Action | Describes which group membership change that triggers the execution condition. Can be Added to group or Removed from group. |
Group membership change scope
The group membership change scope allows you to define for who the workflow runs when the group membership change trigger is met.
When setting the scope of the group membership change trigger, the following details are defined:
| Trigger detail | Description |
|---|---|
| Scope type | Group based. |
| Selected group | Defines the group for which the trigger action is based on. |
Sign-in inactivity trigger
The Sign-in inactivity trigger allows you to set a trigger based on when a certain number of days has passed since the user last signed in.
When setting the scope of the sign-in inactivity trigger, the following details are defined:
| Scope detail | Description |
|---|---|
| Days of inactivity | The number of days since the user last signed in. |
Sign-in inactivity scope
The sign-in inactivity scope allows you to define for who the workflow runs when the sign-in inactivity trigger is met.
| Scope detail | Description |
|---|---|
| Scope type | Rule based. |
| Rule | Defines the rule for who meets the scope of the attribute changes trigger. |
On-demand only trigger
The On-demand only trigger is set to run the workflow for users you manually select. Workflows with these triggers don't run on a schedule. The users are selected within the scope details section of the workflow.
When setting a workflow where the trigger type is On-demand only, the following details are defined:
| Trigger detail | Description |
|---|---|
| Scope type | The scope type determines how the scope of the workflow is defined to run. The default for this is User selection. |
| Selection type | The selection type of the workflow can be set as to either allow you to choose users during its creation for who it runs as soon as the workflow is created, or by allowing you to choose which users to run the workflow for at a later date. |
For a detailed guide on running a workflow on-demand for users, see: Run a workflow on-demand.
Execution user scope
After the execution conditions are set for an enabled workflow, you're able to see a list of users who currently meet it's execution conditions. This user list is made up of users who the workflow runs for the next time it executes, and is based on the last time the workflow engine evaluated users within your tenant.
If the execution conditions recently changed for the workflow, then the execution user scope list might not be current. When the execution conditions are recently changed, the list refreshes with users meeting the latest execution conditions after the workflow engine evaluates the users again. Before the workflow runs for the users, it also checks to make sure the list of users still meet the current execution conditions.
For a detailed guide on viewing the execution user scope of a specific workflow, see: Check execution user scope of a workflow.
Lifecycle workflow catch-up window
By design, Lifecycle workflows provide a three day catch up window to help customers process users that could have been missed due to delays in HR user data updates. This means when the workflow engine evaluates users that meet the current execution conditions for the scheduled workflow, it includes users for whom the expected trigger date has already passed but wasn't more than three days past the original trigger date. Once the user is processed, it would only be considered again if there was a change for the user or workflows that allowed it to meet the execution conditions again.
The following table shows examples of Lifecycle workflow's catch up window:
| Workflow Scenario | User Data | Lifecycle workflow behavior |
|---|---|---|
| A pre-hire template workflow is scheduled to run for users 7 days before their EmployeeHireDate. | A user is provisioned by HR in Microsoft Entra ID with an EmployeeHireDate in 10 days. | The workflow runs for the new user as the date is before the offset. |
| A pre-hire template workflow is scheduled to run for users 7 days before their EmployeeHireDate. | A new user is provisioned by HR in Microsoft Entra ID with an EmployeeHireDate in 5 days. | The workflow runs for the new user as the date is within 3 days of the offset. |
| A pre-hire template workflow is scheduled to run for users 7 days before their EmployeeHireDate. | A new user is provisioned by HR in Microsoft Entra ID with an EmployeeHireDate in 3 days. | The workflow does not run for the new user, as the date is more than 3 days from the offset. |
| A new hire workflow runs on Feb 23 for in scope users with EmployeeHireDate of Feb 23. | A new user is provisioned by HR in Microsoft Entra ID on Feb 24 with an EmployeeHireDate set as Feb 23. | The workflow runs again on Feb 24 for the new user, as the date is within 3 days of the offset. |
Workflow scheduling
While newly created workflows are enabled by default, scheduling is an option that must be enabled manually. To verify whether the workflow is scheduled, you can view the Scheduled column on the workflow overview page.
Once scheduling is enabled, the workflow is evaluated either every three hours(by default), or by the interval you select in workflow settings, to determine whether or not it should run.
Note
Once the user meets the execution conditions, and is in scope of the workflow, the Lifecycle workflow engine evaluates the user once again before the workflow starts to process them. If the user no longer meets the execution conditions of the workflow, then they won't be processed.
For a detailed guide on setting the execution conditions for a workflow, see: Create a lifecycle workflow.