Test and publish

Validate a Workflow against real execution behaviour, then publish the version that production can use.

Treat testing and publishing as part of operating the process, not as a cosmetic step at the end of building.

The builder edits a Draft. Test runs execute that Draft. Publishing creates a Published version that can become the live default.

Validation catches configuration, not the whole runtime

Static validation checks required node inputs, trigger and credential configuration, and a limited set of node-specific minimums. Disabled and disconnected non-trigger nodes are skipped.

It does not currently type-check data across every edge, compile every expression in advance or verify what an external system will return.

A test run is real execution

A Workflow test is not a dry run. It uses real connections and models and can make real third-party writes. It also consumes monthly execution quota, a concurrency slot and the plan's normal run timeout.

Use safe test data and understand the side effects of the actions in the path you are exercising.

Test mode deliberately differs from production for Request handling: Request Decision and Request Input are handled inline, with no real Request Inbox row, assignment enforcement or Workflow Session for the Request flow.

Publishing changes what production can execute

Publishing requires a version bump and a version comment. Live traffic only uses a version that is Published, active and the Workflow's default version.

Publishing can deploy integration triggers and synchronise a schedule when the version becomes default. A schedule-application failure aborts publication rather than silently leaving the scheduled Workflow half-updated.

Use the child pages for tests, failure behaviour, publishing and schedules. After live execution, use Monitoring as the evidence of what actually happened.