Overview
Configuration and Setup covers the org-level foundation an administrator owns: company settings such as fiscal year, business hours and currency; the declarative user interface (app menu, list views, global actions, Lightning App Builder); user setup, licensing and deactivation; org security controls such as identity verification, Setup Audit Trail, login hours and session settings; the record-level sharing model; and the choice between a custom profile and a permission set.
The section exists because almost every later scenario sits on top of these decisions. A report that shows the wrong rows, a flow that fails for one user, or a field a manager cannot edit usually traces back to a license, a permission or a sharing setting configured here. Candidates need a clear mental model of three separate layers: object and field permissions from profiles and permission sets, record access from the sharing model, and org-wide controls that apply to everyone.
How it's tested
Questions here are short user-request scenarios: a manager needs access, a user cannot log in, a team must share records, or a setting must change org-wide. You are asked for the BEST or most scalable configuration. The winning answer grants the least access needed at the correct layer and uses standard features before custom ones.
-
Which access layer fixes this
A user cannot see or edit something, and you decide whether the gap is object or field permission, record sharing, or an org-level control such as login hours.
-
Least privilege and scale
Several options technically work, and the right one grants the narrowest access in the way that scales, such as a permission set group instead of another cloned profile.
-
Irreversible and global settings
A company setting change such as enabling multiple currencies or custom fiscal years is proposed, and you must recognize side effects that cannot be undone.
A support lead says agents can open Account records from a case but cannot see the Annual Revenue field on them. Org-wide defaults and sharing control which records are visible, and the agents already see the records, so sharing is not the gap. The missing piece is field-level security, so the fix is a permission set granting read access to that field rather than any change to org-wide defaults or the role hierarchy.
Objectives 6
Official objectives from the Salesforce outline, in outline order.
1.1 Describe the information found in the company settings (for example: company settings fiscal year, business hours, currency management, default settings).Org-wide defaults for time, money, locale and business calendars.
- What it means
- Company Information holds the org's default locale, language, time zone, corporate currency and license counts. Fiscal Year sets standard (Gregorian, choose the start month) or custom periods, Business Hours and Holidays define when the clock runs for escalation and entitlement processes, and currency settings control single or multiple currencies.
- What to understand
- Some settings cannot be reversed: once multiple currencies are activated they cannot be turned off, and once custom fiscal years are enabled the org cannot go back to standard fiscal years. Advanced currency management adds dated exchange rates but they apply only to opportunity-related amounts, not every currency field.
- How it shows up
- A finance team wants 4-4-5 quarters or a second currency, and you identify the setting and its permanent consequences for forecasting and reporting.
- Common confusion
- Org default locale and time zone are only defaults for new users; each user's own locale and time zone settings decide how dates and numbers display for them.
1.2 Distinguish and understand the administration of declarative configuration of the user interface (UI) (for example: UI/UX settings, app menu, list views, global actions, Lightning App Builder).Shaping what users see without code.
- What it means
- Admins control navigation through Lightning apps and the App Menu order, list views with their filters and sharing (only me, all users, or selected groups and roles), global actions placed in the global publisher layout, org UI settings, and Lightning pages built in Lightning App Builder.
- What to understand
- Global actions are not tied to an object, so the record they create has no automatic relationship to the page the user was on; object-specific actions pre-populate that relationship. A list view's visibility setting controls who sees the view, not which records the viewer can access.
- How it shows up
- Users need a faster way to log a call from anywhere or a shared filtered list for a team, and you choose a global action or a list view shared to a public group.
- Common confusion
- Sharing a list view with a group does not grant access to records; each viewer still sees only the rows the sharing model allows.
1.3 Given a scenario, demonstrate the proper setup and maintenance of users (user name is unique, locales, working hours, how to distribute licenses, types of licenses, not deleting a user, implications of making inactive, override, assigning feature licenses, management of users with various login methods).Creating, licensing, freezing and deactivating users correctly.
- What it means
- Every user needs a username in email format that is unique across all Salesforce orgs, one user license that caps which profiles and objects are available, and optional feature licenses such as Marketing User or Knowledge User enabled on the user record. Users can be frozen or deactivated but never deleted.
- What to understand
- Deactivating frees the license and stops login while preserving the user's records, but it can be blocked when the user is referenced in places like default lead or case owner settings or a custom hierarchy field; freezing stops login immediately while you clear those references. The user license limits which profiles can be assigned, so a Salesforce Platform license cannot use standard CRM objects such as Opportunities.
- How it shows up
- An employee leaves today and owns hundreds of open records, and you must stop access at once, preserve history, and reclaim the license once dependencies are cleared.
- Common confusion
- Candidates look for a delete option; Salesforce keeps the user for audit and ownership history, so the answer is freeze then deactivate, and transfer records if someone must work them.
1.4 Explain the various organization Security Controls (for example: Identity verification, Setup Audit Trail, Login Hours, Session Settings, agent access).Who can log in, when, from where, and what admins changed.
- What it means
- Org security controls include identity verification and multi-factor authentication (MFA), login hours and login IP ranges set on the profile, network access trusted IP ranges, session settings such as timeout and locking sessions to the originating IP, and Setup Audit Trail, which records configuration changes made in Setup.
- What to understand
- Profile login IP ranges block logins from outside the range, while org trusted IP ranges only skip the identity verification challenge. Setup Audit Trail shows the last 180 days of setup changes and who made them; it does not record changes to data in records, which is what field history tracking covers.
- How it shows up
- A contractor must only log in during office hours, or an auditor asks who changed a validation rule last month, and you name the specific control.
- Common confusion
- Adding an address to trusted IP ranges does not restrict anyone; restriction requires login IP ranges on the profile.
1.5 Given a user request scenario, apply the appropriate security controls based on the features and capabilities of the Salesforce sharing model (for example: Teams, Sharing hierarchy, public groups, org-wide defaults, sharing: roles, subordinates, role hierarchy, report and dashboard folders).Opening record access from a locked-down baseline.
- What it means
- Org-wide defaults (OWD) set the most restrictive baseline per object, such as Private or Public Read Only. Access then opens through the role hierarchy (managers see subordinates' records), sharing rules to roles, roles and subordinates, or public groups, account, opportunity and case teams, manual sharing, and folder sharing for reports and dashboards.
- What to understand
- Sharing only ever adds access above the OWD; it can never take access away, so the OWD must be set to the level the least-privileged user should have. The role hierarchy shares upward only, so peers in sibling roles need a sharing rule or group rather than a hierarchy change.
- How it shows up
- Two teams in unrelated roles must see each other's records while everyone else stays restricted, and you choose a sharing rule targeting a public group.
- Common confusion
- The role hierarchy is not the org chart for permissions; it controls record visibility only and grants nothing about which objects or fields a user can use.
1.6 Given a scenario, determine the appropriate use of a custom profile or permission set (using the various profile settings, permission set group, and muting).Assigning object, field and system permissions at scale.
- What it means
- Each user has exactly one profile and any number of permission sets. Profiles still carry settings such as page layout assignments, login hours and IP ranges and default record types, while permission sets add object, field, app and system permissions. Permission set groups bundle sets for a job role, and a muting permission set inside a group removes chosen permissions for members of that group only.
- What to understand
- Salesforce's recommended pattern is a minimal base profile plus permission sets and groups, because permissions are additive and new needs do not multiply cloned profiles. Muting is the only way to subtract a permission, and it works only within the group it belongs to.
- How it shows up
- Three people on a team need one extra permission that the rest of their profile must not have, and the answer is a permission set assigned to those three users.
- Common confusion
- Candidates think a permission set can restrict access below the profile; permission sets only grant, and only a muting permission set in a group removes permissions.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Org-wide defaults (OWD)
The baseline record access for each object, set to the level the most restricted user should have, such as Private, Public Read Only or Public Read/Write.
- Remember
- Every other sharing tool opens access above the OWD; nothing in the sharing model can make a record less visible than the OWD allows.
- Tested as
- The first decision in any record-visibility scenario, especially when one group must be restricted while others share freely.
- Trap
- Opening the OWD to Public Read Only to satisfy one team, which exposes the records to every other user as well.
-
Role hierarchy
A tree of roles where users automatically get the same access to records owned by users in roles below them, when Grant Access Using Hierarchies is on.
- Remember
- Access flows up only, never sideways or down, and it is always on for standard objects.
- Tested as
- Explains why a manager sees a rep's opportunity and why two peer managers do not see each other's.
- Trap
- Restructuring roles so peers share a parent, which gives the parent access but still does not let the peers see each other's records.
-
Sharing rules
Automatic exceptions to the OWD that grant Read Only or Read/Write to roles, roles and subordinates, or public groups, based either on record owner or on field criteria.
- Remember
- Owner-based rules key on who owns the record; criteria-based rules key on field values such as Region equals West.
- Tested as
- The standard answer when a defined set of users outside the hierarchy needs consistent access.
- Trap
- Expecting a sharing rule to reduce access for users who already see records through a more open OWD.
-
Public groups
Reusable sets of users, roles, roles and subordinates, and other groups that can be the target of sharing rules, list views, folders and queues.
- Remember
- Build the group once and reuse it everywhere a cross-functional audience needs access.
- Tested as
- Appears as the cleanest target when a sharing need crosses several branches of the role hierarchy.
- Trap
- Assigning access to individual users repeatedly instead of to a group that will absorb future joiners.
-
Profile vs. permission set
The profile is the single required baseline per user; permission sets are optional, stackable grants of object, field, app and system permissions.
- Remember
- Keep profiles minimal and add access with permission sets, because access in Salesforce is the union of everything granted.
- Tested as
- Tested whenever a few users need more access than their peers on the same profile.
- Trap
- Cloning a new profile for every small variation, creating dozens of near-identical profiles to maintain.
-
Permission set group and muting
A permission set group bundles several permission sets for a persona, and a muting permission set inside it turns off selected permissions for that group's members.
- Remember
- Muting affects only the group it sits in; the same permission granted through another set or the profile still applies.
- Tested as
- Scenarios about one persona needing almost everything in a bundle except one sensitive permission.
- Trap
- Believing muting removes the permission from the user everywhere, when another assignment can still grant it.
-
Freeze vs. deactivate
Freezing blocks a user's login immediately without changing anything else; deactivating ends access, releases the license and keeps the user's records and history.
- Remember
- Freeze first when a departure is urgent and deactivation is blocked by references such as default owner settings.
- Tested as
- The classic employee-termination scenario.
- Trap
- Looking for a delete-user option, which Salesforce does not provide.
-
Login hours and login IP ranges
Profile-level controls that restrict when and from which IP addresses users on that profile can log in.
- Remember
- A user outside login hours is logged out when the window ends; outside the IP range, login is refused.
- Tested as
- Contractor, call-center and compliance scenarios that limit access windows or networks.
- Trap
- Using org trusted IP ranges for restriction, which only removes the verification challenge for those addresses.
-
Setup Audit Trail
A log of configuration changes made in Setup, with who made them and when, covering the most recent 180 days.
- Remember
- It tracks metadata and setup changes, not edits to record field values.
- Tested as
- Answers audit questions such as who changed a profile or deactivated a validation rule.
- Trap
- Choosing Setup Audit Trail when the scenario asks who changed a value on a specific record, which needs field history tracking.
-
Multiple currencies and custom fiscal years
Company settings that add currencies with conversion rates or define non-calendar fiscal periods such as 4-4-5 quarters.
- Remember
- Neither can be switched off once enabled, so test them in a sandbox and plan reporting and forecasting impacts first.
- Tested as
- Appears as a question about consequences before enabling a finance requirement.
- Trap
- Treating these as reversible toggles and enabling them directly in production to see what happens.
-
User license vs. feature license
A user license, such as Salesforce or Salesforce Platform, sets the baseline objects and profiles available; feature licenses such as Marketing User or Knowledge User unlock specific features on top.
- Remember
- The user license determines which profiles a user can be assigned, and Platform licenses cannot use standard CRM objects such as Opportunities or Cases.
- Tested as
- Scenarios where a new hire cannot be given the needed profile or cannot create campaigns.
- Trap
- Trying to fix a missing campaign permission with a profile change when the Marketing User checkbox is what is missing.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Org-wide defaults vs. role hierarchy vs. sharing rules vs. teams
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Org-wide defaults | Baseline access to records you do not own | Sets the floor for everyone; the only tool that can restrict | Opening it for one team's request |
| Role hierarchy | Automatic upward access to subordinates' records | Vertical only; peers never share through it | Rearranging roles to make peers share |
| Sharing rules | Automatic grants to roles or public groups by owner or criteria | Consistent, rule-based exceptions across the hierarchy | Expecting a rule to remove access |
| Account, opportunity and case teams | Per-record access for named collaborators | Set record by record for the people working that deal or case | Using teams for a whole department that a rule should cover |
Profile vs. permission set vs. permission set group vs. muting permission set
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Profile | One required baseline per user | Holds page layout assignment, login hours and IP ranges | Cloning profiles for every small variation |
| Permission set | Stackable grant of extra permissions | Assign to individuals; only adds access | Expecting it to restrict a user |
| Permission set group | Bundle of permission sets for a persona | One assignment delivers the whole job role | Rebuilding the same bundle per user |
| Muting permission set | Turns off chosen permissions inside one group | Only subtraction tool, scoped to its group | Assuming it overrides grants from elsewhere |
Profile login IP ranges vs. trusted IP ranges
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Login IP ranges (profile) | Allowed IP addresses for users on that profile | Logins from outside the range are refused | Setting them org-wide expecting a skip of verification |
| Trusted IP ranges (network access) | Org addresses Salesforce treats as known | Skips the identity verification challenge; restricts nothing | Using it to lock contractors to the office network |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Loosen the OWD
- What candidates pick
- Change the object's org-wide default from Private to Public Read Only so the requesting team can see records.
- Why it looks right
- It solves the stated request in one step.
- Why it's wrong
- It exposes every record to every user, breaking confidentiality for groups that must remain restricted; sharing rules open access only for the intended audience.
Clue to watch for The scenario says other users' access should not change, or that some data is confidential.
-
Fix visibility with the role hierarchy
- What candidates pick
- Move two peer roles under a new common role so they can see each other's records.
- Why it looks right
- Hierarchy changes feel like the natural way to share between teams.
- Why it's wrong
- Access flows only upward, so the new parent role gains access while the peers still cannot see each other's records.
Clue to watch for The users needing access are at the same level or in different branches of the hierarchy.
-
Grant View All
- What candidates pick
- Add View All or Modify All for the object through a permission set.
- Why it looks right
- It guarantees the user sees the records.
- Why it's wrong
- View All bypasses sharing for every record of that object, far beyond the stated need, and fails a least-privilege test.
Clue to watch for The request names a subset of records, such as one region or one team's accounts.
-
Clone another profile
- What candidates pick
- Create a new custom profile for three users who need one extra permission.
- Why it looks right
- Profiles feel like the place permissions live.
- Why it's wrong
- It multiplies profiles that must be maintained in parallel; a permission set assigned to those users is the recommended, scalable choice.
Clue to watch for Only a few users on an existing profile need something extra.
-
Delete the departing user
- What candidates pick
- Look for a way to delete or remove the user record.
- Why it looks right
- Deleting seems like the cleanest offboarding step.
- Why it's wrong
- Users cannot be deleted; you freeze to block login at once, then deactivate, and transfer records if others must work them.
Clue to watch for The scenario stresses immediate lockout plus keeping history or ownership.
-
Field visible to everyone with the record
- What candidates pick
- Assume a user who can see a record can see all its fields, so change sharing.
- Why it looks right
- The user already reports a visibility problem on that record.
- Why it's wrong
- Record access and field access are separate; a hidden field on a visible record is a field-level security gap.
Clue to watch for The user can open the record but one specific field is missing or read-only.
Answer framework
When a configuration or access scenario appears, work down the layers in this order before picking an answer.
- Identify exactly what the user cannot do: log in, use an object, see a field, see specific records, or change an org-wide setting.
- If it is login, check license, freeze or active status, login hours, login IP ranges and identity verification before anything else.
- If it is an object or field, fix it with a permission set or permission set group, reserving profile edits for profile-only settings.
- If it is records, keep the org-wide default at the most restrictive level and open access with the hierarchy, a sharing rule to a public group, or a team.
- Prefer the option that grants the least access to the fewest users in the most reusable way, and check whether any company setting change is irreversible before choosing it.
Practice question
Want more like this? The Salesforce Admin practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with the access model, because it is the backbone of this section and of many questions elsewhere. In a Developer Edition or Trailhead playground, set an object to Private, create two sibling roles, and test what each user sees as you add a sharing rule, a public group and a team. Then layer object and field permissions with a permission set, a permission set group and a muting permission set, logging in as each user to confirm the result.
High-priority concepts are org-wide defaults as the floor, upward-only hierarchy access, profile versus permission set, and the freeze-then-deactivate offboarding sequence. Commonly underestimated areas are company settings with permanent effects (multiple currencies and custom fiscal years), the difference between login IP ranges and trusted IP ranges, and what Setup Audit Trail does and does not capture.
Practice afterwards with scenario questions that describe a symptom rather than a setting, and force yourself to name the layer before reading the options. When two answers both work, ask which grants less access to fewer people and which an admin could maintain as the team grows. Revisit this section after studying reports and Agentforce, because folder sharing and agent permissions reuse the same reasoning.
FAQ
How much of the Platform Administrator exam is Configuration and Setup?
Configuration and Setup is 15% of the exam. Applied to the 60 scored questions, that suggests roughly nine questions as a planning estimate, although access reasoning also appears inside other sections.
Is the sharing model really that heavily tested?
The sharing model is one of six objectives here, but it is the most scenario-driven, and it underpins report visibility, automation and agent access questions. Expect to reason through org-wide defaults, the role hierarchy and sharing rules repeatedly.
What is the difference between a profile and a permission set?
Every user has exactly one profile, which carries baseline permissions and settings such as page layout assignment and login hours. Permission sets add access on top and can be stacked, so the recommended design is a lean profile with permission sets and groups for everything else.
Can I delete a user in Salesforce?
No. You can freeze a user to block login instantly and deactivate them to free the license, but the user record stays for ownership and audit history. Transfer open records if someone else must work them.
What changed in this section in the December 2025 exam refresh?
The refreshed guide, effective 15 December 2025, lists this section at 15% and names agent access among the org security controls alongside identity verification, Setup Audit Trail, login hours and session settings.
How long should I study this section?
Plan roughly 20 to 25 hours as an editorial estimate, more if you have not configured sharing in a real org. Hands-on testing as different users is the fastest way to make the access layers stick.
How does this section relate to Data and Analytics Management?
Reports respect the same sharing model you configure here, and report and dashboard folders are shared to users, roles and groups. A report showing the wrong rows is usually a sharing question in disguise.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 1 knowledge
You have worked through company settings, user licensing and offboarding, org security controls, the sharing model and permission design. Check whether you can pick the least-privilege fix in timed access scenarios.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the Salesforce Admin AI tutor Get any concept explained your way