10.1 New Sales Org Setup Integrated Lab
Key Takeaways
- A new sales org setup should connect company settings, user access, object configuration, sales process design, data readiness, automation, and reporting.
- Use profiles and permission sets deliberately, then verify with Login As, record pages, list views, and report visibility from the user perspective.
- Sales process labs should include expected observations and failure modes, not only the happy path of creating fields and stages.
- Admins should build in a sandbox or Trailhead Playground first, document choices, and move production changes through a controlled release path.
Lab scenario: launch a small sales org
A software company is moving a ten-person sales team into Salesforce. Leadership wants account and opportunity tracking, a clean lead intake process, weekly pipeline reports, and basic activity visibility. The admin has a Trailhead Playground or sandbox, two sample sales users, one sales manager, and a small CSV of accounts, contacts, and open opportunities. The goal is not to build everything Salesforce can do. The goal is to make a working sales foundation that is secure, testable, and easy to explain.
Start with org controls. Go to Setup > Company Information and confirm locale, default currency, time zone, fiscal year, licenses, and storage. Go to Setup > Fiscal Year only if the company uses a nonstandard fiscal calendar. Confirm business hours if sales handoffs or follow-up service work will depend on working time later. These settings shape forecasts, reports, dates, currency display, and user experience. A common failure mode is building reports before confirming fiscal periods, then discovering that quarterly dashboards do not match finance expectations.
Create the people model next. Use Setup > Users > Users for user records, Setup > Profiles only for broad baseline access, and Setup > Permission Sets for additive permissions. Use a Sales User permission set for opportunity, lead, account, contact, task, and report access. Use a Sales Manager permission set for dashboards, forecast management if used, and broader record visibility through roles or sharing. Do not clone large profiles casually. A new org often looks simple, but profile sprawl becomes hard to unwind.
| Build area | Setup path | Expected observation | Failure mode to watch |
|---|---|---|---|
| Company settings | Setup > Company Information | Dates, language, currency, and fiscal periods match the business | Reports show wrong fiscal periods or currency assumptions |
| Users and access | Setup > Users, Setup > Permission Sets | Sales reps can create leads and opportunities but cannot administer the org | Users receive system permissions because a profile was overused |
| Role hierarchy | Setup > Roles | Manager can see direct team records when sharing model depends on hierarchy | Private sharing blocks manager reports unexpectedly |
| Sales process | Setup > Object Manager > Opportunity > Fields & Relationships and Sales Processes | Stages, probability, and record types reflect how the team sells | Required fields block early-stage opportunities or allow closed deals with missing data |
| Reports | Reports tab and Setup > Report Types | Pipeline reports match expected owner, stage, amount, and close date filters | Report folders or sharing hide data from the intended users |
Configure the sales data model. In Object Manager, review Account, Contact, Lead, and Opportunity fields before adding custom fields. Add only fields that support decisions, automation, reporting, compliance, or required business process. Example additions might include Account Tier, Lead Source Detail, Competitor, Sales Motion, and Renewal Risk. Prefer picklists when reporting consistency matters. Use help text for fields that users might interpret differently. Avoid creating a custom object for simple opportunity attributes unless the relationship truly needs its own lifecycle.
Build the sales process with Setup > Object Manager > Opportunity > Fields & Relationships > Stage and Setup > Sales Processes if the org needs different stage paths by record type. For a basic new sales org, one opportunity record type may be enough. Add stages such as Qualification, Discovery, Proposal, Negotiation, Closed Won, and Closed Lost. Confirm probability defaults and forecast categories. Then configure Path from Setup > Path Settings so reps see key fields and stage guidance on the opportunity record page.
Add guardrails only where the business has committed to them. A useful validation rule might require Loss Reason when Stage equals Closed Lost, or require Primary Contact before Closed Won. Test validation rules from a sales rep user, a manager user, Data Loader or import context, and any flow context. The failure mode is a rule that looks correct in a demo but blocks imports, renewals, or manager corrections. If exceptions are legitimate, consider a custom permission used sparingly instead of telling users to enter fake data.
Load sample data only after the schema and access model are understood. Use Setup > Data Import Wizard for a guided small load of accounts and contacts, or Data Loader for a more realistic upsert exercise with record IDs or external IDs. Before loading opportunities, export the source file version, map owners to active users, and make sure lookup values are stable. Expected observations include successful rows, clear error files, and opportunities visible in list views by owner and manager.
Failure modes include invalid picklist values, inactive owners, missing required fields, and duplicate accounts caused by name-only matching.
Create a simple adoption surface. Build a Sales app with the App Manager, include Home, Leads, Accounts, Contacts, Opportunities, Tasks, Dashboards, and Reports, then assign it to the right profiles or permission sets. Edit Lightning record pages so key information is visible without clutter. Use Dynamic Forms where appropriate on supported objects, but do not hide required information behind too many conditions. Add list views such as My Open Opportunities, Closing This Month, and New Leads Today. A user should be able to start work without asking which tab to use.
Finish with analytics. Build a pipeline report grouped by owner and stage, an open leads report grouped by source, and a simple dashboard with pipeline by stage, opportunities closing this month, and lead conversion trend if sample data supports it. Store reports in a folder shared to the sales team and managers. Then test as a sales rep. The rep should see only appropriate records and reports. The manager should see team-level information.
If the dashboard numbers differ from list views, check report type, filters, running user, folder sharing, record sharing, and whether the report includes converted leads or closed opportunities.
Review prompts before the quiz:
- Which settings would you confirm before building reports in a new sales org?
- Which permissions belong in a permission set instead of a cloned profile?
- Which validation rules protect closed opportunities without blocking early pipeline creation?
- How would you prove that a sales manager can see the right records and not too much data?
- What sample import errors would you deliberately test before a production data load?
In a new sales org lab, which action should happen before building fiscal-quarter pipeline dashboards?
A sales validation rule requires Loss Reason for every opportunity edit. Users cannot update early-stage opportunities without selecting a loss reason. What is the best admin response?
After sharing a pipeline dashboard, sales reps report that it is empty even though they have opportunities. Which check is most relevant?