Send to story (StS for short) is an action type that lets one story (the parent) call another story (the sub-story) and receive data back. It's Tines' native way to create modular, reusable workflows.
Think of it like delegating a task to a specialist. When you need expert help with something specific, you hand off the work to someone who specializes in that task, they complete it, and then return the results to you. You then continue with your work using what they provided.
That's exactly how send to story works. The parent story sends data to the sub-story, the sub-story runs its logic, and then returns a result. The parent story continues its workflow using that returned data.
A send to story example
Imagine you have a workflow that requires looking up employee details from your HR system. Instead of building that lookup logic into every story that needs it, you create one "Get employee details" sub-story. Then, any parent story can call that sub-story, send it an employee ID or email, and get back their full information.
Here's what that looks like in practice:
Parent story: "Process access request"
Receives an access request via a Tines page.
Extracts the employee's email address.
Calls "Get employee details" sub-story with the email.
Receives the employee's department, manager, and role from the sub-story.
Routes the request to the appropriate approver based on their department.
Sub-story: "Get employee details"
Receives an employee email from the parent story.
Queries your HR system (Workday, BambooHR, etc.).
Formats the employee data consistently.
Returns the employee's full details to the parent.
When to use send to story
Now that you understand what send to story is, let's talk about when you should use it. Recognizing these patterns will help you build more maintainable and scalable workflows:
You're copying and pasting actions between stories: This is the most obvious sign. If you find yourself duplicating the same 10-action sequence across multiple workflows, that's a perfect candidate for a sub-story.
Multiple teams need the same logic: When different teams need to perform the same operation, a shared sub-story ensures consistency and reduces maintenance burden.
A story is becoming unwieldy: If your story has many actions and you're struggling to follow the logic, it's time to break it into focused sub-stories.