Error overview
You may run into this validation error when you change a Custom field's data type and then you try to deploy that changed Custom field via Gearset (or any other tool using Salesforce Metadata API for deployments).
An example of the error message in our app:
"Cannot change type due to existing data"
We've seen this error on a wide range of field type conversions across validations runs both via Compare and deploy and on PRs in Gearset Pipelines, so the underlying cause isn't specific to any one type combination.
Some examples of converstions we're referring to include changes of Custom fields from: Text to Picklist, Text to Long Text Area, Picklist to Multi-Select Picklist, Long Text to Rich Text etc.
Salesforce can also return a more specific variant of a similar error that names the cause directly, for example:
Explanation of the error
Due to restrictions, Salesforce blocks a data type change on a Custom field whenever it considers the field to have "existing data" tied to it. This is typically broader than just live record values referred to as "existing data".
In practice, we've seen this error being triggered by following scenarios:
Actual record data in the field, in either the source or target org. This includes records sitting in the Recycle Bin, which Salesforce still counts even though they're not visible in normal views.
Formula fields that reference the field being changed.
Flows that reference the field, including in inactive or older versions of a Flow. This is a common gotcha: removing the reference from the active Flow version isn't enough if a previous version of the same Flow still holds it. Every Flow version needs to be checked, and often deleted.
Validation rules that reference the field.
Apex classes or triggers that reference the field.
Lightning Record Pages that include the field.
On top of this, if your deployment also includes another component that depends on the Custom field's new type - for example a validation rule or formula written against the new picklist - Salesforce needs the field's type change to be deployed to the target org before it will accept that dependent component.
This means that deploying both components together in the same deployment package (e.g. as part of the same PR validated in the Pipeline) can still trigger the same error.
Resolution
Because this restriction is enforced by Salesforce, the fix is to make sure nothing in the target org (and ideally in the source org, too) still ties the field to its old type before the Custom field's type change is deployed via Gearset.
Below steps should help you troubleshoot the issue:
Check for real record data, including the Recycle Bin, on both the field being changed and - if you're converting to a multi-select or restricted picklist - any values that might block the conversion.
Remember that deleting records is often not enough on its own if the Recycle Bin still holds them.
Find every metadata reference to the field and remove or temporarily deactivate it.
In Setup, navigate to to Object Manager > [Object] > Fields & Relationships > [field] > Where is this used? to see formula fields and validation rules that reference it.
Check every Flow that touches the field, not just the currently active Flow version.
Open the Flow's version history and remove or delete older versions that still reference the field, in addition to updating the active Flow version.
Search for the field in Apex classes and triggers.
Check whether the field is placed on any Lightning Record Pages.
If your deployment also includes a component that depends on the field's new type (e.g. validation rules or formula built against the new picklist values), split your deployment as follows:
Deploy the field type change on its own first (e.g. as part of a separate PR in the Gearset Pipeline).
Confirm the field type has successfully deployed to the target org.
Then deploy the dependent component as part of a separate deployment (e.g. as part of a separate PR in Gearset Pipeline), or re-validate your existing PR or deployment package that already contains the dependent component.
Alternative workaround
If the error persists even after a thorough cleanup, as a last resort - particularly under time pressure, or when a field has too many dependencies to safely unpick them - consider creating a new field with the desired type instead of converting the existing one, and migrate any Reports, Flows, or other automations over to the newly created field.
This avoids the restriction entirely, since you're not modifying an existing field's type.
Helpful resources
Salesforce knowledge documentation (published 25 Jun 2026)
Disclaimer: This error is returned by Salesforce directly, rather than Gearset. Even so, we offer guidance based on our combined experience with the Metadata API. Where possible, we try to help guide you to fix or avoid this error. In the case that this isn't possible, we may need to direct you to Salesforce support for further clarification.