# How to leverage Data Cloud for B2B account-based marketing

B2B resolution is the account and the buying group. A segment of email addresses is a list, not an account plan.

**Published:** 2026-02-06
**Canonical:** https://synconai.com/data-cloud-b2b-account-based-marketing
**Author:** SynconAI Architecture Team

## In short

B2B resolution is an account and a buying group. A segment of email addresses is a list, not an account plan. Identity resolution builds unified profiles from source profiles stored in Data 360. The product was called Data Cloud until 14 October 2025, and the behaviour is unchanged. Name the account, the people who buy, and the fields you will filter on. Then build the segment.

## Sources

- **About Identity Resolution** (retrieved 2026-10-10)
  https://help.salesforce.com/s/articleView?id=data.c360_a_identity_resolution.htm&type=5
  > Identity resolution is the processing engine that generates unified profiles from source profile data stored in Data 360.
- **About Salesforce Data 360** (retrieved 2025-10-14)
  https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5
  > As of October 14, 2025, Data Cloud has been rebranded to Data 360. During this transition, you may see references to Data Cloud in our application and documentation. While the name is new, the functionality and content remains unchanged.

## What to take away

- Resolve the account and the buying group. A person profile alone is not an account plan.
- Identity resolution builds unified profiles from source data. It does not invent the buying group.
- An email segment is a list. Keep it out of the slide titled account strategy.
- Filter on fields a seller can act on: account, role, consent, and a real opportunity state.

## The guide


A seller is handed a segment and told it is the account plan. The segment is every contact with a corporate email and a job-title keyword. A domain rule, added because it felt clever, has attached a subsidiary and a public-mailbox contact to the wrong account. The seller says the people are wrong. The response in the room is to add more accounts so the argument is diluted by volume. The ads file then receives every employee on those accounts, including people whose consent flag is blank. The plan, the list, and the send have been treated as one object. They are three.

## The unit of work is the account

People search for Data Cloud and account-based marketing in the same breath. The product name is Data 360. It was rebranded on 14 October 2025, and the behaviour is unchanged. You may still see the old name in search and, for a while, in the product. "While the name is new, the functionality and content remains unchanged." Identity resolution still builds unified profiles from the source profiles you store. Those profiles can be people. For this work they also have to be accounts, or you will market to inboxes and call it an account plan.

Start with the account key the seller already trusts. That is the CRM account id, including the parent you have actually agreed is the planning entity. Territory, parent, and billing entity are often three different records. If you have not decided which one the seller means, you do not have an account list. You have a hierarchy argument, and Data 360 will not pick a surviving account for you. It does not override source values. It will show you all three, faithfully, and a segment built on "the account" will pick whichever one your filter happened to name.

Bring the people who belong to that account, with a role the CRM already stores. A buying group is a list of roles you can point at records. If the role field is empty, you do not have a buying group. You have employees. Say so, and do not brief a campaign as if a committee had been identified. Inventing "economic buyer" in a workshop, with no field to put it in, creates a slide. It does not create a key. Empty role fields should fail the segment, not be filled with a keyword from a job title you parsed.

## What identity will not do for you

The engine relates source profiles. It does not read the org chart, and it does not decide that three email addresses are a purchasing committee. Unified profiles are keys. They are not a golden record. Identity resolution does not pick a winning value. If accounts are duplicated in the CRM, you will unify the mess and then build segments on top of it. Clean the account hierarchy in the CRM first, under a rule a person wrote, if one legal entity must remain. The profile will then point at what you kept. It will not lead that cleanup.

Match people to accounts on a key, not on a domain guess, unless you have tested the domain and excluded shared providers and subsidiaries that share a suffix. A domain rule feels clever and glues the wrong staff to the wrong account. Run it on a sample of fifty accounts before it is a rule. Read the sample with a seller, not only with the person who wrote the rule. The seller can see the subsidiary. The rule cannot, unless you taught it. If the sample is wrong, fix the rule. Do not add more accounts to dilute the argument. Dilution is how a bad match becomes a programme.

Consent still applies to each person. An account plan does not put every employee into an advertising audience. Carry the person-level flag, with a source and a time. Hold out blanks and conflicts. The stricter flag stands until a person resolves the conflict. The account can be in a seller's plan while a person on that account is not in the activation. Those are different extracts. Do not collapse them because the count looks small. A small lawful audience is the result you wanted. A large unlawful one is the failure you will have to explain.

The field choices underneath that extract, including which CRM columns are worth mapping and which are noise, are [the mapping decisions](/map-crm-data-to-data-cloud). Bring the account id, the person id, the role if it is maintained, and the consent. Leave the rest until a seller asks a question that names a column.

## A segment is not a plan

Account-based work fails in the tool when the segment is everyone with a corporate email and a job title keyword. That is a list. A plan names the accounts, why they are in, what the seller will do, and which people are in play. Data 360 can hold the attributes for that plan: industry, if you maintain it; open opportunity, if sellers keep stage current; last activity, if the activity is actually captured; consent; role. It should not be asked to be the plan. The plan is a sales management problem. The platform is the place the agreed facts are visible.

Filter on fields a seller will actually use. Opportunity stage is a fair filter when a seller updated it this month. It is a trap when stage is where opportunities go to sit. Read five opportunities in the sample and ask the seller whether the stage is still true. If they wince, do not filter on it. Employee role, if it is maintained. Region, if territory is real. A score you cannot explain is a bad filter. It will be challenged in the forecast meeting and you will not have a sentence ready. "Likely" is not a stage. If you do not have a recorded outcome, you have a rule, and the rule should say so. Do not let the segment name oversell a filter on stale stage.

Keep the activation narrower than the plan. The seller may see the full buying group inside the CRM, including people you will not contact by an ad channel. The ad destination receives only the people whose consent covers that use. Write both extracts down so nobody "helps" by widening the file to match the plan. The plan is allowed to be larger than the send. The send is not allowed to catch up by ignoring the flag.

Zero copy is federation, not a latency promise, and it will not identify a buying group. You can connect external firmographic data with zero copy data federation and leave those bytes in the external store. A federated industry code does not become a role, and it does not tell you the query will return before a seller finishes a sentence. If a seller is waiting on a fact, measure the path or copy the narrow column. Do not federate a wide account table and call it account-based marketing because the table mentions accounts.

Tableau Next does not replace Tableau. A chart of "accounts in the segment" is not a plan, and moving the chart to a new surface does not create roles you did not store. The help page says you can expand Data 360 using Tableau or Tableau Next. Use the tool the seller's analyst already opens, and put the grain in the title: account, or person. A chart that counts people and is labelled as accounts is the double-count that makes a thin territory look crowded.

## The hierarchy problem, stated separately

Parent, child, billing entity, and territory owner fall apart in the first real list. A seller works the parent. Finance invoices the child. Marketing built the segment on whichever account id was populated on the contact, which is often the child, sometimes the parent, and sometimes a duplicate from an old import. Identity resolution will relate the contact to the account id you stored. It will not walk the hierarchy unless you mapped the hierarchy and wrote which level the plan uses.

Pick the level in a sentence. "The plan is the CRM account the opportunity sits on, not the ultimate parent, unless the opportunity is explicitly marked as parent-level." Then filter on that. If you cannot write the sentence, you are not ready to build the segment. You are ready to have the hierarchy meeting, which is a CRM meeting. Hold the Data 360 work until the sentence exists. Building the segment first will set the level by accident, and every later report will cite the accident as the definition.

Duplicate accounts are the same meeting. Running a person match across them will not collapse two legal entities, and it may attach the wrong buyers to the wrong name. Fix the account key in the CRM if the account is the thing that is duplicated. Then map the records you kept.

::: note
A domain match is a hypothesis. It becomes a rule only after a seller has read a sample and the shared providers and the shared suffixes are excluded. Until that reading, match on the CRM account id. Clever joins are how the subsidiary ends up in the wrong plan.
:::

## A first slice you can finish

One sales team. One account list they already work, at the hierarchy level you wrote down. People on those accounts with a non-blank role and a non-blank consent flag. One activation or one CRM view, not both plus a new charting tool. Read twenty accounts with the seller before you widen the list. If the seller says the people are wrong, the match rule is wrong. Fix the rule. Do not add accounts.

| Artefact | What it contains | What it is not |
| --- | --- | --- |
| Account list | Named accounts, the level in the hierarchy, why they are in | A domain, or every account in an industry code |
| Buying group | People on those accounts whose role you store | Every employee, or a job-title keyword |
| Seller view | The group, including people you will not activate | The advertising file |
| Activation | People whose consent covers that use | The plan, and not a place to backfill blanks |
| Profile | Keys back to the account and the person | A golden record, and not a substitute for the CRM survivor |

The product will ingest and unify what you mapped. It will not supply the account strategy, the roles, or the consent. Those remain operational facts you either have or you do not. Pretending the segment created them is how a list gets a strategy slide and a seller who will not use it the following week.

The identity and attribute decisions under that table are cheaper before the first account is activated than after a seller has quoted the list in a forecast. What the account entity is, which key joins a person to it, who owns email and who owns role, whether firmographics are copied or federated. They belong with the other decisions made before ingestion, in [getting Data 360 right the first time](/insights/data-360-implementation-best-practices).

## What you refuse in the kickoff

You refuse to call an email list an account plan. You refuse a buying group you cannot point at a field. You refuse a domain rule that has not survived a sample. You refuse to let the account's presence in a plan stand in for a person's consent. You refuse to widen the list to escape a seller who says the people are wrong.

Those refusals are the design. The segment you build after them is small enough to finish, and dull enough that the seller recognises the accounts. Recognition is the test. A count is not.


## Questions

### Is a segment of work emails an account-based programme?

No. It is a list. An account plan names the accounts, the reason, the seller action, and the people in the buying group whose roles you actually store. A job-title keyword is not a role. If the role field is empty, say you have employees, and do not brief a committee you cannot point at.

### Will identity resolution build the buying group?

It builds unified profiles from source profiles. The roles have to exist on those sources. Empty role fields mean you have people on an account, not a committee. The profiles are keys, not a golden record, and the engine does not read an org chart or override the CRM. Clean the account hierarchy in the CRM if parent, billing, and territory are being treated as one thing.

### Should we match people to accounts by email domain?

Only after a sample. Shared inboxes, public mail providers, and subsidiaries that share a suffix will attach the wrong person. Prefer the CRM account id. Read fifty accounts with a seller before a domain rule is allowed to run. If the seller says the people are wrong, fix the rule rather than adding accounts to dilute the sample.

### Does the account's plan cover consent for every employee?

No. Consent stays on the person. The seller can work the account while activation holds out anyone with a blank or conflicting flag. A buying group does not consent on behalf of a colleague. The plan and the advertising file are different extracts. Do not widen the file so the counts match.

### What is the product called?

Data 360. Data Cloud was rebranded to Data 360 on 14 October 2025, and the behaviour is unchanged. You may still see the old name in search and in parts of the product. The rename does not turn an email list into an account plan, and it does not make identity resolution invent roles.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Data 360 (https://synconai.com/salesforce-data-360-services.html).