Anyone who has built a flow of more than fifteen actions in the Power Automate web designer knows the feeling: the canvas lags, the dynamic content panel opens in the wrong place, you paste an expression and the editor decides focus was somewhere else.

The method I use now is different: export the package, edit the definition outside, reimport.

The workflow

  1. In the flow list, Export → Package (.zip).
  2. Unzip it. Inside there's a definition.json with the whole flow: trigger, actions, expressions and runAfter.
  3. Edit that file in a decent text editor, with JSON validation in front of you.
  4. Zip it back up and Import, choosing Create as new.

"Create as new" is the key. You overwrite nothing: you get a sibling flow, switched off, to test against while production keeps working. If it goes well, you turn one on and the other off.

If it goes badly, you delete the new one and nothing happened.

Why it pays off

You see the whole graph. runAfter is the part of a flow the designer hides best and the part that causes the most incidents. In the JSON it's right there, and you can see at a glance what depends on what.

Expressions get written once. In the designer, a long expression is a fight with a field that closes on its own. In the file it's a line of text.

The diff is your documentation. Keep definition.json in a repository and every change is recorded, dated, with the exact difference.

That's the traceability Power Automate doesn't give you.

The detail that ruins afternoons

If you do have to touch something in the designer, there's one rule with no exceptions:

Any expression, in any field, goes in through the dynamic content panel, Expression (fx) tab, written without @ and without braces. It has to end up as a purple chip.

Paste the text with @ or @{ } straight into the field and it's stored as a literal — and you end up with an email to a customer that reads, word for word, @{body('Select')}.

Related, and also learned the hard way: in the Map field of a Select in text mode the expression goes bare, concat(...), because that field is of type "any"; in the Inputs field of a Compose, you do use @{...}. Same tool, two rules, neither signposted anywhere.

When the designer is unavoidable

Some things don't come in the package: reconnecting connections, approving permissions, running a test. For those you have to go in. My rules when I do:

  • One tab open, and only one. I've watched an expression meant for Power Automate land in a Power Apps Studio search box open in another tab. The clipboard crosses tabs.
  • Check focus before pasting, not after.
  • Save in small pieces, with version notes, so you know exactly which step corrupted something.
  • Run the flow checker after every paste. Zero errors and zero warnings, or you don't move on.

None of these rules is elegant. Every one of them came out of a lost afternoon.