Tines stories can be migrated from non-production tenants to production tenants. This article outlines the procedures to do so, including both manual migration steps and automated change management setup for multi-tenant architectures.
Automated migration through a Tines Story
Tines Stories offers a migration workflow that manages the promotion of stories from a non-production tenant to a production tenant using the Tines Stories API. It is important to note that although most Tines Stories components can be automatically migrated, there are limitations to the API.
This automated approach is ideal for the story migration workflow itself, ensuring consistency and reducing human error. In the following section, we'll walk through the process of setting up an automated story migration system.
Automatic migration
Stories
Records
Actions
Resources*
Private Templates
Manual migration required
Credentials
Resources*
Case Fields
Case Settings (statuses, priorities, sub-statuses)
* Note: Resources may contain environment-specific data that differs between non-production and production. For domains, best practice is to use metadata within the credential instead of a resource. If values are the same across environments, nothing needs to be done and migration can be handled automatically.
Steps to set up dev to prod tenant migration story
Import this story from the Tines story library into your non-production tenant.
Add your
dev_tenant_api_keyto the Tines story. This is the API key for your non-production Tines Stories tenant.You should include the non-production tenant domain as metadata.
Add your
prod_tenant_api_keyto the Tines story. This is the API key for your production Tines Stories tenant.You should include the prod tenant domain as metadata.
Optional - add a resource called
prod_tunnel_name. This is the name of the tunnel used in the production tenant. The story will automatically update any HTTP request actions using a tunnel with the proper production name. Only applicable if tunnels are used and the tunnel naming convention is different between tenants.
Manual migration required
While many Tines Stories components can be transferred automatically between tenants using stories, certain elements require manual migration. The following items cannot be pushed to a production tenant through automated workflows and must be configured directly in the target environment.
1. Credentials migration
Why manual migration is required
Credentials contain sensitive data that cannot be read via the Tines Stories API and therefore cannot be automatically created or updated within the migration workflow. The workflow does include steps to compare credentials in the non-production and production tenants and will list which need to be created or updated based on the naming.
Best practice is to have the credentials in the production and non-production tenants have the same name with differing environment-specific values (e.g., API endpoints, authentication tokens). Non-production credentials point to non-production systems, while production credentials must point to production systems.
Steps to migrate credentials
Before migration (Non-Prod)
Navigate to Credentials in the non-production environment
Document all credential names (exact spelling and capitalization matter)
Ensure credential names follow a consistent naming convention
Important: Avoid environment-specific names like "tines non prod" - use generic names like "S1" or "ServiceNow"
During migration (Prod)
Navigate to Credentials in production
Create new credentials with identical names to non-production
Use production-appropriate values (prod API endpoints, prod tokens, etc.)
Verify each credential is properly configured
After migration
When stories are promoted, they will automatically connect to credentials with matching names
If names don't match, you'll see "reconnect" or “replace” warnings in actions
Test each credential connection in promoted stories
Credential naming best practices
✅ Best Practice:: S1, ServiceNow, Cribble, Zscaler
❌ Avoid: tines non prod, S1 dev, ServiceNow test
2. Resources migration
Why manual migration might be required
Resource values may need to differ between environments (ServiceNow state mappings, environment-specific configurations). The workflow will automatically create and update resource values so if resource values need to be different between tenants, DO NOT have them be named the same.
Steps to migrate resources
Assessment Phase
Navigate to Resources in non-prod
For each resource, determine if values should be:
Identical between environments (queries, mappings that don't change) → Nothing needs to be done.
Different between environments (ServiceNow state mappings, environment-specific configurations) → Follow steps below.
Migration Steps
Navigate to Resources in production
Create new resource with different name from non-production
Modify values as appropriate
At the bottom of each resource, configure team sharing if needed:
Check which teams should have access
Example: Share Security Engineering resources with Security Operations
Once story is migrated, replace the non-production resource with the production resource
Resource Sharing
Resources live within a team but can be shared:
Open the resource
Scroll to bottom
Check boxes for teams that need access
Example: Security Engineering can share resources with Security Operations
3. Case fields migration
Why manual migration is required
Case fields are tenant-level configurations that don't transfer with stories.
Steps to migrate Case fields
Documentation phase (Non-Prod)
Navigate to Cases → Case Settings → Fields
Document all fields currently configured:
Field name (exact spelling)
Field type (text, number, timestamp, boolean, etc.)
Any special configurations
Migration phase (Prod)
Navigate to Cases → Case Settings → Fields
Click New Field for each field
Enter exact field name (must match non-prod)
Select appropriate field type
Configure any additional settings
Repeat for all fields
Important notes
Field names must match exactly between environments
Fields are used across all case types (not application-specific)
Purple highlighting in cases indicates field mapping from different sources
4. Case settings migration
Why manual migration is required
Case settings (statuses, priorities, sub-statuses) are tenant-level configurations.
Steps to migrate case settings
Statuses
Navigate to Cases → Case Settings → Status in non-prod
Document all custom statuses beyond default Tines Stories statuses
In prod, navigate to Cases → Case Settings → Status
Add each custom status with identical naming
Priorities
Navigate to Cases → Case Settings → Priority in non-prod
Document all custom priorities
Recreate in prod with identical naming
Sub-statuses
Navigate to Cases → Case Settings → Sub-Status in non-prod
Document all sub-statuses and their parent statuses
Recreate in prod with identical configuration
Tags
Document all case tags used in non-prod
Create matching tags in prod before promoting stories
5. Best practices for environment-agnostic code
Use INFO formula (Critical)
❌ Bad Practice - Hard-Coded Values:
Status: 2265
✅ Good Practice - INFO Keyword:
Status: <<INFO.cases.analysis.id>>
Why this matters
Hard-coded values (like
2265) won't work in prod if IDs differINFO keyword dynamically retrieves the correct value for each environment
Stories become truly portable between environments
INFO keyword examples
For Case Statuses:
<<INFO.cases.status.draft.id>>
<<INFO.cases.status.to_do.id>>
For Credentials:
<<INFO.credential.S1.id>>
<<INFO.credential.ServiceNow.id>>
For Domains:
<<INFO.credential.S1.metadata.domain>>
For Case Fields:
<<INFO.cases.inputs.closure_code.id>>
<<INFO.cases.inputs.analysis.id>>
For Records:
<<INFO.record.record_type_name.id>>
For Tenant Information:
<<META.tenant.domain>>
Code review checklist
Before promoting stories, verify:
No hard-coded status IDs
No hard-coded field IDs
No hard-coded credential IDs
No hard-coded domains/endpoints
All environment-specific values use INFO or META keywords
Credential names match between environments