4.1 Standard Objects, Custom Objects, and Schema Fit

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.1 Standard Objects, Custom Objects, and Schema Fit

Key Takeaways Explain This Topic AI

Start with standard objects when they already represent the business noun, because they bring native relationships, features, reporting, and app behavior.

Use custom objects when the organization needs to store a distinct business concept with its own lifecycle, ownership, relationships, and reporting needs.

A good schema fit accounts for security, automation, reporting, integrations, mobile use, and long-term maintenance, not just the first screen users ask for.

Object Manager changes are metadata changes, but the data model choices they create can be expensive to unwind after records, flows, and reports depend on them.

Last updated: May 2026

Choosing the Right Object Shape

Object Manager is where an administrator defines the objects, fields, relationships, buttons, record types, compact layouts, page layouts, and other metadata that describe how business data is stored. The first modeling decision is not which custom object to create. The first decision is whether Salesforce already has a standard object that matches the business noun closely enough.

Standard objects such as Account, Contact, Lead, Opportunity, Case, Campaign, Product, Asset, Contract, and User are more than tables. They participate in native application features, automation entry points, sharing behavior, reporting types, related lists, mobile experiences, and setup pages. If the business wants to manage customer support requests, Case is usually the starting point. If it wants to track sales revenue and pipeline, Opportunity is usually the starting point.

A custom object is appropriate when the organization has a durable concept that standard objects do not represent well. Examples include Grant Application, Facility Inspection, Subscription Entitlement, Course Enrollment, or Warranty Claim. A custom object can have its own tab, fields, relationships, record types, sharing model, reports, automation, and Lightning record page. That power is useful, but it also creates maintenance responsibility.

Do not create a custom object just because users say they need a new screen. The request may be a field on an existing object, a record type, a page layout, a related list, a list view, a report, or a Lightning page variation. Creating the wrong object can split the customer story across too many records and make reporting, security, deduplication, and automation harder.

Requirement clue Likely design direction Admin reasoning

Tracks a sales deal amount, close date, and stage Standard Opportunity Native pipeline, forecasting, products, and sales reports are already aligned.

Tracks a support issue from intake to resolution Standard Case Queues, assignment, escalation, email, and service reporting are already available.

Tracks a recurring inspection with its own status and findings Custom object The concept has its own lifecycle and needs related records.

Tracks a customer category or preference Field or picklist A full object would add unnecessary navigation and joins.

Tracks two variants of the same object with different fields and processes Record types and layouts The records share the same business noun and reporting base.

In Setup, the practical workflow is to open Object Manager, review the object list, inspect fields and relationships on likely standard objects, and check whether existing apps already expose the behavior. In a Trailhead Playground or Developer Edition org, build a tiny proof of concept before committing. Create sample records, try a report, view the mobile layout, and test whether the object model answers the actual business question.

Schema fit includes ownership and security. Some objects have special behavior that affects sharing or feature access. Custom objects can use organization-wide defaults, role hierarchy access, sharing rules, teams where supported by product features, and permissions through profiles and permission sets. Before creating an object, ask who owns records, who needs to see them, and whether access differs by region, function, or record type.

Schema fit also includes reporting. If executives need one report showing Accounts, Opportunities, and the new concept, the relationship path matters. If operations needs to group the new concept by status, owner, date, and parent account, those fields must exist in report-friendly types. A field buried in long text or encoded in a naming convention is not a reportable model.

Integration and automation are part of the same decision. API names become contracts for integrations, flows, validation rules, formulas, and reports. A custom object that seems simple on day one may later need record-triggered flows, duplicate rules, approval processes, external IDs, and data imports. Choose names and relationships that still make sense when another system reads or writes the records.

A common exam trap is confusing navigation with data storage. Adding a tab makes an object easier to find, but it does not grant object permissions. Adding a related list shows related records, but it does not create the relationship field. Creating a Lightning page changes the experience, but it does not change the underlying schema. Admins need to know which setup area changes data structure and which changes presentation.

Another trap is assuming custom always means flexible. Standard objects often have the most flexible business value because Salesforce has built surrounding features around them. Custom objects are flexible in structure, but they lack some native app behavior unless you configure it or build it. The best model uses standard capability where it fits and reserves custom schema for concepts the platform does not already model.

A concise checklist helps before you build:

Name the business noun and its lifecycle.

Check standard objects and existing custom objects first.

Identify parent records, child records, and reporting questions.

Decide who owns records and who must access them.

Consider whether record types or fields solve the variation.

Prototype with sample records, reports, and a Lightning page.

Review downstream impact on automation, integrations, and data imports.

For the exam, expect scenario language. If the request says users need different values, screens, or processes for the same kind of record, think record types, page layouts, and business processes. If the request describes a separate thing with its own records, owner, security, and reporting, think custom object. If the request describes one attribute of an existing thing, think field.