Straight answer: some field type changes are lossless, some truncate data silently, and some are refused outright. Salesforce warns you generically and does not tell you which rows will be affected, so the work is finding that out yourself before you click, because there is no undo.
The three categories
Safe. Text to Text Area, a longer length, Number to a larger scale. The data survives unchanged and the change is quick.
Lossy, and permitted. This is the dangerous group because nothing stops you:
- Text to Number. Anything non-numeric becomes null. Not an error, a null.
- Shortening a Text field. Values longer than the new length are truncated. The excess is gone.
- Number to Text. Usually fine, but the formatting changes and anything comparing the value stops matching.
- Picklist to Text is safe. Text back to Picklist is not: values not in the new list remain as data but become invalid.
- Reducing decimal places rounds, permanently.
Refused. Anything to or from a formula, roll-up summary, auto number, master-detail, or encrypted field. Also refused if the field is referenced in a way the change would break, which is where the real friction lives.
What blocks a change even when the type conversion is fine
Salesforce refuses the change if the field is used in:
- A formula or validation rule on any object
- A roll-up summary, as the field being summarised or filtered on
- A workflow or flow criterion, in some cases
- An Apex class or trigger that references it in a typed way
- A report filter, sometimes, depending on the change
- An external ID or unique constraint
The error names one blocker at a time, so a field referenced in six places produces six rounds of find-remove-retry. Search the metadata first rather than discovering them serially.
sf project retrieve start --metadata ApexClass,Flow,ValidationRule
grep -rl "My_Field__c" force-app/The procedure that does not lose data
For anything in the lossy category, do not convert in place.
- Create a new field of the target type, with a clear temporary name.
- Populate it from the old field, with whatever transformation is needed, and handle the rows that will not convert explicitly rather than letting them become null.
- Report on the mismatches. The count of rows where the new field is null and the old one is not is your data loss figure. Decide about it deliberately.
- Repoint everything: formulas, reports, integrations, Apex, layouts.
- Leave the old field in place for a release, read-only, before deleting it.
Step five is the one people skip and the one that saves you. A deleted custom field is recoverable for 15 days and its data is not always intact after restore, so the cheap insurance is not deleting it yet.
Find the rows that will not convert, first
Before a text-to-number change, this tells you exactly what you are about to lose:
SELECT Id, My_Field__c FROM Account
WHERE My_Field__c != null AND NOT My_Field__c LIKE '%[0-9]%'SOQL has no regular expressions, so in practice you export the distinct values and check them outside the platform. An export of SELECT My_Field__c, COUNT(Id) FROM Account GROUP BY My_Field__c gives you every distinct value and how many records hold it, usually on one screen, and it is the fastest way to see the problem values.
Sandbox first, with production data
A Developer sandbox has no data, so the conversion succeeds and tells you nothing. This needs a Partial Copy or Full sandbox with production-shaped data, and it is one of the clearest cases for having one, as covered in sandbox strategy.
Frequently asked
Can I undo a field type change? No. You can change it back, and the data lost in the first change does not return.
Does it lock the object? On a large object the change runs as a background job and can take hours. Plan it as a maintenance activity, not a configuration tweak.
What about changing a picklist to a multi-select? Permitted, and going back is not. Multi-select to picklist loses every record with more than one value selected.
