We are excited to announce that Nintex Workflow for Office 365 has just released a set of actions to provide integration with Azure Active Directory. And we’ve developed it using the Microsoft Graph!
I say they are the same because we developed these actions using the Xtensions® framework, so any updates or changes we make are automatically captured in both Nintex for Office 365 and Nintex Workflow Cloud. This is the first feature in Nintex Workflow for Office 365 that demonstrates the power of the Xtensions® framework.
We believe that Xtensions® capabilities are highly valuable for our users, so we’ll be looking to bring more Xtensions®-built actions to our Office 365 customers in the future.
What Actions Did We Develop?
There are two types of Azure AD actions included in this release: One for general retrieving of user and manager information, and another for more administrative functions like creating/updating/disabling user accounts and assigning managers. Each type of action will use a different kind of connection and level of permissions.
The other new concept we’ve introduced is what we call ‘Connector introspection.’ This feature integrates the connector (Azure AD via the Graph API) to retrieve specific sets of data.
For example, in the Azure AD actions, the list of fields displayed in ‘Add fields’ area is dynamically populated based on the connected AD account. If Microsoft adds a new field to this list, it will automatically be visible the next time a user configures the action.
Connections & Admin Consent
In the Connection manager, you will notice there are two new connection types. The first, ‘Azure Active Directory’, is used for retrieval actions (ex. ‘Get manager details’), and the second, ‘Azure Active Directory Administration’, is for admin actions (ex. ‘Create user’).
Both connections types require admin consent, which simply means that before a connection can be created to an Azure AD instance, an Azure AD admin needs to provide consent for our app to access this instance. If the app has not been granted this permission, then Microsoft displays an admin approval required message as shown below.
Once admin consent has been given, you will also notice that during the auth flow, each connection type will ask for different permissions. This is simply because each connection type has its own permission requirements.
When creating an Azure Active Directory Administration connection type, make sure you create it using an Azure AD admin account. Otherwise, the connection creation will fail as it will again prompt for admin consent. For the Azure Active Directory (non-admin) connection type, you can use a normal user account, as it only requires read permissions.
Further details of specific permissions required for each connection type can be found here.
One other thing to note is that when creating the ‘Azure Active Directory Administration’ connection type, the scoped availability in connection manager of that connection defaults to the person who created it. This is designed to secure the connection. However, to make it available to other users in the tenant (just remember this is a connection type that has a high level of permissions) you need to edit the connection and modify the ‘Users with access’ setting.
A Look at Azure AD Actions
You will notice as you look through the actions that the primary key to identify a user is an email address, which maps the User Principal Name (UPN). This key can come from anywhere as long as it maps to the UPN in Azure AD.
Get User Details
The ‘Get user details’ action allows you to retrieve profile information of an individual user, including properties such as ‘First name’, ‘Last name’, ‘Department’, ‘Job title’, and more.
Here is an example of a configured action:
Get Manager Details
The ‘Get manager details’ action allows you to retrieve the same fields as ‘Get user details’, but this is meant to retrieve details about someone’s manager. All you need to supply is the employee’s email address, and it will return their manager details.
A Look at Azure AD Administration Actions
The next set of actions are more focused around ‘Azure AD Administration’ functions that support processes such as on- and offboarding.
The ‘Create user’ action allows you to provision a new user account in Azure AD. This is perfect for onboarding scenarios where you need to automate account creation.
When creating a new user in Azure AD, you always need to supply both the name (display name) and User name (UPN) of the new account, and additional fields can be added as required.
The action also allows you to store the password for the new account in workflow variable, which you could send to the new account owner once provisioned.
The ‘Update user’ action allows you to update the properties of any pre-existing Azure AD account.
The ‘Disable/Enable user’ action allows you to easily enable or disable an existing Azure AD account.
I’d love to hear any feedback on our new ‘Azure Active Directory,’ or ‘Azure Active Directory Administration’ actions in Nintex Workflow for Office 365. If you have specific scenarios in mind that you are looking to implement against Azure AD, please feel free to email me directly at firstname.lastname@example.org.