Data Types and Field Choice for Data Quality

Why This Topic Matters
Data quality is the foundation of every report, dashboard, automation, and AI feature in Salesforce. If users can type anything they want into a free-text field, you end up with "CA", "Calif.", "California", and "california" all meaning the same thing, which breaks reporting, filtering, and automation. Choosing the correct field data type is the first line of defense for data quality because it enforces structure at the moment of entry, before validation rules, duplicate rules, or cleanup tools are ever needed. On the Advanced Administrator exam, this falls under Advanced Data and Analytics Management, and questions test whether you can select the field type that best prevents bad data while still meeting the business requirement.

What It Is
Field choice for data quality means selecting the Salesforce field data type (and its configuration) that most tightly constrains input to valid values while remaining usable and reportable. The core principle: the more structured the field type, the higher the data quality. A text field accepts anything; a picklist accepts only defined values; a lookup accepts only existing records; a checkbox accepts only true/false. Your job as an admin is to pick the most restrictive type that still satisfies the requirement.

Key Field Types and Their Data Quality Implications

1. Picklist and Multi-Select Picklist
Best for standardizing a known, finite set of values (Status, Region, Industry). Picklists are reportable, filterable, and can be grouped in reports. Use Restricted Picklists to prevent values from being added via API or data loads; unrestricted picklists allow new values through integrations, which degrades quality. Use Global Value Sets when the same list is needed on multiple objects so values stay consistent across the org. Use Dependent Picklists to constrain the child values based on the controlling field (e.g., Country controls State), eliminating invalid combinations. Avoid multi-select picklists where possible: they are hard to report on, cannot be used as controlling fields, cannot be referenced in roll-up summaries, and have limited formula support. If a requirement says "users must select only from approved values" or "standardize entries", think picklist.

2. Text, Text Area, Long Text Area, Rich Text Area
Lowest data quality control because any value can be entered. Use only when values are truly unpredictable (names, notes, descriptions). Long Text Area and Rich Text cannot be used in report filters effectively, cannot be used as grouping fields, and cannot be referenced in some formula/validation contexts. If a question presents a text field with inconsistent values causing reporting problems, the fix is almost always converting to a picklist (with data cleanup) or adding a validation rule, not adding more text instructions.

3. Lookup and Master-Detail Relationships
Use a lookup instead of text when the value should reference an existing record (e.g., Account Owner's Manager, Preferred Partner). This guarantees referential integrity: users can only pick records that exist, and if the name changes, it updates everywhere. Lookup Filters further improve quality by limiting which records can be selected (e.g., only Contacts related to the same Account). Master-detail enables Roll-Up Summary fields, which calculate totals from child records automatically rather than relying on manually entered numbers. If a question mentions "users are typing account names into a text field" or "the related record name is misspelled", the answer is a lookup.

4. Number, Currency, Percent
Enforce numeric input and allow aggregation (sum, average) in reports. Choose Currency for monetary values so multi-currency conversion works; a Number field storing dollars will not convert. Choose Percent for percentages so formulas and displays behave correctly. Set appropriate length and decimal places to prevent impossible values (e.g., 2 decimals for currency). Never store numbers in text fields: you lose sorting, math, and aggregation.

5. Date and Date/Time
Enforce valid date entry with a date picker and enable date-based reporting (grouping by month/quarter, relative date filters like LAST 30 DAYS). Use Date when time of day is irrelevant (Birthdate, Contract Start) and Date/Time when the exact moment matters (Meeting Time). Storing dates in text fields destroys date filtering and is a classic exam "wrong design" scenario.

6. Checkbox
Enforces a strict true/false value. Better than a Text field or Yes/No picklist when the attribute is truly binary. Checkboxes are easy to filter and use in formulas. Note: a checkbox cannot be made required and cannot represent "unknown", so if a third state is needed (Yes/No/Unknown), use a picklist instead.

7. Email, Phone, URL
Provide format validation and functional behavior: Email fields validate basic format and enable click-to-email; Phone fields enable click-to-dial and formatting; URL fields validate format and render as links. Always prefer these over plain text for the corresponding data.

8. Formula and Roll-Up Summary Fields
These are read-only, calculated fields and therefore the highest-quality option whenever a value can be derived rather than entered. If users are manually typing a value that could be computed (Days Open, Total Opportunity Amount, Full Name), replace the manual field with a formula or roll-up summary so it can never be wrong or stale. Roll-ups require master-detail; formulas work across lookups.

9. Auto Number
Guarantees a unique, system-generated identifier. Use instead of asking users to type reference numbers.

10. External ID and Unique Fields
Mark a field Unique to prevent duplicate values at the field level (e.g., Employee ID). Mark it External ID to support upserts from integrations, so records are matched and updated rather than duplicated. Case-sensitive vs. case-insensitive uniqueness is an option to understand.

11. Geolocation, Time, Encrypted Text
Geolocation stores latitude/longitude as a compound field for distance calculations. Time stores time-of-day without a date. Encrypted Text (classic encryption) masks data but has heavy limitations (not usable in filters, formulas, or validation rules), so it is less about quality and more about security; Shield Platform Encryption is the modern approach.

How It Works in Practice: Supporting Features

Required fields: Make a field required at the field level (universally required) or page layout level. Universal requirement applies to API and data loads too; layout-level does not. Exam questions asking to enforce data entry "regardless of how the record is created" point to universally required fields or validation rules.

Validation Rules: Add logic beyond the field type (e.g., Close Date cannot be in the past, Discount cannot exceed 20% unless Stage = Negotiation). They complement, not replace, correct field type selection.

Field-Level Help and Description: Help text guides users to enter correct data; Description documents the field's purpose for admins. Neither enforces quality, so they are rarely the "correct" answer when enforcement is required.

Duplicate and Matching Rules: Prevent duplicate records; often tested alongside field choice.

Changing Field Types: Converting an existing field's type can cause data loss (e.g., text to picklist keeps values but may create unexpected picklist entries; text to number drops non-numeric values; shrinking length truncates). Some conversions are not allowed (e.g., to/from Auto Number in certain cases, anything involving Formula or Roll-Up Summary). Know that a field type change should be preceded by a data export and cleanup.

Exam Tips: Answering Questions on Data Types and Field Choice for Data Quality

Tip 1: Apply the "most restrictive type that meets the requirement" rule. If values are a known set, choose picklist over text. If the value references a record, choose lookup over text. If the value can be calculated, choose formula/roll-up over any manual field. If it is binary, choose checkbox.

Tip 2: Watch for keywords. "Standardize", "consistent values", "only approved options" = Picklist (often Restricted). "Same values on multiple objects" = Global Value Set. "Values depend on another field" = Dependent Picklist. "Must reference an existing record" = Lookup. "Only related records should be selectable" = Lookup Filter. "Total of child records" = Roll-Up Summary (master-detail). "Prevent duplicates for this value" = Unique field. "Integration should update not duplicate" = External ID. "Including via API/data loader" = Restricted Picklist or Universally Required field.

Tip 3: Eliminate weak answers. Answers that rely on help text, training, documentation, or "asking users to be careful" do not enforce quality. On this exam, enforcement beats guidance unless the question explicitly asks only for guidance.

Tip 4: Know multi-select picklist limitations. If a scenario needs reporting, grouping, controlling-field behavior, or roll-ups, a multi-select picklist is usually the wrong choice. Consider a junction object or separate checkbox/picklist fields instead.

Tip 5: Know Restricted vs. Unrestricted picklists. Unrestricted picklists allow new values to be introduced via Data Loader or API, which is a common root cause of "unexpected values appearing in reports" scenarios.

Tip 6: Understand required-field scope. Page layout required only affects UI users on that layout; universally required affects all entry methods. Validation rules can enforce conditional requirements.

Tip 7: Remember report and formula implications. Long Text Area and Rich Text cannot be grouped or filtered well; Text storing numbers or dates cannot be aggregated or date-filtered. If the complaint is about reporting, the root cause is usually the field type.

Tip 8: Be cautious about field type conversions. If a question asks about changing an existing field, consider data loss risk and the inability to convert formula or roll-up fields. The best answer often includes exporting data first or creating a new field and migrating data.

Tip 9: Currency vs. Number. Multi-currency orgs require Currency fields for conversion. If an answer suggests a Number field for money, it is likely wrong.

Tip 10: Checkbox cannot be required and has no "unknown" state. If the scenario needs to distinguish "not answered" from "No", choose a picklist.

Quick Scenario Walkthrough
Scenario: Sales reps type the lead source into a text field. Reports show dozens of variations of "Web" and "Trade Show". The VP wants clean, consistent reporting, and the marketing automation tool also loads leads via API.
Analysis: Known finite set = picklist. API loading could introduce new values = Restricted picklist. Existing data must be cleaned (export, standardize, reimport). Validation rules alone would not fix reporting consistency as well as a structured type.
Best answer: Convert to a Restricted Picklist (after cleaning existing data), not "add help text" or "create a validation rule on the text field".

Summary
Field type choice is proactive data quality. Structured types (picklist, lookup, checkbox, date, number/currency, formula, roll-up) constrain input and enable accurate reporting; unstructured types (text) invite inconsistency. On the exam, identify the nature of the data, pick the most restrictive type that fits, layer on restricted/dependent picklists, lookup filters, unique/external IDs, required settings, and validation rules as needed, and always favor enforcement over guidance.