2.6 Configuration and Setup 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

2.6 Configuration and Setup Case Lab

Key Takeaways Explain This Topic AI

Integrated setup work should start with requirements, current-state evidence, and a change plan before individual settings are edited.

The same business request can touch Company Information, fiscal year, business hours, users, licenses, profiles, permission sets, identity, apps, pages, and release readiness.

Hands-on validation should test both positive and negative cases: users who should have access, users who should not, locations that should work, and locations that should fail.

Admin judgment includes knowing when not to use a feature, including AI or broad permission changes, because the risk is greater than the business value.

Last updated: May 2026

Case lab: regional expansion with controlled access

Scenario: Cloud Kicks Learning, a fictional training company, is expanding from one domestic sales and support team to three regional teams. Finance uses a fiscal year that starts in February. Standard support is open Monday through Friday, while premium support is 24 by 7 except for a small set of holidays. New sales coordinators need access to accounts, contacts, leads, opportunities, reports, and a custom onboarding object. Support specialists need cases, knowledge, accounts, contacts, and a service console app.

A pilot group will later test an Agentforce assistant for internal support summaries, but leadership has not approved broad AI access.

Your job as the admin is to turn that request into a controlled setup plan. Begin by separating facts from assumptions. You need to verify the org edition, available licenses, storage, fiscal year settings, locale, time zone, currency model, current user profiles, current permission sets, business hours, app assignments, and any release updates that could affect service or automation. This is why Company Information and Setup search are part of the lab before any new field or app is built.

Lab design table

Requirement Setup area Admin decision

Fiscal year begins in February Company Settings > Fiscal Year Confirm whether Standard Fiscal Year supports the requirement before considering custom fiscal years.

Premium support runs nearly all the time Business Hours and Holidays Create separate schedules when service commitments differ.

New sales coordinators need limited access Users, Profiles, Permission Sets Use a baseline profile plus permission sets instead of broad admin permissions.

Support users need console workflow App Manager and Lightning App Builder Build or assign a service app and validate navigation, utilities, and page activation.

Remote login must be secure Login History, Session Settings, Network Access, profiles Diagnose access by evidence and avoid weakening global security.

Agentforce pilot is not approved broadly Permission sets, feature permissions, testing plan Limit access to the pilot group and confirm data boundaries before enabling user-facing entry points.

Step 1 is current-state discovery. Open Company Information and record org ID, edition, license counts, default locale, default language, default time zone, storage, currency behavior, and fiscal year type. If license counts are tight, do not create users first and ask questions later. License constraints shape the onboarding plan. If the fiscal year already matches finance, document it. If it does not, gather finance approval and test reporting impact before changing it.

Step 2 is calendar design. Create or review business hours for Standard Support and Premium Support. Add holidays carefully and confirm which schedule each holiday applies to. In a full service implementation, entitlement processes, milestones, case escalation, and support routing may consume these settings. Even in a study lab, write down an example: a standard case opened Friday afternoon should not be measured the same way as a premium case opened at the same time.

Step 3 is user and access design. Create two test users if your practice org allows it, or document the setup choices if license limits prevent it. Choose the correct user license, assign a baseline profile, set role and manager if hierarchy visibility is being practiced, then add permission sets for the sales coordinator and support specialist duties. Do not grant Modify All Data or broad admin permissions to make the lab pass. The point is to prove least privilege while still enabling work.

Step 4 is login and identity validation. Review password policy, session timeout, trusted network ranges, and profile login restrictions. Create a simple test matrix with expected behavior. A sales coordinator should log in during allowed hours and access the sales app. A support specialist should access the service app. A user outside an allowed profile IP range should be blocked if that restriction is part of the design. Review Login History after tests so you learn what evidence Salesforce provides.

Step 5 is app and navigation design. In App Manager, confirm or build a Sales Coordinator app and a Support Console app. Keep navigation focused on frequent tasks. In Lightning App Builder, assign home pages and record pages to the right app and audience. Check that required fields are visible through field-level security and page configuration. If a dashboard appears on the home page, confirm the user can see the underlying report data. A dashboard component that appears empty may be a data visibility issue, not a page design issue.

Step 6 is release and change control. Review pending release updates and release notes for areas touched by the lab, especially automation, security, and service features. Document metadata changes, test cases, affected users, deployment timing, and rollback or correction steps. In a real org, you would normally build meaningful changes in a sandbox, validate with business users, and deploy through the teams approved process. In a Trailhead Playground, the same discipline builds good habits even without a formal release pipeline.

Step 7 is AI boundary judgment. The Agentforce pilot should not be enabled for every user just because the company is curious. Define a use case, such as summarizing internal support case notes for a small operations group. Identify which data grounds the response, which users can test it, who monitors feedback, and what should stay human-reviewed. If the use case would expose sensitive data, make irreversible decisions, or answer beyond approved knowledge, the admin should pause and require governance before rollout.

Validation checklist

Company Information values are documented and license capacity is known.

Fiscal year behavior is approved by finance and tested against sample reports.

Business hours and holidays reflect actual support commitments.

Test users have the correct license, profile, role, locale, time zone, and permission sets.

Apps contain focused navigation and are assigned to the right users.

Home pages and record pages are activated for the correct app, profile, and record context.

Reports and dashboards show data based on sharing, not just page placement.

Agentforce access is limited to the pilot and has a trust, testing, and monitoring plan.

Change records explain what was changed, why, who approved it, and how it was validated.

The lab should leave you with a diagnostic habit. When a user says Salesforce is broken, translate the complaint into a layer: org setting, license, profile, permission set, role and sharing, authentication, session, app navigation, page activation, data, automation, release update, or training. Then verify the layer with Setup evidence. That is the difference between an admin who clicks around and an admin who controls the platform.