As our Tines usage has grown, so has the complexity of keeping everything organized. I’m curious how teams that have been using Tines for a while approach structure at scale. Things like folder organization, naming conventions, shared resources, and knowing when to split a story into sub-stories. Would love to hear what’s actually worked in practice rather than just theory.
This is one of those things where every team lands on slightly different conventions, but a few patterns usually come up consistently.
Folder structure. Most teams organize by function or use case (incident response, identity management, IT ops) rather than by who built what. This makes it easier for someone to find a story when they need to troubleshoot or extend it, even if they didn’t build it. Some teams add a “drafts” or “staging” folder to keep work in progress separate from production stories.
Naming conventions. Agreeing on a naming pattern early saves a lot of friction later. A common approach is [Team/Function] - [What it does], like “IAM - Okta deprovisioning on termination.” The important thing is consistency across the team, not which specific format you pick.
Send to Story. This is probably the single most impactful pattern for maintainability. When you notice the same logic repeated across multiple stories (enriching an IP address, looking up a user in Okta, sending a formatted Slack message), pulling it into its own story and calling it via Send to Story means you only maintain that logic in one place.
Shared credentials. Centralizing credentials and using team-level resources instead of duplicating them per story keeps things cleaner and makes rotation less painful.
Docs cover Send to Story and shared resources in detail, and browsing the Story Library can be a useful way to see how modular, well-organized stories are put together.
Our main use is receiving alerts from a couple dozen different tools. As the webhooks, format decoders, Route, Priority, Enrichment logic was unique per tool, we separated most tools to their own story. Each creates or resolves ServiceNow Incidents, so we centralized the ServiceNow functions into its own story (StS).
We keep Alert state, and this logic was originally laid into each story. To make it more maintainable, we eventually put that in a central StS story as well. Then we encountered performance impacts; Alert State Keeper story became a major bottleneck. The compromise was to encapsulate its standard logic into a Group to be more conveniently replicated into each Story. Better isolation of flood impacts.
We mainly use tagging to classify/scope story types, which also helps our external AI agent know which stories to check for certain things.
Originally I was cramming all kinds of interesting snippets that I had tested or found into a single Sandbox story. Eventually I found I could create a Sandbox folder and keep each separately. Much easier to navigate than a giant story with flow fragments spread across a vast canvas. These days global searching is better. ‘Section’ is helpful to corral flow segments for larger stories into defined areas which are automatically indexed and provide rapid jump-to navigation–one of the many features new since we started.
Really digging that Sandbox folder approach. That’s a fantastic method to keep things structured and maintainable.
Thanks for sharing!