Power Automate: Forms Get Response Details Action

One of the most used triggers in Power Automate for Microsoft Forms is the "When a new response is submitted" trigger. It will trigger when someone submits a response in Microsoft Forms, but this will only return the response ID, so the trigger alone is not useful.

We will need the "Get response details" action to get the details of the Form's submission, so let's explore how it works and some things that you need to know.

Where to find it?

There are two ways to find the "Get response details" action. The first is to go to "Standard."

Find Microsoft Forms.

Then select the action.

Another way, and a bit easier, is to search for it. Then, if you start typing "get response," it will show up at the top of the results.

Usage

99.9% of the time, you'll use it the same way. You'll have a trigger for a new response and get the details of that response.

The action only asks for two things. The "Form Id", which you pick from the dropdown, and the "Response Id", which comes from the trigger. There's nothing else to configure, so if something is not working, it's almost always one of those two values.

The only exception that I can think of is when you store the IDs of the responses for future reference. Then, when you need the data, you'll do a "Get response details" with that ID to fetch the data and parse it. But even this one I strongly encourage you not to do (see below in the recommendations).

One thing worth knowing is that the Microsoft Forms connector also has a "Get form details" action. That one gives you information about the Form itself (the title, the status, and who created it) and not about a response, so if that's what you're after, you're looking at the wrong action.

Non-intuitive behaviors

Long answers in single-line questions can break your Flow

If someone types more than 255 characters into a single-line text question, your Flow will work sometimes and fail other times, which is the worst kind of problem to debug. Microsoft's troubleshooting guide calls this one out, and the fix is on the Form side. Use a multi-line text question whenever you expect a long answer.

The responder is only filled in if the Form records names

The "responder" field is not always there. Microsoft Forms only records who answered when the Form is restricted to people in your organization and the "Record name" setting is on. If the Form accepts anyone, that field comes back empty and any email you try to send to the responder has nowhere to go. When you need the address, add an email question to the Form itself and use that instead.

File upload answers are not files

A file upload question doesn't hand you the file. It hands you a string with the file details inside it, so you can't reach into it directly. Microsoft's own recipe is to run the Flow once with a real upload, copy what comes out, and feed it into a "Parse JSON" action using "Generate from sample". After that you can reference the file properly and do something useful with it.

Limitations

A huge limitation that confuses people is that all data is fetched as a string. So even if you define the field in Microsoft Forms as something else, Flow will only get strings. Here's an example of a Form:

Now let's look at the data returned:

{
  "responder": "manuel@manueltgomes.com",
  "submitDate": "7/28/2021 10:41:26 AM",
  "r917f27f11e4b433c93bfad308c133b94": "[\"IT\",\"Finance\"]",
  "rbce4c992fc4f4453b01567fe21e17099": "2021-07-28",
  "re2c5f1cc0fc14413ad38347f3d5ef9c4": "4",
  "r9d6a6441c0244a269fcafc4fdb879c16": ""
}

This is problematic for several reasons:

1. You need to convert the data. Data conversion is hard and may result in edge cases where you get invalid data. Please be sure to validate the data once converted and warn people or deal with errors when there is an issue.
2. Arrays are strings. I'm not too fond of this, but arrays are also strings, as you can see above. Converting them is not that complex, but it would be a lot nicer to have an object returned where we could do a quick "Apply to each" action and fetch the information.
3. Dates are hard to parse. There are hundreds of variations on how the date is displayed, and there's a lot of room for mistakes. Although the data is always returned the same way, storing it after may result in invalid conversions. Please be sure that you're providing the correct date to where you're storing it.

Another big limitation, but for a good reason, is that the fields have an ID and not a name. As you can see above, the "Department" part is "r917f27f11e4b433c93bfad308c133b94". Understandably, it's hard to generate field names since the question can be quite long and have special characters. But IDs make formulas harder to read and debug, so be very careful when dealing with the information.

Besides the data itself, there are a few hard limits worth keeping in your head.

Throttling

The Microsoft Forms connector allows 300 API calls per connection every 60 seconds, and one trigger poll every 86,400 seconds. The numbers come from the connector reference. If you're catching up on a burst of responses, that first number is the one that will bite you.

Organizational accounts only

The connector only works with organizational accounts, so personal Microsoft accounts are out. The good news is that it's a Standard connector, so you don't need a premium license to use it.

Group Forms need the ID by hand

Forms that belong to a group don't show up in the "Form Id" dropdown. To use one, open the Form for editing and copy the part of the address after "FormId=" into the field as a custom value. It's not obvious, and it's the reason a lot of people think group Forms aren't supported at all.

The Form has its own ceilings

The action can only give you what the Form kept. A Form on a work or school account holds up to 5,000,000 responses, 200 questions, and 200,000 characters of responses in total. Once it hits the response ceiling, it stops accepting new ones, which is another good reason to move the data somewhere else as it arrives.

Troubleshooting Common Errors

The same Form appears twice in the Form Id list

Deleted Forms that are still sitting in the Microsoft Forms recycle bin keep showing up in the picker, so you end up with two entries that look identical. Empty the recycle bin and the duplicate goes away.

A colleague's Form isn't in the list

If a Form was created by someone else and you can't find it, check the "Shared with me" tab in Microsoft Forms first. If it's not there, you need access to it, and if the original owner is gone, transferring ownership of the Form is the cleaner fix.

The files arrive corrupted

If you're forwarding uploaded files by email and they come out broken, check that you're not running them through the "base64" function somewhere along the way. It's a documented cause of corrupted attachments.

Recommendations

Here are some things to keep in mind.

Never generate the ID

IDs may change, so don't generate them. Storing them is also dangerous (see below) since, if things change, you lose access to your source data. I would strongly recommend that you use the references to previous actions to fetch the ID and use that in the "Get response details" action.

Store it first and then use it

I'm not particularly eager to rely on Forms to store the information. Not because it's unreliable but because it's not meant to store data long-term. The information is there temporarily and may be deleted at any time. I see many people storing the response ID and then fetching the data when they need it. There are a few great disadvantages with this:

1. You need to convert the data each time you need it. However, if you store it somewhere, you only need to convert it once.
2. You need to validate the data each time you need it. Same as above, you only need to do it once.
3. Once you receive the information, you don't know for how long it will stay available. For example, if someone deletes the Form or the answers, the data is lost.
4. IDs may change. If they do, there goes the link to your data.

So my recommendation is always the same. When you receive the data, parse and validate it and store the converted values somewhere (SharePoint, Dataverse, database, etc.). The idea is to have it stored in a more permanent place where you can reference it later.

Name it correctly

The name is super important to know at a glance where we are getting the details from. Always mention somehow which Form you're using. Always build the name so that other people can understand what you are using without opening the action and checking the details.

Always add a comment

Adding a comment will also help to avoid mistakes. Indicate the Form and why you're getting the data. Knowing where the data comes from and how you'll use it will make your life a lot easier, especially if you're debugging your Flow.

Always deal with errors

Have your Flow fail gracefully when the ID or some part of the data doesn't exist. I recommend notifying someone that something fails so that the error becomes more visible. It's horrible to have failing Flows in Power Automate since they may go unnoticed for a while or generate even worse errors. I have a template that you can use to help you make your Flow resistant to issues. You can check all details here.

Final Thoughts

The "Get response details" action is simple to use, but the data it hands back needs care. Everything arrives as a string, the answers are keyed by question IDs, and Microsoft Forms is not the place to keep that information long term. Convert it, validate it, store it somewhere safe, and the rest of your Flow gets a lot easier.

Back to the Power Automate Action Reference.

Photo by Kelly Sikkema on Unsplash