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.

In Freshservice, dependencies ensure smooth operations in your Sandbox syncing. Let’s break it down:

What Are Dependencies?

Dependencies refer to the connections between different configurations or components. When one configuration relies on another to function correctly, we call it a dependency. Think of it as a teamwork scenario: each player has a specific role, and their success depends on the others performing their tasks effectively.

Let’s understand the role of Dependencies in the context of Sandboxing with a simple example.

Consider this real-life scenario: You have a workflow automator that sends approval notifications for tickets raised by the Engineering department. The approval goes directly to the department head, John. Here’s how dependencies come into play when syncing changes:

  1. Engineering Department (Task A):

    • Users from this department raise tickets and keep the IT wheels turning.

    • If the engineering department exists in your target instance (e.g., production), that would be great! No additional action is needed.

    • If it’s missing, consider it a “required dependency.” Without the Engineering department, the workflow won’t function correctly.

  2. Department Head, John (Task B):

    • John oversees ticket approvals and ensures smooth ticket flow.

    • Like the Engineering department, if John exists in your target instance, fantastic!

    • If not, he’s also a “required dependency.”


Ensuring all dependencies in the target configuration is crucial during syncing changes from Sandbox to Production. Think of it as adding the missing puzzle pieces to complete the picture.


Handling dependencies - A special case 

Fields and field choices/values are treated slightly differently when it comes to dependency calculation. Suppose a field or choice is identified as a dependency in any configuration. In that case, it will be listed as a "required dependency" even if the field or choice already exists in the target instance.


For example, in a scenario where a workflow W assigns "High" priority to a ticket raised by a VIP user, the Priority field will be marked as a required dependency, even if it already exists in the target instance.