4.2 Fields, Formulas, Rollups, Validation, and Requiredness

Field Design and Data Quality

A field is a contract between users, reports, automation, integrations, and future admins. In Object Manager, field creation starts with a data type, but the real decision is how Salesforce should understand the value. A date is different from text that looks like a date. Currency is different from number. Picklist is different from free text. These choices determine filtering, grouping, validation, formulas, imports, and integration behavior.

Choose the most specific field type that honestly represents the data. Use picklists when values should be controlled and reported consistently. Use checkbox fields for true or false flags. Use lookup or master-detail relationships when the value is another record, not a name typed into text. Use long text only when the business needs narrative detail that is not meant for grouping or precise reporting.

Field type changes can be restricted after data exists or after metadata depends on the field. A casual text field used by flows, formulas, reports, and integrations can become hard to replace. Good admins ask about the reporting question, import source, validation rule, automation use, and expected future values before creating the field.

Formula fields are read-only calculations. They can reference fields on the same record and, in many cases, parent fields through relationships. They are useful for labels, scoring, aging, status indicators, and derived values. A formula is not a place to store history, because it recalculates when referenced data changes. If the business needs the value as it was at a point in time, automation that writes to a stored field may be more appropriate.

Roll-up summary fields are summaries on the master record that aggregate detail records. Common choices include count, sum, minimum, and maximum, depending on the child field type. The key exam point is relationship type: native roll-up summary fields require master-detail. If the relationship is lookup, the admin may need a report, a custom report type, Flow, or another approved tool, but the native roll-up summary field is not available in the same way.

Validation rules evaluate record data and return an error when the rule condition is true. They are strong for business rules such as requiring a reason when status changes to Rejected, preventing an end date before a start date, or requiring a competitor when an opportunity is marked lost. Write the error message for the user, not for the formula author. Place it near the field when possible.

Requiredness has several layers. A universally required custom field at field definition is enforced broadly and should be used sparingly because existing records, imports, integrations, and automation must provide a value. A page layout required field mainly guides users in that page experience. A Dynamic Forms field can be configured as required in its component context. A validation rule is best when the requirement is conditional, such as requiring an implementation partner only for enterprise deals.

Admins should also think about help text, description, default value, field-level security, history tracking, and external IDs. Help text supports users. Description supports future admins. Field-level security controls who can see or edit the value. External IDs and unique fields support integration and deduplication patterns. History tracking can help audit important changes, but it should be reserved for fields where change history has business value.

A reliable field build workflow is:

1. Identify the business question the field answers.
2. Choose the field type and allowed values.
3. Decide whether the value is entered, calculated, summarized, or derived by automation.
4. Configure field-level security for the right users.
5. Add the field to layouts, Lightning pages, compact layouts, reports, and search layouts as needed.
6. Add validation only after testing realistic create, edit, import, and automation paths.
7. Create sample records and confirm reporting behavior.

The exam often describes the same business requirement with slightly different language. If the value must be calculated and not edited, think formula. If the value must summarize child records and the relationship is master-detail, think roll-up summary. If the save should be blocked when data is invalid, think validation rule. If the issue is that users cannot see or edit a field, check field-level security before blaming page layout.