An export contains more than visible logic

When I look at a workflow export, code nodes and connections get most of the attention. Identifiers deserve the same care: workflow and node identities, webhook paths, execution references, and credential bindings can all be dependencies for something outside the canvas.

Changing them can break an otherwise sensible update.

Stable routes reduce coordination

Landing pages and messaging providers call known webhook paths. Replacing a path means changing integrations, test tools, documentation, and possibly a deployment plan at the same time. A workflow version should normally preserve that public contract unless the route change is intentional and coordinated.

Internal calls deserve the same caution. A workflow that invokes another workflow by identity can silently point at an older flow or nothing at all if a replacement is imported with a different identity.

Audit connections, not only identifiers

After a change, I want to check that every connection ends at a real node, both outputs of conditional branches are deliberate, legacy nodes cannot accidentally run, response paths remain connected, and internal calls target the intended flow.

What I learned

Identifiers are production behaviour. They are comparable to application routes and database schema: not always visible to an end user, but still part of the contract other components rely on.

What should happen next

An export validator should compare an updated workflow with its previous version and flag changed identifiers, routes, credentials, and connections before deployment.