Study guide
4.1 Field Type Conversions & Data Loss Considerations
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
4.1 Field Type Conversions & Data Loss Considerations
Key Takeaways Explain This Topic AI
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.
Last updated: October 2026
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 10 converted to Percent displays as 10% , but internal calculations evaluate it as 0.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 of Discount_Rate__c cannot 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 .