Tines story library has over a thousand pre-built examples of Tines in action to accelerate your story building or fuel your imagination on what to build next. These are built by the folks at Tines, and builders who use Tines every day.
Note: You can tell us your ideas for a story, or if you would like your own story featured in our library, submit a copy of it here.
When you're ready to submit a story, here are some tips on how to prepare your story for upload to the library:
Be clear
Edit your story
Make it easy to follow
Be clear
Story name
The story name should make clear what the story does, without being verbose.
You should start with a verb, and highlight the tool(s) used. If a lot of tools are used, this can be changed to “multiple tools” or similar.
Examples of good story names:
- Triage emails with Sublime Security in Slack
- Update Slack Status based on Zoom Meetings
- Reserve IPs for new hosts in Infoblox NIOS
- Respond to alerts from various tools with the AI Agent action
Description
The description panel should outline the main purpose of the story and include a brief description of the story, giving a high level overview of what it does. This should be written in plain text.
Examples of good descriptions:
Receive security alerts from various products and agentically create a case with enriched IOCs and suggested actions. Use agents triggered by case actions to complete the actions and update the case.
Automate Pull Request reviews in GitHub using the AI Agent action. When a review is requested, the system analyzes the changes, generates relevant comments, and posts them for the submitter. Optionally, an AI chatbot can be used to perform a comprehensive review.
Enrich a company when it is added to an Airtable database. Receive a webhook notification when a new record is added and fill out the remaining fields with web searches powered by Tavily.
Edit your story
Before exporting your story, make sure to review it so you’re not sharing any internal details or personal information.
Monitoring
Many times, the monitoring tab is auto-populated with an email which can lead to spam emails from users who later import a story. If this isn't cleared before submission, it will be removed before the story gets published to the library.
Scheduling
Ensure no actions have scheduling enabled so stories aren’t running without a user’s explicit knowledge. If stories should run on a schedule, remember to add a note to the storyboard so people know to enable this.
Security first
Never hard-code emails, IDs, or credentials. Use Resources or "Pills" so the story is ready for anyone to use immediately with their story’s data.
Action naming & cleanup
Be descriptive: Give every action a name that explains its purpose (e.g., "Send a Slack message" instead of just "Message").
HTTP requests: Include the tool name in the action title.
cURL cleanup: If you paste a cURL command, remember to delete the default "Created from cURL command" description.
Action simplicity & logic
The goal is to make automations easy to follow and modify.
Keep formulas simple: If a formula is getting too complex, split the functions into LOCAL fields or multiple actions.
Use placeholders: When using "Pills" for values like domains or IDs, add a note next to the action to guide the user on what they need to update.
Credential metadata: For domains or IDs specifically linked to credentials, set those values directly in the credentials metadata.
Make it easy to follow
The layout of your story is important to help new users understand the overall flow and order of events.
Use the space
Avoid the congestion of elements on the storyboard. The connectors between the actions are enough for our builders to know what is next in the flow. See the heavy congestion to the left.
Let it flow
Think about a grid system, row by row, column by column, everything should slot straight into place and on the right level, actions and notes included.
With more actions and notes, stories can certainly become overwhelming, especially in a larger story.
Floating singular actions
Some stories have actions that have a singular mechanic in what they do and live alongside a story. We recommend that you sign post those with a note, in order to draw attention and for new builders to understand this isn't a mistake in the story.
Notes
Every story should have at least two notes present:
Overview
Requirements
Overview
The overview note should explain the purpose of an automation and how it works. It should be more in-depth than the story metadata description.
Requirements
Every story has it's own level of requirements that could contain: Credentials and Resources. These can be kept in the same note with each item under the sub heading. Checkboxes work nicely here for out requirement too. Ensure details for credential metadata is also provided under each credential.
Note alignment & visual hierarchy
We recommend aligning the top edge of a note with top edge of an action. It seems like a small thing, but it will help your grid feel a lot more concise and from a zoomed out perspective, feel less messy.
The words in notes hold a lot of the untold nuances of our stories. If things aren't clear, it can be super challenging especially while learning a new tool. It can be very tempting to write large notes to get everything down, but this can cause visual chaos and could be slightly overwhelming to builders.
Instead:
Lead with a captivating title - Use H1 for your Leading header and for breaks in sections within a note
Use Body text for paragraphs
Highlight words with bold text
For formula and code use the code snippet markdown
When using links be sure to give it a title instead of the url itself to clean it up.