> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hightouch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments and deployments

> Hightouch supports change management in-app via separate workspaces for different environments, for example, production, staging, development, and sandbox.

> [!NOTE]
>
> Environments and deployments are only available on [Business tier plans](https://hightouch.com/pricing).

> [!TIP]
>
> **Not sure whether you need environments or a separate workspace?**
> Environments are the right choice when your teams share the same sources,
> destinations, and user roster but need a safe promotion path (dev → staging →
> prod). If you need hard isolation — separate sources, separate users, nothing
> shared — you need a separate workspace instead. For a side-by-side comparison,
> see [Do you need another
> workspace?](https://docs.hightouch.com/workspace-management/workspaces.md#do-you-need-another-workspace)

Maintaining separate [environments](https://en.wikipedia.org/wiki/Deployment_environment) for different stages of the release process is a common practice across technical domains.

Separating environments minimizes the risk of accidental changes or disruptions to the user-facing experience.
For example, environments can help you avoid overwriting CRM data you didn't mean to, activating a marketing campaign prematurely, or incurring unexpected data warehouse charges.

Generally, production environments are for live, user-facing applications, staging for pre-release testing, and development for experimentation.

![Environments diagram](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/environments/environments-diagram.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=f585aed9ea9165fe6ed35cac9e027e28)

You can set up whatever environments your organization requires in Hightouch.

## How do environments work?

Each Hightouch [workspace](https://docs.hightouch.com/workspace-management/overview.md#workspaces) in your organization acts as a separate environment.
You can link resources between workspaces, which allows you to **deploy** [models and syncs](https://docs.hightouch.com/getting-started/concepts.md) from one environment to another.

Each workspace can have its own set of [alerts](https://docs.hightouch.com/syncs/alerting.md) and can use its own extensions.
Environments integrate seamlessly with other governance features, such as [role-based access controls](https://docs.hightouch.com/workspace-management/roles.md) (RBAC) and [approval flows](https://docs.hightouch.com/workspace-management/approval-flows.md).
Workspace [permissions](https://docs.hightouch.com/workspace-management/roles.md) and [drafts](https://docs.hightouch.com/workspace-management/approval-flows.md) are enforced across workspaces when deploying changes.

You can set up your organization so that specific team members have access to certain resources.
For example, some team members, such as your data team, may have permission to set up sources and models.
Others, such as the marketing team, can deploy or draft sync deployments.

### Separate resources for separate environments

Each workspace has its own set of resources, including [sources](https://docs.hightouch.com/getting-started/concepts.md#sources), [models](https://docs.hightouch.com/getting-started/concepts.md#models), [destinations](https://docs.hightouch.com/getting-started/concepts.md#destinations), and [syncs](https://docs.hightouch.com/getting-started/concepts.md#syncs).
Hightouch allows you to link resources across workspaces.
For example, you can link a Snowflake playground in your "dev" workspace to a production Snowflake instance in your "prod" workspace,
a Salesforce sandbox to your production Salesforce instance, etc.

![Environments diagram](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/environments/linked-resources.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=907eccafb216e3a94a7b12b85fd4713a)

Environments allow you to **deploy** changes to models and syncs.
When you deploy a model or sync, Hightouch copies its configuration to another workspace, updating or creating resources where necessary.
Before performing the copy, Hightouch checks that all [underlying resources](#resource-dependencies) are appropriately configured.

For example, you may be experimenting with changes to a Salesforce sync [mapping](https://docs.hightouch.com/syncs/mapping-data.md) in your development environment.
When you're happy with your change, you can deploy it to your production environment.
Before copying your changes to a production sync, Hightouch checks that the underlying model and destination have linked counterparts in production.

Keeping resources separate between environments lets you create as many as you want in a development environment without cluttering other environments you may want to keep pristine.
And since changes don't automatically deploy to linked resources,
you can safely delete or update resources without worrying about knock-on effects in other environments.
Each resource also has its own history, which you can inspect, for example, by examining its activity.

### Resource dependencies

While any resources of the same type can be linked, for example, source to source and sync to sync, **you can only deploy models and syncs**.
To deploy models and syncs, you must link their underlying sources and destinations to their relevant counterparts.

> [!NOTE]
>
> Environments apply to **Reverse ETL models and syncs only**. Customer Studio
> resources — including audiences, traits, parent models, and schema models —
> **cannot be deployed between environments**. Each environment must be
> configured and maintained independently for Customer Studio workflows. For
> Customer Studio change management, use [Approval
> Flows](https://docs.hightouch.com/workspace-management/approval-flows.md) instead.

When you [deploy](#deploy-changes) models or syncs, Hightouch checks that the underlying resources match linked counterparts in the target environment.
For example, if you link one **source** to another, you can deploy **models** built off the linked source.

![Deploying a model](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/environments/deploy-model.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=676a5c11a1134b0e4fbed9fd1c8533dd)

![Deployed model](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/environments/deployed-model.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=2c8e10d9e743cfc605500225b9dbc6b0)

To deploy **syncs**, the underlying linked **models** *and* **destinations** need to match in both workspaces.

![Deploying a sync](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/environments/deploy-sync.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=eaf65053042526626ac78f543dd6f69e)

![Deployed sync](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/environments/deployed-sync.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=c17fe1359c6ff3b077019a617c1047a0)

## Environment usage

To deploy changes, you first need to link resources.
You can either link existing sources and destinations on their configuration pages,
or link them as part of the [deployment workflow](#deploy-changes).

You only need to link underlying resources once to allow deployments.
Removing links between resources doesn't impact syncs or models you previously deployed.

### Link resources

> [!TIP]
>
> To link resources, you need [`create`
> permissions](https://docs.hightouch.com/workspace-management/roles#custom-role-grant-reference) for the
> relevant resource type (source or destination) in all workspaces you want to
> create the link between. For example, if you want to link two sources, you
> need [`create`
> permissions](https://docs.hightouch.com/workspace-management/roles#custom-role-grant-reference) for
> sources in both workspaces you want to link them in.

You can link existing sources and destinations to their counterparts in other workspaces.
You can only link models and syncs during the deployment workflow.

When you [deploy](#deploy-changes) a resource for the first time, you create and simultaneously link the resource to a counterpart in the target workspace.
During deployments, Hightouch ensures you've linked the necessary [underlying resources](#resource-dependencies).
If you haven't, you can link them directly from the deployment wizard.

#### Link sources and destinations

To link existing sources and destinations, follow these steps:

1. Go to the resource's overview page and open the **Linking** tab.

![Linking resources in the Hightouch UI](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/environments/link-resources.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=81dc5169dc50254ed4e12752b632d091)

2. Select the relevant resource for each workspace you want to link and then click **Link**.

> [!NOTE]
>
> Hightouch only displays eligible resources for linking. To be eligible: - the
> resources must be of the same type; for example, they both must be Snowflake -
> the user creating the link must be a member of both workspaces - both
> workspaces must belong to the same organization

#### Link syncs and models

The only way to link syncs to other syncs and models to other models is by [deploying them](#deploy-changes).
Once deployment creates a new sync or model, it's automatically linked for future deployments.

You cannot deploy to existing syncs or models. If you want to link existing syncs or models from one workspace to another,
delete the development or testing version and recreate it by deploying it from your production environment.
Don't hesitate to [get in touch](#pylon-chat) if you have any questions or concerns.

### Deploy changes

> [!TIP]
>
> To deploy changes, you need [permission to at least create
> drafts](https://docs.hightouch.com/workspace-management/roles.md#approval-flows) for the relevant resource
> type (model or sync) in the target workspace to which you want to deploy
> changes. For example, if you want to deploy a sync, you need permission to
> create sync drafts in the workspace you want to deploy the sync to.

To deploy syncs or models, follow these instructions:

1. From a model or sync's configuration page, click the deploy icon to the left of the **Run** button and select **Deploy**.

![Deploying changes in the Hightouch UI](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/environments/deploy-button.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=0a1cf635f90bf9db69149692f916e30f)

2. Select the environment you want to deploy the change to. The first time you deploy a particular resource, Hightouch creates a new resource in the target environment. If you've deployed the resource before, the deployment updates the previously created and linked resource.
3. If the relevant [underlying resources](#resource-dependencies) aren't already linked, follow the steps in the modal to link them.
4. The deployment wizard shows what has changed: added, removed, and updated configurations. Review these to ensure they're the changes you want to deploy.

![Deploying changes in the Hightouch UI](https://mintcdn.com/hightouch-3c037897/L_vQfA0JQEpeGUUo/images/workspace-management/environments/review-deployment.png?fit=max\&auto=format\&n=L_vQfA0JQEpeGUUo\&q=85\&s=ce3fe9270569bd2129c2d791d30ca9fb)

5. For sync deployments, you can choose whether to deploy its [schedule](https://docs.hightouch.com/syncs/schedule-sync-ui.md#schedule-types) as well as the other configuration changes.
6. Click **Deploy**.
7. **Syncs created via deployment are disabled by default.** If you want to enable a deployed sync, make sure to do so from its [overview page](https://docs.hightouch.com/syncs/overview.md#individual-sync-overview-page) once you've deployed it.

> [!NOTE]
>
> You can't deploy
> [drafted](https://docs.hightouch.com/workspace-management/approval-flows.md#edit-existing-resources)
> changes on a configuration. You first need to get approval and/or publish
> changes to a resource before deploying the changes.

#### Deployment validations

Before deploying changes, Hightouch validates dependencies.
Hightouch blocks deployments until you've resolved all dependency issues.
For example, if you try to deploy a [dbt-based](https://docs.hightouch.com/extensions/dbt-models.md) model from your staging to production workspace,
but the [dbt extension](https://docs.hightouch.com/extensions/dbt-models.md) isn't set up in production, Hightouch blocks the deployment.
Once you've resolved the issue, for example, by configuring a missing extension, you can retry the deployment.

Deployments will clear or replace any existing [drafts or approval requests](https://docs.hightouch.com/workspace-management/approval-flows.md) on a sync or model in a target workspace. You will be warned if a deployment will replace a draft during the validation step.

## FAQ

### What permissions do you need to use environments?

To link resources, you need [`create` permissions](https://docs.hightouch.com/workspace-management/roles#custom-role-grant-reference) for the relevant resource type in both workspaces you want to create the link between.
To deploy changes, you need [permission to create or update drafts](https://docs.hightouch.com/workspace-management/roles.md#approval-flows) for the relevant resource type in the target workspace you want to deploy changes to.

### Can you link any resource to another resource of the same type?

You can link sources to other sources, models to other models, destinations to other destinations, and syncs to other syncs.

> [!NOTE]
>
> **Customer Studio resources — including audiences, traits, parent models, and
> schema models — cannot be linked or deployed between environments.** Each
> environment must be set up and maintained independently for Customer Studio.
> For Customer Studio change management, use [Approval
> Flows](https://docs.hightouch.com/workspace-management/approval-flows.md) instead.

Please [let us know](#pylon-chat) if this is something you're interested in.

### How do you link existing models and syncs?

The only way to link syncs to other syncs and models to other models is by [deploying them](#deploy-changes).
Once deployment creates a new sync or model, it's automatically linked for future deployments.

If you want to link existing syncs or models from one workspace to another,
delete the development or testing version and recreate it by deploying it from your production environment.
Don't hesitate to [get in touch](#pylon-chat) if you have any questions or concerns.

### Can you use environments to copy resources?

You can use [deployments](#deploy-changes) to copy existing models and syncs but not sources and destinations.
To copy an existing model or sync to a different workspace, follow the instructions for [deploying changes](#deploy-changes).

### Can you only deploy changes to production environments?

Deploying changes has no directionality.
You can deploy changes from a testing workspace to a production workspace and vice-versa, as long as the [validations](#deployment-validations) pass.

### Can you use environments and deployments with Git Sync?

If you already use [Git Sync](https://docs.hightouch.com/extensions/git-sync.md) to manage your syncs and destinations across workspaces, deploying a sync or model to your target workspace would create its corresponding `yaml` file in the configured Git Sync repository.
Beyond updating `yaml` files, environments and deployments don't interact with your Git Sync repositories.

You should use *either* Git Sync *or* the in-app environments and deployments feature for your environment management.

### Can you use environments and deployments with Hightouch Event Collection?

At the moment, it's not possible to create deployments of event resources like event syncs, event sources or event destinations and so it isn't currently possible to separate your Event Collection resources into staging and production environments.