One draft, three destinations
A parallel step isn't three steps in a row. Every branch receives the same text at the same instant, so the step takes as long as the slowest tool rather than the sum of all three.
One decision, three placesit has to land
Refinement ends and the same scope change now has to reach the epic in Jira, the squad channel in Slack and the decision log in Confluence. Written three times, it comes out three slightly different ways. A Khint workflow drafts it once and writes it to all of them in the same shortcut.
The writing took four minutes,
the distribution took twenty
Three tabs, three tones, three slightly different versions of the same decision, and no way to tell later which one the team actually read. A fan-out step keeps the wording in one place and puts a link to each destination in your hands.
KhintPalette
Sprint 24
/
Workflows
A real workflow with a fan-out: one draft, three destinations, dispatched at the same instant.
Building it, once
Five minutes in the editor, then it's a keyboard reflex.
Start with the agent that writes the update once
Build a workflow the usual way: it starts from the text you've selected, and its first step is an agent that turns your rough refinement notes into the update you want to publish. This is the only place wording is decided, which is precisely why the three versions can no longer drift apart.
Add a parallel execution step, not three steps in a row
In the workflow editor, next to Add agent, there is Parallel execution. Where a normal step is a single box on the rail, this one draws as a visible split: a tie bar, one column per destination, then a bar where they rejoin. You aren't reading a description of the behavior, you're looking at it.
Pin each destination once
A destination card shows the tool’s logo, what it does and where it writes: Comment on Jira issue · AUTH-112, Post to Slack · #squad-checkout, Append to Confluence page · Decision log. One you have not finished configuring keeps a dashed border, and the workflow won't save until every one is answered.
One run, every destination at the same instant
When the step runs, all the destinations receive the same text and are dispatched concurrently, not one after another: the step takes as long as the slowest tool, not the sum of all three. Launching it doesn't change — the same palette entry, or the shortcut you gave the workflow, from whatever app you're in.
You get back the list of what landed where
The step produces one line per destination with the key or URL that was created, so a closing paste step drops the whole set of links into what you were writing. Worth knowing before you build a longer workflow: a step placed after the split reads that list of links, not the text that went in. The editor prints that rule at the rejoin bar.
One step, three tools
How the split is drawn, what a failing branch does to the others, what the run actually costs, and what the next step reads.
Comment on AUTH-112
Append to Decision logA failure never rolls back the others
A comment that already landed in Jira can't be un-landed, so one branch failing doesn't abort the run. The failure is written next to the successes and you redo that one.
Three writes, one model call
Credits are spent on model calls, and a destination isn't one. The whole fan-out also counts as a single step against a workflow's five.
The step after the split reads the links
Each branch returns the key or URL it created, and that list becomes the running text. An agent placed after the rejoin is reading receipts, not the draft that went in.
What happens when a destination fails
Writes into other people's tools can't be undone, so the step is built around that fact rather than pretending otherwise.
A failed destination never rolls back the others
The writes that succeeded are already in your tools and can't be taken back. So one failure doesn't abort the run: the workflow finishes, the status pill counts the successes against the total, and a notification tells you a destination is missing rather than leaving you to discover it in the retro.
The failure is written next to the successes
The result list carries the failed destination with its reason on its own line, in the same block as the links that worked. You redo the one that failed instead of re-running everything and creating a second copy of the two that already landed.
Two to four destinations, all of them writes
The step is deliberately narrow. Destinations are writes to your connected tools, never agents: parallel agents would produce several pieces of prose and no rule for merging them back into one text, whereas a set of links joins cleanly every time.
A paused integration says so, in that branch
If you have paused an integration on the Integrations page, its destination fails with a message naming the tool and telling you to re-enable it, rather than failing silently or taking the whole workflow down with it.
Which tools can be
a destination
Any write on a tool you've connected can be a destination. The one rule is that it has to return one addressable result, which is why a chat with Claude is deliberately not on the list: it hands back a whole text rather than a link.
See the integrationsJira · open an issue, or comment on one
Confluence · create, append to or comment on a page
Linear · open an issue
Notion · create a page, or append to one
Slack · post to a channel
Gmail · draft an email
Mix any of them inside the same step
Never a chat step: it returns text, not a link
The rest of Khint
The fan-out is one step of five. These three are what surrounds it.
Common questions
How many tools can a single step write to?
Between two and four. Each destination is one integration write, and you can mix them freely across the tools you've connected: open a Jira issue, comment on a Jira issue, create, comment on or append to a Confluence page, open a Linear issue, create or append to a Notion page, post to Slack, or draft an email in Gmail. One destination that's deliberately not allowed is "Chat with Claude", because it hands back the whole text rather than a link, and the point of this step is that every destination returns one addressable result.
What happens if one of the destinations fails?
The others keep their result. A write that already landed in Jira can't be un-landed, so aborting the run would only destroy your record of what did go through. The workflow carries on, the status pill reads something like "2 of 3 destinations · 1 failed", you get a notification, and the failure is written into the result list next to the successes so you know exactly which one to redo. The step only counts as failed when every destination failed, since there's then nothing partial left to protect.
Does writing to three tools cost three times the AI credits?
No. Credits are spent on model calls, and the destinations aren't model calls: they're writes to tools you've connected. The AI cost of the workflow is the agent that drafts the text before the split, exactly as it would be if you posted the result in one place. The whole fan-out also counts as a single step against a workflow's five-step limit, so it doesn't eat the room you need for the rest of the workflow.
Can I choose the destinations at run time instead of pinning them?
Not in a workflow step. The Jira issue, the Slack channel and the Confluence page are pinned once in the editor, which is what makes the step a one-shortcut reflex for destinations that repeat every sprint: your epic, your squad channel, your decision log. For a one-off destination that changes each time, use the integration rows in the palette or describe what you want in the idea bar, both of which ask you where to write on each run.
Announce it once, everywhere
Free with 300 credits a month, about 10 AI actions a day. No credit card. Build the workflow once and let the next scope decision reach every tool in one shortcut.