As your workflow needs become more sophisticated, you'll encounter situations that require handling different outcomes based on specific conditions. This is where the story fork (also called branch) design becomes essential.
When to use story forking
When your workflow needs to handle different cases or scenarios.
For implementing "if-then-else" logic in your automations.
When different types of data require different processing paths.
For approval workflows where human decisions affect the process.
When you need to handle errors or exceptions differently from successful operations.
Common story forking patterns
Simple if/else: Basic two-path branching based on a single condition.
Multi-condition routing: Series of triggers to route to multiple destinations.
Error handling: Separate paths for successful operations vs. errors.
Approval workflow: Different paths based on approve/reject decisions.
Data validation: Branching based on whether data meets quality requirements.
Understand the Trigger action
While not a requirement for story forks, the Trigger action is your primary tool for creating them in Tines:
How it works: A trigger evaluates a condition and creates two possible paths.
Condition types:
Simple comparisons (equals, contains, greater than).
Existence checks (is present, is blank).
Regular expression matching.
Complex logical combinations (
AND,OR).
Outcomes:
"True" path: Events that run when the condition is met. This path is visualized with the solid connector line from the Trigger action.
"False" path: Events that run when the condition is not met (optional). This path is visualized with the dotted connector line from the Trigger action.
Practical trigger example
Let's examine a practical example: Customer Support Request Router
1. Receive Support Email (Receive Email)
↓
2. Extract Request Details (Event Transform)
↓
3. Is it a billing question? (Trigger)
↓ ↓
Yes No
↓ ↓
4. Forward to 4. Is it a technical issue? (Trigger)
Finance Team ↓ ↓
(Send Email) Yes No
↓ ↓
5. Create Tech 5. Forward to
Support Ticket General Support
(HTTP Request) (Send Email)Multiple forks and conditions
There are two primary designs when it comes to forks and triggers:
Cascading triggers
A story fork with cascading triggers is ideal for validation checks. For example, let's take a look at an employee onboarding story that utilizes cascading triggers:
An example of the cascading trigger design.
Notice how the story flows into each trigger and does a check on the department value before moving forward to the next action/trigger check?
Parallel triggers
A story fork with parallel triggers is ideal for scenarios where the data passing through is being categorized. For example, let's take a look at the employee onboarding story that utilizes parallel triggers:
An example of the parallel trigger design.
See how the story utilizes triggers to categorize the employee's department and handle the event flow depending on the value?
When should I use each trigger design type?
See how we built essentially the same flow with different trigger designs? That's on purpose! While both options are almost identical in technicality, the decision is ultimately up to you and your team to decide on what design fits best for your workflows.