Few days back, Microsoft announced the general availability of Lifecycle Workflows, a new feature intended to help organizations automate some aspects of the joiner/mover/leaver process. In this article, we will take a quick look at the Lifecycle Workflows, disregarding much of Microsoft’s marketing hype.
What are Lifecycle Workflows and how to access them
In a nutshell, the feature allows you to configure a set of tasks that will execute upon satisfying certain conditions. The focus is on the lifecycle of an Azure AD user account, so the tasks involve things like sending a welcome email or adding to a group. Similarly, the conditions are also focused on various events in the lifecycle of an account, such as its creation date. We will explore both tasks and conditions (triggers) in the next section. For now, let’s focus on how to get access to the feature.
First things first, the feature is certainly not cheap. Positioned as part of the Microsoft Entra ID Governance product, and thus not included in any of the existing Office 365 or Microsoft 365 bundles, it will cost you $7 per user per month ON TOP of the required Azure AD Premium license. But don’t worry, Microsoft’s sales page will cheerfully inform you that a special price is available for Microsoft Entra ID P2 customers until Dec 31, 2023.
What Microsoft fails to inform you is how the feature is actually licensed. Do you need a license for each user under the scope of any workflow? Can you remove the license once the desired flows have run? Can you “cycle” available Entra ID Governance licenses between users? Are the licensing requirements enforced in code, i.e. will there be any impact on workflow runs against unlicensed users (I can tell you the answer here: NO)? Those are all questions Microsoft does not currently address in their documentation. What they do mention is how the feature will behave after the license has expired:
Be aware that if your license expires, any workflows that you have created will stop working. Workflows that are in progress when a license expires will continue to execute, but no new ones will be processed.
On the positive side, a free 30-days trial of Microsoft Entra ID Governance is available. Once you have procured the required licenses, or activated the trial, you can access the Lifecycle Workflows feature in the Entra portal. Open the portal, then expand the Identity Governance node and click on Lifecycle Workflows. If you are fan old the Azure portal instead, you can access the feature via the Azure AD blade > Identity Governance > Lifecycle Workflows. In either case, the UI is still powered by the Azure “blades” interface, which is another, albeit more subjective, nitpick.
And of course, you also need to have permissions in order to access the feature. Currently, the only roles that can manage Lifecycle workflows are the Global administrator one, and the newly introduced Lifecycle workflows administrator. Read-only access is facilitated via the Global reader role. No granular controls are available to limit access per different business units.
Configure your first Lifecycle workflow
With the basics out of the way, let’s see the feature in action. To do so, we will need to create at least one workflow, by clicking the Create workflow button on the Overview page, or navigating to the Workflows tab and clicking the same button. The first step is to select the template on which your workflow will be based. There is no option to start from scratch, so selecting a template is mandatory step. The templates themselves are grouped by Category (Joiner, Mover or Leaver, respectively) and Trigger type (date with an optional offset or on-demand). Click the Details link under each template to review additional information about its purpose and configuration.
Once you have pinpointed the most suitable template, hit the Select link (or the Select template button if you have the Details pane opened). In our scenario, we will use the Onboard new hire employee template. On the next page, you can change the Name and Description of the workflow, or accept the defaults. As some of the templates enforce mandatory scoping (more on this in a bit), it’s a good idea to at least amend the Description property with information about the scoping filters.
Next, you configure the workflow’s Trigger details. Not much choice is given here, as a workflow can either be run on a given date, or on demand. The former is determined based on the value of the user’s employeeHireDate or createdDateTime properties (for Joiner scenarios), or employeeLeaveDateTime (for Leaver scenarios). An optional offset can be configured, ranging from -180 to +180 days (i.e. six months). Workflows based on the Mover templates on the other hand are always run on demand.
The next step is to Configure scope for the workflow. For any workflows that execute automatically, such as the one we selected in the previous step, scoping is mandatory. Luckily, the rules syntax used exposes a wide range of properties, so you are given some freedom. Though you should be aware that values are case-sensitive! The process itself is similar to that of creating a dynamic membership rule, so you might already be familiar with it. At least one rule must be configured however, so if you want a workflow that targets all users, make sure to change the default selection. Similarly, you can configure a rule to only target Guest users.
Lastly, we need to select the Tasks to be executed as part of the workflow. Similar to workflow templates, you are given the option to select from a set of tasks, scoped by a Category that should match the workflow’s Category. Most workflows come with a predefined set of tasks, but you can add, remove, reorder or disable/enable tasks as needed. Another important thing to note is that some tasks require additional input to be provided, and the UI will not allow you to proceed further before you’ve taken care of filling all the details.
No screenshots are included for the steps above, as the documentation on creating and managing Lifecycle Workflows is quite comprehensive – make sure to read through it for detailed step-by-step instructions and additional details. But as we are going to reuse the Onboard new hire employee workflow in the rest of the article, it makes sense to at least show its settings here. As illustrated on the screenshot below the defaults are kept for all the settings, so the new workflow will trigger on the hire date of any employee joining the Marketing department, and will result in three actions:
The last thing to mention in this section is the fact that workflows support versioning, though only in the form of showing you a snapshot of the workflow configuration at a given time. While you cannot rollback to a previous version, this functionality is useful for troubleshooting and auditing purposes.
Lifecycle Workflows in action
Now that we have at least one workflow configured, let’s see it in action. The fastest way to do this is to select it under the workflows page and click the Run on demand button. Of course, running automated workflows is much more valuable, and if we are to test this scenario, we need a new user provisioned. There is no task available currently to provision a user account, so you need to do this outside of Lifecycle Workflows. Same goes for configuring any of the user’s properties, such as the mandatory employeeHireDate, and the Department one, that will ensure the workflow above actually triggers.
Here is a good place to mention that any scheduled workflow (i.e. one for which you toggled the Enable schedule setting as part of the creation process) runs on a predefined cadence – once every three hours. While you can adjust this period under the Workflow settings page, the value selected therein will apply to all scheduled workflows within the organization and you cannot have a different schedule per workflow. On the same page you will find a handful of other settings related to workflow execution, such as the email address from which notifications will be sent (you can only modify the domain part) and whether to use the company branding logo for said notification emails.
Anyway, once our scheduled workflow stumbles upon a user account with employeeHireDate value of today, while also matching the configured scoping filter, any tasks associated with the workflow will be executed. Actually, the above statement might not always hold true, as there is a three day window in processing scheduled workflows, as detailed in the documentation. This might pose some challenges for workflows that are time-sensitive, but for our examination, the important thing is that the workflow will eventually process the user.
A comprehensive Workflow history is provided, showcasing statistics around each workflow run, the set of tasks executed and the users processed. As the scoping filter is effectively a dynamic user query, you can preview the set of users which will be included in the next flow execution by selecting Execution conditions > Execution user scope, which is a nice touch. Lastly, you can use the Overview page to check when the workflow is scheduled to run next.
As indicated on the screenshot above, our workflow will process a total of one new user in the next run. At the designated time, the workflow was executed and the user was processed, as expected. Due to the fact that we provisioned a user without a mailbox (or a mail attribute, in general), the Send Welcome Email task failed, and in turn caused the workflow to fail as a whole. While you can certainly hope for the best, in real life scenarios it’s almost inevitable that one or more tasks will eventually fail. To help with such scenarios, Lifecycle Workflows allows you to configure the behavior for failed tasks by toggling the Continue workflow execution on error setting for each task.
The Workflow History page is the main tool for troubleshooting failing workflows. It offers breakdowns by user, workflow run or task and allows you to quickly investigate why a given task/workflow failed. In the example below, two runs are shown (the workflow was updated in between them to ensure the user is reprocessed). You can click the date link to bring up a pane showing a list of all processed users and executed tasks, along with their corresponding status and any errors encountered. Starting from the Users or Tasks tabs, you are also able to obtain the same information.
When it comes to fixing the errors, things could be better. While you can update a missing attribute, you cannot rely on the workflow engine to reprocess the failing user(s). As quoted from the documentation:
For a particular user and workflow version, the scheduled workflow execution is performed only once every 30 days. Also, the execution of on-demand workflows of a particular workflow version in the last 30 days results in the scheduled workflow execution not taking place for a particular user.
Making a change to the workflow should trigger reprocessing, however that’s not something you’ll be doing for all failed user. In most scenarios, you will likely end up executing the workflow on demand. Running a workflow on demand ignores any scoping filters and execution conditions.
Additional notes and summary
The above should cover the basics of Lifecycle workflows. As mentioned already, comprehensive documentation is available online, which should address questions not answered here, and provide you with detailed step-by-step instructions. Before closing the article, we’d still want to mention few important bits.
Firstly, the feature is released with full API support, by means of the workflow resource type and its corresponding methods and properties. And while the feature currently offers a limited set of templates and tasks, an extensibility mechanism is provided in the form of custom task extensions, powered by Logic Apps. Personally, I would prefer if the feature itself offered more customizability, without having to rely on additional services, but perhaps that’s something we will see in the future.
Next, as with any other feature, there are certain limits that you should be aware of. Two limits in particular raise an eyebrow: the 50 workflows per tenant will likely be a problem for any large organization, whereas the 10 users per on-demand workflow execution makes sense only if you are using this functionality for testing purposes. The single execution per user per workflow version was already mentioned above and is also likely to cause some trouble. While you can execute the workflow on demand as a workaround, the 10 users per execution limit makes this method impractical for a workflow that can potentially span across hundreds of users.
The other major limitation to Lifecycle Workflows is the limited task support. A total of 22 tasks are currently supported, most of which are variations of sending email, adding/removing users to group or a team, and managing access package assignments. There is no task to provision a new user, assign a license (one can argue that access package assignment takes care of that), reset a password or any action covering Exchange Online mailboxes or SharePoint Online sites. In fact, I will also add the fact that you cannot get a full lists of tasks anywhere in the UI as a con here, too.
While you can leverage a custom task extensions via Logic apps, integration with Power Automate looks a lot more logical to me. And while I’m sure the number of tasks will steadily grow over the coming months, some further customization capabilities will be much appreciated. For example, being able to select which attribute to be used as input for the task, instead of the hardcoded values currently in use. And, the task description itself should be a lot more comprehensive. For example, does the Remove user from all groups task include Distribution groups, or groups with Dynamic membership?
Lastly, custom workflows are a must. At the very least, being able to select other trigger types. Or ideally, using an Audit event as the trigger, instead of a (offset) datetime value. As an example, changing the user’s Department attribute could trigger a Mover workflow, instead of having to run it on-demand, as with the current implementation. Other potential improvements include per-workflow schedules, the option to add an approval step, execution fallback options, and more.
Speaking of audit, the feature does generate audit records, though some of them are light on details. For example, a Scheduled workflow execution completed record will neglect to tell you which specific tasks failed, if any. Thus, for troubleshooting purposes, you’re better off using the Workflow History data, as mentioned above.
All this is not to say that Lifecycle Workflows are without merit. They will surely be appreciated by some companies and most of the issues outlined above are likely to be addressed as the feature matures. I’m not so sure about the licensing aspect of it however – Microsoft has a very poor track record on that front lately and is still stubbornly trying to push new SKUs left and right. And while Lifecycle Workflows certainly has potential, the current price is ridiculous, and you’re better off looking at third-party alternatives, or even investing in your own solution.
1 thought on “First look at Microsoft Entra’s Lifecycle Workflows”