As more and more people move towards Office 365 as their platform of choice for some key business functions, more and more people are realising the need to manage the user licenses for this platform as part of their standard starters/leavers processes.

I wanted to explore this further to see how simply this could be managed with existing investments such as that of Nintex Workflow On Premises.

Whilst Nintex Workflow covers most things you may need to do with regards to interaction with Office 365, sometimes you need to push things a little further such as managing the revocation of user licenses.

This post explores creating or extending an existing Nintex Workflow On Premises to manage your users not only On Premises, but also on Office 365.

To reiterate, this shows an alternate approach utilising PowerShell to provide more flexibility in some scenarios and should only be considered when the “out of the box” actions don’t quite do what you need.

In my demo scenario, I’m assuming that we already have internal starters and leavers under control. As you are hopefully aware, Office 365 is a subscription service per user – so there is a necessity to have a single view of all active users and any applicable licensing assignments to enable you to manage your subscription and more importantly decommission old users to free up valuable licenses that you are paying for.

My managing this process with Nintex Workflow and SharePoint lists, you also create a very useful data source for maintaining visibility of this – and introducing the possibility of cross department charging for actual Office 365 license usage for example.

A bit of discipline is involved (i.e. don’t go and create users directly on Office 365), but hopefully you appreciate the demo use case.

One additional point before we get started, is that I am demonstrating the creation of cloud only accounts (* – the same process applies to domain accounts that you may be pushing up to Office 365 via DirSync.

One final point for this example is that the process and associated PowerShell commands should be used at your own risk – you have the potential to adversely affect your Office 365 tenant and/or user accounts and data if used incorrectly.

Example Process

I begin by creating a simple list to create my new starter within. Note that this is cut down for the purposes of this demo, but focuses on capturing enough information to generate a new user account based on the name of the individual.


To keep things simply, I have actually split the Office 365 process into three separate workflows which I am going to manually run (see closing comments about putting this into a state machine). The supported stages are:

  • Create
  • Assign Licenses
  • Revoke Licenses


Once I run the Create workflow, the net result is a new cloud based user within Office 365:


Initially, there are no licenses assigned to the user:


Note that so far, we could be doing all of this within standard Nintex Workflow actions….

Next I can run my Assign workflow and give the new user account one of my E3 licenses:


Finally, I am running my Revoke licences workflow. You can hopefully appreciate why this process really needs to go into a state machine to manage the full user life cycle.


To prove a point, note that the final workflow remains In Progress vs. just revoking the license for the user. This is very important as when you revoke a licence within Office 365, by default – all user data for that account will be deleted. Given this constraint, it’s probably a good idea to have another layer of approval/confirmation just to make this clear:


The net result is that we have created a user, assigned a license, then demonstrated revoking that licence. The revocation aspect is an example where you may want to follow my approach below vs. the standard workflow actions.


How it’s done

The workflows themselves are actually very simple. I have implemented this with a third party custom action “PowerActivity” produced by DataOne. It’s quite powerful and lets you take complex activities which require the use of PowerShell and maintain these within a logical business process inside of a Nintex based Workflow.

The first create workflow is as follows:


To show PowerActivity in a little more detail, you can use actual PowerShell commands within the action and also manage variables to/from Nintex and PowerShell.


Additionally, you can also make use of Nintex Constants e.g. for credentials to build a new credential object from in PowerShell.


The PowerShell code for this is:

$password = ConvertTo-SecureString -String $credentials.Password -AsPlainText -Force
 $credential = New-Object System.Management.Automation.PSCredential ($credentials.UserName, $password)

Connect-MsolService -Credential $credential

New-MsolUser -DisplayName "{ItemProperty:Display_x0020_Name}" -FirstName "{ItemProperty:First_x0020_Name}" -LastName "{ItemProperty:Last_x0020_Name}" -UserPrincipalName {ItemProperty:Email_x0020_Prefix}@<tenant_name> -UsageLocation GB

Next we have the assign workflow, again very simple with one action:


The PowerShell code for this is:

$password = ConvertTo-SecureString -String $credentials.Password -AsPlainText -Force
 $credential = New-Object System.Management.Automation.PSCredential ($credentials.UserName, $password)

Connect-MsolService -Credential $credential

set-msoluserlicense -UserPrincipalName "{ItemProperty:Email_x0020_Prefix}@<tenant_name>" -AddLicenses <tenant_name>:ENTERPRISEPACK

Finally, there is the revoke licence – with the addition of a task to confirm that the user will have their information deleted from Office 365:


The PowerShell code for this is:

$password = ConvertTo-SecureString -String $credentials.Password -AsPlainText -Force
 $credential = New-Object System.Management.Automation.PSCredential ($credentials.UserName, $password)

Connect-MsolService -Credential $credential

set-msoluserlicense -UserPrincipalName "{ItemProperty:Email_x0020_Prefix}@<tenant_name>" -RemoveLicenses <tenant_name>:ENTERPRISEPACK


Whilst the example itself is quite simplified, hopefully you can see the business applications of being able to extend your Nintex Workflows to cross into other systems while still being able to build simple workflows to manage how and when that interaction takes place.

Leave a Reply

Your email address will not be published. Required fields are marked *