> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/build-and-improve/automate/test-and-publish.md). # 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.lleverage.ai/build-and-improve/automate/test-and-publish.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.