Bring your Teams provisioning order form and approvals where they matter the most — Part 2

Last updated on October 16, 2021

Based on my experience, most of the organizations that want a custom Teams provisioning solution wish to have an approval step as a part of the process. Typically these organizations are just getting started with Teams and want to ensure that users don’t set up duplicate teams or create teams for inappropriate purposes.

Sometimes, the approval requirement might be temporary. The plan can be first to get users well acquainted with Teams and the company guidelines when it comes to creating new teams. After that, the approval step can be removed.

Alternatively, the approval step can be disabled for all except certain types of teams. For example, the approval might be required for teams that are going to have external collaboration (the guest sharing settings are going to be left enabled) but skipped for all internal teams.

Some organizations say they don’t have the resources for handling approvals, no matter how simple and streamlined the approval process is. Still, they want to benefit from the other aspects of workspace provisioning. In those cases, we automate the creation and configuration of teams to ensure they are all set up consistently and correctly. We just don’t ask for permission for creating the team.

This blog post is not for the last mentioned customers. This blog post is about showing how we can have as effortless team order approvals as possible right where they matter the most: in Microsoft Teams. That’s where most of the modern collaboration happens these days, and it is also the most logical place for everything related to the Teams provisioning process itself. Let me show you an example of how you can build a smooth approval process for Microsoft Teams with Power Automate.

Using Power Automate to handle the approvals

The workspace order approvals are typically done by utilizing adaptive cards with Approve and Reject buttons. Adaptive cards are essentially JSON markup that allows you to easily create interactive messages that look like cards for different platforms, including email and Teams. You mostly have control over the card structure and displayed information while the styles are applied by the platform where the card is displayed to achieve a consistent look-and-feel.

In the past, we used to send these adaptive cards to approvers via email. However, one of the reasons why organizations want to use Teams is to reduce the number of emails they receive. To respect that, let’s move away from sending approval emails, and start handling approvals in Teams instead.

Creating an approval, sending it, and waiting for a response

What I tend to do, is to create a separate team in Teams for approving the workspace provisioning orders. Only the people (often company administrators) who are allowed to handle the approvals have been invited as members to this team.

The Create an approval action that we are going to use in this process requires us to specify the users who are allowed to participate in the approval. Because of that, the first thing we need to do is to get members of the approval team. I’ve specified the team ID in a variable at the beginning of the flow, so it can be easily changed if needed.

I’ve also initialized another variable for storing the approver emails. After we’ve successfully fetched the team members, we’ll add their emails to this string variable, separated with semicolons. We can then easily use the string containing all the member email addresses when creating the approval.

When we’ve successfully gathered all the team member emails, we can configure the Create an approval action, and set the ApproverEmails variable to the Assigned to field. In addition, we need to specify the card content and behaviour.

When it comes to approvals, I tend to always use the first response applies option. Typically the purpose of having multiple people as the approvers is to have a backup in case someone, e.g., goes on a holiday. The point is not to have all of the approvers to agree. Anyone of them is allowed to make the decision on their own.

The Details field allows you to specify the information displayed on the card. There’s a specific syntax for styling the content. The same syntax can also be used for styling TextBlock control content on your custom adaptive cards.

When we are done with the approval configurations, we send the adaptive card the Create an approval action generates for us to a Teams channel using the Send your own adaptive card as the Flow bot to a channel action. We already have the team ID in a variable because we needed it for getting the approver team members, but we’ll also need the channel ID. Again, I’ve specified it in a variable for easier maintenance.

Here is a picture of what the adaptive card created by the Create an approval action looks like when posted in Teams. In addition to using the buttons for approving or rejecting the order, the approver can also provide comments. If you like, you can send these comments to the person who made the order as a step in your Power Automate flow after receiving a response. It can be particularly useful if the order was rejected, so the person knows the reason and if they need to fix something.

When someone handles the approval, the card layout changes automatically. It will no longer contain the buttons. Instead, the approval outcome, possible comments, and who approved the request will get displayed at the bottom of the card.

There are a couple of things we still need to do before we can say we’ve created an approval process successfully. We need to stop to wait for the response and then handle the response.

The nice thing about being able to do all of these steps separately is that it allows us to do other actions in between them. For example, if you tend to track the provisioning status in a list column, you can update the field to say, e.g., Pending approval after sending the adaptive card to Teams but before you actually stop to wait for a response.

Finally, after we do get a response, we need to ensure we act accordingly. You need to check for the approval Outcome in a condition action, and then direct the execution to the appropriate branch. The outcome options are Approve and Reject. You can also find a lot of other information about the approval in a similar manner, such as who responded and any comments they might have provided.

Afterword

I’ve been building a lot of different kinds of Teams provisioning solutions over the past three years. The methods I have used have depended on the customer-specific requirements, and have changed over time as Microsoft has introduced new features or licensing changes.

What I showed you in this blog post is currently my favourite way of implementing approval processes. It is quick to develop and allows the approvers to perform the approval step where it is the most relevant to them.

I have another blog post coming out in the near future where I discuss about the different Teams approval scenarios and options much more in-depth. If you’d like to get notified when that blog post has been published, subscribe to my Insider news letter via the sidebar, and follow me on your favourite social media platforms (Twitter, Github, LinkedIn, YouTube).

I hope you found this Teams approval example useful. As always, thank you for reading, it is much appreciated, and until next time!

Laura