Automate your own Microsoft 365 Copilot trial system

While Microsoft 365 Copilot (formerly called Microsoft Copilot for Microsoft 365, and referred to in the rest of this article as just “Copilot”) has been with us for some time, unfortunately many organisations are yet to deploy it far and wide amongst their users.

While there are plenty of case studies, blogs, LinkedIn posts and support being given by Microsoft via partners – the reality is that the numbers are just not there.

Why? Because it’s expensive! And because organisations aren’t sure they’re ready to commit to the annual subscription (monthly is not an option).

While a lot of work is being done to help get organisations ready for Copilot, it’s still the great unknown – regardless of how many sizzle reels and use cases you throw at business decision makers.

Often in scenarios like these, a handful of licenses will be purchase and given to advanced users to flesh out. Unfortunately, this ignores people who might be more willing to give Copilot a go, who might be more open to newer ways of working, and potentially less bound by technology and product experience. 

The Challenge

Say an organisation purchases 200 licenses and already has allocated about 170 of those to specific users and groups – there’s 30 remaining. What to do with those?

In one scenario, these remaining 30 licenses might be available in a first come, first serve basis. In another, it may be managed by the service desk.

Or, if the organisation uses group-based license assignments – then there may be someone who has the ability to assign licenses by merely adding to or removing people from a designated security group. Wonderful!

That still adds overhead to someone to manage the process. And who decides who has a license and for how long? How do we ensure the allocation remains fair?

The Solution

This is where my friends Power Automate, Lists, and Entra ID come in handy.

What I’ve created is a solution that:

• Accepts trial license requests from a user
• Checks if licenses are available or not, and if not – adds the user to a waitlist
• When a license is available, it will be assigned to the user
• After a set number of days (I’ve gone with 21), the license is removed from the user

Also built into the system is validation as to whether the user has requested a trial previously, and if so – prevents them from requesting it again.

Requirements

Our shopping list for this solution will include:

• Security group
• SharePoint List
• Team or Viva Engage community
• Power Automate account

Let’s break down how these requirements work together.

Security group

My hope is that your organisation already uses group-based licensing, as we’re going to need a security group, and the licenses assigned to it. Here’s a primer if you don’t do this already.

SharePoint List

Secondly, we’re going to need a List in a SharePoint site somewhere. This is going to be used to track the licenses. Ideally, this list should be created in a location where the average user doesn’t have the ability to edit records (otherwise they can reset their trial).

Here’s what the columns should look like:

The TrialRequested field should have a default value of “Yes” set, for primarily the use of the form submission.

Once our columns have been created, you’ll need to use the fancy new forms functionality in Lists, and customise the form to look like this:

When we look at in the preview, it should appear as this:

Again, making sure that the average user doesn’t have access to modify the SharePoint List directly, you can use the Send form button to generate a link to use:

Team or Viva Engage community

Ideally you have some place where people can come together to share knowledge and ask questions about working with Copilot. While many would opt for Teams, I would strongly suggest looking at Viva Engage as it has a built-in template for exactly this purpose:

You can read more about this out of the box community here: https://learn.microsoft.com/en-us/viva/engage/engage-365-copilot-adoption-platform

Implementing the solution

I’ve tried to make the trial management solution as ready-to-go as possible.

In theory all you need to do is have the following details ready:

• SharePoint site URL
• List to use
• Object ID of the M365 Group for the community (either Team or Viva Engage)
• Object ID of the security group used for licensing
• Number of licenses you want to allocate

Head over to my PowerThings repository on GitHub to download the solution file. Once downloaded, head into Power Automate and import the solution.

Upon importing the solution you’ll need to create several connections:

The account you use will need to be an owner of the two security groups mentioned previously.

Once you’ve gotten past the connections, you’ll then need to input the various bits of information used by the workflows:

After you input the various bits, it should look like this:

Hit Import, and away you go.

From this point on the solution should take care of itself. However, to explain how it works should you wish to adjust or tweak some things…

How it works

There are 3 workflows involved that work with the SharePoint list created earlier.

New trial request processing

This workflow is triggered when a new item is added to the SharePoint list (i.e. a new trial request).

 The first thing this workflow does is gets the profile details of the user creating the request. Elements of the user’s profile will be used both in this and other workflows to save having to perform profile lookups again.

Then, using the ID of the user from the profile, the workflow then checks the list to see if an item with the same ID already exists. (How it gets there I’ll address shortly.)

If an item is found in the list with the same user ID, the condition is marked as positive.

And the requestor gets a rejection email.

However, the user ID is not found in the list, then we update the newly created list item with said user ID, as well as other profile elements we’re going to use later.

Once that’s done, we then check to see if the person is already a member of the Copilot community (you never know, they may have been an eager beaver), and if they’re not we add them.

Then, as a final step, we inform them that they’ve been successfully added to the list. I suggest you customise this text, especially the “XXXX” part where you’ll need to put in the name of your community.

Once the person is now on the list, our next workflow kicks in to check for availability licenses and assign them.

Trial license assignment

This workflow works off the licensing security group, the number of items in the SharePoint list, and the maximum license quantity defined.

This workflow runs daily (although you can set it to whatever frequency you like) and will retrieve items from the list where the LicenseAssigned field is blank. It’ll also order them by the Created date, so we respect the queuing order. 🙂

If we’ve got people in the queue, then let’s do some checking & assigning! Otherwise, the workflow ends with nothing to do.

It then extracts the number of members already in the license security group:

Here’s what our calculation looks like:

If it’s not a smaller amount, then we don’t have any licenses to assign, and therefore the users get a polite rejection email.
(Again, this runs daily – so you might want to consider whether the email is sent every day.)

However, it is a smaller amount (i.e. we have licenses available), then we need to know exactly how many licenses we have to assign. For that, we do a small calculation:

Now let’s retrieve the list of people we’re going to give licenses to!

We then add each of those users to the licensing security group:

Let them know they’ve received a license, point them to some resources and again the community, and anything else you’d like to say here (again, please replace the “XXXX” text).

And then the final step is to update the list item with the date of when the license was assigned:

Trial license removal

Now that the user has had their license for 3 weeks (or whatever you choose to make it), it’s time to remove their license.

Again, I have a workflow running on a daily basis to check for people who have had a license assigned but not removed, and where the assignment was 22 days ago (I give an extra day just in case).

Once we’ve identified those users, we then remove them from our licensing security group:

Update the list item to show the date that the license has been removed:

And then send them an email informing them of the license removal:

Just make sure to put a link in the email to point to the feedback form, and that’s it!

Next possible steps and tweaks

One of the things I found when using this system was that some people might get a trial license assigned at an inopportune time such as over a holiday period. The fix for this was simply to remove their license assignment & removal dates from the SharePoint list item – which would then put them back into the queue.

Another potential extension is to track whether people submit their feedback via the form, and if they don’t – hound them. 🙂

And if you really want to lock this down…

One of the challenges I faced was that some people would assign Copilot licenses by elevating to an admin role such as Groups Administrator and then adding people into the licensing security group. This could mess up the system and was generally done out of ignorance rather than malice (which is almost as bad).

To address this, an extra workflow I built was one that would scan the audit log for changes to the licensing security group membership every day. If it detected someone had been added by a non-authorised account (e.g. the workflow service account, or one of the designated owners), it would:

• Remove the person from the security group.
• Send me a notification email to say who had been added and by whom.
• Send a notification email to the person who added the user, informing them that it was done out of process and that the user had been removed.

You might then ask – what if the person just added themselves as an owner? Well, the workflow didn’t care who the owners of the group were as the officially sanctioned owners were hardcoded into the workflow and part of the condition checking. 🙂

 

If you want any of the additional workflows – please let me know! I haven’t included them in the published solution file but would be quite happy to a follow-up post with them.

---

Also published on Medium.