Moving changes to production

Treat testing and publishing as operational change, especially when Workflows can affect external systems.

A Lleverage change can affect real operational work, so the release question is not only “does it run?” but “is this the version we are prepared to operate?”

Test with production consequences in mind

Workflow tests are real executions. They can call real Connections and cause real external side effects. Use safe inputs and appropriate environments where the connected system supports them.

Testing should cover the failure and human-handoff paths as well as the happy path.

Publish deliberately

Builder changes live in Draft. Publishing creates the version used for live execution according to the current active/default version semantics. Publishing can also affect live triggers and schedules.

For material processes, agree who is allowed to publish and what evidence they need before doing so.

Prefer bounded changes

When changing a live operation:

• know which Project and Workflow are affected;

• understand which triggers, schedules and Connections can be exercised;

• keep unrelated changes out of the same release where practical;

• know how you will recognize a bad outcome quickly;

• know who can stop, correct or replace the live path.

The product supplies versioning and execution evidence; the release policy remains an organisational decision.