Skip to main content

Send to Story Best Practice: “One In, One Out”

Implementing send to stories with "one in, one out"

Written by Jamie Gaynor
Updated this week

What is "one in, one out"?

One in, one out is a critical design best practice for building send to stories. It ensures consistency and prevents unexpected multiplication of subsequent actions in your stories. For send to stories, this principle mandates that for every single event that enters the story, only one single event should exit.

For more information on the send to story action, click here.

How to ensure "one in, one out”

To adhere to the "one in, one out" principle, you must merge all data back into a single event before the exit action.

The correct technical approach for branching and merging is:

  1. Use triggers: Set triggers at the top of each parallel branch to route the event correctly.

  2. Include conditional bypass: Implement a conditional bypass (like a "no match") for branches that do not execute.

  3. Use implode action: Feed the results of all branches and any conditional bypass paths into an event transform (implode) action.

    • The implode action should be configured to expect the total number of branches in your story to ensure it waits for all paths to complete.

  4. Format and exit: Route the single, consolidated output from the implode action to the final exit action.

This ensures that regardless of which branches ran, one consolidated event consistently exits the send to story.

Here is an example story you can import to your own tenant to help you understand:

If you need a hand importing a story, take a look at this article.

What happens if "one in, one out" isn’t adhered to?

If a send to story processes one incoming event but allows multiple events to reach the exit action (e.g., "one in, three out"), it leads to inconsistencies in the calling story:

  • Multiplication of actions: Any subsequent actions in the calling story will run once for every event that exits the send to story. For example, if three events exit, the next action (like an HTTP request to block a user) will run three times.

  • Unexpected behavior: When you use a send to story action, you expect one event with correlated information back. If you receive multiple, unexpected data streams (e.g. you have multiple exit actions), your flow is compromised, requiring you to account for unnecessary complexity further down the line.

Read more about send to story in our docs, here.

Did this answer your question?