If you’re wiring Microsoft Planner to Azure DevOps in Power Automate, three things will bite you before the flow is reliable: a license you probably didn’t budget for, an update trigger that silently ignores half of what changes on a work item, and a wall no amount of clever flow design gets you past. This is the practitioner-level breakdown for whoever’s already mid-build — what actually breaks, why, and where the workaround runs out.

The premium license you need before the first flow

The Azure DevOps connector isn’t on Power Automate’s free tier. It’s flagged Premium both in the connector’s own documentation and on Microsoft’s premium-connector reference list, which means the flow owner needs a paid per-user (or per-flow) plan — the free tier that ships in most Microsoft 365 tenants can’t call it (Microsoft Learn — connector, premium connector list). Confirm this before you promise anyone a “quick no-code flow” — it’s the first thing that stalls a proof of concept once it hits procurement.

This is the one that costs the most debugging time, because the flow looks like it’s working right up until it isn’t. Microsoft’s own connector documentation lists it as a known limitation: the “When a work item is updated” trigger is skipped when links are added to or deleted from a work item (Microsoft Learn — connector docs). Practitioners hit the same wall from a different angle — a Power Platform Community thread found that System.ChangedDate itself doesn’t update when a relation changes, so there’s no timestamp field to poll against as a fallback either (Power Platform Community).

Practically: if your sync needs to know when a work item gets linked to a Planner task, a parent item, or a pull request, the standard trigger won’t tell you. The only workaround in circulation is adding a “Send an HTTP request to Azure DevOps” action with $expand=relations and diffing the result yourself — which puts you back to owning state by hand, the exact thing the low-code connector was supposed to save you from.

Repro Steps images over 500KB get silently stripped

If your flow writes into Repro Steps or another HTML-formatted field — say, forwarding a screenshot from a Planner task description into a new work item — check image size first. The connector’s own docs say images under roughly 30KB render correctly, and images over 500KB may be removed from the field entirely, with nothing flagged as an error in the flow’s run history (Microsoft Learn — connector docs). A run that shows green can still have quietly dropped the one screenshot that mattered.

The wall: Planner Premium isn’t reachable at all

This is the same wall mapped at a higher level on the head page covering all three Planner–Azure DevOps sync routes, but it’s worth restating here because it’s specifically where Power Automate builds fail — not just where they get more expensive. If your plans are the new Planner Premium (formerly Project for the web), the standard “List tasks” and other free-tier Planner actions in Power Automate don’t reach them. Premium task data lives in Dataverse — msdyn_project, msdyn_projecttask — and practitioners report exactly this dead end trying to connect it from Power Automate (Power Platform Community). Microsoft’s own accepted answer on the question is explicit: the Graph API’s Planner endpoints don’t support Premium data at all, and the supported path is the Dataverse Web API instead (Microsoft Q&A).

That’s not a Power Automate setting you can flow around — it’s a different backend, with different actions, different auth, and effectively a separate build. Check your Planner tier before you invest in anything else here. If you’re on Premium, the license question above is moot: the free-tier Planner action won’t see your data no matter what you pay for.

A flow shape that survives these limits

Given all of the above, a Power Automate build that actually holds up in production looks like this:

  • Confirm you’re on basic (non-Premium) Planner before you start — this decides whether Power Automate is viable at all.
  • Budget the premium per-user Power Automate license for the flow owner up front, not after a “why is this connector greyed out” ticket.
  • Trigger on the work-item fields you actually need — state, assignee, title — and don’t design around link or relation changes; the trigger won’t see them.
  • If relations do matter, add the $expand=relations HTTP call and diff it yourself, and treat that as a small standing maintenance job, not a one-time setup step.
  • Keep anything going into Repro Steps or similar HTML fields under ~30KB, or route larger images through a blob link instead of embedding them.

None of this makes Power Automate the wrong choice — it’s still the fastest way to get a one-directional, basic-Planner sync running without standing up a service. It just isn’t the no-code afternoon project it looks like from the connector’s setup screen.

Where this leaves you

We build integrations for a living — Crosstown Tech’s Planner-to-Jira connector exists because we hit this exact class of problem on the Jira side. We don’t have a Planner-to-Azure-DevOps product today, but we’re mapping the same territory, and the limitations above are near the top of the list of things a real bridge would need to handle better than a flow can. If you’re mid-build and one of these just broke your flow, tell us what happened — hello@crosstowntech.com.