키와 쓰기 소유권

19개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

A semi-detached house with each half painted a different colour, blue and cream, meeting in a straight line down the middle. — AI로 생성한 이미지

Data Architect 과정 9장인 통합과 데이터 이동의 모듈 2/4. 각 모듈은 독립적으로 읽을 수 있습니다. Previous: Before the Arrow · Next: Proof of Delivery ⟲

이 모듈이 답하는 질문: 레코드는 어떻게 짝을 유지하고, 누가 무엇을 바꿀 수 있을까요?

Every time an integration touches a record, it has to answer two questions: which record is this? and whose value is this? Get the first wrong and you create duplicates or update the wrong record. Get the second wrong and you overwrite data someone else owns. These aren’t edge cases. They’re two of the most common ways integrations damage a good data architecture. ⟲

Start With the Flows

In chapter 6 we drew the most common integration I see: one Salesforce and one ERP. Customers and products come in from the ERP; orders and order items go out from Salesforce. Several flows, in order. ⟲

클릭하여 확대

From chapter 6: Salesforce and the ERP, several flows in order. ⟲

Now zoom in on the first arrow: customers into Account. Every record that crosses it asks both questions. Which account is this customer? And which of its fields may the ERP write? ⟲

“고객을 찾아 줘”

The ERP sends a customer: Steve’s Plumbing, payment terms Net 30. Which account? Search by name? Then you meet Steve’s Plumbing, Steve’s Plumbing LLC, Steve’s Plumbing - West, and a Steve’s Plumbing & Heating that has nothing to do with it. Everyone knows the first two are the same company, and the integration doesn’t. Names are useful to people and terrible as integration keys. The integration needs a stable identity. ⟲

One Record, One Key

So when a Salesforce record corresponds one-to-one with a record in a significant external system, carry that system’s key on the Salesforce record, in a field marked External ID. The ERP’s customer number 10442 lives on the account. Now the ERP’s updates don’t need guessing. ⟲

And an External ID can drive upsert: one call that decides for you. If the key isn’t found, the record is created (unless the call says update only). If it’s found once, that record is updated. If it’s found more than once, the call fails with an error and nothing is created or updated (Insert or Update (Upsert) a Record Using an External ID (새 탭에서 열림), REST API Developer Guide, checked 2026-10-27). That makes integrations far easier to restart safely. ⟲

That last rule is why I mark the field Unique as well. External ID says this field holds another system’s identifier and can be used for matching. Unique says two records may never share the value (Custom Field Attributes (새 탭에서 열림), Salesforce Help, checked 2026-10-27). If the architecture depends on one-to-one identity, I’d rather hit the conflict the moment someone creates a second account with 10442 than discover it as an integration mystery six months later. ⟲

Test knowledge. Upsert matches on an External ID field: no match creates a record, one match updates it, more than one match fails without changing anything. Marking the External ID field Unique stops the duplicates that cause that failure. An object can have up to 25 External ID fields, and fields marked Unique count toward that limit. ⟲

믿기 전에 두 가지를 확인하십시오

First: is the relationship really one-to-one? One Salesforce record for one external record, and back. If one ERP customer maps to three Salesforce accounts, or three ERP customers legitimately map to one account because Salesforce models the parent differently, the External ID can’t be a one-to-one key. Don’t force a complicated relationship into a field because External IDs are convenient; design a different identity. ⟲

Second: does the field hold one system’s key, with one meaning? If a field sometimes holds the ERP’s number and sometimes a partner’s, whose number is 847291? The field no longer says what its value means. One key field, one meaning. ⟲

When the Customer Is in Two ERPs

Then the company opens an office in Munich, and the European ERP creates its own customer record for Steve’s Plumbing: customer 88310. Same company, two ERP records, two keys. They can’t both live in one External ID field on one account. ⟲

The answer is the rule from chapter 6: add records, not fields. Give each ERP record its own Salesforce record, one-to-one: child accounts under a parent, peer accounts, or one account with a child object per ERP. Which one depends on how much of the ERP structure sales should see, and on how well the client keeps its own ERPs in sync. ⟲

클릭하여 확대

One of the three ways: a child object per ERP record. All three, and the costs of each, are in chapter 6: One Customer, Two ERPs. ⟲

What I don’t want is the fourth answer: one account with a key field for each ERP, NA_ERP_ID__c, EMEA_ERP_ID__c, and another every time the company buys a business. That’s an anti-pattern I don’t like. It hides repeating structure in fields, makes every new ERP a schema change, and spends the object’s allowance of External ID fields one acquisition at a time. Integrations make that mistake tempting, because each new arrow seems to need “its” field. It doesn’t. It needs its record. ⟲

Steve Trucking: One Field, the Source in the Value

Now our own landscape. Back in module 1 we zoomed in on Redrock’s manifests: about 1,100 deliveries a day, each one becoming a Work Order. At Checkpoint 1 we gave every Work Order one External ID field, unique, holding the partner’s own order and delivery reference with the partner named in the value. ⟲

클릭하여 확대

One key field on every Work Order. The value says whose delivery it is. ⟲

Is that the same rule? Yes. A Work Order comes from exactly one partner, so each record has exactly one key from one source. The field’s meaning never changes: the Retail Partner’s delivery reference. And because the value names the partner, REDROCK-8472914-1 can never collide with a Keystone delivery that happens to have the same number. ⟲

Now the late change from the brief: a fourth partner, Oakline, wants to go live at three distribution centers in 90 days. ⟲

클릭하여 확대

A new partner is new data, not a schema change. ⟲

With a key field per partner, Oakline would mean a new field, new matching logic and a deployment before the first manifest. With one field and the source in the value, it means a new prefix. The account and the Work Order end up following the same rule from different directions: one key per record. When one business thing has several external records, add records. When each record has one source, one field is enough, as long as the value says which source. ⟲

키가 재시도를 안전하게 만듭니다

Remember the end of module 1. Tonight’s Redrock manifest timed out on its way into Salesforce, and the integration layer didn’t know whether anything had saved (And When It Fails). So it sent the manifest again. A blind insert would have created a second Work Order for every delivery that had already saved. An upsert on the partner’s key matches the existing records and creates only what’s missing. That’s the beginning of idempotency: repeating an operation shouldn’t keep creating extra effects. Module 3 goes further. Safe retries begin with keys. ⟲

키는 권한이 아닙니다

The key tells Salesforce which customer. It doesn’t mean the ERP owns every field on the account. Identity and authority are different questions, which is why “the ERP syncs accounts to Salesforce” is a dangerous design. All fields? Some? Both directions? Which one wins? That isn’t a data architecture; it’s an argument waiting to happen. ⟲

When I teach this, I ask the room: what fields come over from SAP? Name, address, billing and shipping addresses, payment terms. Those are the ERP’s master data fields. Then: do we have the ability to add our own fields in Salesforce that we don’t send to SAP? Yes. A sales rating, the last order date, pretty much anything marketing related. So the account in Salesforce is a golden record that’s really a hybrid: the ERP is the system of record for some fields, Salesforce for others. ⟲

클릭하여 확대

One record, two owners. The integration writes the ERP’s fields; sales edits Salesforce’s. ⟲

That’s chapter 6’s rule, authority is assigned attribute by attribute (Truth Per Attribute), made executable. The rule isn’t “the ERP can update Account.” It’s “the ERP can update the fields the ERP owns.” A much stronger contract. ⟲

And protect it in the org, not just in a document. A common construct I’ve seen across implementations: separate the ERP’s accounts by record type, and let only the integration create them. Salespeople create and edit their own sales accounts; the ERP’s customer accounts come in through the integration, with the ERP’s fields read-only on the page layout (A Record Type for Each Flow). ⟲

Test knowledge. Write authority is enforced in the org, not only in the integration. Expect to separate integration-owned records by record type, make integration-owned fields read-only for users with page layouts and field-level security, and give the integration user only the access its contract needs. ⟲

Salesforce가 ERP 소유 필드를 바꾸고 싶을 때

A rep needs the payment terms changed. The ERP owns them. Bad answer one: let Salesforce change them locally until the ERP overwrites them. The user’s change appears to succeed, then mysteriously vanishes. Bad answer two: let both systems write them and the last write wins. That’s not mastering; that’s a race condition. ⟲

If the ERP owns the field, a change from Salesforce is a request to the authoritative system. Sometimes the ERP even owns creation: you can’t just create the account, you submit a request through an API, and the ERP creates it. ⟲

클릭하여 확대

A request, not an edit. The ERP accepts or rejects it, and its answer comes back through the integration. ⟲

The ERP accepts or rejects it, and the authoritative value comes back down the same arrow it always does (When Authority Is Shared). Integration is where that authority model becomes real. ⟲

Two-Way Movement, One Owner per Field

“We need a bidirectional integration.” Fine, but that doesn’t tell me enough. Data can move both ways while every field still has one owner. Look at Steve Trucking’s Redrock arrows: the manifest comes in, and Redrock owns what was ordered and where it goes; status goes back out, and Salesforce owns the appointment, the crew and the delivery status. Two-way movement, clear authority, very different from “both systems can update everything.” Bidirectional movement doesn’t require bidirectional authority. ⟲

And when both systems really can write the same field, you get the loop: Salesforce changes the phone number, sends it to the ERP, the ERP sees a change and sends it back, Salesforce sees a change… Good integration design tells a real business change from the echo of one it just sent, and there are several technical ways to do it. But the data architect should see the root cause: write authority and change provenance aren’t clear enough. The cleaner the authority model, the fewer loops you have to engineer around. ⟲

권한을 보이게 만들고, 왜 복사하는지 물으십시오

그래서 저는 외부 소유 데이터의 소유자를 보여 주는 이름을 좋아합니다. 때로는 Credit_Status__c보다 ERP_Credit_Status__c가 낫습니다. 필드 자체가 “이건 ERP에서 왔어요”라고 말하니까요. 통합된 필드마다 접두사가 필요한 것은 아니니 판단하십시오. 하지만 권한이 중요할 때, 미래의 개발자가 “그건 갱신하지 마, ERP가 소유해”를 알기 위해 90쪽짜리 아키텍처 문서가 필요해서는 안 됩니다. 모델이 그것을 말해야 합니다.

그리고 ERP가 신용 상태를 소유한다면, Salesforce에 사본이 필요하기는 할까요? 그럴 수도 있습니다. 사람들이 늘 필요로 하고, 자동화가 의존하고, 보고서가 쓰고, 필요한 최신성을 달성할 수 있다면요. 하지만 모든 사본은 동기화 책임입니다. Salesforce가 그 값을 가끔만 필요로 하고 늘 최신이어야 한다면 원본에서 가져오는 편이 나을 수 있습니다. 그것이 파트 3의 가상화입니다. 질문은 “그 필드를 통합할 수 있나?”가 아닙니다. **“왜 그것을 복사하나?”**입니다.

키에도 수명 주기가 있습니다

External identifiers aren’t always permanent. Systems merge customers, organizations consolidate, an acquired company brings its own ERP, legacy IDs are retired, records get new numbers in a conversion. For each important cross-system key: who assigns it, when, can it change, can it be reused, what happens in a merger or a migration, and do we keep the old ID for traceability? When a company buys a business that runs its own ERP, the answer is a new record per ERP record, not a new field. A key is part of the data lifecycle. ⟲

Salesforce org 사이에서도 마찬가지입니다. 인수 후 org A와 org B가 있습니다. org A의 레코드 ID는 org A 안에서 의미가 있습니다. 자동으로 기업 키가 되지는 않습니다. org B가 같은 비즈니스 엔티티를 맞춰야 한다면, 여전히 의도적인 시스템 간 정체성 전략이 필요합니다. 이 목적에서는 Salesforce org 둘이 시스템 둘입니다.

키가 복구를 가능하게 합니다

A nightly job sets out to send 20,000 customer updates and fails at 12,417. Tomorrow, what? Start over? Continue? Which already succeeded? With stable keys and safe upserts, you have options: retry, restart, reconcile, detect duplicates, compare source and target, prove completeness. Without them, recovery gets hard fast. Identity isn’t just a modeling concern. It’s operational reliability. ⟲

Beyond the exam: what AI changes. “Agent, update the customer.” Which customer, by what key, and update what: everything it can technically reach? An agent is another integration client. Its actions need explicit keys and narrow write contracts: resolve the right identity, respect the authoritative source, write only the fields that action may write, turn changes to another system’s fields into requests, keep provenance, and don’t turn retries into duplicates. Autonomy makes those controls more important, not less. ⟲

아키텍트가 여기서 결정하는 것

Which stable key identifies the same business record across each significant system boundary, and whether the relationship is truly one-to-one. ⟲
When one business thing has several external records, which records represent them: a hierarchy, peers or a child object, never a key field per system. ⟲
Which system owns each important attribute, and so which integration may write it, enforced with record types, page layouts and field-level security. ⟲
How a change to a field another system owns becomes a request to that system. ⟲
양방향 이동이 “마지막 쓰기가 이긴다”가 되지 않고 권한을 분명히 유지하는 방법.
외부 소유 데이터를 애초에 복사해야 하는지, 그리고 같은 규칙이 에이전트와 다른 Salesforce org에 어떻게 적용되는지.

Every integration write has to answer which record? and whose value? The key answers the first; the authority model the second. So don’t settle for “the ERP syncs accounts.” Tell me how the ERP identifies the account, which key we store and on which record, whether it’s really one-to-one, which fields each system owns, what happens when Salesforce wants to change an ERP value, and what happens on retry. Know the record. Know the owner. Then let the integration write. ⟲

더 알아보기

Salesforce Developers, REST API Developer Guide, Insert or Update (Upsert) a Record Using an External ID (새 탭에서 열림), checked 2026-11-01. ⟲
Salesforce Help, Custom Field Attributes (새 탭에서 열림) (External ID and Unique), checked 2026-11-01. ⟲
This course, chapter 6: When Authority Is Shared, for the several flows and the three ways to represent one customer in two ERPs. ⟲
Integration Architect 과정: 통합 패턴, 멀티 org (coming soon).