Now that you know how to build individual sub-stories, let's talk about architecting larger systems with multiple stories and send to story connections. This is where send to story really shines, enabling you to build sophisticated, maintainable workflows.
Why modular architecture matters
Modular architecture helps you organize complex automations into small, reusable building blocks. Instead of repeating a pattern in several stories, you build it once, enable it as a sub-story, and call it using send to story. The benefits of modular architecture are:
Maintainability: Fix logic in one place instead of multiple copies. When you need to update how IP enrichment works, you update one sub-story instead of hunting through 10 different stories.
Reuse: Share core workflows across teams without rewriting.
Clarity: Keep parent stories readable by delegating detailed logic.
Scalability: Build new workflows faster by combining existing sub-stories.
Layers of abstraction
Well-designed systems often have layers. Each layer has a specific responsibility, making your system easier to understand and maintain. Send to story works the same way!
Orchestration layer (parent stories): These coordinate high-level workflows, calling sub-stories and managing the overall process. They focus on the "what" and "when," not the "how."
Logic layer (sub-stories): These perform specific tasks like enrichments, lookups, calculations, and formatting. They focus on the "how" of a single operation.
Integration layer (sub-stories): These handle interactions with external systems like API calls, database queries, and third-party services. They abstract away the complexity of working with specific tools.
ℹ️Info
Send to story build patterns
Here are some proven patterns for organizing sub-stories in larger systems.
Hub and spoke pattern
One central orchestration story (the hub) calls multiple specialized sub-stories (the spokes). Each spoke does one thing well.
When to use: When you have a clear main workflow with multiple independent operations.
Example: A "Process security alert" parent story (hub) calls multiple specialized sub-stories (spokes):
"Enrich IP address" (gets threat intelligence)
"Check user risk score" (queries HR and past incidents)
"Determine severity" (calculates alert priority)
"Notify appropriate team" (routes to the right responders)
Each spoke is independent and can be updated without affecting the others.
Library pattern
A collection of utility sub-stories that many parent stories can call as needed.
When to use: When you have common operations used across many workflows.
Example: Your team maintains a library of utility sub-stories:
"Format timestamp" (converts dates to standard format)
"Parse email headers" (extracts sender, recipient, subject)
"Lookup user by email" (queries your directory)
"Send Slack notification" (standardized messaging)
Any parent story across any team can call these utilities, ensuring consistency and reducing duplicate code.
Nested pattern
Sub-stories that call other sub-stories, creating multiple levels of abstraction.
When to use: When you have complex operations that benefit from further decomposition.
Example: A "Full phishing investigation" sub-story calls other sub-stories:
Calls "Analyze email" sub-story
Which calls "Extract URLs" sub-story
Which calls "Check URL reputation" sub-story
Calls "Generate report" sub-story
Which calls "Format findings" sub-story
Each layer adds abstraction, making complex operations manageable.