Why Flow Designer Replaced Workflow Editor
Workflow Editor still runs, but new automation belongs in Flow Designer. It handles async triggers, record operations, integrations, and subflows in one place. Legacy workflow record producers still work but Flow Designer is where Now Assist, IntegrationHub actions, and Virtual Agent handoffs converge.
The reverse migration — Flow Designer to Workflow — is almost never appropriate. If you’re on Workflow Editor and adding new logic, it’s time to move.
Scope Your Flows Deliberately
Flows run in a scope. Global flows touch everything and are hard to package. App-scoped flows package cleanly and encapsulate well. Unless a flow genuinely needs to cross applications, build it in an app scope and use cross-scope queries with caution.
Public-scope flows are a middle ground for shared utility subflows. Keep them narrow and versioned.
Always Build Error Paths
Every action in a flow can fail. Without an error path, a single broken action stops the flow and the caller never knows why. Add an error handler branch on every action that hits a table, a callout, or a credential. The handler should log to an error log table and optionally notify an admin.
Test error paths explicitly. Simulate a failing subflow and verify your handler runs.
Use Subflows for Anything Called Twice
Flow Designer subflows are the equivalent of functions. If you copy-paste the same action sequence into a second flow, extract it. Benefits: one place to update, one place to test, one place to document.
Subflows can accept inputs, return outputs, and be called from triggered flows, scheduled flows, and REST calls alike.
When to Drop Back to Scripting
Flow Designer covers ~90% of automation. For recursive operations, deep string manipulation, or integrations with strict performance budgets, scripting in a business rule or script include may still be the right choice. Don’t force Flow Designer onto jobs it’s not built for.