Account Settings
Account Settings is the Salesforce Setup page that controls organization-wide defaults for the Account object: whether Account Teams are enabled, whether Contacts can relate to multiple Accounts, whether Account Hierarchies display in the record detail, whether Account Insights surfaces engagement signals, and several smaller toggles for Account behavior across the platform.
Definition
Account Settings is the Salesforce Setup page that controls organization-wide defaults for the Account object: whether Account Teams are enabled, whether Contacts can relate to multiple Accounts, whether Account Hierarchies display in the record detail, whether Account Insights surfaces engagement signals, and several smaller toggles for Account behavior across the platform. Changes here apply to every Account in the org and to every user who works with Account records.
The page is one of the lower-traffic Setup destinations and often holds settings that were configured years ago and never revisited. Account Teams is the most consequential toggle (it adds an entire object relationship to the data model). Contacts to Multiple Accounts is the second (it changes how the Contact object behaves across Sales, Service, and Marketing). Most other settings are smaller, but the page deserves a quarterly audit because settings here cascade across the platform and quietly affect downstream automation when they drift from current business requirements.
Why Account Settings is the highest-leverage Setup page nobody visits
Where Account Settings lives and what it covers
Setup, Object Manager, Account, Account Settings. The page also appears under Setup, Feature Settings, Sales, Account Settings depending on the edition. The settings cluster into four groups: relationships (Account Teams, Contacts to Multiple Accounts), hierarchy (Account Hierarchy display, view-all access), reporting (Account Insights, Account-level sharing in reports), and behavior (Account Owner reassignment behavior, default record type). Each group has 2 to 5 toggles. The page reads quickly but the implications of each toggle take longer to think through.
Account Teams: the relationship toggle with the biggest blast radius
Account Teams enables a related list on Account that holds named team members with specified roles (Account Manager, Executive Sponsor, Inside Sales) and access levels (Read, Read/Write). Once enabled, the AccountTeamMember object exists and reports can be built against it. Disabling Account Teams after it has been used does not delete the data; it hides the related list. Most orgs that enable Account Teams keep it enabled forever. The decision to enable in the first place should be deliberate; backing it out cleanly later is hard because the data and the reports built on it persist.
Contacts to Multiple Accounts: a data-model shift
The default Salesforce model has each Contact owned by exactly one Account. Contacts to Multiple Accounts (also called the Contact-to-Account relationship) introduces a junction object (AccountContactRelation) so the same Contact can relate to multiple Accounts with different roles (Primary, Influencer, Decision Maker). This matches how complex B2B sales actually work where a Contact's employer changes or where they sit on multiple boards. Once enabled, the data model is more flexible but every report that joins Account and Contact must be reviewed for whether it wants primary-only or all-relations behavior.
Account Hierarchy and the view-all-records question
Account Hierarchy lets Accounts have parent-child relationships through the Parent Account field. The Account Settings page controls whether the hierarchy displays inline on the record and whether users with access to a parent automatically see children. The second toggle is significant; without it, a sales rep looking at the parent of a global account may not see the regional subsidiaries they should know about. With it, sharing rules for the parent cascade to children automatically. Most enterprise orgs enable both; small business orgs often leave them off because the complexity is not worth the trade-off.
Person Accounts and the one-way toggle
Person Accounts let an Account also act as a Contact, which is useful in B2C orgs where the customer is an individual rather than a company. Enabling Person Accounts is one of the few Salesforce settings that is truly one-way; once enabled, the data model changes cannot be reversed by an admin. The setting lives in Account Settings but with a heavy warning. The decision to enable should involve a real architecture conversation; many B2C orgs that enabled Person Accounts in 2017 wish they had used a different model in 2026 but cannot easily migrate off.
Account-level sharing and visibility
Several toggles in Account Settings affect what users can see across Accounts. View All Records on Account grants read access to every Account regardless of sharing model; this is appropriate for some admin roles and inappropriate for most others. Default Account Owner Behavior on reassignment controls whether related Contacts, Opportunities, and Cases follow the new owner automatically. Misconfiguration here creates the "where did all my Opportunities go" support ticket; the rep transferred Accounts and the Opportunities went with them silently. Document the chosen behavior so the team knows what to expect.
Audit cadence and what to look for
Audit Account Settings quarterly. Specifically: confirm Account Teams toggle still matches the org's account team model, confirm Contacts to Multiple Accounts setting matches current B2B sales practice, confirm Account Hierarchy access matches current geographic and divisional sharing needs, confirm reassignment behavior matches the team's expectations. The audit catches drift; settings configured for the org of 2022 may not match the org of 2026. The audit takes 15 minutes and prevents the silent downstream surprises that happen when default behavior diverges from what the team thinks the behavior should be.
How to audit Account Settings without breaking things
The audit pattern: review each toggle, confirm it matches current business requirements, document any change, deploy through your normal change pipeline. Most toggles are reversible but a few (Person Accounts) are not; treat the page with respect even though it looks like a simple checkbox list.
- Open Account Settings in your sandbox first
Setup, Object Manager, Account, Account Settings. Document the current state of every toggle before changing anything. Sandbox first is non-optional for irreversible toggles like Person Accounts.
- Review each setting against current business needs
Walk through the page top to bottom. For each toggle, ask: does this match what the sales and service teams currently expect? Document the answer per setting.
- Flag toggles that need stakeholder review
Account Teams, Contacts to Multiple Accounts, Account Hierarchy access, Person Accounts. Each of these has business-process implications. Flag them for a sales ops or RevOps review before changing.
- Make changes one at a time and observe
Toggling two settings simultaneously makes it hard to attribute any new behavior to a specific change. One toggle, validate, then the next.
- Document changes in the change log
Account Settings changes affect every Account and every user. The change log entry should name the setting, the old value, the new value, the date, and the stakeholder who approved.
- Push from sandbox to production through the normal pipeline
Change sets, source-tracked sandboxes, or DevOps Center. Skip the pipeline only for emergency rollback.
- Schedule the next quarterly audit
Add the audit to your calendar. The quarterly cadence catches drift before the team experiences it as a surprise.
Enables the AccountTeamMember related list and reporting object. Once enabled, hard to reverse cleanly.
Enables the AccountContactRelation junction so Contacts can relate to multiple Accounts.
Controls whether parent and child Accounts display inline and whether parent access cascades to children.
Enables the Person Account hybrid model. One-way; cannot be reversed by an admin.
Controls whether related records (Contacts, Opportunities, Cases) follow on Account owner change.
- Person Accounts is one-way. Enabling cannot be undone by an admin and migrating off requires a Salesforce architectural engagement.
- Account Teams data and reports persist after the toggle is turned off. The related list disappears but the data remains in the database.
- Account Owner reassignment behavior is silent. Reps who do not know whether related records follow on owner change are surprised when Opportunities move with the Account.
- Contacts to Multiple Accounts changes the data model. Reports and integrations that join Account and Contact must be reviewed for whether they want primary or all-relations behavior.
- Account Hierarchy view-all access cascades parent permissions to children. A sharing model that worked at the Account level can over-grant when hierarchy access is enabled.
Trust & references
Cross-checked against the following references.
- Account Settings referenceSalesforce
- Accounts overviewSalesforce
Straight from the source - Salesforce's reference material on Account Settings.
- Account SettingsSalesforce Help
- Contacts to Multiple AccountsSalesforce Help
- Person AccountsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. In which area of Salesforce would you typically find Account Settings?
Q2. What is the primary benefit of Account Settings for Salesforce administrators?
Q3. Can a Salesforce admin configure Account Settings without writing code?
Discussion
Loading discussion…