I recently worked with a multi-select choice field in SharePoint & used it in Power Automate & the result wasn’t quite what I expected. Turns out, it’s one of those things that makes perfect sense once you understand what’s happening behind the scenes.

The setup

We have a SharePoint column: Choice field with multiple selections enabled.

In the list it looks absolutely normal, nothing fancy:

The flow

I have simplified the flow to reproduce the issue. We’ve got a trigger, we get the item & then update the item as follows:

& then this happens.

The problem

If you just take the dynamic content “MultiChoice” & put it into the update action:

You suddenly get this in SharePoint:

[{"@odata.type":"#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference","Id":0,"Value":"Choice 1"},{"@odata.type":"#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference","Id":1,"Value":"Choice 2"}]

Instead of just:

Choice 1, Choice 2

Not ideal.

So what is OData actually?

Quick detour, because this helps a lot to understand what’s going on.

OData is basically the format SharePoint (& a lot of Microsoft APIs) use to send structured data.

Instead of just returning a simple value like:

"Choice 1"

You get a full object, like:

{
"@odata.type":"#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference",
  "Id": 0,
  "Value": "Choice 1"
}

& for multi-select fields you get an array of those objects. So what you are seeing is actually correct, just not what you want.

This happens because a multi-choice field is not a simple value. It’s an array of objects, something like:

[
  { "Value": "Choice 1" },
  { "Value": "Choice 2" }
]

& when you use the object in Power Automate, in my case “MultiChoice”, you are passing the entire object structure. Power Automate does not flatten it automatically – unfortunately.

When you look at the dynamic content, you see:

Quick breakdown:

Field (object) (e.g.: MultiChoice)
– This is the full object (includes OData, IDs, … everything).
– ❌ usually not what you want – just use it if you really need the full structure.

Item (e.g.: MultiChoice Item)
– This represents each individual item inside the array/multi-select field.
– useful inside loops (Apply to each) – one entry inside the array

Example as in my use case:
Item 1 > “Choice 1”
Item 2 > “Choice 2”

Value (e.g.: MultiChoice Value)
– These are just the values (clean text).
– ✅ usually what you want – this gives you the actual readable text

Example:

["Choice 1"]

Use this when you want to display the selected choices, store it somewhere else or as in our case just simply avoid the OData output.

The fix

My first thought was to simply swap the object with the value. However, as soon as we do that, the flow automatically introduces a loop, which makes sense, since we’re dealing with multiple values.

As the values are updated after each other, our result would look like this:

Which can be better seen in the version history:

This is obviously not what we want, but the fix is actually pretty straightforward.

Create an array variable & append each value to it. The key here is to make sure the structure is correct, so that the final array matches the format SharePoint expects.

Why do we use this structure? We are wrapping each selected value into the correct object format so SharePoint can process it properly.

{
  "Value": MultiChoice Value
}

This might look a bit strange at first, but it’s required because SharePoint does not expect a plain value. Instead of passing just:

"Choice 1"

you have to wrap each value in an object like this:

{
  "Value": "Choice 1"
}

To be able to use the variable as input parameter, we need to “switch to input entire array”.

One thing to watch out for: the UI changes here & once you add content, you are basically stuck in that mode until you clear the field again.

This honestly confused me more than I’d like to admit. Sometimes I saw the nice “Add new item” option, sometimes I didn’t… and there was no obvious reason why. 😄 Since I was troubleshooting a flow someone else had built, it took me a moment to realize what was actually going on.

Then pass the full array variable:

The result

If everything is correct, your flow input will look something like this:

[
  { "Value": "Choice 1" },
  { "Value": "Choice 2" }
]

& SharePoint will finally display the correct values:

& done! ✨

Side note: I personally still prefer working with the classic designer. I know I’ll have to say goodbye to it at some point… but I’m holding on as long as I can. 😄

That said, if you’re already using the modern designer, you probably won’t run into this issue anymore. The new UI actually guides you a bit better here & only allows you to select the value for the value field, which avoids the whole OData situation altogether.