Problems Gearset solves with relaxing metadata restrictions and disabling automations during data deployments
​

Click the VIEW AND DISABLE RULES button in the bottom-right of screen:

Once it’s ready, you’ll be able to view a list of all the problems that Gearset solves by relaxing metadata restrictions and disabling automations during data deployments.
​
​By hovering over the question mark icon next to each item in the list, you can see a tooltip with detailed explanations of the issue and the solution.
​​

When migrating legacy data from a source org that predates the implementation of validation rules, you may encounter issues because the source org contains data that does not comply with the current validation rules.

Gearset provides an option to temporarily disable certain rules to allow for the creation of this legacy data, ensuring that records can be successfully deployed even if they violate current validation or duplicate rules.

Below are examples of problems that Gearset currently solves by temporary metadata changes during deployment.

Active validation rules in the target org are a frequent cause of FIELD_CUSTOM_VALIDATION_EXCEPTION errors in data deployments (see our documentation on how to resolve such errors).

An Account record in the source org contains a "Revenue" value that exceeds the threshold set by a custom validation rule. Deploying this record to the target org fails because it violates the validation rule.

You're deploying Contacts, and some records in the source org share the same email address as existing Contacts in the target org. A duplicate rule in the target org prevents these records from being deployed.

An "old Opportunity record" uses a picklist value for "Stage" that was deprecated or made inactive after the data was created. Deploying the record fails because the picklist restriction in the target org no longer permits this value.

When migrating data into Salesforce, it’s important to ensure that automations such as Workflow rules, Apex triggers, and Flows do not run when you deploy the records.

Running these automations on legacy data could trigger unnecessary notifications, create redundant records, or cause other unintended data modifications. Gearset provides the ability to temporarily disable automations during deployment to avoid these issues.

Active flows and process builders in the target org can also cause errors during data deployments, such as "CANNOT_EXECUTE_FLOW_TRIGGER: We can't save this record because the process failed."
​

A Flow is set up to automatically send a welcome email when a new Lead is created. Deploying a large set of legacy Leads triggers the flow for each record, potentially overwhelming your email system.

You’re deploying a batch of "Opportunity records" that should bypass workflow-triggered actions, like automatically sending approval requests. These actions interfere with the data migration and create additional tasks in the target org.

Active triggers in the target org can cause System.LimitException: Apex CPU time limit exceeded if they fire on lots of records in your deployment. Any unhandled exceptions thrown by triggers will also cause deployments to fail.
​
An Apex trigger is configured to update related records whenever an Account is created or updated. Deploying a large set of Accounts causes the trigger to run, resulting in unintended cascading updates to related records in the target org.

Once you've disabled all the validation rules, triggers and flow by selecting Start deactivation deployment, you will get a success screen.

Once you've finished your data deployment, you can re-enable the rules, triggers and flows by selecting Rollback deactivation deployments via the deployment summary:

You can always find the Rollback deployment in the Deployment history page in the Gearset app.
​
You can filter that list to find the Disabled rules for data deployment.

And then click on Roll back... button to enable the rules, triggers, and flows.