Story syncing
Some sophisticated deployments of Tines call for managing stories centrally, but having them run in a variety of different teams or even tenants, for example:
MSSPs often maintain consistent stories for end-customers, but each customer runs in their own team with segregated credentials, etc.
Multi-region deployments: deploy centrally-managed stories to tenants in different regions, for compliance with data residency requirements.
Story syncing is the solution to problems like these.
Prerequisites
Story syncing can only be managed by tenant owners. The management UI can be found in the main settings sidebar, as ‘Story syncing’, within the ‘Access & security’ sidebar section.
In order to be used in story syncing, stories must have change control enabled. By default, when changes are published to the live version of the story, they will be automatically synced to all destinations, unless the destination has Auto-sync mode disabled.
When there are pending changes for a story in the destination and auto-sync is disabled, changes must be manually synced via the Sync button.
Creating sync destinations
When first accessing the story syncing UI in settings, a blank state will be shown. Hit ‘Get started’ to create your first sync destination.
In order to configure a sync destination, the following details must be provided:
the team to sync from,
the tenant and team to sync to,
a Tines API key, if syncing to a remote tenant,
which stories should be synced,
and the syncing mode for the destination - by default, destinations are set to automatically sync.
Once you save your first sync destination, it will be synced immediately and will continue to sync on an ongoing basis as the selected stories are updated - provided auto-sync mode is enabled. When auto-sync is disabled, stories will only sync when first added to the destination. This means that when setting up a new destination, stories will sync immediately, but updates to stories already in the destination will not be synced - only stories newly added to the destination will trigger a sync.
Managing sync destinations
Once one or more sync destinations have been created, the dashboard will show them and their statuses – including surfacing any errors (e.g. when networking to a remote tenant) that are preventing sync from operating.
When you select an individual destination, you can edit and delete existing sync destinations, and also run a manual sync – handy for debugging problems such as networking errors.
When deleting a sync connection, there is a possibility to choose whether to keep or remove the synced stories on the destination tenant. Check “Keep synced stories in destination” to detach the stories from the sync source and preserve them as independent stories. If keeping the stories would exceed your destination tenant’s usage limits, they are automatically disabled. Leave it unchecked to delete all synced stories from the destination (the previous default behavior).
Detaching from sync
In certain circumstances, "detaching" a story from sync may be required. For example, if you no longer want the story to be centrally managed, but instead customized and locally managed in the destination team.
To achieve this, navigate to the story in the destination team and choose 'Detach from source' in the story toolbar.
Data segregation & security
Only stories themselves are synced. Objects such as credentials and resources are deliberately not synced – you'll need to set these up on the destination side. Think of objects like these as ‘environment variables↗’ – they allow the centrally-managed story to run securely in its destination context, with the appropriate local secrets and context established.
Story syncing mechanics
Records
When syncing stories that use records, the record types are automatically created on the destination team if they don't exist. If a record type with the same name already exists on the destination, Tines will update or create a new record type based on the schema changes:
Adding fields: If you add new fields to a record type on the source story and sync it, the existing record type on the destination will be updated with the new fields. This preserves any existing record data and history.
Removing or changing fields: If you remove fields or change field types (e.g., TEXT to NUMBER), a new record type with sequential naming will be created (e.g., "Alert" becomes "Alert (1)"). This prevents data loss and maintains backward compatibility.
Licensing
Only the source/synced stories and flows↗ count towards your plan limits. You can sync to as many destinations as you like, without paying additional costs for those stories or flows.
API
Sync destinations can additionally be entirely managed via our API. See our sync_destinations API docs for full details.