4.2 Fields, Formulas, Rollups, Validation, and Requiredness

Salesforce Admin Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Platform Administrator Orientation and Official Source Control

1.1 Credential Name, Current Outline, and Search Language 1.2 Exam Format, Fee, Score, and Reference Rules 1.3 Trailhead, Trailhead Academy, and Pearson VUE Delivery Workflow 1.4 Domain Weights, Agentforce, and Study Prioritization 1.5 Maintenance Modules, Credential Ethics, and Exam Security 1.6 Developer Edition, Trailhead Playground, and Practice Bank Workflow

2 Chapter 2: Configuration, Setup, User Management, and Org Controls

2.1 Company Information, Fiscal Year, Business Hours, and Locale 2.2 User Records, Licenses, Profiles, Permission Sets, and Login Access 2.3 Login Security, Session Settings, and Identity Basics 2.4 Setup Navigation, Release Readiness, and Change Control 2.5 UI Settings, Home Pages, Apps, and Navigation 2.6 Configuration and Setup Case Lab

3 Chapter 3: Security, Access, Identity, and Sharing Model

3.1 Org-Wide Defaults, Roles, Sharing Rules, and Teams 3.2 Profiles, Permission Sets, Permission Set Groups, and Muting 3.3 Field-Level Security, Page Layouts, and Dynamic Forms 3.4 Record Access Troubleshooting and Login-As Workflow 3.5 Identity, Login History, MFA, and Session Risk 3.6 Data Visibility, Reporting, and Analytics Security 3.7 Security and Access Case Lab

4 Chapter 4: Object Manager, Lightning App Builder, and Data Modeling

4.1 Standard Objects, Custom Objects, and Schema Fit 4.2 Fields, Formulas, Rollups, Validation, and Requiredness 4.3 Lookup, Master-Detail, and Junction Relationships 4.4 Record Types, Business Processes, Page Layouts, and Lightning Pages 4.5 Dynamic Forms, Dynamic Actions, and User Experience 4.6 Schema Change Risk, Data Quality, and Deployment Readiness 4.7 Object Modeling Case Lab

5 Chapter 5: Sales, Marketing, Service, and Support Applications

5.1 Lead, Campaign, Account, Contact, and Opportunity Flow 5.2 Sales Processes, Path, Products, Price Books, and Forecasting 5.3 Case Management, Queues, Assignment, Auto-Response, and Escalation 5.4 Knowledge, Entitlements, Service Console, and Support Productivity 5.5 Sales-Service Data Quality and Automation Boundaries 5.6 Application Configuration Troubleshooting 5.7 Sales and Service Applications Case Lab

6 Chapter 6: Data and Analytics Management

6.1 Data Import Wizard, Data Loader, Export, and Backup 6.2 Duplicate Management, Validation, and Data Quality Controls 6.3 Data Transfer, Ownership, Mass Update, and Mass Delete 6.4 Report Types, Filters, Summary Formulas, and Buckets 6.5 Dashboards, Components, Subscriptions, and Sharing Impact 6.6 Analytics Security, Visibility, and Executive Reporting 6.7 Data and Analytics Case Lab

7 Chapter 7: Automation, Flow, Approval, and Operational Processes

7.1 Automation Tool Selection and Order of Execution 7.2 Flow Builder: Screen, Record-Triggered, Scheduled, and Autolaunched Flows 7.3 Approval Processes, Email Alerts, and Notification Patterns 7.4 Validation Rules, Assignment Rules, and Escalation Rules 7.5 Automation Testing, Debugging, and Governance 7.6 Automation Performance, Recursion, and Maintainability 7.7 Automation Case Lab

8 Chapter 8: Productivity, Collaboration, Mobile, and AppExchange

8.1 Activities, Tasks, Events, Calendar, and Email Productivity 8.2 Chatter, Feeds, Groups, Notifications, and Collaboration Governance 8.3 Salesforce Mobile Navigation, Actions, and Page Design 8.4 List Views, Kanban, Path, and User Adoption Tools 8.5 AppExchange Evaluation, Installation, Permissions, and Risk 8.6 Productivity and Collaboration Case Lab

9 Chapter 9: Agentforce for Platform Administrators

9.1 Agentforce Use Cases, Admin Boundaries, and Fit 9.2 Trusted AI, Security, Data Access, and Permission Implications 9.3 Agent Builder, Prompt Builder, and Grounding Concepts 9.4 Testing, Deployment, Monitoring, and Feedback Workflows 9.5 Agentforce Service, Sales, and Internal Productivity Scenarios 9.6 Agentforce Risk, Troubleshooting, and Governance 9.7 Agentforce Case Lab

10 Chapter 10: Integrated Salesforce Admin Scenario Labs

10.1 New Sales Org Setup Integrated Lab 10.2 Service Team Case Management Integrated Lab 10.3 Data Quality and Analytics Integrated Lab 10.4 Security, Access, and Reporting Integrated Lab 10.5 Flow Automation and Change Control Integrated Lab 10.6 Agentforce and Adoption Integrated Lab 10.7 Full Admin Simulation Strategy

11 Chapter 11: Final Review, Maintenance, and Test-Day Strategy

11.1 Final 30-Day Salesforce Admin Review Plan 11.2 Trailhead Playground Hands-On Drill Plan 11.3 105-Minute Exam Timing, Flagging, and Review Workflow 11.4 Test-Day Checklist: Online or Test Center 11.5 Post-Exam Maintenance Modules and Next Certifications 11.6 Salesforce Admin Final Mixed Review

4.2 Fields, Formulas, Rollups, Validation, and Requiredness

Key Takeaways Explain This Topic AI

Field type choices affect reporting, automation, integrations, conversion options, and data quality, so choose the narrowest type that represents the value accurately.

Formula fields calculate values and stay read-only, while validation rules block saves that do not meet business rules.

Native roll-up summary fields summarize child records across master-detail relationships and a few standard relationships, such as accounts over opportunities; other lookups need a different design or automation.

Requiredness can come from field definition, page layout, dynamic form behavior, validation rules, or automation, and each applies in a different context.

Last updated: October 2026

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.

Need Better tool Why it fits

Calculate age from a date Formula field The value should update automatically and not be edited.

Prevent close date in the past for open opportunities Validation rule The rule blocks invalid saves across supported entry points.

Count related detail records Roll-up summary field Native roll-ups work across master-detail relationships.

Require a value only for one sales process Validation rule or layout by record type The requirement is conditional, not universal.

Show different fields to different users Field-level security and page design Visibility must respect security, not only layout preference.

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 work on master-detail relationships, plus a few standard relationships such as accounts summarizing their related opportunities. For other lookup relationships, 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.

Required mechanism Best use Trap

Field required setting Always required for every record of that object Can disrupt imports and integrations if added without data cleanup.

Page layout required Required in a specific layout-driven user experience Does not replace data quality controls for every save path.

Dynamic Forms required Required in a Lightning page field component context Visibility and requirement behavior must be tested by app, record type, and form factor.

Validation rule Required only when conditions are met A poorly written rule can block admins, automation, or data loads unexpectedly.

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:

Identify the business question the field answers.

Choose the field type and allowed values.

Decide whether the value is entered, calculated, summarized, or derived by automation.

Configure field-level security for the right users.

Add the field to layouts, Lightning pages, compact layouts, reports, and search layouts as needed.

Add validation only after testing realistic create, edit, import, and automation paths.

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.