Power Platform Community Forum Thread Details

I am a lawyer, not a programmer. I am trying to set up workflows for case management and Copilot has been slowly walking me through the process. I hit a wall when I was trying to create a planner item from my SharePoint list. I can create the item in Planner, but I could not get the Assigned User data to follow the item.

Copilot said this:

Problem:
In Microsoft Power Automate, Planner task assignment cannot be automated reliably using first‑party Planner connectors (Create a task, Add assignees, or Update task details) in some tenants.

Although Power Automate exposes fields suggesting that assignment by user ID is supported (e.g., Assigned User Ids), Planner rejects all non‑JSON assignment inputs with schema validation errors.

Furthermore, in some environments, the assignments field required to pass a valid plannerAssignment object is not exposed at all in the Update task details action, making assignment automation impossible without custom Graph API calls.

This creates a false affordance in the UI and breaks cross‑product automation scenarios between SharePoint Lists and Planner.

By the way, Copilot is pretty critical of Microsoft's User Interface. As a professional user (not a programmer, I find some of the user interface to be baffling and impossible to use. I should post the transcript of my Copilot session for all the times I had to upload screenshots to show what I was seeing when it was describing something else.

4. Why this is especially galling (and why you’re right)

You called out something important that’s worth underscoring:

Microsoft already has globally unique user identifiers.

Exactly. This isn’t a technical impossibility. It’s a coordination failure between product teams:

SharePoint → fine with person fields
Teams → fine
Outlook → fine
Azure AD / Entra → fine
Planner → insists on an internal object shape and refuses to resolve identities

And worse: Power Automate pretends otherwise, exposing UI fields that don’t actually work.

That’s why this feels insulting rather than merely annoying.

This is a serious disconnect between Microsoft products. I am a power user for sure, but coding baffles me. When my List includes a user look up for the "assigned to" field, that data should easily translate to Planner inside Teams.

Please fix this and clean up your UI! What a nightmare.

Hi, I completely know your pain. What you’re seeing isn’t a mistake on your side. It's a real inconsistency between how different Microsoft services represent users.

SharePoint person fields return claims/email-style identity values, while Planner expects an Azure AD object ID (GUID). Power Automate sits in the middle and doesn’t automatically translate between the two, even though the underlying directory already has that mapping.

So the fix today is basically to do the conversion explicitly.

Pattern that works:

a) After your SharePoint trigger, add an "Office 365 Users -> Get user profile (V2)" action.
b) In the User (UPN) input, pass the email from your SharePoint person field. The dynamic content picker usually shows it as "Assigned To Email" or similar.
c) That action returns the user's Id -- a GUID like 09dbe02f-b15a-4c13-...
d) In Planner "Create a task (V4)", drop that Id into the Assignments field.

I verified this end to end. The V4 action accepted the user GUID and the assignment came through correctly, with no Graph calls or custom JSON needed.

Funnily enough I had GitHub Copilot in agent mode build and test the validation flow via the MCP setup I mentioned below - which is exactly the kind of iteration loop that Copilot Agent in the Microsoft UI can't do yet as of now.

We’ve been experimenting with exposing that runtime detail directly to agents through an MCP layer so they can inspect failures themselves instead of asking for screenshots (mcp.flowstudio.app - disclosure: I’m one of the builders), but for the Planner assignment issue specifically the Get user profile (V2) → Assignments (V4) pattern above should unblock you immediately.

Step 1: retrieve GUID