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

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.