2.6 Configuration and Setup Case Lab

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

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.
• Login rules are tested with Login History evidence.
• 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.