Account Contact Relationship
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.
Definition
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.
How the indirect relationship actually behaves
The direct vs. indirect distinction
The Contact's AccountId is the direct relationship. Every other ACR row is indirect. The flag IsDirect on the ACR record marks which is which. There is always exactly one direct ACR row per Contact, even if nobody created it manually, because Salesforce auto-generates one to match AccountId. Change the AccountId on the Contact and Salesforce silently flips IsDirect on the corresponding ACR row. Delete the direct ACR row and you delete the Contact's primary affiliation.
Roles, the most-used field on the object
Roles is a multi-select picklist that names what the Contact does at that Account. Common values are Decision Maker, Influencer, Executive Sponsor, Buyer, Evaluator, Business User. The set is fully customisable through the picklist value set. Roles is what most reports actually filter on. Salesforce ships a similar but separate object called OpportunityContactRole, confusing because the two look alike but answer different questions. OpportunityContactRole says who is on this deal. ACR.Roles says what this person does at this company.
IsActive, StartDate, EndDate and historical relationships
ACR is not only about who works where right now. The IsActive flag plus StartDate and EndDate make it a timeline. A former CFO who left the company in 2024 stays on the Account with IsActive set to false and an EndDate populated. That history is what powers ex-customer-became-customer-somewhere-else plays. Marketing automation typically filters IsActive equals true to avoid emailing someone at a job they no longer hold. Reports that ask for all stakeholders we have ever worked with at this Account leave the filter off.
Turning the feature on with Allow Users to Relate a Contact to Multiple Accounts
The feature is off by default in older orgs. Setup, Account Settings, Allow Users to Relate a Contact to Multiple Accounts must be checked. Once enabled, the setting cannot be cleanly disabled if any indirect ACR rows exist. Salesforce treats this as a one-way switch in practice. New orgs created after Spring 17 have it on by default. If a Contact related list is missing the Related Contacts component, the setting is almost always off.
Sharing rules treat indirect Contacts separately
Direct Contacts inherit Account sharing automatically. Indirect ones do not. When the feature is enabled, a separate sharing model kicks in for indirect ACRs. The default is Controlled by Parent of the related Account, but admins often need to add Account Contact Relationship sharing rules to expose indirect Contacts to teams that should see them. This is one of the easiest things to miss after a rollout: the Contact exists, but a sales rep on a different Account cannot see it because no sharing rule grants access.
ACR in Person Accounts orgs
In Person Accounts orgs, every Account also has a Contact under the hood. ACR works there too, but the common use is relating a Person Account's Contact to a Business Account. A private individual who also serves on a corporate board, for example. It keeps household and B2B affiliations on one Contact record without duplicating the person across two records.
Reporting and custom report types
The standard Accounts and Contacts report type only walks the direct relationship. To report across indirect affiliations, create a custom report type with primary object Account and child object Account Contact Relationship, optionally with Contact as a related object. The same logic works in reverse for all Accounts for this Contact. Most reporting bugs after enabling ACR come from analysts forgetting which report type they are sitting in.
Automation patterns and integration gotchas
Flows that create or update an ACR fire the standard Contact triggers indirectly only if the row is the direct relationship. Indirect ACRs have their own object triggers on AccountContactRelation, so any logic that depended on Contact changed Account needs a parallel path on the junction object. Data Loader imports usually start by loading Accounts, then Contacts, then ACR rows referencing both. Remember that IsDirect cannot be set on insert for the auto-generated direct row, since Salesforce manages that flag itself.
How to enable and use Account Contact Relationships
Enabling the feature and adding the related list to page layouts takes about ten minutes. The judgement call comes later, when you decide which roles your business actually tracks.
- Turn on multi-Account relationships
Setup, Feature Settings, Sales, Account Settings, then check Allow Users to Relate a Contact to Multiple Accounts. Save. The button to add an indirect Contact now appears on Account page layouts.
- Add the Related Contacts component
On the Account Lightning record page, add the Related Contacts component, or the related list if the org is still on Classic. This is the list that shows direct and indirect Contacts side by side.
- Configure the Roles picklist
Setup, Object Manager, Account Contact Relationship, Fields, Roles, Picklist Values. Start narrow. Three to five roles is enough. Add more only when reporting demands it.
- Review sharing on the AccountContactRelation object
Setup, Sharing Settings. AccountContactRelation defaults to Controlled by Parent. If sales teams complain they cannot see indirect Contacts, add a sharing rule from Account ownership to the junction.
- Train users to use Add Relationship, not new Contacts
The most common mistake is creating a new Contact at every Account. Train reps to search first, then click Add Relationship if the person already exists somewhere in the org.
- Disabling the feature after going live is effectively impossible without deleting all indirect ACR rows first. Plan as if the switch is one-way.
- Standard report types do not cover indirect relationships. Build a custom report type before promising the data to a stakeholder.
- Sharing for indirect Contacts is separate from Account sharing. Add explicit rules or indirect Contacts will be invisible to teams that own the related Account.
- OpportunityContactRole and AccountContactRelation answer different questions. One tracks deal involvement, the other tracks ongoing affiliation. Do not try to merge them.
Trust & references
Cross-checked against the following references.
- Relate Contacts to Multiple AccountsSalesforce Help
- AccountContactRelation API ReferenceSalesforce Developer Docs
Straight from the source - Salesforce's reference material on Account Contact Relationship.
- Set Up Contacts to Multiple AccountsSalesforce Help
- Considerations for Relating Contacts to Multiple 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.
Discussion
Loading discussion…