Hierarchies and Two-Way Data

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 5 of 6 in the chapter Master Data and Identity, chapter 6 of the Data Architect course. Each module stands on its own. Previous: A Map Is Not a Decision · Next: Checkpoint 1: Steve Trucking

The question this module answers: How do you manage data that more than one system maintains?

The easy architecture: the ERP owns the customer, Salesforce gets a copy, done. Real enterprises aren’t that clean. The ERP owns the legal customer and Salesforce the sales relationship; one division lives in SAP, an acquired one in a different ERP; prospects exist only in Salesforce. Then someone wants Salesforce users to update an ERP-controlled field, and the arrows start pointing both ways. As I say when I teach this: “The hardest thing are the bi-directionals.” Not because sending data both ways is technically hard, but because once both systems take part in change, you have to be extremely precise about authority.

Two-Way Data Doesn’t Mean Two Masters

The ERP owns the billing address, copied into Salesforce. A rep learns from the customer that it’s changed, and the business wants them to update it without leaving Salesforce. Reasonable. Now data flows ERP → Salesforce and Salesforce → ERP. Does Salesforce now co-own the billing address? No. The direction of an integration doesn’t decide authority. The rep isn’t changing Salesforce’s copy. Architecturally, they’re asking to change the authoritative value. You aren’t changing the ERP’s field; you’re asking to change it. Salesforce is the interface; the ERP is still the master.

That changes the design. If Salesforce owned the field, save and done. If the ERP owns it, “save” means Salesforce sends the proposed address, the ERP validates and accepts it, updates its master, and sends the authoritative value back. Only then has the governed value changed: request → validate → accept → publish, not “update both systems and hope they stay in sync.”

Click to enlarge

A bidirectional integration does not create bidirectional authority.

When the Master Says No

The ERP rejects the change: the customer is inactive, the address breaks an ERP rule, the user may not change legal addresses, the ERP is down, or someone else changed the customer in the meantime. If Salesforce already showed the new address, we now have two truths, and module 1 already told us which wins: the ERP’s. So the architecture needs a state for requested, not yet accepted: a separate proposed value, a “pending change” flag, or waiting for confirmation before showing it. The mechanism depends on the use case. The rule doesn’t: never let a rejected request turn into competing truth.

Loops and Collisions

Here’s a classic. The ERP updates Salesforce; Salesforce’s integration sees a change and sends it to the ERP; the ERP sees an update and sends it back. You’ve built a very expensive loop. Good two-way design knows where a change started, whether the master has accepted it, and whether this is a new business change or just the echo of one already processed: source identifiers, timestamps, integration metadata, idempotent processing. The Integration chapter goes deep. The master-data principle is simple: know whether you’re originating a change or reflecting one.

Then collisions. You met one in chapter 5: a rep asks for Steve’s Plumbing LLC while someone in the ERP types Steve’s Plumbing L.L.C. (Protect the Governed Record). Here’s another. Salesforce proposes 125 Main Street; at almost the same moment an ERP user changes it to 130. Which wins? There’s no universal technical answer. Maybe the ERP always wins because it owns the field; maybe the Salesforce request goes to a review queue; maybe the later accepted change wins; maybe the ERP rejects any update whose starting value has changed. That’s concurrency, but underneath it is an authority decision, and no integration pattern can save you if nobody decided who may make the authoritative change.

And a single field is the simple case. An address is a street, a city, a postal code. Salesforce sends a new street while the ERP has just changed the city. Do you let the street through on its own? Or do you treat the address as one transaction, so the fields all go together or none of them do, and reject the entire change? Decide which fields travel as a group before the first collision, not after.

Whenever I see a two-way integration, I ask what happens when both sides change the same data? If the answer is “that probably won’t happen,” we’re not done. Which wins, do we reject, queue, compare versions, review? Should the field be editable in both places at all? Sometimes the best two-way design removes one direction for a given attribute: Salesforce may request; only the ERP publishes the accepted value. Data still moves both ways, but only one system masters the field. That difference is everything.

Hierarchies Are Master Data Too

Relationships can be master data as well. A global parent with North American and European regions, each with country subsidiaries: the hierarchy itself carries meaning. Who’s the parent? Which subsidiary sits under which legal entity? Which accounts roll up to the global customer? That drives reporting, territories, pricing, contracts, credit exposure, service, data access and analytics. A hierarchy can matter as much as the records in it, and it needs the same governance. (The exam names hierarchy management; it’s easy to forget.)

On Salesforce, account hierarchies are built with the Parent Account field. The Lightning hierarchy view shows up to 2,000 accounts, and only those the user may see; person accounts aren’t supported in the hierarchy; and Account Site distinguishes a company’s locations (Considerations for Using Account Hierarchy (opens in a new tab)). But the Parent Account field doesn’t answer the architecture question: who owns the hierarchy?

Test knowledge. Know the account hierarchy basics: it’s built with Parent Account; the Lightning view shows up to 2,000 accounts, only those the user can see; person accounts aren’t supported; and Account Site distinguishes a company’s locations.

One Hierarchy, Several Masters

In my experience, hierarchies are split-mastered. North American entities come from SAP, European ones from another ERP, new prospects are built in Salesforce, and an acquired subsidiary hasn’t migrated yet. Who owns the hierarchy? It depends on the branch. Each ERP controls its branch; Salesforce controls prospect relationships until they convert. That’s a legitimate architecture, as long as everyone knows where the boundaries are. Decide per branch.

Click to enlarge

Hierarchy authority can be assigned branch by branch.

So don’t let the Parent Account field hide the authority. A user re-parents a subsidiary in Salesforce. Technically trivial. Architecturally, did they just change the company’s legal structure? If the ERP masters that branch, probably not, so Salesforce should block it, or turn it into a change request. Or perhaps Salesforce legitimately keeps a commercial hierarchy while the ERP keeps the legal one. Then maybe they shouldn’t be the same relationship at all.

A company can have several valid hierarchies: legal, billing, sales, service, geographic. The global parent signs the contract, regions get service on their own, billing runs through a shared finance entity, sales manages by region. Which is the true hierarchy? All of them; they answer different questions. The mistake is assuming there must be one. There should be clear authority for each kind of relationship: module 1’s attribute principle, applied to relationships.

And not every parent-child relationship is master data. Grouping today’s deliveries onto one route is a relationship, but it’s transactional, an operational event. A customer hierarchy describes a durable business relationship. Both look like parent-child in a model; they don’t share a lifecycle. Ask what the relationship means and how long that meaning lasts.

One Customer, Two ERPs

When I teach this I ask the room: who has worked with a client that has one Salesforce and more than one ERP? Hands go up every time. Ask why, and the ERPs turn out to be split regionally (one for North America, one for Europe), functionally (a plumbing company buys an electrical company, and each keeps its own ERP), or just historically: the business was acquired, and nobody has migrated it yet.

Take Steve’s Plumbing as the customer. It does business in North America, so the North American ERP has a customer record for it. Then it opens an office in Munich, and the European ERP creates a customer record of its own, with its own customer number. Same company, two records, two IDs. How do I represent that in one Salesforce org? I’ve seen three ways.

An account hierarchy. Steve’s Plumbing is the parent, with Steve’s Plumbing North America and Steve’s Plumbing Europe as child accounts, each child standing for one ERP’s record. The catch: the children aren’t really Steve’s Plumbing anymore. They’re Steve’s Plumbing doing business in a region, and as we just saw, a hierarchy carries meaning.

Peer accounts. Two accounts side by side, each with a field that says which ERP it belongs to: a company code, a region. Nothing is hidden. The cost shows up in reporting: to see Steve’s Plumbing across the world, you need something that says these two accounts are the same company.

One account, with a child per ERP. One Steve’s Plumbing, and a child object with a record for each ERP holding that ERP’s customer ID. Two ERPs or ten. The salespeople see one customer and place one order; behind the scenes, flows decide which ERP each line goes to: electrical work to the electrical ERP, plumbing to the plumbing ERP. But now you have to decide which ERP is primary for the shared values, like name and address, and what happens when the customer exists in one ERP and not the other.

Click to enlarge

One customer, two ERPs: three ways to represent it in Salesforce.

Ask How They Keep the ERPs in Sync

So which one? First: how much of the ERP structure should the salespeople see? If they’ve always known that North America and Europe are separate businesses, because they log in to one ERP or the other, don’t hide it from them. Carry that structure into Salesforce as peers. If the business wants one Steve’s Plumbing in front of sales, you’re looking at one account with a child per ERP.

Then the question that really decides it, and it isn’t decided in Salesforce. I ask the client: how do you keep those two records in sync between your ERPs? Not the things that are local to each ERP, like the balance; that’s transactional. I mean the master data: the legal name, the addresses. If they have a team that keeps the two ERPs in sync, we can bring them together as one account. If they can’t keep them in sync in their own ERPs, how are they going to expect us to keep them in sync in Salesforce? Then it’s peers, or a hierarchy.

Remember what an ERP is. These are massive systems that take years to put in place, and they come with their own way of managing master data. Salesforce isn’t going to drive them. We don’t get to control the ERPs. We get to control how we represent them in Salesforce.

MDM in the Middle

Some clients have already solved this before we arrive. A large company, many years in business, several ERPs: they hit this problem long before Salesforce and put a dedicated MDM product in the middle to broker between the ERPs. That’s the coexistence or centralized MDM of module 2. Now Salesforce doesn’t wire itself to every ERP. It points to one place, the MDM hub, and gets a single representation of the customer. Don’t expect to meet one often, though. These are big implementations in their own right; in all my years I’ve worked with one only two or three times. And even with the hub, you may still need that child object, so each order knows which ERP it’s going to.

Click to enlarge

MDM in the middle: Salesforce points to one place.

Steve Trucking: Whose Hierarchy?

A Retail Partner has its own structure: corporate parent, regional divisions, distribution centers, stores. Does Steve Trucking own that hierarchy? No; the partner is the authority for its own organization. But Steve Trucking may need its own commercial view of those same locations, for contracts, account management, service and reporting, perhaps a child account for each DC under the partner. Two legitimate hierarchies, two authorities. Name them, and don’t pretend one tree represents every relationship.

Make the Boundaries Visible

Whenever authority is split, I want the boundary visible: field naming, record metadata, source-system identifiers, permissions, integration behavior, documentation. What I don’t want is a developer reading five integrations to discover “these Parent Account values come from SAP, except prospects, except Europe.” That’s not a maintainable authority model. If the hierarchy is split-mastered, document the split. If authority changes at conversion, document the change. If Salesforce can request but not make a change, make that obvious in the experience.

In Salesforce, that starts with one field. There needs to be a field that clearly says this is master data: the ERP’s key, or an “is master data” flag. Drive field editability from that field, not from a record type; with Dynamic Forms you no longer need a record type to show the ERP’s fields read-only (chapter 5, A Record Type for Each Flow). You can allow records to be created outside the master, but watch the edits.

Beyond the exam: what AI changes. A customer tells an agent, “change our billing address to 125 Main Street.” The field is right there in Salesforce. Should the agent update it? Not if the ERP owns it. An agent needs write authority, not just field access: its action should encode the approved path, submitting a change request and saying “I’ve submitted the change for processing,” not falsely reporting “I’ve updated your billing address.”

What an Architect Decides Here

• Whether a Salesforce edit changes authoritative data or requests a change from the system that owns it.
• How two-way flows tell originating changes from echoes, and handle rejection, collisions, latency and failure.
• Who owns each hierarchy, branch by branch if need be.
• For one customer held in several ERPs: a hierarchy, peers, or one account with a child per ERP, decided by how well the client keeps its ERPs in sync.
• Whether competing hierarchies are really different legitimate relationships: legal, billing, sales, service.
• How authority boundaries and approved write paths are made visible to users, integrations, developers and agents.

Shared authority isn’t the problem. Ambiguous authority is. Several ERPs can master different branches, Salesforce can master some attributes and request changes to others, and several hierarchies can describe one enterprise. All of that works, as long as for every important attribute and relationship you can say who owns it, who may change it, where the authoritative change is made, and what happens when systems disagree. If you can’t, another two-way arrow on the diagram won’t fix it.

Explore

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab), checked 2026-10-14.