4.1 Field Type Conversions & Data Loss Considerations
Key Takeaways
Converting a Lookup relationship to a Master-Detail relationship requires that every existing record in the database contains a populated, non-null value in the lookup field.
Converting a Master-Detail relationship to a Lookup relationship requires deleting all roll-up summary fields referencing the detail object and permanently hard-purging them from the Deleted Fields recycle bin.
Changing a Multi-Select Picklist to a Single-Select Picklist permanently truncates data, retaining only the first chosen value and irrecoverably discarding all secondary selections.
Converting Text to Auto-Number retains compatible historical text while numbering new records; review the 30-character limit.
Custom field type conversions are completely blocked if the field is referenced in active formula fields, validation rules, Apex triggers/classes, Flow criteria, or approval processes.
Field Type Conversions & Data Loss Considerations
Important
Modifying custom field definitions in Salesforce Object Manager is a powerful declarative capability, but it carries substantial risks of irreversible data loss, schema corruption, and downstream automation failure. Understanding which conversions preserve data integrity and which cause permanent data truncation is a foundational requirement for the Platform App Builder certification.
In an evolving Salesforce implementation, business requirements frequently change, necessitating updates to data models. While administrators can modify custom field data types post-deployment, standard fields (such as Account Name or Close Date) have permanent, unalterable data types. When altering custom field types, the platform evaluates whether existing data can be safely converted or if the schema modification will truncate values, drop historical selections, or violate referential integrity.
Custom Field Data Type Conversions & Truncation Risks
Converting custom field data types requires an understanding of how underlying database columns handle typing, precision, and character encoding. Certain conversions are entirely safe, while others result in partial or total data loss.
Picklist and Multi-Select Picklist Conversions
Picklists and multi-select picklists exhibit nuanced behaviors during data type changes:
- Text to Picklist: Salesforce warns that this conversion can lose data. Export values, define the intended picklist entries, and verify every resulting value in a sandbox; do not assume arbitrary text is automatically added as an allowed option.
- Picklist to Text: Safe conversion. Existing picklist selections are converted to raw text strings matching their API values. However, picklist dependencies, restricted picklist value set rules, and global value set linkages are permanently removed from the field definition.
- Single-Select Picklist to Multi-Select Picklist: Defined picklist values are retained. Existing record values absent from the field's value definition can be lost, so audit inactive and undefined values and export first.
- Multi-Select Picklist to Single-Select Picklist (High-Risk Data Loss): When converting from a multi-select picklist to a single-select picklist, Salesforce preserves only the first selected value in each record's delimited string. All secondary and subsequent selections are permanently dropped and erased from the database.
Warning
If an Account record has the multi-select picklist values "Gold;Silver;Bronze", converting that field to a single-select picklist permanently retains only "Gold". "Silver" and "Bronze" are immediately destroyed without generating a warning prompt on individual records. Always perform a full data export before converting multi-select picklists.
Numeric, Currency, and Percent Conversions
Numeric fields in Salesforce are defined by their total length (precision) and decimal places (scale), constrained by the rule that integer digits plus decimal digits cannot exceed 18 (e.g., length 16 with 2 decimals):
- Reducing Scale (Decimal Places): If an administrator reduces decimal places (e.g., from 3 decimals to 1 decimal), existing values are rounded or truncated to fit the new scale.
- Reducing Precision (Integer Length): Decreasing total integer length can cause data loss if existing records contain values exceeding the new maximum character limit.
- Number to Currency: Stored numerical values are preserved and formatted with the organization's default currency symbol (e.g.,
$1,500.00). In multi-currency organizations, the stored value assumes the record's corporate currency. - Number or Currency to Percent: A numerical value of
10converted to Percent displays as10%, but internal calculations evaluate it as0.10. Downstream formula fields and validation rules must be reviewed to prevent calculation errors.
Auto-Number and Text Conversions
Converting between Auto-Number and Text fields is a common requirement when transitioning from legacy identifiers to automated numbering systems:
- Auto-Number to Text: Current auto-number values are frozen and converted into static text strings. The auto-increment engine ceases, allowing users to manually edit or overwrite values going forward.
- Text to Auto-Number: Existing text can be retained. Auto-number values have a 30-character maximum; shorten incompatible existing values before conversion. Verify the numbering options offered for the actual field and test new records rather than assuming that all historical text will be overwritten.
Conversion Availability and Data Preservation
The available Change Field Type choices depend on the source field. A missing choice means the conversion is unsupported; it is not permission to force a destructive transformation. Salesforce warns about potential data loss for date/time, numeric, percent, currency, checkbox, multi-select, and several text conversions. Picklist-to-checkbox can map selected values to checked/unchecked states. Formula fields cannot be converted to another type, and another field cannot be converted into a formula field.
For date and time changes, create a replacement field and explicitly transform/export/import values when the desired direct conversion is unavailable. Verify timezone semantics, empty values, maximum lengths, decimals, and downstream formulas with known sample records. Keep the backup until record-level reconciliation succeeds.
Custom Field Type Conversion Risks & Behavior Matrix
| Source Data Type | Target Data Type | Conversion Feasibility | Data Truncation / Loss Impact | Administrative Consideration |
|---|---|---|---|---|
| Text | Picklist | Check available conversion | Potential data loss; audit value definitions | Export and reconcile values first |
| Picklist | Text | Check dependencies | Audit values and dependencies | Review formulas, integrations, and value sets |
| Picklist | Multi-Select Picklist | Supported | Defined values retained; undefined record values can be lost | Test historical selections |
| Multi-Select Picklist | Picklist | Supported; destructive | Secondary selections lost | Export and define one intended value per record |
| Number / Currency / Percent | Other numeric type | Check available choices | Precision and percent semantics can change | Test known amounts and ratios |
| Auto-Number | Text | Supported | Existing text retained | Future records no longer auto-number |
| Text | Auto-Number | Supported | Preserve compatible historical text | Maximum 30 characters; test numbering |
| Date / DateTime / Checkbox | Another type | Not every conversion is available | Potential data loss or unsupported conversion | Use a replacement field and explicit migration when needed |
| Formula | Another field type | Unsupported | Create a new field instead | Rebuild references deliberately |
Relationship Field Conversions: Lookup vs. Master-Detail
Converting relationships between loosely coupled (Lookup) and tightly coupled (Master-Detail) architectures represents one of the most heavily tested declarative tasks on the Platform App Builder exam.
+-----------------------------------------------------------------------------------+
| RELATIONSHIP CONVERSION PREREQUISITES |
+-----------------------------------------------------------------------------------+
| LOOKUP =======> MASTER-DETAIL |
| 1. Every single child record MUST have a valid parent populated in the lookup. |
| 2. No null/blank lookup values are permitted in the entire database. |
| 3. Child custom object must not already have 2 Master-Detail relationships. |
| 4. Detail record cannot be a standard object. |
+-----------------------------------------------------------------------------------+
| MASTER-DETAIL =======> LOOKUP |
| 1. ALL Roll-Up Summary fields on the master referencing the detail must be |
| deleted. |
| 2. Deleted roll-up summary fields must be PERMANENTLY ERASED from the |
| 'Deleted Fields' recycle bin before conversion is permitted. |
+-----------------------------------------------------------------------------------+
Converting Lookup to Master-Detail
Because master-detail relationships enforce strict referential integrity—where child records cannot exist without a parent—Salesforce will not allow an administrator to convert an existing Lookup relationship field to a Master-Detail relationship if any existing child record has a blank (null) lookup field.
To successfully convert Lookup to Master-Detail:
- Execute a report or SOQL query (
SELECT Id FROM Child__c WHERE Parent__c = null) to identify orphaned child records. - Update all records to populate a valid parent reference.
- Verify that the custom object does not already possess two Master-Detail relationships (the platform architectural limit is 2 per object).
- Confirm that the child object is a custom object (standard objects can never reside on the detail side of a custom relationship).
- Navigate to Object Manager, edit the lookup field, click Change Field Type, and select Master-Detail Relationship.
Converting Master-Detail to Lookup & The Deleted Fields Trap
Master-Detail relationships enable Roll-Up Summary fields on the master object, whereas Lookup relationships do not natively support roll-ups. Consequently, Salesforce blocks converting a Master-Detail relationship to a Lookup if any Roll-Up Summary fields exist on the master object that reference the detail object.
Important
The Deleted Fields Trap: Merely clicking "Delete" on a roll-up summary field does not remove its underlying schema dependency. In Salesforce, deleted fields enter a soft-deleted state within the Deleted Fields holding bin for up to 15 days. As long as the roll-up summary remains in the Deleted Fields bin, the platform will continue to block the relationship conversion. An administrator must navigate to Object Manager > Master Object > Fields & Relationships > Deleted Fields, and click Erase to permanently hard-purge the roll-up field before the relationship can be converted.
Once converted to a Lookup, the child object gains independent ownership (an Owner field is added), independent sharing rules and Organization-Wide Defaults, and cascade deletion ceases.
Declarative & Programmatic Dependency Blockers
Salesforce enforces metadata dependency tracking to protect system stability. An administrator cannot change the data type of any custom field if that field is actively referenced in downstream platform components:
- Formula Fields: If a formula references a field (e.g.,
AnnualRevenue * Discount_Rate__c), the data type ofDiscount_Rate__ccannot be modified. - Validation Rules: Fields referenced in validation criteria must have their validation formulas removed or updated before altering the data type.
- Salesforce Flow & Process Automation: Active or inactive versions of Record-Triggered Flows, Screen Flows, Autolaunched Flows, or Approval Processes that reference the field will block type conversion.
- Apex Code: Apex classes and triggers referencing the field API name will throw deployment/conversion blocks until the code references are commented out or refactored.
- Shield Platform Encryption: Fields encrypted with Shield Platform Encryption or Classic Encryption cannot be converted to unsupported data types without first removing encryption.
Tip
When encountering a "Field In Use" error when attempting to change a field type, click the Where is this used? button on the custom field detail page in Object Manager. This tool provides a useful but incomplete dependency list across formulas, validation rules, flows, and page layouts, expediting remediation before conversion.
Official Source Check
Checked October 19, 2026: Field conversion restrictions.
Universal Containers tracks customer equipment installations on a custom Installation__c object. Installation__c currently references Account through a Lookup relationship. Management requests converting this relationship into a Master-Detail relationship so that total completed installations can be displayed on the Account page layout using a Roll-Up Summary field. When the administrator attempts to change the field type in Object Manager, Salesforce displays an error preventing the change. What is the most likely cause of this issue?
Existing Installation__c records exist in the database where the Account lookup field is blank or null.
The Account standard object cannot serve as the master record in a master-detail relationship with a custom object.
Roll-up summary fields must be created on the Account object prior to changing the relationship type.
The administrator must delete the existing lookup field and create a new master-detail relationship field from scratch.
An administrator needs to modify the custom field Support_Tier__c on the Account object from a Multi-Select Picklist to a Single-Select Picklist to enforce cleaner categorization. The field currently contains multi-value selections on several hundred accounts (for example, 'Gold;Platinum'). What occurs to existing record data when this field type conversion is executed?
All existing values are preserved as comma-separated text strings within the newly converted picklist field.
Only the first value in each record's multi-select string is retained in the picklist, and all secondary values are permanently lost.
Salesforce blocks the conversion until an administrator manually clears secondary values from all existing records.
The conversion succeeds without data loss by automatically generating duplicate account records for each selected value.
A custom object Project_Milestone__c is currently the detail object in a Master-Detail relationship with Project__c. Business requirements change, and Project_Milestone__c records now need independent ownership and sharing rules, requiring a conversion to a Lookup relationship. The administrator deletes the only Roll-Up Summary field on Project__c that referenced milestones. However, when attempting to convert the relationship in Object Manager, Salesforce still displays an error stating that roll-up summaries exist. What step must the administrator take to allow the conversion?
Deactivate all workflow rules, processes, and flows that reference the Project_Milestone__c object.
Export all Project_Milestone__c records, delete them from the org, convert the relationship, and re-import the records.
Navigate to Deleted Fields on the Project__c object and permanently erase the deleted roll-up summary field.
Change the Organization-Wide Default sharing setting of Project_Milestone__c from Controlled by Parent to Private.
Sections you finish are checked off in the contents.