Note: This article is on the new Sandbox which is now enabled for Enterprise plan customers. For Freshservice's current Sandbox version click here. Click here to learn more about its phase-out plan.


Freshservice's Sandbox environment lets you test configurations before deploying them to your Production. However, during this journey, you might encounter some unexpected detours. This guide equips you with the knowledge to navigate these roadblocks and ensure a smooth sync between your Sandbox and Production.

1. Avoid Using Special Characters to Differentiate Between Two Configurations

Imagine this: You create workflow automators named "Incident Escalation" in your Sandbox and "Incident@escalation" in Production. While the "@" symbol seems like a differentiating factor, Freshservice might consider them the same due to their similar base names.

Error: Syncing "Incident Escalation" from Sandbox to Production will overwrite the existing "Incident@escalation", leading to data loss.

Solution: Steer clear of special characters in configuration names. Opt for clear and descriptive names. Think "New Ticket Notification" instead of "New Ticket@Alert."

2. Renaming Configurations Overwrites Upon Sync

Let's say you have an "Engineering" department in both Sandbox and Production. You renamed it "Development" within the Sandbox to improve clarity.

Existing Behaviour: Syncing "Development" from Sandbox (assuming it will be created as a new Department in Production) overwrites the existing "Engineering" department in Production instead of creating a new one. This leads to data loss and confusion for your agents.

Solution: Before syncing renamed configurations, beware of the configuration that it will overwrite. This clarity before syncing will avoid conflicts and data loss.

3. Deletions and Recreations: Double-Check the Mapping

Imagine this scenario:

  • Both Sandbox and Production have an "Engineering" department.

  • In Production, you rename it to "UX/UI Design."

  • You delete "Engineering" within the Sandbox and create a new department named "UI/UX Design."

Error: During sync, Freshservice treats the "UI/UX Design" from Sandbox as a new addition because the base name for it in the Sandbox differs from that of Production. This, in turn, leads to data conflicts as two workflow automators cannot have the same label, i.e., "UI/UX Design" in this case.

Solution: Review configuration names in both environments before syncing any configuration changes, especially after deletions and recreations, and address potential naming clashes. Ensure the names are distinct to prevent unintended overwrites.

4. Syncing With Inconsistent Admin Permissions

An admin's permissions in the source (Sandbox) and target (Production) instances should be consistent for successful sync.

Example: An admin with "Play God" access in Sandbox but "IT admin" access in Production will face partial sync failure due to insufficient permissions. For instance, the IT admin in Sandbox will not have the privileges to sync global settings, which require Play god admin access in Production.

Solution: Ensure the admin performing the sync has the same permissions in both Sandbox and Production. If unsure about the required permissions, consult your Freshservice administrator guide or contact Freshservice support.

5. Inconsistent Settings Lead to Sync Failures

Ensure field settings (mandatory/optional) in both Sandbox and Production are consistent.

Example: The "Department Head" field is mandatory in Production's department creation form. However, the same field is non-mandatory in the Sandbox. Trying to sync a department without a department head from the Sandbox to Production can lead to sync failure.

Solution: Before syncing, ensure field settings are consistent across both environments.

6. Configuration Order In Source Is Not Guaranteed Post-Sync 

Freshservice doesn't guarantee the order of configurations (workflows, SLAs, etc.) after sync. Think of it like rearranging deckchairs on the ship – it might not affect the core functionality, but it can impact your workflow.

  • Adding new configurations: New configurations are added to the bottom of the list in Production, regardless of their position in Sandbox.

  • Updating existing configurations: Only the updates in the configuration are copied, not the position.

Solution: Reorder configurations as per your business requirements after sync to ensure a smooth workflow.

7. Workspace Privileges Are Not Copied When Syncing Users

While all user information except "Workspace Privileges" (email, name, location, manager, etc.) is copied during sync, think of workspace privileges as separate train tracks leading to different destinations.

Solution: Assign workspace privileges separately after the sync to ensure proper access control.

8. Field Choices Are Always Merged, Not Overwritten

Field choices/values are merged and not overwritten during sync. 

Example: Both Sandbox and Production have a "Priority" field with choices  ("Low," "Medium," "High"). The choices in Sandbox are replaced with new choices  ("Very Low," "Moderate," and "Very High"). 

Syncing the "Priority" field with new choices in Sandbox will add them to the existing choices ("Low," "Medium," "High") in Production. The choices for the "Priority" field in Production now will be ("Low," "Medium," "High", "Very Low," "Moderate," and "Very High") instead of replacing all. 

Solution: Remove unwanted choices directly from Production if needed to maintain a clean and efficient system.

9. Sync Parent-Child Configurations Together to Maintain Data Sanity

When dealing with configurations with parent-child relationships (e.g., locations, asset types), ensure to sync the entire lineage to maintain data integrity.

Example: "San Francisco" is a part of ("North America" -> "United States" -> "California" -> "San Francisco") in the Production. If you create a standalone "San Francisco" location (without the parental relationship with “California”) and sync it from Sandbox to Production, it will create a new location "San Francisco" in the Production instead of updating the existing "San Francisco" in "North America" -> "United States" -> "California" -> "San Francisco".

Solution: Always sync the entire lineage of parent-child configurations to avoid data inconsistencies.

10. Ensure Both the Accounts (Source and Target) Are In the Same Workspace Mode 

Sandboxes with multiple workspaces cannot be synced with Production instances in single workspace mode (and vice versa). Imagine driving a car on a train track – they're simply incompatible!

Solution: Before attempting to sync, ensure both Sandbox and Production are in the same ESM mode (single or multi-workspace)

11. Custom Object Records Are Not Copied During Sync

Custom object records are copied to Sandbox during the sandbox creation process. However, they are not copied during the sync process. 

Example: A custom object "C" contains 5 fields and 100 records. When a sandbox is created, all 5 fields and 100 records are copied to the sandbox. However, if you update a few fields and add 20 new records in the sandbox, the sync will only copy the changes made to the fields, not the records. 

Solution: Once the custom object details (metadata and fields) are successfully synced to production, use the Export/Import feature to keep your records up to date.

Following these guidelines can help you navigate potential pitfalls and ensure a smooth and error-free Freshservice configuration sync between your Sandbox and Production environments. Remember, a little preparation goes a long way in ensuring a successful journey from testing to deployment!