Custom Actionable Messages with Microsoft Flow – part 2 – Getting the response

This is part 2 of the Custom Actionable Messages with Microsoft Flow series

In my previous post, I wrote about sending out a custom Actionable message. In this post, I will explain how you can get the response back (and do something with this response).

The last thing we did in the previous post was clicking the ‘Respond’ button, which led to an error:

This is because we did not configure the action that will trigger after clicking the button.

I want to write the feedback back into the SharePoint list item and notify the author of the item that feedback has been given. For this, I need to extend my list I using for my previous post and add a Feedback column to it.

HTTP Request

To do something with the given response, we need to post that response to somewhere. That somewhere is an HTTP endpoint.

In this case, I created a new Flow with the Request – When a HTTP request is received trigger.

This trigger will generate an HTTP Post URL endpoint for you (after you first save your flow). Within this trigger, you need to provide the request body for your endpoint. In other words: what do you want to receive on this endpoint?

To write the feedback back to SharePoint, we need:

  • Item ID
  • Feedback

You can use the Use sample payload to generate schema to generate the request body for you, but this method does not generate all attributes that make configuring the rest of your Flow easier (such as the title attribute – explained below).

Ofcourse you can add these manually after the schema has been generated, but I prefer using an online tool that can generate the complete JSON body for you: JSON Schema Tool. Within this tool, you provide the properties that you want to receive and click on Submit. The JSON body will then be configured for you.

If we put our data into the JSON Schema Tool and click Submit, the JSON body will be generated for us:

Our When a HTTP request is received trigger doesn’t necessarily need the default and examples attributes (but you may find the default property interesting in some cases to make sure you don’t receive empty values), so we can delete them from the body. The title attribute is the attribute that will show up as Dynamic content in our Flow, so make sure you put in a recognizable title!

After copying the JSON body into my When a HTTP request is received trigger and making these changes, my body is as follows:

{
  "$id": "http://example.com/example.json", 
  "type": "object", 
  "definitions": {}, 
  "$schema": "http://json-schema.org/draft-07/schema#", 
  "properties": {
    "itemID": {
      "$id": "/properties/itemID", 
      "type": "string", 
      "title": "The ID of the list item"
    }, 
    "feedback": {
      "$id": "/properties/feedback", 
      "type": "string", 
      "title": "The feedback given by the feedback user"
    }
  }
}

Processing the request properties

I always like working with variables because they are recognizable and you don’t have to search through your dynamic content for your properties anymore which can save you a lot of time and frustration.

For this, I will add two Initialize variable actions and set their values to the output of our HTTP request. When you do this, you can see why the title attribute of our request body is nice to have: you can see exactly when you will get from the request.

Testing the request

We now have the basic configuration of our Flow. We haven’t configured the list item update and the email action yet, but before we proceed, I need to make sure my request works. We therefor need the HTTP POST URL to be generated, which will be triggered by saving your Flow for the first time. After the Flow is saved, the URL is shown on top of your When a HTTP request is received trigger.

Please note that this endpoint does not require any form of authentication, so anyone with this URL can do something. This is very important to keep in mind and you might want to provide some check within the start of your Flow to see if the Flow is actually triggered for a legit reason (for example: by always requesting some sort of unique identifier and only run the Flow if that unique identifier matches). Definitely make sure you don’t share this endpoint with anyone who doesn’t need it!

Because it does not need any authentication, we can easily test this endpoint by using Postman. Make sure you select the POST request, paste the URL into the Enter request URL text-box and add the following Headers and click Send

key value
Content-Type application/json
itemID 1
feedback This is some cool stuff!

When you return to your Flow and look  at the Run history, it should show a Succeeded Flow. If you open that run, it should show the properties you filled into Postman underneath the Outputs:

Processing the properties

Now that our HTTP Post URL has been validated, we can update our list item with the feedback and send it to the item author by adding a Update item and Send an Email action to our Flow and configure them properly, using our variables.

Because the Title field is required and Flow always wants an required field to be filled (even when it’s already filled), you need to get the Title value before you can proceed by updating the item by using the Get item action. You can use the Dynamic content from this action in the Send an email action as well so it’s no problem to add this action at this time.

Please note that our Get item action expects an Integer value for item ID, so we need to convert our itemID variable to an integer by using the int() expression:

int(variables('itemID'))

You can also set the property type of your request body to other values (e.g. integer or boolean), but I experienced some issues when storing the ID as an Integer so I configured it like this.

After that, we can add our Update item and Send an Email action.

Configuring the Actionable Message

Now that we can process the incoming request, we need to make sure that the right request will be sent when a user clicks the Respond button inside the Actionable Message. To do this, we must alter the actions section of our JSON we composed:

"actions": [
  {
    "@type": "HttpPOST",
    "name": "Respond",
    "target": "http://..."
  }
]

To get a valid response, we need to make sure that the target URL is correct, because now it is set to nothing. We also need to provide the body of the request which is in the following format:

{
  "itemID": "<ID of the list item>",
  "feedback": "<feedback from the Actionable Message>"
}

We can get the ID from the Dynamic content inside our Flow (like we did before by adding the Author and the Created date). In our Actionable Message, we have given our feedback TextInput field the id feedback. We can use this id to get the value from the TextInput field by using the following text:

{{feedback.value}}

The When a HTTP request is received trigger does not expect any credentials, but Outlook automatically sends out a bearer token when you submit an Actionable Message by default. This will lead to a HTTP Unauthorized error message

To avoid this, you must provide a Header with an empty Authorization token inside:

"headers": [ {
  "name": "Authorization",
  "value": ""
} ]

If you merge all these changes together, your actions section will be configured as follows:

"actions": [
  {
    "@type": "HttpPOST",
    "body": "{\"itemID\":\"@{triggerBody()?['ID']}\",\"feedback\":\"{{feedback.value}}\"}",
    "name": "Respond",
    "target": "https://prod-32.westeurope.logic.azure.com:443/workflows/<rest-of-the-POST-url>",
    "headers": [
      {
        "name": "Authorization",
        "value": ""
      }
    ]
  }
]

Running the Flow

If all has been configured correcly, we can now do a full run by creating a new item in our list, which will send out the Actionable Message. This Flow will stop when the message has been sent and will not wait for any response. When we fill on our feedback and click the Respond button, we will now see that we don’t get any error anymore:

After the Respond button is clicked, the other Flow will start because after clicking the button, the HTTP Post request will be send and the Flow reacts to that HTTP Post URL. If we look at our Flow Run history, we can see that the second Flow ran successfully.

If we look in SharePoint, we see that the list item has been updated with the given feedback:

And if we look into the mailbox of the person who created the list item, we can see that this person received a confirmation as well:

Final thoughts

With Actionable Messages, you can send out messages that provide that bit more functionality than Approvals or Emails with options. But there are also some things that you need to be aware of:

  • The When a HTTP request is received trigger does not require any form of authentication which can make your process vulnerable to incoming attacks. Make sure you think about ways to eliminate the risk of unwanted incoming requests manipulating your data.
  • When an Actionable Message is sent, it will not track if anyone responded to that message. In other words: Someone can respond unlimited times to the same message. There are ways to make sure only one response per message will be recorded, like providing the message with an unique ID, storing that ID into another SharePoint list and update its status to Complete when a response has been provided.
  • Actionable Messages are not bound to the person that the message is sent to. This person can forward the message to any other person who then can respond to it, even though they were not the original receiver. This can be very useful (e.g. for delegating tasks), but in some cases you only want the receiver to be able to respond. In that case you may want to consider not to use an Actionable Message because the request does not provide who responded to the message so you can’t perform a check. (at this moment) I don’t know a solution to this, but maybe there are ways to solve it.

21 Replies to “Custom Actionable Messages with Microsoft Flow – part 2 – Getting the response”

  1. Thanks so much for this tutorial Rik! I just have a question about the “When an HTTP request is received” trigger. It requires a premium license, right? Would purchasing the premium license only for the Flow owner/creator account suffice, or would I need to purchase a premium license for all users who will be receiving Actionable Messages in their emails?

    0
    0
    1. The HTTP connector is premium indeed. Microsoft is still a bit fague about this unfortunately. Technically, it will be sufficient to only provide the flow owner with a premium license. But Microsoft introduced something called multiplexing that states that everyone that takes part in the process of the flow, should have a premium license. I don’t know if and how they check this though..

      1
      0
  2. I registered in the developer dashboard for test users in my tenancy, but only I see content in the email – any tips. Status for registration in approved.

    0
    0
    1. I haven’t tried it with other users because I only have one user in my tenant unfortunately. But it should work with other users as far as I was informed. Is the originator email adress you entered in the Developer Dashboard the same as the actual email address from which the actionable message is sent?

      1
      0
  3. This is really useful stuff. I’m able to get the adaptive and actionable cards to render in Outlook for the Web, however; in the Outlook client (using Office ProPlus monthly channel) the message is blank. I even tested from the Actionable Message designer (https://amdesigner.azurewebsites.net/), and I have the same problem. Is there something we need to do to get these to render properly in the Outlook client?

    0
    0
    1. Hi Riley,

      I just checked and the adaptive card is shown in both Outlook Online and Outlook ProPlus (v1911).
      I saw that you referred to the AM Designer. Actionable messages are depricated and it’s advised that you use adaptive cards instead. I wrote about this in part 3 of my blog series: https://www.about365.nl/2019/05/01/custom-actionable-messages-with-microsoft-flow-update/. I think this is your issue. Please change your actionable message to an adaptive card and I think it will work.
      You can find more information on adaptive cards at https://adaptivecards.io/.

      0
      0
    2. I thought the same thing at first, but I tried both adaptive cards and actionable messages. Both result in the same behavior in our production tenant. I happened to try it in our test tenant, and the messages rendered as expected in the Outlook desktop client. I’m wondering if the problem is related to number 2 on this list:

      https://support.microsoft.com/en-us/help/4515128/issues-with-flow-approval-emails-in-outlook-desktop-and-web

      Our Cloud Services team have the Office Store restricted in production but not test. That’s my current working theory anyway. I’ve reached out to MS, and I’ll reply here once I determine what’s happening.

      Thanks.

      0
      0
  4. I followed your example but the itemID when assigned to a variable appears to be null. In the oputput of the flow trigger it looks good.

    0
    0
    1. Hi Edgar, have you incorporated the item ID into your actionable message when sending the message?
      “body”: “{\”itemID\”:\”@{triggerBody()?[‘ID’]}\”,\”feedback\”:\”{{feedback.value}}\”}”,

      Please make sure to handle the item ID as a string, not an integer. Later, you need to use the int() expression to transform it into an integer again.

      0
      0
    2. Hi. Thanks for the answer. When i test the flow with the email everything is fine, but, with postman fails. By now, i’m modifying your example to meet my needs.

      0
      0
    3. Did you put quotes around your itemID in Postman? Otherwise Postman will process the item ID as an integer while your Flow expects it to be a string

      0
      0
  5. hello, thanks a lot but how can i get the response of the user for exemple if i have two buttons approve and reject how can i get the name of the response choosed by the reciever ??
    response=approve
    or response=reject

    0
    0
    1. You need to alter the actions section of your Approve and Reject buttons so that the body of your request contains the name of the response.
      You can use something like this: “body”: “{\”outcome\”:\”Approved”}”,

      0
      0
  6. When I open the approval mail in Outlook ios app i see nothing. Also i can’t approve an item in the flow app

    0
    0
    1. I don’t think the Outlook app on both Android and iOS are supported yet for handling actionable messages. You need to use Outlook Online or Outlook 2016+.
      Approvals won’t show up in the Flow app, since you are using a custom approval, not the Flow approval

      0
      0
  7. Thanks so much for your post, it’s really expanded the use for flow!

    Quick note, if the feedback doesn’t show for others, make sure the input’s ID matches the column name:

    “inputs”: [
    {
    “@type”: “TextInput”,
    “id”: “comment”, <————-
    "isMultiline": true,
    "isRequired": true,
    "title": "Feedback (required)"
    }
    ],

    0
    0
    1. You’re absolutely right. I’ve used the id ‘comment’ in my previous post which of course doesn’t match with the feedback id I used in this post. I changed it in part 1. Thank you!

      0
      0

Leave a Reply

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The reCAPTCHA verification period has expired. Please reload the page.

This site uses Akismet to reduce spam. Learn how your comment data is processed.