Most Flow Designer flows I inherit don’t fail because the logic is wrong. They fail because no one can read them six months later, and the first refactor accidentally rewires three integrations.
Here are the six patterns I keep coming back to — the ones that hold up when the original author has rotated out and a new admin has to extend the flow under deadline.
1. Name like you’re paginating a runbook
Flows aren’t code, but they get grepped like code. I prefix every flow with the domain it belongs to (HRSD - , ITSM - , Integration - ) and end with the trigger style (on Approval, Scheduled Daily, Webhook). When something breaks at 2 a.m., a sortable name is worth ten dashboards.
2. Make the trigger boring
A Flow’s trigger should be the least clever part of it. If you find yourself adding conditions to a record-changed trigger that look anything like business logic, pull them into a Decision step inside the flow. Triggers that read like English age better than triggers that read like SQL.
3. Idempotency or it didn’t happen
Anything that talks to an external system gets wrapped so it can be re-run safely. That usually means an external correlation ID and a “look before you create” check, not a try/catch. If a network blip can produce a duplicate change request, you don’t have automation, you have a coin flip.
4. Error handling at the boundary, not the step
I stopped putting error handlers on every action. Now there’s one error handler at the subflow boundary that classifies the failure (transient, validation, auth) and decides whether to retry, alert, or create a fallback record. Stops the noise from fan-out alerting.
5. Subflows = the verbs of your domain
If a chunk of logic could be reused even hypothetically, it becomes a subflow. “Notify approver”, “Sync to vendor”, “Create fulfillment task” — these are verbs the rest of the platform speaks. Once you have them, building new flows feels like writing sentences.
6. One Flow, one outcome
When a flow’s description starts with “and also”, split it. The temptation to bundle related side-effects into one flow is real, but the moment one of them needs to change independently, you’re rewriting all of it.
What I’d add if I were starting today
A simple naming convention test in CI that fails on flows missing a domain prefix. Half the long-term mess on platforms I audit could be avoided by that one rule.