> ## Documentation Index > Fetch the complete documentation index at: https://docs.audimate.ai/llms.txt > Use this file to discover all available pages before exploring further. # Workflows > Bundle a recording, a playbook, and the task boards a task runs over into one workflow, then run it yourself or hand it to an agent. A workflow is the unit of work in Audimate. It bundles a recording of how a task is done, a written playbook describing the steps, and the task boards it reads from or writes to. Running a workflow means Arro reads its playbook and completes the task for you. Every recording you save, every playbook you write, and every run you trigger lives inside a workflow. ## Where to find it Workflows live in the Audimate workspace, in your browser and in the [desktop app](/concepts/desktop-app). You create, edit, and run them from either. Capturing a recording happens in the desktop app through [watch mode](/concepts/watch-mode). To open one, choose **New** then **New Workflow** in the sidebar, or double-click any workflow file in **Team Library** or **Private**. Saving a watch recording opens the new workflow's detail page for you. ## The workflow detail page Three tabs run across the top, each mapping to a core concept. The captured steps. Reorder, rename, or delete them. Plain-language instructions for handling one task. The task boards holding the tasks a run works through. A workflow opens on the **Playbook** tab, since that is the part a run and a coaching session both read. The header above the tabs holds the title, the version selector, and the action buttons. When a task board feeds a **second** workflow, Audimate adds a **Workflow** field to it so each task says which workflow should process it, and removes the field again if the task board drops back to one. ### Plugins this workflow needs An `@` mention declares a plugin the workflow uses. The strip below the header shows each plugin's readiness for your account. | Action | What happens | | ----------- | ----------------------------------------------- | | **Install** | Adds the plugin and starts required setup | | **Enable** | Enables the plugin and starts any missing setup | | **Connect** | Opens authorization or a credentials dialog | Authorization opens separately, keeping your workflow edits open. Plugin settings and connections belong to your account within the workspace, so teammates can see different readiness. ## Create a workflow Enter a name and click **Create workflow** to open the editor. See [Creating files](/concepts/libraries#creating-files) for its location. Write the playbook first and attach a recording later, or build it up from the **Recording** tab by adding steps by hand. To capture a task instead of writing it out, record it in the desktop app with [watch mode](/concepts/watch-mode). Recording always produces its own new workflow, so start there rather than from inside one you have already created. Once you have a recording, the **Create** button in the header opens the **Create with AI** dialog. | Tab | What it does | | ---------- | ---------------------------------------------------- | | **Create** | Scaffolds a new playbook or a template task board | | **Edit** | Applies a change you describe in plain language | | **Manual** | Creates a recording, playbook, or task board by hand | Inside **Create** and **Edit** you tick what to generate: a **Playbook** of step-by-step instructions, or a **Template task board** carrying the field schema and no tasks. Generating a playbook from a recording is the usual first step, because the agent follows what the recording shows. ## Running a workflow The **Start workflow** button in the header opens a dropdown with two ways to run. From the web app both hand off to the desktop app, and the dialog that appears has a download link if it does not open. Both are unavailable until the workflow has something to work from: recorded steps, a playbook with something written in it, or an attached task board. Until then they are greyed out and say so on hover. ### Guide me [Arro](/concepts/arro) walks you through the workflow on your own screen, one step at a time. It highlights the control to use, tells you what to do, and waits. It coaches from the recording when there is one and from the playbook when there is not, so it works as soon as the workflow has either. Arro follows what is actually on your screen, so it adapts when the app has changed since the recording was made. ### Run with AI The workflow runs once in the desktop app. Follow its progress and open its result in **Tasks**. | Start | What happens | | ---------------------------------- | ------------------------------------------------------ | | **Run with AI** or a voice request | Runs once, with you available to answer questions | | **Run again** | Starts a fresh run once | | A scheduled workflow | Follows its procedure, including starting queued tasks | | A task board worker | Processes only its assigned task | A manual run needs no task board. Attached task boards and their queued tasks stay untouched. If required inputs are missing, Arro asks you. Recording examples do not become inputs automatically. Answer inline in the dock or open the task in **Tasks**. Select an offered option, or type your response and click **Send answer**. The run waits up to 10 minutes for an answer, then reports what it could not complete. You can cancel while it waits. For a browser login or verification step, use **Take over**, complete the step, then resume. A run cannot start until every mentioned plugin is installed, enabled and connected for your account. The message names what needs attention. See [Plugins](/concepts/plugins) for setup and reconnection. Routine connection renewal happens automatically. A connection marked for reconnection requires you to reconnect before running. In the desktop app you can start either mode by voice: ask Arro to run a workflow by name, or ask it to walk you through one. ### What each plan can do Building a workflow is free, and Free includes 3 runs to try what you built. They are counted once per person, not per workspace or per month. After those, running starts on Plus. What each run may use, and the messages you see when a run stops, are on [Plan limits](/account/plan-limits#what-happens-when-you-hit-a-limit). | Action | Free | Plus and above | | --------------------------------- | ------------------------------------- | -------------- | | **Guide me** | Yes | Yes | | **Run with AI** | 3 included runs, then upgrade options | Yes | | Editing **Settings → Agents** | Yes | Yes | | **Run agents on this task board** | On, while included runs remain | Yes | | Snapshots | Upgrade prompt | Yes | Setting a task board up stays free, so you can choose the four agent lists, the workflow the task board runs, and **Start cards automatically** ahead of an upgrade, and take any of it back out again. Agents pick work up while included runs remain. Each card an agent works counts as one run, so a full queue can use them quickly. Everything else about a task board is free too: drag tasks between lists, and a task dropped in the pick-up list waits there. See [Plan limits](/account/plan-limits). ### Running many tasks at once Use the [task board's agent controls](/data/boards) to start queued work, or schedule a workflow whose procedure starts queued tasks. Each waiting task gets its own worker, a few at a time. On a task board of 20 leads, that means twenty separate runs. Configure the workflow and agent lists in the task board's **Settings → Agents**. The pick-up list determines which tasks can run. Starting a workflow manually executes it once and leaves that queue untouched. Tasks move out of the pick-up list, through the working list, and into **Done** or **Failed** live as workers finish them. A worker [files its own task](/data/boards#done-and-failed) into the list holding that role, so which list a task is in IS what happened to it, and nothing else decides where it lands. Each worker also appears in your **Tasks** list if you want its step-by-step detail. Two workers can never pick up the same task, so a task is never processed twice. If a worker stops unexpectedly, its task returns to the pick-up list after a while and another worker picks it up. On a task board with a [Priority field](/data/boards#priority), the most urgent waiting tasks go first. Workers cannot ask you questions. One that hits a login screen or a CAPTCHA marks its task **Failed** with the reason and stops. For a login, sign in to that site once from **Arro → Browser → Sign in** (see [Signing in when a task asks](/concepts/desktop-app#signing-in-when-a-task-asks)); for anything else, clear the blocker where it lives. Then use **Retry** on the failed card to send it back to the pick-up list. ### What your task board needs Work is picked up through the task board's [**Stage**](/data/boards#stage) field and its **pick-up list**, the list labeled "Agents pick up here". A task waits there, and moves to the working list while a worker runs it. Every new task board arrives with its four agent lists set up and agents switched on, on every plan, though nothing is picked up until the workspace is on a plan that runs agents. Two things stop a run once it is: the **Agents** master switch being off, and the agent lists having been cleared, both under **Settings → Agents**. You can also start work from the task board itself. Turn on auto-run so a card dropped into the pick-up list starts immediately, point a personal schedule at the task board, or select cards and choose **Run**. See [Starting agents](/data/boards#starting-agents). Tasks imported from a spreadsheet land in the **Inbox**, and so does a task added with **New task** unless you file it into a list. Only the pick-up list is taken from, so a run over a freshly imported task board starts nothing until you move those tasks into the pick-up list. ## Working copy and snapshots Versions belong to the workflow and include every recording, playbook, and task board attachment. Attached task boards stay live: snapshots do not freeze their tasks, fields, or settings. The workflow's title, description, and sharing also remain outside its versions. You edit the **working copy**. Saving updates it without increasing the version number. Creating a snapshot freezes that version and starts the next working copy with the same content. For example, snapshotting v1 leaves a read-only v1 and an editable v2. To freeze a known-good version: Click the **⋯** menu in the workflow header. An immutable copy of the current working copy is saved. Audimate prompts you to save first if you have unsaved edits. **Rollback to Snapshot** replaces the working copy's content with an earlier snapshot. Its version number stays the same, and existing snapshots remain available. Take a snapshot before letting [Arro Workspace Agent](/concepts/workspace-agent) rewrite a workflow's steps. Its edits save immediately, so a snapshot is your undo. It only ever edits the working copy, and declines to change a published snapshot. ### Default run version Runs use the working copy unless you pin a version. Once a workflow has at least one snapshot, the **⋯** menu gains **Default run version**: choose the working copy or a snapshot, and any run that does not name a version uses your choice. The menu item shows the current setting, for example **Runs snapshot v3**. Audimate keeps your edits in memory until you save, showing a **Saving...** indicator briefly when changes flush. Leaving with unsaved changes warns you first. ## Sharing | Where it lives | Who can open it | | ---------------- | --------------------------- | | **Private** | Only you | | **Team Library** | Anyone in your organization | | **Team space** | Members of that team | Sharing is always with people inside your workspace, and always with a group. There is no per-person share and no public link, so nothing in Audimate is reachable by holding a URL alone. Sharing a folder covers everything inside it, at any depth. Private means **not shared**, not sealed. A private workflow does not appear in a teammate's search results, document lists, or the pickers Arro uses, not even for an admin or the workspace owner. An admin can still [take ownership](#ownership) of any item, which is a deliberate, recorded step and never a way to browse. Move a workflow between Private and Team Library by dragging the file, or with **Move** in its right-click menu. Only the owner can take it back to Private. A workflow can also be exported as a **PDF** for anyone outside Audimate, on every plan. ### Ownership Every workflow, task board, and folder has exactly one **owner**: whoever created it, unless ownership has been handed over. Ownership is separate from access. Sharing a workflow lets people open and edit it, and does not make them owners. Making the file **Private** again is reserved for the owner alone, and no workspace role substitutes for it. **Transferring ownership is done by a workspace admin or the workspace owner**, not by the item's own owner. Open the share dialog, select **Transfer** on the owner row, then choose the new owner and confirm. The new owner must be a member of your workspace. Because an item has exactly one owner, the previous owner stops being the owner as soon as it completes, keeping only whatever was separately shared with them, which for a private item is nothing. It is an administrative action because it cannot be undone by the person who gave the item up. Only an admin or the workspace owner can transfer it back. Every transfer is recorded in the workspace [audit log](/account/audit-log), and if your workspace requires [2-factor for admins](/account/organization#require-2-factor-for-admins), the person doing it must have it enabled. Creating something grants you nothing on its own. Your name stays on it as a matter of record, but what you can open is what you have been granted. Admin and owner roles govern the workspace, not its files. See [Roles](/account/organization#roles). Two things sit outside that rule, both recorded: an admin can take ownership as described above, and when a member leaves, what only they could open is listed for an admin to [claim](/account/organization#what-happens-to-a-departing-members-work). ### Plan limits Workflows count against two separate caps. See [Workflow and task board limits](/account/organization#workflow-and-task-board-limits) for the full model. | What you do | Which cap it hits | If the cap is full | | ------------------------------- | --------------------------- | ------------------------------ | | Create a private workflow | Your own private cap | **+ New workflow** is rejected | | Move Private to Team Library | The org's shared cap | The move is blocked | | Move Team Library to Private | The **owner's** private cap | The move is blocked | | Take ownership of a private one | Your own private cap | The transfer is blocked | Plan caps follow the **owner**, so a transfer moves a workflow from one person's allowance to the other's. Changing a folder's access cascades to every workflow inside it. When unsharing a folder sweeps in workflows other people own, the message names the owner at their limit rather than blaming the person doing the unshare. Claiming an unassigned resource is the one exception: it is a repair action, so it is never blocked and can put you over your own cap. Otherwise, free up a slot in the destination pool or upgrade. ## Replay the tour A guided tour runs the first time you open a workflow. Replay it from the more actions (**⋮**) menu with **Restart tour**. ## Related The raw capture that feeds a workflow. Step-by-step instructions for you and for the agent. The tasks a run works through.