From time to time I find myself back in Power Automate building something that should be incredibly simple. Usually it’s because a customer needs a quick workflow, someone asks for a proof of concept, or I just need to automate something without overthinking it. And every now and then I run into one of those issues that has been around since what feels like the beginning of the Power Platform.

The platform has come a long way. It’s faster, more capable, and far more polished than it was in the early days. But it still has a handful of those “oh yeah… I forgot about that” moments. They’re not necessarily bugs, and they’re usually documented somewhere if you know what to search for. They’re just quirks you eventually learn to work around.

This week it was SharePoint multi-value choice fields.

On paper, the scenario couldn’t be simpler. Read a field from SharePoint, use it in an approval, and write it back to the same list without changing it. Except the SharePoint connector has other ideas. The exact same field is represented three different ways depending on what you’re trying to do with it, which means the flow ends up spending more time transforming data than actually processing it.

A multi-value choice field in SharePoint should be simple. Read the value, use it in a flow, write it back. Except the SharePoint connector exposes that same field differently depending on what you are doing.

That sounds minor until the flow starts failing. The trigger gives you objects with both Id and Value, but the Update item action refuses the Id because it is read-only. Then, when you want to show the selections in an approval or email, neither object shape is useful. You need plain text instead.

So you read this:

[
  {
    "Id": 0,
    "Value": "Option A"
  },
  {
    "Id": 1,
    "Value": "Option B"
  }
]

Then you try to write it back.

Power Automate says no.

For Update item, you have to reshape it into this:

[
  {
    "Value": "Option A"
  },
  {
    "Value": "Option B"
  }
]

Then, for an approval or email, you reshape it again into this:

Option A, Option B

Same field. Same values. Three shapes.

The annoying part is that none of this exists because the business process needs it. It exists because the connector handles reading, writing, and displaying the field differently.

In practice, that usually means two transformations. One turns the SharePoint objects into plain text for emails and approvals. The other removes the read-only properties so Update item will accept the value.

So how do you actually deal with it?

Once you understand what the connector expects, the workaround is straightforward. I ended up creating two separate Select actions, each with a different purpose.

The first one is for anything that needs to display the values, like approval emails or notifications. It converts the SharePoint objects into a simple array of strings.

From

triggerBody()?['YourMultiChoiceField']

Map

item()?['Value']

That gives you:

[
  "Option A",
  "Option B"
]

From there, displaying the values is as simple as:

join(body('Select_MultiChoice_Values'), ', ')

The second Select action prepares the same field for Update item. This time, you keep only the writable property.

From

triggerBody()?['YourMultiChoiceField']

Map

That produces:

[
  {
    "Value": "Option A"
  },
  {
    "Value": "Option B"
  }
]

You can then pass that output directly into the SharePoint Update item action without the connector complaining about the read-only Id property.

There is nothing particularly difficult about the workaround. The hard part is realizing that the same SharePoint field needs to be represented three different ways depending on which action you are talking to. Once you know that, you stop fighting the connector and start reshaping the data before it gets there.

Could Microsoft make this easier? Absolutely. If I am not changing the field, I should not have to rebuild it. And if the trigger returns a valid SharePoint object, the Update item action should not reject that same object shape.

Once you know the pattern, it is manageable. The problem is that nobody tells you until the flow breaks. And when Power Automate starts throwing timeout or gateway errors, your first instinct is usually to look in the completely wrong place.

Multi-value choice fields are not alone, either. Person, lookup, and managed metadata columns can pull the same nonsense.

So if you have ever stared at a perfectly valid SharePoint field wondering why Power Automate suddenly hates it, there is a good chance the problem is not your logic. It is probably the same SharePoint field, just in the wrong shape for the action you are using.