For the August release the Nintex Workflow Cloud team is super excited to be announcing our initial set of actions for providing integration with Azure Active Directory, not only that but we’ve also developed it using the Microsoft Graph! And if that’s not exciting enough for you then this surely will, all the actions have been built on top of the recently released Xtensions framework which should give you an idea of the power of Xtensions on how it can be leveraged to develop your own custom actions in Workflow Cloud.
What is the Microsoft Graph?
As mentioned, we developed the Azure AD actions using the Microsoft Graph which for all the non-techies out there (and maybe some techies) is Microsoft’s single endpoint (API) that provide access to a range of Microsoft Cloud services including Azure AD, Office 365, Planner, SharePoint, OneDrive to name just a few. One of its purposes is to simplify access to all of these cloud services.
How can I use the Graph in Workflow Cloud?
For anyone who wants to build custom actions that integrate with the Graph the good news is that the Xtension framework now supports a new security option for ‘Microsoft Graph’. Under the covers this is exactly how we developed the AD actions so if you’re feeling adventurous to start building your own actions the building blocks are in place, we’d love to see what you come up with (see Xtensions™ SDK for more information).
One of the important things to understand when you start working with the Microsoft Graph is that many of the operations require what’s called ‘Admin Consent’. It simply means that before a Connection can be created in Workflow Cloud to an Azure AD instance an AD admin needs to provide consent for the Workflow Cloud to access the AD instance (we only require read permissions), this is just part of the normal Microsoft auth flow dialog. However if a non-admin account is used to create a connection they will see the consent dialog below.
Important to note that Admin Consent is a once-off process and only required by someone who is not an AD admin.
Enough about that, let’s have a look at the actions in detail.
Our first release of Azure AD integration is primarily focused on retrieving and querying user based information, we understand you need more than that which is why Create/Update//Disable user will be coming in the not to distance future..
As you begin to look at the actions you will notice the primary key to identify a user is an email address which in AD language maps the User Principal Name (UPN), this key can obviously come from anywhere as long as it maps to the UPN in Azure AD.
Get user details action
This action allows you to retrieve profile information of an individual user including properties such as First name, Last name, Department, Job title to name a few. Here's a configuration with four properties added plus showing how you would add additional AD properties using the 'Add fields' multi field selector.
Get manager details action
This action allows you to retrieve the same fields as Get user details however this time it’s for retrieving details about someone’s manager, all you need to supply is the email address on an employee (person's who's manager you want to get) and it will return all their manager details.
The Get manager action becomes extremely powerful when building workflows that involve some kind of task approval. Many of the workflows we build today usually involve some kind of manager approval however in Workflow Cloud (unlike SharePoint) we don’t really have an easy way of finding out who this is, now it’s as simple as using this action and supplying the users email address.
Another way Get manager can enhance the power of your workflow is by using it in conjunction with the recently released Task escalation feature. The Express approval action just got a major enhancement to include the ability to escalate a task based on a specified time frame.
For example, let’s say you have an Express Approval task assigned to your manager (using Get Manager of course) and s/he doesn’t action the task for say 1 week, you can configure the task to be escalated to your manager’s manager by using the Get Manager action and passing in the manager's name. So simple but extremely powerful, really helps to ensure your workflows continue their flow and don’t get bogged down due to inactivity of participants.
Below shows the updated Express Approval action with escalation configured to the manager of the task assignee.
Query user action
Just like the SharePoint ‘Query a list’ action the Query user action can be used in a similar vein where it allows you to return a list of unique email addresses based on a set of conditions.
The example below demonstrates how you could configure the action to return all users who belong to the 'Product Management' Department using a condition, to make it as simple as possible we also provide full introspection for the ‘When’ clause in the condition so it loads all the fields directly from Azure AD.
Something to note however when using the query action, the output is a Collection of unique email addresses so in order to get the details of each person simply use the ‘Loop for each’ action in combination with the ‘Get user details’ action to cycle through each email is the Collection.
So that covers the first round of Azure actions but don’t worry as the next set is not too far away!
I’d love to hear any feedback on both these actions or any specific scenarios that you are looking to implement against Azure AD, comment below or feel free to email me directly @ email@example.com