Skip to main content
A workflow brings what a connected tool holds straight into Squad. Name it, say what it covers, switch it on. There is no brief to write. Most capture as things happen, so there is no schedule to pick either. The card tells you which kind you are switching on: As it happens for the ones that wait on the tool, Keeps up to date for the repo scan, which reads the repository when you install it and tracks it from then on. An agent reasons. A workflow does not. An agent reads what you gave it and decides what to do, which is what you want for research and reports, where a wrong answer costs you a paragraph. Ingestion is different. A customer’s support ticket should reach your signals whether or not a model felt like fetching it that morning.

​
Switching one on

Open Agents in the sidebar and go to the By Squad tab. Workflows sit in the same gallery as the agent templates, with the provider’s logo on the card and how often it runs where a cadence would be. A workflow card carries one button, Set up. There is no cog beside it, because a workflow has no brief to open and edit.
Setting up a workflow

Pick a workflow

Click Set up on the card. Every workflow is on the tab whether or not you have connected the tool behind it. Pick one you have not connected and the modal offers Connect for that provider right there. Tools that ask for a key collect it in the modal and drop you straight back on the form. Tools that sign you in on their own site send you back to this card with the modal still open. Jira ends on its settings page instead, because it needs you to choose which service desks Squad watches before it can bring anything in.

Name it

The name is prefilled and yours to change. It is what you will scan for in the list, so name it after what it covers rather than the tool it came from.

Set the scope

Each workflow asks for whatever it needs to know what is yours. Leave it empty and you get everything the connection can see. Gong calls skips this step, because the automation rule you wrote in Gong is already the filter.

Switch on

It starts immediately. For the capturing workflows, nothing that arrived before this moment is backfilled.
You can run several instances of the same workflow. Two Jira workflows over two different sets of projects, each named for the team that cares about them, is a normal setup. Set up stays on the card once one is running, and the card badges how many you have. Take the prefilled name twice and the second becomes “Jira requests 2”, so the list never shows you two rows you cannot tell apart.

​
What you can switch on

Jira requests

Every new service desk request, with its comment thread, as it is raised. Scope it to the service desks you pick, or leave it empty for every service desk the connection is monitoring.

Fellow meeting notes

Meeting notes and their transcripts, as Fellow finishes them. Scope it by words in the meeting title, so “discovery” and “renewal” come in and your one-to-ones stay out.

Gong calls

Call transcripts with speaker names, as Gong finishes recording them. This one has no scope to set: your Gong automation rule already decides which calls get sent.

GitHub issues

Issues people open, with their comment threads. An issue also comes in when it is reopened, so an older one joins the moment it comes back into play. Scope it to the repositories you pick.

Repo scan

Reads one repository and writes up what the product does, capability by capability, into your knowledge base. Reads it when you install it, then corrects what merged code has made wrong.
Fellow’s scope is worth setting. Its trigger fires for every meeting the connected user attends, so an empty list pulls in one-to-ones, interviews and board calls alongside the customer calls you wanted.
GitHub’s scope is worth setting too. An empty repository list means every repository the install can see, private ones included, and installs are often set to All repositories on the whole account.

​
Reading what happened

Workflows appear in the Agents tab alongside your agents, with what they have captured and when they last did. Open one and the page is mostly its history. The repo scan reads differently: it writes documents rather than capturing items, so its history is a record of what merged and what it rewrote, and the documents themselves are in your knowledge base.
A workflow's capture history
Every attempt is a row, and there are three kinds.
It arrived and is in your feedback. The title links out to the item in the tool it came from, when the provider has a web view for it. A repo scan uses this row for the other direction. A merge that changed files your documents describe says how many documents are waiting, and a finished rewrite says how many parts it corrected and at which commit.
It was outside the scope you set. On a narrowly scoped workflow this is most of the list, and that is the workflow doing its job. On a repo scan it means a merge landed and touched nothing you have documented, or a rewrite ran and found nothing worth changing.
Something went wrong, and the row says what. A transient failure is retried; a permanent one is not.
This history is the answer to “why is nothing arriving”. A column of skips means the scope is narrower than you thought. A column of failures usually means the connection broke.

​
Running one by hand

Most workflows wait on the tool and give you nothing to press. The repo scan is the exception, because keeping documents current is work you sometimes want done now. Refresh appears in the header when the Freshness row says documents may be out of date, and rewrites the flagged parts immediately rather than leaving them for the overnight sweep. Scan the whole repository again lives in the ⋯ menu. It asks you to confirm first, since a full re-read costs what the first scan cost and nothing on the page moves while it works. Starting either one disables both until it finishes, so an impatient second click cannot buy a second run.

​
Pause, resume, delete

Pause stops new items arriving and keeps everything else. Nothing is captured while it is paused, so this is a real off switch rather than a filter on the view. Resume starts it again, and the gap is not backfilled. Deleting removes the workflow and its history. Everything it already captured stays in your feedback, because those are signals now and they belong to your workspace rather than to the workflow that fetched them.
A workflow shows Error when its connection stops working. The page says what broke and offers Check connection and Retry. Reconnect the provider on Integrations first, then retry. A repo scan whose repository has dropped out of the GitHub install lands here too, and says so. Put the repository back in the install, then retry.

​
Workflows and agents together

Use both. Run a workflow to get the raw material in reliably, then point an agent at the insights it feeds, or at the goals those insights move. The workflow guarantees the evidence arrives. The agent is what has an opinion about it.