Come On In!

More Flexibility with Custom Extensions

If you can't find what you are looking for in the list of available tasks, you can add your own. A Logic App helps you do so, offering virtually any option you could imagine to help manage the infrastructure (Figure 4). When you add Custom extensions , you can either select an existing Logic App or create a new one.

Figure 4: Logic Apps can be integrated into custom tasks for special requirements.

If you choose to create a custom extension, it is a good idea to set up the Logic App at this point to guarantee that the app is given the right body and that all parameters are taken into account. For example, the Logic App can be given the user name or even the manager's name as a parameter. Microsoft has given this some careful consideration, and depending on how complex the Logic App ends up being, you can specify what you want to happen after the tasks are completed. For example, do you want to move on to the next task without waiting or wait for the first task to complete?

Planning Considerations

If you want to use the option of mailing TAPs to managers and sharing them with employees, you need to include this ability in the TAP policy available in the Security | Authentication methods section of the AAD dashboard. By default, a pass code is only valid for one hour, which might not be enough in your case. The maximum lifetime can be 30 days, but this is a comparatively long period in terms of security. You need to think carefully about the best possible time setting – Microsoft recommends 24 hours.

Some workflow tasks support the assignment of group memberships to a user account. Depending on a user's work area, it can make sense to provide them with licenses directly; the licenses themselves are linked to groups. Ultimately, this decision is a matter of strategy, but it certainly makes more sense to think about dynamic groups that let you handle the tasks at hand in an elegant way.

At the time of writing, no Mover workflow templates were at hand, and the tasks that a Joiner operation supports are fairly static and related to onboarding. However, if a user changes department and needs different licenses or applications, dynamic groups become a useful option. Remember that lifecycle workflows are just one tool in the Entra toolbox. Sometimes it makes more sense to switch to a different toolset (e.g., dynamic groups in this case) for certain requirements, such as assigning licenses or applications.

The Manager attribute for user accounts is another important aspect for some workflows, but it is not a mandatory attribute and is not set for a new user account, no matter where the user account is created (locally or as a cloud-only account in AAD). Before you start with workflows, you need to make sure that the Manager attribute is populated. It is also worth mentioning in this context that the manager's user account also needs to exist in AAD, which might not be the case depending on filters and the synchronization setup. If the manager's user account is missing, execution fails when the workflow needs to send mail to them.

Synchronization Tools

Virtually any company will have user account management processes in place. These can be based on simple Excel spreadsheets in conjunction with PowerShell, or they can rely on complex HR systems that provide end-to-end user management. No matter how you set up user accounts, they usually reside locally in Active Directory. However, when combined with Azure AD, you face the challenges of a hybrid setup. The two attributes EmployeeHireDate and EmployeeLeaveDateTime , which are important for the workflows, are attached to the user object in Azure and are unknown to the AD domain services. Therefore, you need to map the attributes to ensure that the user accounts have this information locally in AD and then synchronize the information with AAD.

Microsoft currently offers two technologies to configure synchronization in a hybrid environment: The long established Azure AD Connect server and the new Azure AD Connect cloud sync variant, which is managed on the Azure portal. Both technologies are supported: Your task is to make sure that one of the extension attributes is reserved in the local AD to field the time information for the EmployeeHireDate and EmployeeLeaveDateTime attributes in Azure AD. You can use mappings to make sure that the information is synchronized with the AAD account and that the downstream lifecycle workflow can react to it.

Azure AD Connect cloud sync is very easy to manage in Azure AD, where the attribute mappings are set up quickly. The rules editor on the AAD Connect server, where you implement mappings as transformations, is a little more complex. Both are fairly well described in the Microsoft docs [3], and the description also tells you the date and time format you need for the attributes. What the description fails to mention, however, is that the Connect server does not automatically synchronize the extension attributes by default. You need to enable this in Exported Attributes in the Connect Server's install wizard.

By the way, the lifecycle of an identity does not have to start in the local Active Directory or in Azure AD. You can also synchronize identities from another system directly with AAD by HR provisioning, but you still have to assign the attributes. With Workday and SAP SuccessFactors as examples, Microsoft describes how IT managers can configure the mappings on the systems. In summary, no matter how a user account gets into your Azure AD, the AAD attributes for the lifecycle workflows need to be populated.