Sending Adaptive Cards to Microsoft Teams users from Azure Logic Apps

Adaptive Cards are increasingly used as a rich medium to communicate with users. This communication may include notifications, approvals or require action from an end user. With the growth of Microsoft Teams continuing to skyrocket, sending Adaptive Cards to Microsoft Teams makes perfect sense.

From an Enterprise Integration perspective, we can incorporate Adaptive Cards and Microsoft Teams to participate in a re-submit process for our Center of Excellence (CoE) team. From a scenario perspective, let’s assume that we are using Service Bus Queues as part of our solution. We can try to process requests and if we run into an issue, we can publish a message to a Microsoft Teams channel where we can allow them to repair the message and choose if they want to re-submit. If they choose to repair and resubmit, we will put the message back on the queue for reprocessing. If they decide not to repair and re-submit, we will just let the process complete.

Solution

Let’s start with building our Adaptive Card. We can use the editor found at https://adaptivecards.io/designer/. Using this designer, we can create a card like the following.

For the purpose of this post, our example will be quite simple. We will try to divide two numbers within Azure Logic Apps. Should we encounter a failure, we will send the two values to our Integration CoE team where they can review the numbers. They can subsequently correct them and then send the data back to Logic Apps. Logic Apps will subsequently re-publish this message so that it can be processed again. Naturally, you can tailor the scenario to better align with your needs.

Once we are happy with how our card looks, we need to copy the Card Payload Editor text. For convenience, I am including my payload here.

With our Adaptive Card complete, we can now go build our logic app. I am using Logic Apps (Standard), but this will work with Logic Apps (Consumption) as well.

We will start with a Service Bus Trigger – When a message is received in a queue (auto-complete)

Next, we will declare Float variable called result.

Add a Scope to our canvas and rename it to be Scope-Try. We can now add a Parse JSON action and can generate schema using the following sample message:

{
  "operand1":10,
  "operand2":0
}

We need to set our result variable where we will take our operand1 and divide it by operand2 that were defined in our Parse JSON action previously. The expression we will use to do this is: div(body('Parse_JSON')?['operand1'],body('Parse_JSON')?['operand2'])

We are done with our Try Scope and will add our Catch Scope. This will be our exception handler. As a result, we need to configure our Run After settings to ensure we select has timed out, is skipped and has failed.

Within our Catch Scope we will add our Teams action that allows us to Post adaptive card and wait for response. Within this action, we can configure it to use our adaptive card that we created previously. Feel free to download my sample adaptive card here.

As part of our adaptive card that includes two buttons, One button is called Re-submit Run and the other is called Cancel Run. If the user clicks cancel, we just want to terminate our processing. To include a good error message, we will populate the Message property with the following expression: result('Scope-Try'). To learn more about this expression, please check out this video.

Should the user click on the Re-submit Run button, our condition will fire and we will head down the true path. The value we will check for is if the Teams dynamic content (submitActionId is equal to Re-submit Run). When this occurs, we will send a message back to the Service Bus queue. However, we will re-assemble a message using the values that were updated in our Adaptive card.

We can now go ahead and test our process by placing a message, similar to the one below, onto our Azure Service Bus Queue:

{
  "operand1":10,
  "operand2":0
}

Once our message is received by our logic app, we will discover that we run into an error. As a result, our exception handler will detect this and will send an Adaptive Card to our user who can review the inputs and override them. We will populate our two numbers and then choose to Re-submit run. The logic app will detect this and then construct a new, valid message and put that message back on the Service Bus queue.

Conclusion

In this post, we discovered how we can build a repair and re-submit process with the help of an Adaptive Card. This functionality will be useful by Integration CoEs and support teams where they can respond to events in a common tool that they frequently use.