> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Flows: Automate Thread Routing and Actions in Inbox

> Use Flows to automate Inbox actions with if-this-then-that logic. Build triggers, route threads to Teams or Slack, and apply nested filter groups.

## Flows

Flows are the core of **Inbox automation**. They let you automatically trigger actions when threads meet specific criteria.

From the **Admin Panel**, you can create new flows or edit existing ones. Each flow is a set of conditions and actions — essentially, an **“If this → then that”** system.

## How Flows Work

A flow consists of **triggers** (conditions) and **actions** (what happens when conditions are met).

For example:

* **If** a thread is on the **Help Desk** OR **Sales** board
* **And** its status is not “New”
* **And** its status is not “Product Backlog”

**Then** the thread is automatically updated, assigned, or flagged based on the flow’s action.

This logic ensures the right tasks happen automatically without manual intervention.

## Actions a Flow can run

Actions are grouped under **Magic** and the ticket fields in the Flow Builder. A flow can run more than one.

| Action                                          | What it does                                                                                                                      |
| ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Set priority, status, board, agreement, or team | Update the ticket's fields when the conditions match.                                                                             |
| Assign                                          | Route the ticket to a member or team.                                                                                             |
| Reply · Note                                    | Post an external reply or an internal note.                                                                                       |
| Auto-Prioritize · Auto-Categorize               | Run the Magic AI classification on the ticket — see [auto-prioritization](/assistive-ai/how-to-set-up-auto-prioritization).       |
| Generate Title · Recap                          | Write the ticket title, or a recap from one of your [recap templates](/assistive-ai/magic-recap-template-library).                |
| **Run Skill**                                   | Run one of your saved Super Magic skills against the ticket.                                                                      |
| **New Super Magic Agent**                       | Run a prompt you write, unattended, on every matching ticket — and check the write tools it's allowed to use.                     |
| Call an On-Call Technician *(beta)*             | Page your on-call rotation by phone until a technician accepts. See [on-call escalation](/ai-agents/voice-ai-on-call-escalation). |

The last two are how a skill becomes an agent: the Flow is the trigger, the skill is the work. Because nobody confirms each step, the **write tools you check become the agent's scope** — leave them all unchecked and it can read and summarize but change nothing. See [Agents](/skill-library/agents) for the jobs worth running this way.

<Note>
  Flows are **event**-triggered — they run when a ticket changes. There's no schedule or timer, so a job that needs to run "every night" or "after N hours" stays a [skill](/skill-library/skills) you run on demand.
</Note>

## Creating a Flow

<Steps>
  <Step title="Navigate to Flows">
    Navigate to Thread Admin -> [Flows](https://admin.getthread.com/dashboard/flows)
  </Step>

  <Step title="Create Flow">
    Click **Create Flow** in the top right
  </Step>

  <Step title="Give your flow a name">
    Give your flow a name
  </Step>

  <Step title="Apply your filters">
    Apply your filters Filters will follow AND or OR logic. You can create and nest groups within your flow to create precise and powerful automations
  </Step>

  <Step title="Send threads to Companion App (Optional)">
    Send threads to Companion App (Optional) If you have a Teams or Slack Companion app installed, you can have the threads that match this flow sent right into a channel, or create a new channel per thread. This is great if you want to keep track outside of Inbox or prefer to work out of your chat app.
  </Step>

  <Step title="Set your Actions">
    Set your Actions Here we set what happens when the filter matches. You can add more than one action, so get creative with it!
  </Step>

  <Step title="Save your flow">
    Ensure your flow is toggled **ON** and click **Save** in the top right.
  </Step>

  <Step title="Your flow is active">
    Congrats! Your flow is active and ready to go!
  </Step>
</Steps>

## FAQs

<AccordionGroup>
  <Accordion title="Do flows apply to existing threads immediately?">
    No. Flows are **evaluated when a thread changes**, not retroactively — so a flow you just created only acts on a thread the next time that thread is updated.

    Thread re-evaluates a thread's active flows whenever the thread changes, whether the change happens **in Inbox** or is **synced in from your PSA**. Each time, Inbox checks every active flow's conditions against the thread and runs the actions on the ones that match — except flows whose actions already ran on that thread, since a flow's actions run at most once per ticket (see the next FAQ).

    **Examples of changes that re-evaluate flows:**

    * Sending a reply
    * Adding an internal note (recommended — a reliable, low-impact way to trigger evaluation)
    * Changing the status
    * Changing the board
    * Assigning or mentioning a member
    * Logging a time entry, or reopening a thread
    * Auto-dispatch assigning the thread, or a Magic Agent updating it

    <Note>
      PSA-synced changes rely on webhooks, which aren't 100% guaranteed. Rarely, a PSA update may be missed. Only **active** flows (toggled on) are evaluated.
    </Note>
  </Accordion>

  <Accordion title="Why did my flow run its actions only once on a ticket?">
    That's by design. A flow runs its **actions at most once per ticket**. Thread keeps re-evaluating the flow's conditions every time the ticket changes, but once a flow has executed its actions on a ticket, that flow is skipped for that ticket from then on.

    This prevents loops and duplicates: without it, a flow whose action updates the ticket would re-trigger itself, and a flow that posts a reply or pages on-call would do it again on every ticket change.

    Two things this limit does **not** apply to:

    * **Companion app channels.** A flow that sends threads to a Teams or Slack channel keeps sending updates to that channel as the ticket changes.
    * **Other flows.** The once-per-ticket rule is per flow. A different flow with its own conditions still runs its own actions on the same ticket.

    If you need the same job to run on a ticket again — for example, to retry a [Run Skill](/skill-library/agents) action — run the skill by hand in Super Magic on that ticket.
  </Accordion>

  <Accordion title="My skill works in Super Magic chat but does nothing when a Flow runs it">
    The usual causes, in order of likelihood:

    * **The skill's output is text, and text isn't posted.** In a Flow run, nothing the agent *says* lands on the ticket — the ticket changes only through the **write tools you check** on the action. A skill whose job is producing text needs a note write tool checked, and a prompt that says to post the result as an internal note.
    * **The skill isn't shared.** The **Run Skill** action only runs **shared** skills. A personal skill is skipped silently.
    * **The flow never fired, or already ran on that ticket.** Flows are event-triggered and run their actions at most once per ticket (see the FAQs above). Use [Flow Debugger](/skill-library/automation-and-flows/flow-debugger) to check.

    The full checklist, including what to look for on the ticket after a run, is in [Troubleshooting an agent run](/skill-library/agents#troubleshooting-an-agent-run).
  </Accordion>

  <Accordion title="What’s the difference between Status and Status Name?">
    * **Status** → Targets a single status on a single board.
      * Example: “Waiting Client Response” only on the **Help Desk** board.
    * **Status Name** → Targets status names across all boards.
      * Example: “Waiting Client Response” on both **Help Desk** and **Sales** boards.
  </Accordion>

  <Accordion title="What’s the difference between Owner and Member?">
    * **Owner** → The primary assigned technician.
    * **Member** → Includes both the owner *and* any additional assigned resources.

    Use **Owner** to target only the primary tech. Use **Member** to include secondary resources as well.
  </Accordion>

  <Accordion title="How do I test a flow safely before it runs on live tickets?">
    Thread does not have a separate sandbox or test-mode environment for flows. Flows always run against your live workspace. Use these techniques to test with low risk:

    * **Scope to a test board.** Add a **Board** filter so the flow only fires on a dedicated test board, then create a ticket on that board to trigger it. Widen the filter once the behavior is correct.
    * **Scope to a test client or contact.** Add a **Client** or **Contact** filter alongside your real conditions so only tickets from a chosen test account match while you iterate.
    * **Start with read-only actions.** Save the flow with only **Note** (internal note) or a **New Super Magic Agent** action that has no write tools checked. The flow will still fire and log what it would do, without changing ticket fields, replying to clients, or paging on-call.
    * **Trigger evaluation with an internal note.** Post an internal note on a candidate ticket to re-evaluate the flow — see the *Do flows apply to existing threads immediately?* FAQ above.
    * **Use a fresh ticket for each test run.** A flow's actions run at most once per ticket, so once your flow has acted on a test ticket, it won't act on that ticket again — create a new test ticket for each iteration.
    * **Keep the flow toggled off until you're ready.** Save with the toggle **OFF**, review the filters and actions, then flip it **ON** when you are confident.

    Only **active** flows are evaluated, and PSA-synced changes rely on webhooks that are not 100% guaranteed, so allow a moment for a triggering event to propagate before assuming the flow did not fire. Use [Flow Debugger](/skill-library/automation-and-flows/flow-debugger) if a flow does not behave the way you expect.
  </Accordion>
</AccordionGroup>

## Best Practices

* Use **internal notes** to reliably trigger flow updates.
* Use **Status Name** to apply flows across multiple boards.
* Keep flows simple; overly complex flows are harder to maintain and troubleshoot.

<Note>
  See **Flows** updates in the [changelog](/changelog/q3-2026).
</Note>

## Skills that use this

Let Super Magic build, debug, and bulk-edit your Flows.

<CardGroup cols={2}>
  <Card title="Flow Builder" icon="bolt" href="/skill-library/automation-and-flows/flow-builder">
    Design and build Flows conversationally.
  </Card>

  <Card title="Flow Debugger" icon="bug" href="/skill-library/automation-and-flows/flow-debugger">
    Figure out why a Flow isn't firing.
  </Card>

  <Card title="Flow Bulk Editor" icon="layer-group" href="/skill-library/automation-and-flows/flow-bulk-editor">
    Update many Flows at once.
  </Card>

  <Card title="Browse automation skills" icon="sparkles" href="/skill-library/automation-and-flows/overview">
    Every automation and Flows skill.
  </Card>
</CardGroup>


## Related topics

- [Catchall Routing](/skill-library/triage-and-routing/catchall-routing.md)
- [Set Up Thread Inbox by Service Team Structure](/inbox/service-team-structure.md)
- [Ticket Triage](/skill-library/triage-and-routing/ticket-triage.md)