4.7 Object Modeling Case Lab

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.7 Object Modeling Case Lab

Key Takeaways Explain This Topic AI

A modeling lab should begin with business nouns, relationships, ownership, lifecycle, reporting questions, and user experience needs before metadata is built.

The right design often combines standard objects, custom objects, fields, record types, relationships, validation, and Lightning pages.

Hands-on testing with sample records exposes flaws in relationship choice, requiredness, page activation, and reporting assumptions.

Admin exam scenarios reward practical tradeoff reasoning: avoid unnecessary custom objects, but create them when the business concept truly needs records.

Last updated: May 2026

Case Lab: Modeling Customer Training Delivery

Scenario: a software company sells implementation services and customer training. Leadership wants Salesforce to track which customer accounts buy training, which courses are delivered, who attends, instructor assignments, and post-course satisfaction. Sales already uses Account, Contact, Opportunity, Product, and Case. The admin must decide what belongs on standard objects, what needs custom objects, and how users should work with the records.

Start by listing business nouns. Account and Contact already exist. Opportunity can track the sale of training packages. Product can represent sellable course offerings if the sales process uses products. A delivered class is not the same as a product; it has a date, capacity, instructor, delivery method, location, status, and attendance. An attendee's enrollment is also its own concept because it connects one contact to one delivered class and has status, attendance, and survey score.

A reasonable model could include a custom Course Delivery object and a custom Enrollment junction object. Course Delivery relates to Account when the class is private for a customer, and may relate to Product or a custom Course Catalog object if the company needs reusable curriculum records. Enrollment relates Contact to Course Delivery. Instructor Assignment could be a lookup to User from Course Delivery if there is one primary instructor, or a separate child object if multiple instructors need roles and hours.

Requirement Design choice Reasoning

Track the customer organization Standard Account Native customer model and reporting already exist.

Track people who attend Standard Contact Attendees are people related to accounts.

Track the sold training package Standard Opportunity and Products Sales pipeline and revenue should stay in sales objects.

Track a scheduled class instance Custom Course Delivery object Each delivery has its own lifecycle and operational fields.

Track each attendee in each class Enrollment junction object Many contacts can attend many deliveries.

Track satisfaction by attendee Field on Enrollment The score describes the attendee's experience in that class.

Now choose relationships. Course Delivery to Account might be lookup if public courses can exist without a single customer account, or master-detail if every delivery must belong to one account and inherit access. Enrollment to Course Delivery is often master-detail because an enrollment should not exist without the delivery, and the delivery may need roll-ups such as number of enrollments. Enrollment to Contact could be lookup or master-detail depending on ownership and deletion needs; many orgs prefer lookup to Contact to avoid overly tight lifecycle behavior.

Fields should match reporting questions. Course Delivery needs Status, Start Date, End Date, Delivery Method, Capacity, Location, Primary Instructor, and maybe Course Level. Enrollment needs Enrollment Status, Attendance Status, Registration Date, Completion Date, Survey Score, and Certificate Sent. Use picklists for statuses and delivery method. Use date fields for dates. Use number for capacity and score when calculation or reporting is needed.

Requiredness should be staged. At creation, Course Delivery may require Start Date, Status, Delivery Method, and Course Name. Instructor might be required only when Status moves to Scheduled. Survey Score should be required only when Enrollment Status becomes Completed and the business truly requires it. Conditional validation rules are better than making every field universally required.

Record types may or may not be needed. If public, private, and virtual deliveries use different status values, fields, and pages, record types could help. If the differences are minor, one record type with Dynamic Forms sections based on Delivery Method may be simpler. The admin should avoid creating record types just to hide one field.

Lightning page design should reflect user work. Training coordinators need schedule, capacity, instructor, enrollments, and status actions. Sales users may need a compact view of delivery status from the Account or Opportunity. Managers may want report charts for upcoming deliveries and completion rates. A Course Delivery record page can use tabs for Details, Enrollments, Activity, and Insights, with Dynamic Actions that show Cancel only when the delivery is not completed.

Build the lab in a playground with a small data set:

Create Course Delivery as a custom object with a tab.

Add fields for dates, status, capacity, delivery method, location, and instructor.

Relate Course Delivery to Account and test whether lookup or master-detail matches the scenario.

Create Enrollment as a junction object between Contact and Course Delivery.

Add enrollment status, attendance, completion date, and survey score fields.

Add a roll-up summary on Course Delivery if the Enrollment relationship supports it.

Create validation rules for realistic conditional requirements.

Build a Lightning record page with focused sections and related lists.

Create reports for upcoming deliveries, enrollments by account, and completion rate.

Test as a coordinator, sales user, and manager.

This lab also shows why schema and UX cannot be separated. If Enrollment is a multi-select picklist on Contact, reporting by delivery becomes painful and attendance details have no proper home. If every class type becomes a different object, reporting across all deliveries becomes painful. If page visibility hides fields but field-level security is open, sensitive survey data may still be exposed elsewhere.

For Agentforce-aware administration, a clean model helps future AI and assistant use cases. A support or training agent should be grounded in reliable Course Delivery and Enrollment records, not scattered notes. However, the admin must verify permissions, data sensitivity, and testing boundaries before exposing actions or answers. AI should assist users within trusted data and access rules, not compensate for missing schema discipline.

The exam version of this lab would usually be shorter, but the logic is the same. Identify the business concept, select standard objects first, create custom objects only for distinct records, choose relationship type based on lifecycle and access, enforce data quality at the right layer, and shape the Lightning page around user tasks. When two answers look plausible, choose the one that preserves clean data and uses native platform behavior with the least unnecessary complexity.