Following from my previous blog on Integrating HR and IAM systems I thought I’d go over a more detailed walkthrough of Azure Lifecycle Workflows. 

Lifecyle Workflows is a service offered in Microsoft Azure that allows companies to automate a significant portion of their on and offboarding processes. This service can help organizations reclaim product licenses, free up the help desk’s time, and improve security and compliance by ensuring users are properly decommissioned.

These workflows are separated out into stages, allowing you to space out different actions to take on a user object at different times in the employee lifecycle. For example, you can send an employee a welcome email several days prior to their start date with information for new hires and links to public-facing self service sign up portals, and wait to enable their account until their actual start date. 

It’s important to note that Lifecycle Workflows aren’t a 100% replacement for a full IAM program. It can’t manage things like programmatic access to resources like you would with Infrastructure as Code, but it will make your Joiner, Leaver, Mover processes much more streamlined.

Planning

Before we start diving into trying to create these workflows, it’s important to take a step back and ask a few questions. What do we want the employee experience to be? What will this cost? What’s our roadmap for starting features vs. long term implementation?

Employee Experience

At a very basic level, the goal of any Joiner Mover Leaver process should be to ensure employees have access to what they need when they need, and to remove those accesses when no longer needed.

To take it a bit further, we should aim to hand a new employee access to everything they need to do their job on day 1, remove their accesses immediately upon offboarding, and ensure their manager remains informed every step of the way.

Cost

Back when it was in public preview, Lifecycle Workflows were included in Microsoft Entra P2 licensing. Now that it has left public preview, an Identity Governance license costs $7 per user per month – on top of P2 licensing.

To me this came as a real disappointment. It started out as a feature which saved time, money, and improved security – three things that are almost always a tradeoff. Now, as with other products, implementing Lifecycle Workflows means you’re paying extra for those time saving and security benefits.

So is it still worth it? This ultimately depends on your budget, your risk tolerance, and how much time IT staff have for user provisioning and offboarding. It’s worth considering that you could automate just about the same features with some PowerShell scripting, but this comes with the downside that the code will need to be updated and maintained. When turnover eventually occurs you may lose the institutional knowledge of how the process functions. Meanwhile, basic Lifecycle workflows are much simpler to approach for those who aren’t familiar with scripting.

Roadmap

Just like with a business writ large, it’s best to start with a sort of minimum viable product when starting to roll out Lifecycle Workflows.

A good first step is to make a simple workflow applicable to everyone in the organization. What actions do you want to take for every new employee regardless of their role in the company? Working with stakeholders across the organization at this stage to craft the vision for the employee experience can go a long way to building positive relationships between an IAM team, HR, and the IT service desk among others.

Once you’ve built this first basic workflow and proven the benefits, then it’s time to build out your next steps – making custom workflows for different groups within the company based on their access needs. This can be be based on team, job role, business unit, or even location.

One big question you will want to ask is how you want to go about tackling these custom workflows. The IAM team could proactively reach out to one (or several) new team(s) per sprint to work with managers on building a custom workflow for their team. Alternatively, you could set up a ticketing process where team leads can request new workflows on demand.

The Phases

Azure Lifecycle workflows are broken down into onboarding, offboarding, and real-time changes. Onboarding and Offboarding are both further broken down into workflows that execute on the day of a join/leave event, and actions taken before or after.

This comes in handy when you don’t want every action to occur all at once. For example, you would probably want an email sent out to a new hire with their first day instructions a few days prior to their actual start date. You wouldn’t want to enable their access until their first actual day of work, however.

Here’s an example of how we might separate actions out into the different phases of Lifecycle Workflows:

Pre-onboarding:

• Send an informational welcome email to the new hire’s personal email
• Send an email to the employee’s manager reminding them of the upcoming new hire start date

Onboarding:

• Enable the user account
• Send a day 1 welcome email to their company email address laying out a schedule of onboarding meetings and important steps to take in their first few days – mandatory trainings, where and how to set up their benefits, etc. 
• Add the user account to the appropriate email groups and teams
• Assign licenses needed by members of the new employee’s team

Post-onboarding:

• Send a follow-up email inviting the new hire to various optional groups within the company

Pre-offboarding:

• Send email to user’s manager prior to their last day explaining things like “how long will I have access to my former team member’s inbox and data?”
• Cancel all future access requests

Offboarding:

• Disable account
• Remove from all groups and teams
• Reclaim licenses
• Send email to the employee reminding them to back up their data (to OneDrive, etc.)
• Send email to manager confirming user is offboarded, inform them they will have access to the terminated employee’s email for 30 days and how they can request an extension

Post-offboarding

• 30 days after offboarding, delete the user account
• Send email to manager letting them know what they need to do if they still need access.

Now that we’ve covered the planning stage and have a solid idea of what we want to implement for our first set of workflows, lets see how we might put this into action in the Azure portal.

Pre-onboarding

When we configure our pre-onboarding workflow, the default is to take action 7 days prior to the “employeeHireDate” attribute in Entra (formerly Azure Active Directory). This is where it becomes useful to sync this attribute from your company’s HR system, such as Workday. 

On the “Configure Scope” tab, we can customize who the workflow is going to apply to. We can for example set up a workflow that operates on all new employees by setting “companyName” to the name of your company as it appears when synced from your HR system.

This also allows you to designate different workflows (including custom welcome emails and accesses) for employees in different business units, offices, teams, or even countries. You can also designate “userType” – this is typically either Member or Guest to distinguish internal employees vs. guest users from outside the company.

Remember, If your organization is just starting out with these kinds of automation, break it up into chunks. IAM is a process, not a single project. Build a single, basic onboarding workflow for all new hires to send welcome emails, enable accounts, add new users into company-wide email lists, and add them to a group from which they inherit an Office license. 

Once this is in place, you can begin the process of creating custom workflows for individual teams. For example, you can create tasks which will add members of the Sales department to their own distribution lists, M365 groups, or shared mailboxes, and add them to groups which grant access to sales applications.

The desired end-state of this process is to ensure every user has the accesses they need on day one of their employment. 

The next tab is “Review tasks”. This is where we will designate what actions we want the workflow to take. For pre-onboarding, let’s stick with sending a welcome email to the new employee’s manager, and to the new employee’s personal address. This can be synced from the HR system, kept as a separate attribute from their company email.

You’ll notice on any email related workflow tasks that you can customize the subject and email body. In the email body, Azure can substitute user attributes which will automatically be replaced with the value of the given attribute.

This is where you’ll want to partner with Human Resources. HR and those they work with are great at crafting user-friendly messaging. As engineers, it’s part of our job to translate the “tech-speak” you can see in the screenshot below and to provide guidance on what these attribute substitutions can accomplish. 

The “Review + create” tab will summarize the settings you’ve chosen before creating the workflow itself. 

*A note on TAP

You might have noticed a “Generate TAP and send email” task. A Temporary Access Pass, or TAP, can be used as a time-limited code that allows users to enroll in passwordless solutions. It can also be used for end-user device setups, like sending a laptop to the new employee which can be set up to join the domain when the TAP is entered. If your desktop management team is interested in this, be sure to include them as a key stakeholder. Setting up TAP – or not – can have a major impact on end user device rollouts.

Setting up TAP and integrating it as a part of the onboarding process is a project unto itself, and may be outside the scope of your first workflows.

Onboarding

On the Basics tab, you will see that the workflow is set to execute based on the “employeeHireDate” attribute. On the Configure scope tab, make sure all attributes and values match what you entered for the Pre-onboarding workflow – this will ensure users are affected by both phases of the workflow.

On the Review tasks tab, we will select the actions we want to take on the first day of a user’s employment. This is where we will want to enable the user account. We will also send a welcome email to their employee inbox with any internal company resource links we want them to have. Lastly, we will add the user to any teams and groups they need to be a part of. For our first workflow, this will specifically be for all-employee groups.

In our future workflows, we can set the Configuration scope to indicate individual company teams, and then designate groups to add the team members to which will grant them access to additional licenses and resources needed by their team members.

You may have noticed two additional tasks listed here. “Request user access package assignment” will only be applicable if we choose to make use of Access Packages in Azure. These are basically a different way to bundle access permissions within Azure.

“Run a Custom Task Extension” is a powerful tool that we can use to link other actions to Lifecycle Workflows. One of the first ways most organizations will want to use this is to connect Lifecycle Workflows to their on-premises Active Directory environment. Once configured, a custom task extension can be used in conjunction with Azure Logic Apps, Runbooks, and PowerShell to allow Lifecycle Workflows to trigger actions on objects within Active Directory.

In a future post, I will cover how to use this functionality to add and remove users from on-premises AD groups.

Post-onboarding

We may also want to set up a Post-onboarding workflow for tasks such as sending training reminders. Once again we will copy the Configure scope tab from Pre-onboarding to ensure actions apply to our users at all stages. On the Basics tab, you can customize the number of days after the “employeeHireDate” attribute to initiate the action.

On the Review tasks tab, add the “send a welcome email” task and configure the message with any post-onboarding information you would like to convey.

Pre-offboarding

In the offboarding phases, we will largely be reversing the operations we performed in the onboarding phases.

In Pre-offboarding, we can set the number of days prior to the “employeeLeaveDate” attribute on which to take these actions. When configuring the scope, you should generally aim to be as broad as possible – by simply setting the “companyName” attribute as the scope for example – to ensure all offboarded users are properly decommissioned.

To start, let’s add the task “Send email to manager before user’s last day” and customize the email to remind their manager of the offboarding process and how to access their employee’s data. This is another sensitive area in which it is best to consult with managers from across the organization to come to an agreement of a reasonable duration for this access to remain.

Second, add the “Cancel all pending access package assignment requests for the user”. This will delete any requests they have submitted for additional access packages, as they are unlikely to need new accesses in their last days with the company.

Offboarding

These actions will be taken based on the “employeeLeaveDate” attribute, or on the day and time the user’s employment is scheduled to end. This should be synced from your HR system – without establishing proper attribute syncing first, these tasks will not trigger. As with pre-offboarding, leave the “Configure Scope” tab fairly broad so users aren’t unintentionally skipped.

At the end of the user’s last work day, the tasks below will disable the user’s account and prevent them from logging in, remove the user from all groups and teams, reclaim their licenses, and remove any currently assigned access packages. Ideally all your licenses should be inherited from group memberships, but it’s always best to be safe and include the “Remove all licenses” task just in case.

As with onboarding, the “Run a Custm Task Extension” can be used to interact with on-prem Active Directory to remove the user from any groups that may not be synced to Azure, and remove their on-prem permissions.

Post-offboarding

Lastly we will add a small number of tasks to perform after a user has left the company. On the Basics tab we can set the number of days after the “employeeLeaveDate” attribute when we want this task to occur. My recommendation is 30 days. For Configure scope, we’ll keep it the same as in our other offboarding phases.

The reason we want to stick with 30 days is tied to the tasks we will be performing with this phase of the workflow. This plan assumes that we want an employee’s manager to maintain access to their inbox and data for 30 days.

The custom extension attributes can be set up to take actions such as delegating access to the manager, but it’s unlikely you will want this access to remain indefinitely. We will add a task to delete the user’s account when the workflow triggers (30 days after departure) and to let the manager know how to submit a request in the event they need to recover this data.

Once the user account has been deleted by the workflow, Microsoft retains the data for an additional 30 days – during this time, you can restore the account in the M365 admin console and the data can still be recovered.

Conclusion

When it comes to IT management, balancing security, efficiency, and user experience is pivotal. Microsoft’s Azure Lifecycle Workflows offer one possible solution to managing the employee lifecycle. As you contemplate adopting this feature, be sure to weigh the benefits of its simplicity versus the licensing costs.

And remember – start small. IAM is a process, not a project.

The step-by-step breakdown in this guide serves as a roadmap, steering you towards a well-executed implementation that brings both security and efficiency to your IT operations. Happy workflow crafting!