Skip to main content

Migrating stories from non-production to production tenants

How to migrate Tines stories to production tenants.

Written by Danielle Swanser
Updated today

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 offers a migration workflow that manages the promotion of stories from a non-production tenant to a production tenant using the Tines API. It is important to note that although most Tines 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 Templates

  • 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_key to the Tines story. This is the API key for your non-production Tines tenant.

    • You should include the non-production tenant domain as metadata.

  • Add your prod_tenant_api_key to the Tines story. This is the API key for your production Tines 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 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 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 Templates Migration

Why manual migration is required

Current Limitation: Tines does not support exporting/importing case templates between environments.

Steps to migrate Case templates

Before migration (Non-Prod)

  • Navigate to Security Operations Team → Cases → Templates

  • Open each template you need to migrate

  • Document the following for each template:

    • Template name

    • Description

    • Priority settings

    • Records configuration

    • Case requirements

    • All field mappings and value pills

    • Actions configured in the template

Migration (Prod)

  • Navigate to Security Operations Team → Cases → Templates

  • Click Create New Template

  • Manually recreate each template:

    • Right Side Panel:

      • Add case requirements (click + to add sections)

      • Configure priority

      • Add records

    • Main Area:

      • Copy/paste descriptions (value pills should carry over)

      • Add all configured actions

      • Set up field mappings

Verification

  • Create a test case using the new template in production

  • Verify all fields populate correctly

  • Confirm actions trigger as expected

  • Compare side-by-side with non-production template

4. 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

5. 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 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

6. 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 differ

  • INFO 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

Related Articles
Stories in Tines
Tenants and teams
Tenant settings
Custom Tenant URLs
Importing and exporting stories
Did this answer your question?