> 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.