Salesforce dictionary,
defined.

An Account is the company, household, or person you do business with. In a Business-to-Business org it represents a buying organization, the one signing the contract and getting invoiced. In a Business-to-Consumer org it can represent an individual through Person Accounts, a variant covered later in this entry. Either way, the Account is where the data graph converges. Contact records carry an AccountId. Opportunities carry an AccountId. Cases, Assets, Orders, Contracts, and most Activity records do too. Even custom objects in most orgs add an Account lookup early in their schema. Reports without one end up answering "which deals" but never "whose deals." The Account is the join condition for nearly every cross-object report you will build. In Salesforce's standard data model the Account sits at the top of a small but heavily-trafficked subtree. Whatever you do here, the rest of the org feels. Bad Account hygiene shows up downstream as duplicate forecasts, broken sharing, mis-routed Cases, and territory rules that fire on the wrong region. Good Account hygiene quietly keeps every other object honest. The cost of getting Accounts right is one careful design pass on day one. The cost of getting Accounts wrong is paid every quarter, mostly by whoever's holding the forecast.

An Account Assignment Rule is the territory-management mechanism that automatically associates Accounts with one or more Territories based on rule criteria. It is part of the Enterprise Territory Management feature, the modern replacement for the legacy Customizable Territory Management module. The rule evaluates Account fields (Industry, BillingCountry, AnnualRevenue, custom fields) against an ordered list of conditions, and assigns matching accounts to the territory the rule belongs to. Account assignment rules sit between two concepts often confused: territory models and territories. A Territory Model is the active or planning version of the entire territory tree. A Territory is a node inside the model, with its own users, account assignments, and child territories. An Account Assignment Rule is attached to a single territory and runs when the territory model is activated or when an account is created or edited. The rule is the bridge between the data (accounts) and the structure (territories), without which territory management is just an org chart with no records inside it.

An Account Contact Relationship, often shortened to ACR, is a junction record that links a single Contact to additional Accounts beyond the one stored in the Contact's primary AccountId field. In a Business-to-Business org a real person rarely belongs to only one company. A consultant works with several firms. A board member sits on three boards. A buyer at a parent company also influences purchases at the subsidiary. The Contact's AccountId can hold only one of those affiliations. Every other relationship lives in an AccountContactRelation row, with the role described in fields like Roles, IsActive, StartDate, and EndDate. The object exists because Salesforce's data model is a star, not a graph. Contacts hang off one Account by design, which keeps reporting simple and ownership obvious. ACR is the escape hatch for the real world. Once enabled, the Contact's related list shows every Account it touches and every Account's related list shows every Contact that touches it, indirect ones included. Report Builder gains a fresh report type, custom report types can use the junction, and sharing for indirect Contacts is controlled separately from the primary affiliation. It is the difference between modelling people who happen to work somewhere and modelling people who participate in multiple revenue stories.

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.

An Account Team is a defined group of Users who collaborate on a single Account in Salesforce. Each team member has a role (Account Manager, Executive Sponsor, Channel Sales Manager, Lifecycle Manager, Pre-Sales Engineer, Sales Manager, Sales Rep, or any custom role your org adds) and a set of access levels on the Account and the related Opportunities, Contacts, and Cases. Account Teams give selling organizations a way to model who actually works a deal beyond the single Account Owner field, and they give the platform a way to share visibility automatically rather than through manual sharing buttons. The point of an Account Team is to stop the most common sharing-rule workaround in Salesforce. Without teams, granting visibility on an Account to anyone other than the Owner requires either expanding the Role Hierarchy, building Account-specific sharing rules, or hitting the manual Share button on every record. Each of those has costs. Role-Hierarchy changes affect every Account in the org. Sharing rules require criteria that you have to maintain. Manual sharing breaks the moment ownership changes. Account Teams sit in the middle: they grant access record-by-record but in a structured way that survives Owner transfers and is easy to report on. For enterprise sales orgs with named-account books, Account Teams plus a clear role taxonomy beats the alternative of dumping everyone into the manual sharing button.