This article explains how syncing works between Sandbox and the target (Production), focusing on the key factors that influence this process, including the role of the internal name and how it impacts configuration creation and syncing.

TABLE OF CONTENTS

Role of internal names in the syncing process

When you create any configuration such as Workflow automators, Departments, Fields and so on a unique identifier-Internal name is automatically generated for every configuration. The internal name is:

  • Not visible in the user interface. It is generated at the backend.

  • Identifies configurations in both Sandbox and Production environments.

How are internal names generated?

When a configuration is created, the system generates the internal name.

Example: For a Workflow automator named Development in the IT workspace, the internal name will be IT_Development.

This ensures that configurations are uniquely identified within their respective workspaces.

Note: 

  • The internal name remains unchanged, even if the configuration is renamed later.

  • Deleting and recreating configurations in Sandbox can result in sync conflicts if the internal names differ from those in Production, leading to duplicate or unintended configurations.

Sync behavior based on internal name presence

When syncing configurations from Sandbox to Production or vice versa, the sync process checks for the internal name in the target (Production). The following table describes the result of the sync process.

Internal name exists in Production

The configuration in Sandbox overrides the corresponding configuration in Production

Internal name does not exist in Production

A new configuration is created in Production.


Note: For Field names the behavior is different, it will merge the changes made in Sandbox with the fields in target. 

The following flow chart explains the sync process.

Example scenarios

Renaming a configuration

Initial setup

  • In the IT workspace, you create a Workflow automator named Development in both Sandbox and Production.

  • The internal name is generated as IT_Development in both environments.

Renaming in Sandbox

  • In Sandbox, you rename the Workflow automator from Development to Engineering. The visible Workflow name changes, but the internal name remains IT_Development.

Syncing Sandbox to Production

  • During sync, the system detects that the internal name IT_Development exists in Production.

  • The Workflow automator in Sandbox (now named Engineering) overrides the one in Production (still named Development).

Result

  • Sync fails or overwrites occur because the internal name does not update to reflect the new Workflow name.

Deletions and recreations

Initial Setup in Sandbox and Production

  • In both Sandbox and Production, you have a department named Engineering.

  • In Production, you rename Engineering to UX/UI Design but the internal name remains the same. 

Deleting and Recreating in Sandbox

  • In Sandbox, you delete the existing Engineering department and create a new department named UI/UX Design. However, the internal name for UI/UX Design is different in both Production and Sandbox.

Syncing Sandbox to Production

  • During the sync, Freshservice treats UI/UX Design in Sandbox as a completely new department, as it no longer matches the internal name of the renamed department in Production (Engineering → UX/UI Design).

  • This results in a data conflict because two departments cannot have the same visible name (UI/UX Design) in Production.

Result

  • Instead of updating the existing department in Production, a duplicate department may be created, or the sync may fail due to naming conflicts.

Field choices are always merged, not overwritten

Initial setup in Sandbox and Production

  • In both Sandbox and Production, there is a custom field named Priority with the following choices:

    • Low, Medium, High.

Updating Field choices in Sandbox

  • In the Sandbox environment, you modify the Priority field by replacing the choices with:

    • Very Low, Moderate, Very High.

Syncing Sandbox to Production

  • During the sync, Freshservice merges the field choices from Sandbox with those in Production instead of overwriting them.

  • As a result, the Priority field in Production will now contain the following choices:

    • Low, Medium, High, Very Low, Moderate, Very High.

Result

  • The choices from both environments are combined, leading to additional values in the field that might not align with your intended changes.

Sync Parent-Child configurations together to maintain data sanity

Initial Setup in Production

  • In Production, there is a location hierarchy:

    • North America → United States → California → San Francisco.

Creating a New Configuration in Sandbox

  • In Sandbox, you create a new standalone location named San Francisco, without associating it with the parent hierarchy (California, United States, or North America).

Syncing Sandbox to Production

  • During the sync, Freshservice treats the San Francisco location in Sandbox as a new, separate entry.

  • In Production, a new standalone location San Francisco is created alongside the existing hierarchical location (North America → United States → California → San Francisco).

Result

  • This leads to data duplication, as there are now two San Francisco locations:

    • One under the existing hierarchy.

    • One as a standalone location.

Best practices to avoid sync issues

  • Avoid renaming configurations: Avoid deleting and recreating configurations; instead, rename configurations consistently in both environments to maintain data integrity.

  • Manual updates: If renaming is necessary, manually update the configuration in Production to maintain consistency.

  • Review before syncing: Always review configurations in both environments to identify potential conflicts.

By following these guidelines, you can minimize sync errors and ensure smooth transitions between Sandbox and Production.