Note: This article is on the new Sandbox which is being rolled out for Enterprise plan customers in batches currently. For Freshservice's current Sandbox version click hereClick here to learn more about its phase-out plan.

In Freshservice, configurations are assigned unique identifiers when they are created. These identifiers are critical in syncing configurations between Sandbox and Production environments. Let’s understand how this works.

Sync Scenarios

1. Adding New Configurations

  • Scenario:

    • You create a new configuration (e.g. a workflow automator, custom object, or a business rule) in the Sandbox.

    • Let’s say you name it “New Incident Workflow.” The system generates a unique identifier using its label, e.g., newincidentworkflow. This unique identifier remains hidden from the UI.

  • Sync to Production:

    • When you sync to Production, the system checks for the configurations with the same unique identifier in Production.

    • If no existing configuration in Production shares the same unique identifier, the system treats “New Incident Workflow” as an addition and creates it in Production.

2. Updating Existing Configurations

  • Scenario:

    • You modify an existing configuration in Sandbox, such as updating the conditions in a workflow automator called “New Incident Workflow.” 

    • The unique identifier remains unchanged as “newincidentworkflow”, even if you change the label to “New Incident Workflow Automator”.

  • Sync to Production:

    • The system looks up the configuration based on its unique identifier (not visible to you).

    • If found, it is treated as an update and overrides the configuration in Production.

Special Considerations

  • Case-Insensitive and Space-Agnostic:

    • Freshservice identifiers are not case-sensitive.

    • Special characters, including spaces, are ignored in unique identifiers.

    • Example: “My_Config”, “My Config”, “MY CONFIG”, and “MyConfig” will all have their identifier as “myconfig”.

Note: If you have multiple configurations in the same instance (Sandbox), the system will auto-add a suffix to keep them unique. For example, if you create two configurations called “My_Config” and “My Config”, the unique identifiers would be “myconfig” and “myconfig_000”, respectively.

Sync Changes - Special Cases

Below are a few cases where syncing configurations could fail:

1. Unique identifier clash between source and target instances 

Example 1: Two different workflow automators, “My Workflow” and “My@workflow,” are created in Sandbox and Production, respectively. Both will have the same unique identifier, e.g., myworkflow. When you try to sync “My Workflow” from Sandbox to Production or vice versa, the system matches it with “My@workflow” as they share the same unique identifier. 

It is recommended to exercise caution when using special characters in the configuration names.

Example 2: An " Engineering " department is created in both Sandbox and Production. They have the same unique identifier (derived from the label). Later, ‘Engineering’ in the Sandbox instance is renamed ‘Development’. 

When you try to sync Engineering from the Sandbox to Production, Freshservice overrides ‘Engineering’ in Production with ‘Development’ from Sandbox, as both share the same unique identifier.

2. Label clash between source and target instances

Example: From the above example, consider the below sequence of events:

T0: Sandbox is created. Both instances have an Engineering department with a unique identifier (engineering).

T1: The department ‘Engineering’ is renamed ‘Development’ in Production. The unique identifier is still engineering, constructed at t0

T2: The department ‘Engineering’ is deleted from Sandbox, and a new department named ‘Development’ is created. The new department has a unique identifier: Development.

T3: When the user tries to sync Development from Sandbox to Production, Freshservice treats it as a new addition. However, the sync fails as the label ‘Development’ is already in Production, albeit with a different unique identifier.

In such scenarios, it is recommended that the name of the configuration(s) in one of the instances be updated.

3. Insufficient sync permissions 

Example: admin A is a Play God admin in the source (Sandbox) but an IT admin in the target (Production). If a few global dependencies are identified and added to the config set, the sync would partially fail as A only has workspace admin access permissions in Production, which is insufficient to sync global settings. 

For a successful sync, it is recommended that the admin's permissions be consistent. Alternatively, other admins with consistent privileges can help sync the config set.

4. Inconsistent settings between two instances. 

Example: Say the ‘Department head’ field in the department creation form is mandatory in Production but not in the source. In this case, when a department without a Department head is synced from the source to the target, the sync fails as some mandatory fields are missing. 

It is recommended that the field settings be consistent between the two instances.

5. Post-sync, the order of configurations (such as workflows, business rules, SLAs, etc.) is not guaranteed upon sync. 

Syncing (adding) new configurations: 

  • If you create a new workflow automator in the Sandbox and sync it to Production, it will be added to the bottom of the list by default, regardless of its position in the Sandbox.

Syncing (updating) existing configurations:

  • If you update an existing workflow automator in the Sandbox, reorder its position relative to Production, and sync it to Production, the updates in the workflow automator will be copied, not the position.

It is recommended that you reorder as per your business requirements post-sync.

The list of valid admin settings for this case includes department fields, User fields, OLA policies, Field Manager, Business Rules, workflow automator, Supervisor rules, Asset Types and fields, Vendor Fields, Software Fields, and Purchase Order fields.

6. Attributes copied when a user is synced

All the user information, including email, first name, last name, reporting manager, department, location, etc., will be copied except ‘Workspace Privileges.’

It is recommended that workspace privileges be assigned separately after the sync.

7. Field choices/ values are always merged on sync instead of overriding.

Example: A field called ‘Priority’ has three choices in Sandbox: “Low,” “Medium,” and “High.” If the choice “High” is replaced (not renamed) to “Very High” and synced to Production, Production will now have four choices: “Low,” “Medium,” “High,” and “Very High.” This behavior differs slightly from the rest of the modules where we override the data in Production. This is to maintain data sanity in your Production environment. 

You should remove any unwanted choices directly from the Production based on your business requirements.

8. Configurations with the parent-child relationship, e.g. Locations, Asset Type

Example: North America → United States → California → San Francisco is a location present Production. A standalone location, San Francisco, has been newly created in the Sandbox. When you try to sync San Francisco to Production, it will be considered a new location as the parent relationship is missing in the Sandbox.

It is important to sync the entire lineage of the locations to ensure data sanity in the target instance.

9. Source and target instances in two different ESM modes. 

In cases where Sandbox has multiple workspaces, but the production is in single workspace mode or vice versa, sync is not allowed. Ensure both your accounts are either in single workspace or multi-workspace mode to be able to sync