Output destination
- Standard term
An output destination is the place where a workflow saves its result for whatever comes next, such as a spreadsheet, a database, a file, a draft, a ticket, or a message.
A chat reply scrolls away under newer messages, so a result left there is hard to search, compare, or hand to the next step. A destination that keeps each result as a record, such as a dated row, builds a history that people and later workflows can sort, chart, and build on.
Where you’ll meet it
Every Monday your team's agent posts a summary of last week's sales in a busy team chat. At the quarterly meeting someone asks how March compared with February, and nobody can find the February numbers among a month of messages.
What to do
Keep the Monday post, since it still reminds people to look, and have the agent also add each week's totals as a new row in one shared spreadsheet, dated in the first column. Ask it to fill in the past weeks from the old chat posts.
Easy to mix up
| Output destination | Notification |
|---|---|
| No, it waits for the next step, person or program | Yes, it exists to catch a person's eye |
Check yourself
An agent drafts replies to customer emails every night. Where should the drafts go?
Go deeperRecords from a recurring run have to survive repeats, failures, and edits
Recurring work gets run again, sometimes twice by mistake, so each record needs an identity, such as the week's date, that lets a repeat run update the row it already wrote instead of adding a second. Engineers call that property idempotency.
A failed run should leave a mark as well, such as a row marked failed with its error. Otherwise a missing week looks the same as a quiet one, and a chart built on the sheet shows a dip that never happened.
Each record also carries where it came from and when, so a strange number can be traced back to its run. Who may edit the destination is part of the design, since a sheet anyone can edit holds records anyone can quietly rewrite.