> For the complete documentation index, see [llms.txt](https://docs.couchdrop.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.couchdrop.io/automations/overview/visual-automation-builder.md). # Visual Automation Builder Learn about how Couchdrop's visual workflow builder works ## Overview The Automation Builder provides a visual way to define the order in which actions run in a Couchdrop Automation. Actions are arranged as a tree. Actions moving **down** the tree are **Primary Actions**, while actions branching to the **right** are **Sub-actions**. Understanding this structure is important because it determines which file each action operates on and the order in which Couchdrop processes the workflow.

Automations have two main pathways. Moving down the tree are primary actions. Moving to the right are sub-actions.

## Primary Actions Primary Actions run vertically down the workflow and operate on the **original file**. For example, if a Primary Action copies a file, any Sub-actions attached to that Copy action operate on the copied file rather than the original. Because Primary Actions continue to reference the original file, some actions are not available at this level where their use could interfere with later processing. For example, **Rename File** is not available as a Primary Action. ## Sub-actions Sub-actions branch to the **right** of another action. A Sub-action operates on the output of its parent action. If the parent action creates another file, such as with a Copy action, the Sub-action operates on that new file. If no additional file has been created, the Sub-action operates on the original file. This lets you build dependent sequences where each action works with the result of the previous action. {% hint style="warning" %} If a Sub-action fails, Couchdrop will not continue processing any child actions beneath it. {% endhint %} ## Processing Order Couchdrop processes Automation actions **top-to-bottom, then left-to-right**. This means an action and its Sub-actions are completed before Couchdrop continues to the next Primary Action. The Automation Builder indicates processing order using letter groups and numbered actions. All actions in the **A** group are processed first in numerical order. Couchdrop then processes the **B** group, followed by subsequent groups. For example, a workflow may be processed as: `A1 → A2 → A3 → B1 → B2 → C1` The visual hierarchy therefore represents both the relationship between actions and the order in which they run.

All A group actions will occur first in numerical order, followed by the B group, and so on.

## Modifying an Automation Once an action has been added, its action type cannot be changed directly. To use a different action, delete the existing action and add a replacement. You can insert a new action between existing actions using the **plus icon** between steps. Couchdrop will adjust the subsequent steps and processing order automatically. {% hint style="warning" %} Deleting an action also deletes any Sub-actions beneath it. If an action has child actions, Couchdrop displays a warning showing how many actions will be removed before you confirm the deletion. {% endhint %} --- # 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.couchdrop.io/automations/overview/visual-automation-builder.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.