Accounts and Contacts in Salesforce

This is Part 18 of our ongoing Salesforce series. In this post, we dive deep into the foundational objects of Salesforce’s data model — Accounts and Contacts. These two objects sit at the center of nearly every Salesforce implementation, linking together Opportunities, Cases, Activities, and more. Understanding how they work, how they relate to each other, and how to extend them with features like Account Teams, Contact Roles, and the Account Relationship object is essential for any Salesforce administrator or consultant.

What Salesforce Licenses Can Use the Account and Contact Objects

Not every Salesforce license grants access to Accounts and Contacts in the same way. Here is a comparison of common license types and their access levels.

Key takeaway: If your users need to create and manage Accounts and Contacts as part of their daily workflow, they typically need a Sales Cloud or Service Cloud license. Platform licenses work for lighter use cases where Accounts and Contacts are reference data rather than the primary work objects.

What Are Accounts

An Account in Salesforce represents an organization, company, or individual (in the case of Person Accounts) that your business has a relationship with. Accounts are the anchor object in the Salesforce data model — almost every other standard object relates back to an Account in some way.

Standard Fields on Accounts

Some of the most commonly used fields include:

• Account Name — The name of the company or organization (required)
• Account Number — An external reference or ID number
• Account Owner — The user responsible for the account
• Industry — The industry classification (picklist)
• Type — The type of account such as Customer, Partner, Prospect, or Competitor
• Phone, Fax, Website — Basic contact information for the organization
• Billing Address and Shipping Address — Address fields for invoicing and delivery
• Annual Revenue — Estimated annual revenue of the company
• Number of Employees — Size of the organization
• Parent Account — A lookup to another Account, enabling hierarchy
• Description — A free-text area for notes about the account
• Rating — A picklist to classify account priority (Hot, Warm, Cold)

Business Accounts vs Person Accounts

Salesforce supports two types of Accounts, and understanding the difference is critical for choosing the right data model.

Business Accounts are the default. They represent companies, organizations, or any entity that is not a single individual. Contacts are separate records linked to the Account.

Person Accounts merge the Account and Contact into a single record. They are designed for business-to-consumer (B2C) scenarios where you deal directly with individuals rather than companies — think wealth management, healthcare, or retail.

Important considerations for Person Accounts:

1. Enabling Person Accounts is a one-way change — once turned on, it cannot be disabled.
2. Person Accounts do not appear in the Contacts tab by default, but they can be found through search and list views.
3. Some AppExchange packages may not fully support Person Accounts.
4. Data migration requires careful planning since Person Accounts have both Account and Contact fields on one record.
5. You can mix Business Accounts and Person Accounts in the same org using record types.

What Is the Account Hierarchy

The Account Hierarchy allows you to represent parent-child relationships between accounts. This is essential for modeling corporate structures — for example, a global headquarters with regional subsidiaries, or a holding company with multiple brands.

How It Works

Every Account has an optional Parent Account lookup field. By populating this field, you create a tree structure. Salesforce provides a built-in “View Account Hierarchy” button that displays the full tree from the top-level parent down through all children.

Example hierarchy:

Acme Corporation (Global HQ)
├── Acme North America
│   ├── Acme USA East
│   └── Acme USA West
├── Acme Europe
│   ├── Acme UK
│   └── Acme Germany
└── Acme Asia Pacific
    ├── Acme Japan
    └── Acme Australia

Setting Up Account Hierarchies

1. Navigate to any Account record.
2. Edit the record and populate the Parent Account field with the name of the parent organization.
3. Save the record. The child account is now linked.
4. To view the hierarchy, click the View Hierarchy link on any Account in the tree. Salesforce will display the entire chain from the ultimate parent downward.

Best Practices for Account Hierarchies

• Keep it shallow. While Salesforce does not impose a hard depth limit, extremely deep hierarchies become difficult to navigate and report on. Three to five levels is a practical guideline.
• Establish naming conventions. Use consistent naming so that parent-child relationships are clear even outside the hierarchy view (e.g., “Acme Corp — North America Division”).
• Use the Ultimate Parent. Consider creating a formula or custom field that always points to the top-level parent account. This is invaluable for roll-up reporting across an entire corporate family.
• Automate where possible. Use Flow or triggers to enforce that certain fields (like Industry or Account Owner) cascade from parent to child when appropriate.
• Avoid circular references. Salesforce prevents an Account from being its own parent, but be careful when bulk-updating Parent Account fields — circular chains can cause errors.

Limitations of Account Hierarchies

• There is no built-in roll-up summary across the hierarchy (since Account-to-Account is a lookup, not master-detail). You need custom solutions (Flow, Apex, or third-party tools) to aggregate revenue or opportunity counts across child accounts.
• The hierarchy view shows limited fields. For richer visualization, consider third-party tools or custom Lightning components.
• Reporting across hierarchies requires the “Accounts with Account Hierarchies” report type or custom report logic.
• The hierarchy is strictly single-parent — an Account can have only one Parent Account. For more complex relationships (joint ventures, partnerships), you may need the Account Relationship object discussed later.

What Are Account Teams

Account Teams allow you to associate multiple users with a single Account, each with a defined role and specific access level. This is how you model collaborative selling or servicing scenarios where multiple people from your organization work together on an account.

Enabling Account Teams

Account Teams are not enabled by default. An administrator must turn them on.

1. Go to Setup.
2. In the Quick Find box, search for Account Teams.
3. Click Account Teams under the Feature Settings or Accounts section.
4. Click Enable Account Teams.
5. Optionally configure the page layout to display the Account Team related list.

Account Team Member Roles

When you add a user to an Account Team, you assign them a Team Role. Salesforce comes with some default roles, and administrators can customize them.

Default roles include:

• Account Manager
• Executive Sponsor
• Sales Representative
• Technical Advisor

To customize Account Team roles:

1. Go to Setup and search for Team Roles.
2. Click Account Team Roles.
3. Add, edit, or reorder the available roles.
4. Click Save.

Access Levels for Account Team Members

When adding a team member, you define what level of access they receive on the Account and its related records.

These access levels work in conjunction with your organization-wide defaults (OWD). If your OWD for Accounts is Public Read/Write, then Account Team access settings for the Account itself are effectively moot — everyone already has Read/Write. Account Teams become most valuable when OWD is set to Private or Public Read Only.

Setting Up a Default Account Team

Users can configure a Default Account Team that is automatically added whenever they become the owner of a new Account.

1. Navigate to your personal settings (click your avatar, then Settings).
2. In the Quick Find, search for Default Account Team.
3. Click Default Account Team.
4. Add team members, assign roles, and set access levels.
5. Optionally check Automatically add my default account team to accounts that I create or accounts that are transferred to me.
6. Click Save.

Real-World Example

A technology company selling enterprise software might set up Account Teams like this:

• Account Executive (Read/Write on Account, Read/Write on Opportunities) — owns the commercial relationship
• Solutions Engineer (Read Only on Account, Read Only on Opportunities) — supports technical discovery and demos
• Customer Success Manager (Read/Write on Account, Read/Write on Cases) — handles post-sale support and renewals
• Executive Sponsor (Read Only on Account, None on Opportunities) — a senior leader engaged for strategic accounts

What Are Contacts

A Contact in Salesforce represents an individual person associated with an Account. Contacts are the people you communicate with, sell to, and provide service for.

Standard Fields on Contacts

Key fields include:

• First Name and Last Name — The person’s name (Last Name is required)
• Account Name — A lookup to the Account this Contact belongs to
• Title — The Contact’s job title
• Department — Their department within the organization
• Email — Primary email address
• Phone, Mobile Phone, Fax — Communication numbers
• Mailing Address and Other Address — Location information
• Reports To — A self-lookup to another Contact, modeling organizational reporting lines
• Contact Owner — The Salesforce user who owns this Contact record
• Description — Free-text notes about the Contact

The Contact-Account Relationship

By default, every Contact has a direct (primary) Account through the Account Name lookup field. This is a many-to-one relationship — many Contacts can belong to one Account, but each Contact has exactly one primary Account.

However, in the real world, people often have relationships with multiple companies. A consultant might work with three of your clients. A board member might sit on multiple customer accounts. Salesforce handles this through Account Contact Relationships, discussed in the next section.

The Reports To Field

The Reports To field creates a self-referential hierarchy among Contacts within the same Account. This lets you model the organizational chart of your customer’s company. While not used as frequently as Account hierarchies, it can be helpful for understanding decision-making chains during complex sales cycles.

What Are Account Contact Relationships

Account Contact Relationships allow a single Contact to be related to multiple Accounts. This feature replaces the older, more limited approach of creating duplicate Contact records across Accounts.

How It Works

When Account Contact Relationships are enabled, every Contact still has one Direct (primary) Account — the one in the Account Name lookup field. But you can also create Indirect relationships to additional Accounts.

Example scenario: Sarah Chen is the VP of Procurement at Acme Corporation (her Direct account). She also sits on the advisory board of two of your other customer accounts, Beta Industries and Gamma Solutions. Rather than creating three Contact records for Sarah, you create one Contact with a Direct relationship to Acme and Indirect relationships to Beta and Gamma.

Enabling Account Contact Relationships

1. Go to Setup.
2. Search for Account Contact Relationships in the Quick Find box.
3. Click Account Contact Relationships under Feature Settings.
4. Toggle the feature on.
5. Update your Account and Contact page layouts to include the Related Contacts and Related Accounts related lists.

Managing Relationships

Once enabled:

• On an Account record, you will see a Related Contacts related list showing all Contacts associated with that Account (both Direct and Indirect).
• On a Contact record, you will see a Related Accounts related list showing all Accounts the Contact is associated with.

To add an Indirect relationship:

1. Navigate to the Account or Contact record.
2. Click New in the Related Contacts (or Related Accounts) related list.
3. Search for and select the Contact (or Account).
4. Set the Roles (optional) and mark whether the relationship is Active or Inactive.
5. Optionally check Is Direct if this should be the primary relationship (changing this will update the Contact’s Account Name field).
6. Click Save.

Fields on the Account Contact Relationship Object

Best Practices

• Use the Is Active flag to track when a Contact leaves a company rather than deleting the relationship. This preserves historical data.
• Define meaningful Roles so that sales reps can quickly identify who the decision makers and influencers are at each Account.
• Train users on the distinction between Direct and Indirect relationships to avoid confusion.
• Remember that sharing rules apply based on the Contact’s Direct Account. Indirect relationships do not automatically grant record access.

What Are Contact Roles

Contact Roles define the part that a Contact plays in relation to a specific Account or Opportunity. They answer the question: “What is this person’s involvement?”

Contact Roles on Accounts

Account Contact Roles let you tag Contacts with a role on the Account record itself. Common roles include:

• Decision Maker
• Business User
• Technical Buyer
• Executive Sponsor
• Evaluator
• Influencer

To add a Contact Role on an Account:

1. Navigate to the Account record.
2. Scroll to the Contact Roles related list.
3. Click New.
4. Select a Contact and assign a Role from the picklist.
5. Optionally mark the Contact as Primary.
6. Click Save.

Contact Roles on Opportunities

Opportunity Contact Roles are arguably more widely used. They track which Contacts are involved in a specific deal and what part they play.

Making Contact Roles Required on Opportunities

Many organizations want to enforce that at least one Contact Role exists on every Opportunity before it can be moved to a certain stage. This ensures sales reps document the stakeholders involved in a deal.

Approach using Validation Rule:

You can create a validation rule on the Opportunity object that checks a roll-up or custom field tracking the number of Contact Roles. Since Opportunity Contact Roles is not a master-detail relationship, a direct roll-up summary is not available. Common solutions include:

1. Apex Trigger — Write a trigger on OpportunityContactRole that updates a custom field (e.g., Contact_Role_Count__c) on the Opportunity. Then create a validation rule that prevents stage advancement when the count is zero.
2. Flow — Build a record-triggered Flow on Opportunity that queries OpportunityContactRole records and blocks advancement if none exist.
3. AppExchange — Tools like “Require Contact Role” provide declarative solutions.

What Is the Account Relationship Object

The Account Relationship object is a newer addition to Salesforce that allows you to define and track relationships between two Accounts. This goes beyond the parent-child hierarchy — it lets you model peer-to-peer, partner, competitor, or any other type of inter-account relationship.

Why It Exists

Account hierarchies only support a single parent-child chain. In reality, businesses have much more complex networks:

• A company might be both a customer and a partner.
• Two accounts might be competitors in one market but collaborators in another.
• Joint ventures, distributors, resellers, and affiliates all represent Account-to-Account relationships that do not fit neatly into a hierarchy.

Account Hierarchy vs Account Relationship Object

Enabling and Setting Up Account Relationships

1. Go to Setup.
2. Search for Account Relationship in the Quick Find box.
3. Ensure the feature is enabled for your org. In some editions, this may require contacting Salesforce or enabling it through a specific setting.
4. Add the Account Relationships related list to your Account page layouts.
5. Customize the Relationship Type picklist to include your organization’s relationship categories.

Fields on the Account Relationship Object

When to Use Account Relationships vs Account Hierarchy

Use Account Hierarchy when:

• You are modeling a corporate ownership structure (parent company, subsidiaries, divisions).
• The relationship is strictly hierarchical and single-parent.
• You need to roll up data from child to parent accounts.

Use the Account Relationship object when:

• The relationship is not hierarchical (partnerships, competitors, vendors).
• An Account has multiple non-hierarchical relationships with other Accounts.
• You need to track the type and timeframe of the relationship.
• The relationship is bidirectional or does not imply ownership.

Use both together when: You need to model a corporate hierarchy AND track non-hierarchical business relationships. For example, you can use the hierarchy to show that Acme North America is a subsidiary of Acme Corporation, while using Account Relationships to show that Acme North America is a partner of Beta Industries and a competitor of Gamma Solutions.

Data Model Diagram

Below is a text-based representation of how Accounts, Contacts, and their related objects connect in Salesforce.

                    ┌─────────────────────┐
                    │   ACCOUNT (Parent)  │
                    │   ─────────────     │
                    │   Account Name      │
                    │   Parent Account ───┼──── (self-lookup for hierarchy)
                    │   Account Owner     │
                    └────────┬────────────┘
                             │
          ┌──────────────────┼───────────────────┐
          │                  │                   │
          ▼                  ▼                   ▼
┌──────────────────┐ ┌──────────────┐  ┌──────────────────────┐
│  CONTACT         │ │ ACCOUNT TEAM │  │ ACCOUNT RELATIONSHIP │
│  ──────          │ │ MEMBER       │  │ ──────────────────── │
│  First Name      │ │ ──────────── │  │ Account              │
│  Last Name       │ │ User         │  │ Related Account      │
│  Account (lookup)│ │ Team Role    │  │ Relationship Type    │
│  Title           │ │ Account Acc. │  │ Start Date           │
│  Email           │ │ Opp. Access  │  │ End Date             │
│  Reports To ─────┤ │ Case Access  │  │ Is Active            │
│  (self-lookup)   │ └──────────────┘  └──────────────────────┘
└────────┬─────────┘
         │
         ├─────────────────────────────┐
         │                             │
         ▼                             ▼
┌─────────────────────────┐  ┌───────────────────────────┐
│ ACCOUNT CONTACT         │  │ OPPORTUNITY CONTACT ROLE  │
│ RELATIONSHIP            │  │ ───────────────────────── │
│ ────────────────────    │  │ Contact                   │
│ Account                 │  │ Opportunity               │
│ Contact                 │  │ Role                      │
│ Roles                   │  │ Is Primary                │
│ Is Direct               │  └───────────────────────────┘
│ Is Active               │
│ Start Date              │
└─────────────────────────┘

Reading the diagram:

• An Account can have many Contacts, many Account Team Members, and many Account Relationships to other Accounts.
• A Contact belongs to one primary Account but can have Account Contact Relationships to additional Accounts.
• A Contact can also have Opportunity Contact Roles linking them to specific deals.
• The Account has a self-referential Parent Account lookup that creates the hierarchy.
• The Contact has a self-referential Reports To lookup for org chart modeling.

Section Notes

Here are important points to keep in mind as you work with Accounts and Contacts in Salesforce:

1. Data quality is paramount. Accounts and Contacts are the foundation of your CRM. Duplicate records, incomplete data, and inconsistent naming conventions will cascade problems across Opportunities, Cases, and Reports. Invest in duplicate management rules and validation rules early.

2. Plan your Account model before implementation. Decide upfront whether you need Person Accounts (B2C) or Business Accounts (B2B) — or a mix. Decide how you will handle corporate hierarchies. These decisions are difficult to reverse later.

3. Account ownership drives sharing. In most orgs, the Account Owner has full access, and sharing rules cascade from there. When designing your security model, start with Account sharing and work outward to related objects.

4. Account Teams complement role hierarchies. If your sales motion involves collaborative selling, Account Teams give you a structured way to share access without creating overly broad sharing rules.

5. Account Contact Relationships vs Contact Roles. These features serve different purposes. Account Contact Relationships model the structural connection between a person and an organization. Contact Roles describe the functional involvement of a person in a specific context (Account or Opportunity). Use both when appropriate.

6. The Account Relationship object fills a real gap. Before this object existed, administrators often created custom junction objects to model Account-to-Account relationships. If your org has such custom objects, evaluate whether migrating to the standard Account Relationship object simplifies your data model.

7. License considerations matter for budgeting. Not every user needs a full Sales Cloud license. If some users only need to view Account and Contact data without creating Opportunities or Cases, a Platform license may suffice and can significantly reduce licensing costs.

8. Think about Experience Cloud. If you plan to expose Account and Contact data to external users through a portal or community, remember that Community licenses have different access patterns. Customer Community users typically see only their own Account’s data, while Partner Community users may see a broader set.

Summary

Accounts and Contacts are the backbone of Salesforce. In this post, we covered:

• Accounts as the anchor object representing organizations (or individuals in B2C with Person Accounts)
• Account Hierarchies for modeling corporate structures through the Parent Account field
• Account Teams for collaborative account management with defined roles and access levels
• Contacts as the people records linked to Accounts
• Account Contact Relationships for connecting one Contact to multiple Accounts
• Contact Roles on both Accounts and Opportunities for defining functional involvement
• The Account Relationship object for modeling peer-to-peer, partnership, and competitive relationships between Accounts
• License considerations to ensure users have the right level of access

Mastering these objects and their relationships gives you the foundation to build effective sales processes, accurate reporting, and a clean data model that scales with your organization.

In the next post, Part 19: Chatter in Salesforce, we will explore Salesforce’s built-in collaboration platform — how to use Chatter feeds, groups, mentions, and file sharing to keep teams aligned without leaving the CRM. Stay tuned!