An account-level campaign report can look clean while assigning a person’s activity to the wrong company. A shared domain, a subsidiary, or a contact who works with several organizations can move a lead or pipeline record between accounts before any campaign calculation begins.
In short: define how a contact relationship maps to the account used in a report, keep the evidence and effective dates visible, and leave unresolved records in an unmatched bucket until someone reviews them. A contact-to-account match is a reporting link. It does not prove campaign attribution or buying intent.
Decide what an account means in this report
Start with the decision the report should support. Is the account a legal company, an operating subsidiary, a regional business unit, or a parent-level buying group? Those are different reporting grains. A parent roll-up should be a separate, documented step after the contact has been linked to an account.
Keep three records distinct:
- the contact and the campaign interaction;
- the contact’s relationship to one or more CRM accounts;
- the account chosen for this particular report.
This separation makes the logic easier to review. A contact may have a primary employer and a second relationship with a client or partner. That does not mean every interaction should count for both accounts. Decide which relationship qualifies for the question being measured.
If the report is used to prioritize sales attention, combine fit and account-level evidence carefully. The guide to prioritizing target accounts by buying-group progress covers that decision; this article focuses on the data link that makes the account roll-up possible.
Use a domain as evidence, not as the whole rule
An exact work-email domain can be a useful match signal when it maps to one approved company record. It is less reliable when a company uses several brands, a domain is shared across business units, a consultant uses their own employer’s address, or a contact signs up with a personal email.
HubSpot documents automatic contact-to-company association by matching an email domain to a company domain. Its behavior also shows why teams need exceptions: subdomains can create separate company records, a shared domain can resolve to only one company, and a free email address may need a website value to attempt a match. Treat this as one CRM’s configured behavior, not a universal identity standard.
Write down which evidence is sufficient for an automatic reporting match. For example:
- Verified: an active CRM relationship has a named source and a review date.
- Strong candidate: a normalized work-email domain matches one entry in an approved, current domain map.
- Unresolved: the domain is shared, personal, missing, or conflicts with another account signal.
Do not silently promote a candidate to verified because a system created the association automatically. Keep the rule, its evidence, and the confidence level available to the person reviewing the report.
Preserve multi-company and time-bound relationships
People can have legitimate relationships with more than one company. A consultant may work across clients; a board member may serve several organizations; an employee may move from one employer to another; a subsidiary may share a brand with its parent.
When the CRM supports relationship records, use them to represent these connections instead of creating duplicate contact records or forcing every person into one account. Salesforce, for example, distinguishes a contact’s primary account from other account relationships and can record roles and relationship dates. The exact objects and reporting behavior depend on the CRM and its configuration.
For each relationship used in reporting, preserve at least:
- the contact and account IDs;
- relationship type or role;
- whether the relationship is active;
- start and end dates, when known;
- how the match was made and who reviewed it.
Use the relationship that was valid when the campaign interaction occurred if the report is meant to describe that period. A contact’s current employer should not automatically rewrite last year’s activity. Also check the report type: Salesforce notes that indirect account-contact relationships are not available in its standard Account and Contact report type, so a technically valid association can still be absent from a particular report.
Keep account ownership separate from contact matching. A new domain match should not change an account owner, merge records, or rewrite a company crosswalk. For company renames and acquisitions, follow a deliberate history and ownership process such as the one in the account-ownership guide. For suspected duplicates, use a review queue; a possible duplicate is not itself proof of identity.
Choose one reporting account for each eligible interaction
Define the join before building the dashboard. A practical rule might use the active primary account as of the interaction date, then include a secondary relationship only when its documented role is relevant to the report. If the CRM cannot preserve historical relationship dates, record a dated account snapshot for the reporting period.
Keep the underlying contact, campaign interaction, relationship, and selected reporting account IDs. This lets a reviewer trace a number back to the records and see which rule assigned it.
Avoid joining one interaction to every account related to a contact and then summing the result as if each row were a separate person or conversion. That can multiply activity and pipeline. If the business question requires a person’s activity to appear under more than one account, label the report as relationship-level and state that account totals can overlap.
Keep uncertain matches visible
An unmatched or ambiguous record is useful information about data coverage. Forcing it into the most convenient account makes the report look more complete while hiding the uncertainty.
Keep separate counts for:
- eligible interactions with a verified account match;
- interactions with a candidate match awaiting review;
- interactions with no defensible match;
- interactions with more than one plausible account.
Measure association coverage beside campaign outcomes: matched eligible interactions divided by all eligible interactions. Review that coverage over the same period and population as the campaign report. A change in match coverage can move reported account totals even when campaign performance has not changed.
Track corrections too. If reviewers frequently change automatic matches for one domain, brand, or segment, update the mapping rule and reprocess the affected reporting window with a visible change date. Do not compare the revised series with an older report as if the definitions had stayed constant.
Test the rule on the cases most likely to break it
Before using the mapping in a regular report, review a small sample that includes ordinary contacts and known edge cases: subsidiaries, multiple domains, shared domains, consultants, personal email addresses, former employees, recent acquisitions, and accounts with duplicate records.
For each sample record, ask:
- Does the selected account match the business question and reporting grain?
- Was the association active on the interaction date?
- Can another person reproduce the decision from the stored evidence?
- Does the report count the interaction once, or explain why it appears under multiple accounts?
- Are unresolved records still visible in the coverage figures?
Compare both incorrect matches and missed matches. A domain rule that avoids false positives by leaving too much data unmatched may need a review path; a rule that maximizes coverage may be assigning contacts too freely.
Keep the policy small enough to maintain
Store the policy next to the report definition or data model. It can be short if it states the choices that change the result:
- Reporting grain: Which CRM account level does the report use?
- Primary evidence: Which relationship or approved domain map qualifies?
- Fallback: Who reviews shared, missing, personal, or conflicting domains?
- Time rule: Which relationship date applies to a historical interaction?
- Multiple accounts: When can a secondary relationship qualify, and can totals overlap?
- Coverage: How are verified, unresolved, and ambiguous matches shown?
- Ownership: Who maintains the mapping and records each rule change?
If a team cannot explain why a contact’s campaign activity belongs to a particular account, keep it out of the confirmed account roll-up until the evidence is reviewed. A clear unmatched count is more useful than a precise-looking total built on an invisible guess.
If account-level campaign reports disagree across CRM, analytics, and ad platforms, map the association rules, reporting grain, and coverage gaps.
Sources and scope
- HubSpot Knowledge Base: Automatically create and associate companies with contacts — domain-based matching behavior and documented exceptions.
- Salesforce Help: Account Contact Relationship Fields — primary and related account fields, roles, active status, and relationship dates.
- Salesforce Help: Considerations for Relating a Contact to Multiple Accounts — relationship behavior and reporting limitations.
These are examples of product-specific behavior. Confirm the objects, settings, permissions, and report types in your own CRM before adopting a matching rule. The recommendations above define a reporting policy; they do not establish a universal identity standard. Accessed October 9, 2026.
How did this article land?
Choose one reaction. You can change it anytime.