> For the complete documentation index, see [llms.txt](https://docs.middle.app/middle-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.middle.app/middle-docs/building-workflows.md). # Automate Workflows are the automation and programming layer in Middle. They define what happens when data moves, such as when a record is created, a scheduled trigger fires, or an external system calls Middle's API, and what to do in response: send data somewhere, update a record, notify a system, chain multiple actions together, etc. To run a workflow, a few pieces need to be in place. You need at least one **app connection** — Middle's authenticated link to an external service — so the workflow has somewhere to read from or write to. That connection runs **syncs** that pull records into Middle's storage, giving the workflow data to act on. A **trigger** determines when the workflow runs automatically. And the workflow itself is made up of **steps** — a sequence of actions, decisions, and variable assignments built in a visual editor, no coding required. This page covers all of those pieces. If you're ready to build, see Create a workflow. {% hint style="info" %} ENTERPRISE customers can create a new account by going to the **Accounts** tab and clicking **+ New Account**. {% endhint %} *** ### Key concepts #### App Connection Before a workflow can do anything, Middle needs access to your apps. An **app connection** is a secure link between your Middle account and an external app — it holds the credentials (API keys, tokens, or login details) that Middle uses to read and write data on your behalf. Each app connection has four parts: * **Authentication** — the credentials that grant Middle access to the app * **Syncs** — jobs that pull records from the app and store them in Middle * **Actions** — functions your workflows can call to write data back to the app * **Stored records** — the records Middle has already synced and saved *** #### Triggers A trigger is what kicks a workflow off. Without a trigger, a workflow only runs when you start it manually. With one, it runs automatically. There are three types: * **Activity trigger** — fires whenever a synced record is created or updated. For example: run this workflow every time a new member is added in your CRM. * **Scheduled trigger** — fires on a fixed schedule, such as once a day or once an hour. For example: every morning, pull yesterday's check-ins and send a summary report. * **API trigger** — fires when an external system calls Middle's real-time workflow API. This is useful for transactional integrations driven by user actions — for example, a button press in your app that immediately kicks off a workflow in Middle. See Real-time Workflow API for setup details. **Filtering with triggers.** Triggers support discard logic — rules that tell Middle to skip a workflow run if the record doesn't meet certain conditions. For example, you might discard the run if the member's status isn't "active." Using discard logic is more efficient than filtering inside the workflow itself, because Middle never starts the execution in the first place. {% hint style="info" %} Trigger runs are not logged in execution history. If you need a record of every run for auditing purposes, use a decision step inside the workflow instead. {% endhint %} *** #### Steps A workflow is made up of steps that run in sequence. There are four step types: **Begin** — the starting point of every workflow. This is where you define what data comes in: the synced record that triggered the workflow, plus any other variables you want available throughout. Think of it as the top of a funnel. **Action** — calls a function in a connected app. This is where data moves: creating a contact in your CRM, updating a record, sending a notification. Actions have inputs (what you send) and outputs (what the app returns). Outputs are captured in variables you can use in later steps. **Decision** — branches the workflow based on a condition. For example: if the member's plan is "Premium," go left; otherwise, go right. Decisions let you handle different cases in a single workflow rather than building separate ones. Branches can also rejoin later — two separate paths can converge on the same next step, which reduces duplication in complex workflows. **Return** — ends the workflow and sends a value back to the caller. Only relevant when a workflow is triggered via the real-time API — this is how Middle responds to the external system that initiated the call. *** #### Variables Variables hold data that you can read and write throughout a workflow. The pattern is straightforward: declare a variable, then set it at any point during execution and reference it in any later step. You declare variables from the **Variables drawer**, accessible from the top of the workflow editor or above any step. Once declared, a variable starts as empty — it returns nothing until something sets it. There are two ways to set a variable during a workflow run: * **Set Variable step** — a dedicated step that assigns a value to any declared variable. Useful for computing or storing intermediate values. * **Action output** — when an action step runs, its output can be assigned directly to a variable. This is the recommended way to capture data returned from an external app. **Special variables** are available within a specific context, usually inside an array loop. They represent the current item being processed and are scoped to that loop only. *** #### Arrays An array is a list of items — for example, a list of all check-ins linked to a member, or all memberships tied to an account. Many synced records contain arrays as part of their data. Middle can work with arrays directly inside workflows. You can loop through each item, filter the list down, extract specific values, or pass the whole array as an input to an action. See Working with arrays for a full breakdown of the available tools. --- # 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.middle.app/middle-docs/building-workflows.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.