> 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 Middle is organized into these basic components: * [Accounts](/middle-docs/accounts.md) are isolated containers of [data](/middle-docs/accounts/sync.md) and [workflows](/middle-docs/accounts/create-or-copy-a-workflow.md) intended to encapsulate a single business. * [Apps](/middle-docs/apps.md) are intended to wrap a single API. Within an app, Python scripts define how data is [synced](/middle-docs/apps/sync-records.md) into Middle, or how data is pushed out of Middle in [Actions](/middle-docs/apps/actions.md). * [Modules](/middle-docs/modules.md) define reusable components that can be used across many accounts. Modules are an advanced feature designed to streamline managing many accounts at once. ## Getting started If you're an application developer and want to code a new sync or action, you'll want to read documentation on [building apps](/middle-docs/apps.md). If you need to complete, or investigate, an end-to-end integration for a business, you'll want to read the documentation on [accounts](/middle-docs/accounts.md). If you'd like to build basic building blocks that many accounts can use, first familiarize yourself with how accounts work, then review the documentation on [modules](/middle-docs/modules.md). ## Terminology ### Top-level concepts

Top level navigation bar in Middle

An **account** groups workflows, workflow triggers, data, app connections, account users and account specific performance data into a single, logically isolated grouping that ought to represent a single business, and all the integrations for that that business. An **app** groups record types and their syncs, actions, authorization code, reusable code packages, and app-specific performance data into a single grouping designed to represent one API, such as ABC Financial, or Hubspot. A **module** defines reusable workflows, grouped into discrete module features, that help reduce duplication across many accounts. ### Accounts and modules {% hint style="info" %} These terms apply to both accounts and modules. {% endhint %}

Example of a Workflow

A **workflow** is the "last mile" of automation. They accept some data (like an ABC Financial prospect in the example above) and do something with that data (like conditionally send that prospect to Hubspot). Workflows are a programming language (a VPL, or visual programming language). [See more.](/middle-docs/accounts/create-or-copy-a-workflow.md) **Workflow steps** come in several types and are connected with wires. Wires indicate the ordering of what step is after the other (in the example above, the "Begin" step leads to a "Decision", which only runs "Action" if "Decision" is true). New steps can be inserted between existing steps, and steps can moved around and rewired. [See more.](/middle-docs/accounts/workflow-steps.md) **Workflow versions:** Workflows are versioned, and a specific version is called a workflow version. A version can be locked and made active, which freezes it from being updated. Locking a workflow is permanent. The most common workflow steps are: * The **begin step** is required in every workflow and defines what data type it can be called with * The **decision step** can use logic to determine if the left or right path is taken after it is run * The **action** **step** calls an API with some data

Example of the workflow parameter system, from the above decision step.

The **workflow parameter** system, pictured above, is Middle's visual programming language for [expressions](https://en.wikipedia.org/wiki/Expression_\(computer_science\)). That is, they are a way of using variables in the workflow (such as workflow inputs, the current day and time, module-defined variables, results of action steps) to calculate a new value for some purpose. In the example above, a boolean value (True or False) is calculated and determines if the decision step goes down the "if True" or "if False" paths. Learning how the expression system works is key to understanding Middle workflows. [See more.](/middle-docs/accounts/workflow-parameters.md)
**Workflow errors and warnings** can prevent a workflow from being made live, depending on organization settings. We encourage you to review and solve all errors and warnings before making a workflow live. **Workflow execution** refers to running a workflow once. **Workflow history** shows a table of what workflows that have been executed for that account or module. For a single workflow execution, Middle stores every step that was executed, how the inputs to those steps were calculated, and other information. The **real-time workflow API** allows you to call Middle's API and run a workflow synchronously. Unlike ordinary workflows, which run asynchronously, real-time workflow calls run quickly, and are designed for use with a website or mobile app in an online, real-time environment. [See more.](/middle-docs/real-time-workflow-api.md) ### **Accounts** {% hint style="info" %} These terms apply to just accounts. {% endhint %}

An example of connected apps

An **app connection** represents an account's connection to a specific app. When making a new app connection, one chooses an app and completes an authentication flow. Once that's done, syncs can be turned on and data can begin to be added to Middle. [See more.](/middle-docs/accounts/connect-or-edit-an-app-connection.md) **Middle API keys** are used to call Middle's API, allowing for programmatic access to Middle. ### Modules {% hint style="info" %} These terms apply to just modules. {% endhint %} A **required app connection** is a sort of placeholder app connection. When an account connects to a module, any required app connection has to be "filled in" with a real one. Modules can define required syncs on that app connection, and can call its actions in Module-defined workflows. [See more.](/middle-docs/modules.md#required-app-connections) **Module variables** are a special global variables accessible in all Module workflow parameters. When an account connects to the module, it will have to choose values for all the variables defined in the module. [See more.](/middle-docs/modules.md#variables) **Module features** are designed to help group together a bunch of settings into a single conceptual feature like "Send ABC prospects to Hubspot," for example. The idea here is that for a full concrete integration, several Middle settings have to be turned on, and the right variables must be filled in. A feature is an opt-in on the account side, and when opting in, the account user is prompted to fill in all required feature variables, and all feature-required settings are turned on automatically. [See more.](/middle-docs/modules.md#features) A **module-account connection** is an account that has opted into using a module. ### Apps {% hint style="info" %} These terms apply to just apps. {% endhint %} An **invocation** refers specifically to a Python script that was executed. It may be attached to an action, sync or authentication step. A **failed invocation** is a Python script that was executed, but ended with a Python exception, ran out of memory, or ran out of time. An **app API key** is just a container of authentication data that is supposed to be an API key, but in reality could be anything. When an account connects to an app, an API key can be chosen if configured. This can be a useful way of persisting a key bit of data across many accounts, such as an OAuth secret or SSL certificate. [See more.](/middle-docs/apps/credential-storage.md) An **app connection** refers to an account connecting to an app. **Auth config** refers to the configuration needed to create an app connection (connect an account to an app). This means filling out a form and optionally running a script, or multi-step oauth flow. [See more.](/middle-docs/apps/authentication.md) **Record types** are the types of data that Middle will store for this app. Examples might be "users," or "sales," or "check-ins." They are essentially tables in a database. [See more.](/middle-docs/apps/sync-records.md) **Actions** are called by accounts in workflows. They accept some data and typically represent some new data being created or updated in the app. [See more.](/middle-docs/apps/actions.md) **Code packages** allow developers to define Python scripts that can be used throughout all the entire app. [See more.](/middle-docs/apps/code-packages.md) --- # 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.