Note: This article is on Freshservice's legacy Sandbox. Click here to know more about its phase-out plan. The new revamped Sandbox will be available for Enterprise plan customers from April 29, 2024. Learn more about the new revamped Sandbox here.

Table of contents

1. Sandbox in a multi-workspace account

2. Sandbox for both Global and Local configurations

3. Modules that are copied to sandbox and support sync

4. Modules that do not get copied to your Sandbox account

5. Global Sandbox and Reverse Sync 

6. Setting up a Sandbox

7. How to Sync Global and Local changes from Sandbox to Production?

8. Sandbox Expiry

9. Limitations when an active sandbox exists

Note: Refer to this solution article for the sandbox created after January 4th,2023.

          Refer to this solution article for the sandbox created before January, 2023.


Sandbox in a multi-workspace account

Multiple teams such as IT, HR and Finance can now co-exist within the same helpdesk, creating and managing their own configurations. It thus becomes imperative that administrators across each of these teams have full autonomy to test changes in a secure sandbox environment and sync them to production at their own timelines. For eg: HR can sync their changes without having to wait for IT’s changes to finish.


With sandbox in a multi-workspace account, administrators of individual workspaces can work on their workflows and configurations in their respective workspaces without impacting the service desk configuration of other teams. This way, admins can test out new configurations and sync them to production without depending on global / account-wide administrators.

Sandbox for both Global and Local configurations

A multi-workspace account has both workspace specific configurations (eg: workflows, form fields for IT, HR , Finance) and global configurations that apply across all workspaces (eg: requesters, Ticket status and category fields).


Both global and local workspace configurations can now be tested securely in sandbox environments and synced to production independently. 


It’s important to note that much like your production account, a single sandbox account houses every workspace that’s a part of it. To spin up a sandbox for your workspace or global configurations, use the admin switcher -> click on sandbox -> hit the create sandbox button.



Modules that are copied to sandbox and support sync

Business Hours, Departments & department fields, Requester Fields, Roles & Permissions, Agents, Groups, CAB, Locations, Form Fields(Tickets/Problems/Changes/Releases), Service Catalog, SLA policies, Workflow Automators, Change lifecycle, Asset Automations (Deletion of asset types and fields, product, vendor, and domain is not possible), Business Rules, Custom Objects.

For more information on whether these modules are global, local, or both, refer to this article.

Modules that do not get copied to your Sandbox account

Tickets data, Ticket list views, Portals - logo, favicon, customization, Gamification, Apps, and integrations, SSO and SSL settings, Asset Data, and Knowledge Base.


Global Sandbox and Reverse Sync 


Global configurations are shared across all workspaces, for eg: Ticket fields such as Category and Status are global fields applicable to tickets from all workspaces. These global configurations can also be referenced in local workspace-specific configurations for eg: Workflows from the IT workspace can reference the category or status field in their routing and fulfillment flows respectively.


In the sandbox environment, global configurations are reverse-synced to ensure that every local admin working in their respective sandboxes always has the latest version of these global configurations. This helps to avoid conflicts and errors that could occur when changes are synced to the live production environment.

Exceptions to reverse sync: If a global sandbox is spun up, and changes are made to global configurations, such configurations are not overwritten via the reverse sync mentioned above.


Setting up a Sandbox


1. Global Sandbox: Navigate to Admin Switcher - Global settings  - Sandbox



2. Worksapce/ Local Sandbox: Navigate to Admin Switcher - Choose the Workspace (IT/HR/Finance)  - Sandbox



3.  In the Sandbox Details tab, click on Create Sandbox, and once the Sandbox account is created and the admin will be notified via email. This will take some time, based on your service desk configuration.


4. Click on Open Sandbox to log in to your Sandbox account in a new tab. Here, you can test out configurations before syncing them to your Freshservice account.




 

Note: Workspace admins can only view their respective workspace configurations in the sandbox. For e.g. IT workspace admin, who has access only to configurations in the IT workspace, is able to access just those configurations in sandbox too. 

How to Sync Global and Local changes from Sandbox to Production?


In order to sync changes from the Sandbox environment to Production, it is necessary to have an active Sandbox environment.


What is an Active Sandbox?


A sandbox is active only when the admin creates a sandbox via global / workspace settings. 


For eg: In an account with IT, HR, and Finance workspaces, when IT decides to spin up the first sandbox, the sandbox account will also copy over HR and Finance workspace configurations. However, since HR and Finance haven’t explicitly spun up a sandbox environment, configurations belonging to these workspaces cannot be synced as their respective workspace sandboxes are not active


Local and Global Sync process

The sync process referenced in this article largely remains the same for both global and local sandboxes. Outlined below are the steps and a few exceptions that apply in a multi-workspace account

  • Navigate to Admin Switcher → Based on which changes you want to sync, choose the  Global / Workspace (IT/HR/Finance)  → Sandbox.

  • To sync changes, select View Changes to fetch all the changes made in your Sandbox account.


  • Click on Regenerate Change List -> Regenerate to ensure all the changes created are included in the change list before syncing them.

  • After selecting the sync source, click on the Confirm changes button to save the selected options in the change list.


  • Now, go ahead and click on Test Sync to ensure there aren’t any errors while syncing the sandbox data.


  • Global Dependencies during Local Sync: While syncing local sandbox changes, if the local configuration references a new/ changed configuration in the Global sandbox, the test sync will fail. The Global sandbox changes should be synced first to proceed with the local sandbox changes.

    For example, A status value is added in the global sandbox but doesn’t exist in the production environment. If the local admin references this status value inside a local sandbox while configuring the workflow, the test sync will fail.

    Global admin has to sync the status value first to the production environment followed by local admin.


               


Best Practice: Avoid making both global and local changes simultaneously in sandbox unless global and local changes are planned to be synced together (global sync first, followed by local sync)



Note: When there is only one active workspace sandbox, the sandbox account gets destroyed after syncing changes since the global and other workspaces in sandbox are inactive. 


Sandbox Expiry 


The expiry date of the sandbox will be updated based on when the last sandbox was created.


For eg, When the IT creates a sandbox on Day 1, the expiry date will be set to Day 180,
 When the HR creates a sandbox 10 days later, the expiry date will be updated to Day 180+10

Limitations when an active sandbox exists

If an active sandbox exists, administrators cannot do the following:- 

  • Create an additional workspace that moves it from the single to multi-workspace mode. 

  • Delete any workspaces which moves the account from a multi to single workspace mode.

  • Switch to MSP mode and vice versa