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 can draft it once and write it to all of them in the same keystroke.

For product owners and business analysts who announce the same thing in several tools. macOS and Windows, menu-bar app.

The writing took four minutes,
the distribution took twenty

Nobody struggles to write “we are dropping guest checkout from this sprint and here is why”. What costs the afternoon is that the sentence has to exist in three tools, each with its own tab, its own formatting habits and its own way of being forgotten. So the Jira comment gets written, Slack gets a shorter version an hour later, and the decision log gets nothing at all until someone asks in the retro why the scope moved. The problem is not writing. It is distribution.

Three tabs, by hand

Three versions of the same decision, each drifting from the others.

The last destination is the one that gets skipped when something urgent lands.

No record of where the announcement actually went.

One parallel step

One text, drafted once, written to every destination unchanged.

Nothing gets skipped, because skipping would mean editing the workflow.

You get back the links to all three, ready to paste.

What the step looks like

One input, up to four destinations, no order between them.

The update your agent just drafted
All at the same time

Jira

Comment on AUTH-112

Slack

Post to #squad-checkout

Confluence

Append to Decision log

Back to you: one line per destination, with its link

Building it, once

Five minutes in the editor, then it is a keyboard reflex.

  1. Start with the agent that writes the update once

    Build a workflow the usual way: it starts from the text you have selected, and its first step is an agent that turns your rough refinement notes into the update you actually want to publish. This is the only part where wording is decided, which is precisely why the three versions that used to drift apart no longer can.

  2. Add a parallel execution step instead of 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, then one column per destination, then a bar where they rejoin, with a small “all at the same time” label. You are not reading a description of the behaviour, you are looking at it.

  3. 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. Click one and only that card’s fields open, one level below. A destination you have not finished configuring keeps a dashed border and says Choose a target, and the workflow will not save until every one of them is answered.

  4. One run, every destination at the same instant

    When the step runs, all of 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. Nothing about launching it changes. It is the same palette entry, or the same keyboard shortcut you gave the workflow, from whatever app you happen to be in.

  5. You get back the list of what landed where

    The step produces one line per destination, each with the key or URL that was created, so a closing paste step drops the whole set of links into the document or message you were writing. Worth knowing before you build a longer chain: 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, where it matters.

A PO’s Tuesday, ten minutes after refinement

The call ends at 11:40 and guest checkout has just moved out of the sprint. In your notes you have four scrappy lines: the trigger, the impact on the release date, who agreed, what happens to the two tickets already started. You select them and press the shortcut on the workflow you built once, called “Announce a scope decision”. The agent turns the four lines into a short, complete note. The split then writes that note as a comment on the epic, as a post in the squad channel and as an appended entry in the decision log, at the same moment. By 11:42 the paste step has dropped the three links into your notes, and the decision is on the record in every place someone will look for it. For the drafting half of that reflex, see writing to Jira from anywhere, and for chains that transform text step after step rather than broadcast it, see the workflow builder.

What happens when a destination fails

Writes to other people’s tools cannot be undone, so the step is built around that fact.

A failed destination never rolls back the others

The writes that succeeded are already in your tools and cannot be taken back. So one failure does not 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 MCP 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 destinations

Any of the writes you have switched on from the integrations page: opening or commenting on a Jira issue, creating, commenting on or appending to a Confluence page, opening a Linear issue, creating or appending to a Notion page, posting to Slack, drafting an email in Gmail. You connect each tool once, with credentials that stay in your system keychain, and every one of those writes is then available both as a single workflow step and as a destination inside a parallel one. If you are still deciding what to connect, the integrations walkthrough covers what each one adds to the palette.

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 have 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 is 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 cannot 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 is 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 are not model calls: they are writes to tools you have 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 does not eat the room you need for the rest of the chain.

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-keystroke 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 keystroke.