> ## Documentation Index > Fetch the complete documentation index at: https://docs.letsflow.ai/llms.txt > Use this file to discover all available pages before exploring further. # Test and publish > Test saved revisions, run linked actions, and publish Flow automations. ## What testing and publishing check Validation scenarios and draft testing check a saved revision before release. Publishing makes a saved version available for a team or the organization. ## Save before testing Save the draft before you run Validation scenarios, test, or publish. When you ask Flow to edit a scenario and test it, Flow saves the edit before starting the run. Saved revisions include automation code, prompts, and Validation scenarios. If the draft has blocking issues, fix them first. Common blockers include missing automation details, invalid inputs, or integration actions that cannot be resolved. ## Validation scenarios Validation scenarios are saved checks that travel with each revision. Each scenario has a display name, a short description, fixed input, mocked actions, and an expected result. In the editor, Validation scenarios appear as their own group. Saving keeps them with that revision. Editing or removing a scenario creates a new revision; earlier revisions keep the scenarios they already had. Run Validation scenarios against the revision you are reviewing. Results and action coverage stay attached to that revision and run; a new revision does not inherit them. Run the scenarios again after saving changes. Publication needs current Validation scenario review for the revision you publish, not only that the scenarios exist. In the Automations chat, use `/review` to review the draft and its Validation scenarios. Flow saves each new scenario as a draft before running it. Creating a scenario does not establish a passing result or publish the automation. The review covers a representative happy path and distinct business outcomes, such as approval and denial. It adds failure cases when they establish important behavior, such as recovery. Flow runs one scenario at a time and waits for its result before starting another. Every declared action must execute successfully in a passing scenario before Flow finalizes review changes. Complete action coverage alone does not prove every business outcome. If Flow cannot establish a required correction, it reports the blocker and leaves the draft unfinished. You can also ask Flow to inspect results or run selected saved scenarios once, without creating scenarios, repairing failures, or finalizing changes. An empty selection starts no runs. ## Test options Use these modes for an interactive draft run in addition to Validation scenarios: | Mode | Use when | | - | - | | **Simulated** | You want to choose approval and provider-action outcomes without changing connected apps | | **Live** | You intend to call real provider connections | Live runs require ready integration connections. Cover the successful path and the important failure paths before publishing. When you ask Flow in chat to run a live test, review the saved version's required connections and input in the approval card. Choose **see details** to edit input in Form or JSON, then select **Approve and run**. A submitted run has a log link in the card; open it to follow execution and see the final status. **Deny** starts no run. ## Run linked actions without changing your automation In the Automations chat, ask Flow to prepare a separate set of actions when you need to inspect data or make a specific change without running or editing the automation you have open. Flow saves these actions as a linked automation and associates it with the main automation. It does not appear as a separate item in the automation list or change the main automation's revision. This is not a test of the main automation. Flow uses the same live run tool as a normal automation run, targeting the linked automation's saved revision. Before approving, review the actions and their effects, open **Review full saved source and fixed arguments** to inspect the saved source and exact targets, and select any required connections. These actions can change real data. Select **Run actions** to submit the run, or **Deny** to start nothing. After submission, select **View RUN-…** in the chat card to open the run tab on the main automation. Its Run history shows main automation runs by default. Select **Linked runs** in the history filter to see only runs linked to this main automation, then open a run to inspect its recorded steps, output, and saved source from that run's revision, not the main automation's current draft. Use Validation scenarios or a draft test when you need to check the main automation itself. ## Choose the publish scope Choose **Publish**, then select the audience: | Audience | Who can use it | | - | - | | **Service desk agents in selected teams, from Web** | Service desk agents in the teams you choose, not all team members | | **Everyone in the organization, from any activated Slack, Teams, Email, Web** | Any employee in the organization, subject to channel and availability rules | Publish to the smallest audience that matches the automation's purpose. See [Publish and execution scope](/automations/build/publish-and-execution-scope) for Slack, Teams, and email channel limits, connection, identity, Validation scenario readiness, and execution-team checks. ## Version behavior Publishing creates a version. New runs use the active published version. Runs that already started keep using the version they started with. Draft changes are safe to continue editing. They do not affect published runs until you save and publish a new version. ## Check a publication Use [Monitor automations](/automations/monitor) to review run status, failures, retries, permissions, and history. ## Related topics * [Build your first automation](/automations/build/first-automation) * [Monitor automations](/automations/monitor) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.