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.
- 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. |
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 is being changed to trigger the workflow to run. |
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:
Scope detail | Description |
---|---|
Scope type | Group based. |
Selected group | Defines the group for which the trigger action is based on. |
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.
Note
There's currently a catch up window for users based on a 3 day period. This means that when a workflow is created, the workflow engine considers users, who previously met its execution conditions, within 3 days of the scope of the users. For example, if you created a pre-hire workflow to run for users in a certain department 1 week before their hire date, a user who was created within 10 days before their hire date would also fall under the scope of the workflow.
For a detailed guide on viewing the execution user scope of a specific workflow, see: Check execution user scope of a workflow.
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.