迁移首先是一个质量项目

🌐 另有 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)

图片由 AI 生成

由 AI 翻译，尚未经过社区审校。 阅读英文版 本节的英文原文已有改动，尚未重新翻译。 (81)

第 1 个模块，共 5 个，属于 Data Architect 课程第 10 章迁移与同步。每个模块都可以单独阅读。 上一篇：上一章集成与数据流动 · 下一篇：大数据量加载

**本模块回答的问题：**在开始把数据加载到 Salesforce 之前，应该对数据做些什么？

迁移项目会骗人。数据在这边，你需要它到那边，于是有人开始谈 Data Loader、Bulk API、CSV 文件、批次大小和加载顺序。这些都很重要。但不是我的起点。我的第一个问题是：**我们到底要移动什么？**如果源系统里有重复的客户、无效的地址、过时的值、断开的关系，以及十五年没人需要的数据，Salesforce 会很乐意成为它们全部的新家。加载得更快修复不了这些。迁移首先是一个质量项目。

Start With the Picture

Here’s Steve Trucking’s landscape from Checkpoint 1, the weekend RouteDesk retires. RouteDesk is the desktop dispatch tool the coordinators used inside each distribution center (DC) to turn manifests into routes. It holds eight years of delivery history, about 5 million deliveries, and the quality varies by DC. At Checkpoint 1 we decided it retires, and we left one question open: what, if anything, comes into the org? That’s a migration decision, and this is the chapter for it. ⟲

点击放大

One new arrow. It runs once, and then it disappears. ⟲

A migration is an arrow on the landscape like any other. Everything chapter 9 asked of an arrow applies: what moves, how much, by which key, who proves it arrived. The difference is that this arrow has an end. When it’s done, RouteDesk is switched off and the arrow comes off the drawing. That makes it easy to rush, because “we only do it once.” But the data it carries stays in Salesforce for years. ⟲

把坏数据移得更快不算成功

遗留系统有 500,000 条客户记录，我们迁移了 500,000 条客户记录。我们成功了吗？也许吧。如果其中 40,000 条是重复的，75,000 条十年没有活动，几千条的州代码无效，有些没有可用的标识符，有些子记录指向已经不存在的父记录，还有些字段的含义随记录创建的时间而不同呢？报告依然可以写着来源 500,000 条，目标 500,000 条，加载率 100%，而项目依然可能是失败的。完整性很重要，但光有完整性并不能证明质量。

所以在设计加载之前，我要先理解源数据。有哪些数据，它们意味着什么？有多旧，多可信，哪些字段真的在用，哪些值有效，存在哪些关系，哪些标识符可以信任？什么应该在迁移中保留下来，什么不应该？这就是前面几章派上用场的时候：第 4 章教了我们企业全景，第 5 章说质量必须被设计，第 6 章讲身份和权威。迁移把这一切应用到一批已有的数据上。它不只是移动行。它是在决定过去的哪些部分值得成为未来架构的一部分。

迁移、归档还是丢弃，并且知道为什么

一份迁移清单至少需要三种答案：**迁移、归档，或按策略丢弃。**五年前的交易明细可能出于合规需要保留，却不必放在活动数据模型里；过时的临时数据可能既没有保留要求，也没有价值；历史可能属于一个可搜索的归档。第 7 章的生命周期原则是“设计出口”，而迁移正是应用它的绝佳时机。不要因为记录存在就把每一条都带过来。

So zoom in on RouteDesk and take it apart, one class of data at a time. ⟲

点击放大

Every class of data gets a decision, a place and a reason. ⟲

The deliveries not yet made have to come in: manifests arrive one to two days ahead, so on cutover weekend RouteDesk holds about two days of work, roughly 6,400 deliveries, and the crews need them on Monday morning. The recent history comes in because of claims. A damage claim is a Case in Salesforce, and the agent working it needs the delivery behind it. So deliveries still inside the claim window come in too. Steve Trucking accepts claims for 60 days after a delivery, so that’s about 190,000 more Work Orders. Had the business said 30 days, it would be half that. The window is the business’s number, not ours. ⟲

The other 4.8 million deliveries go to Snowflake, where Checkpoint 1 already sends status history, kept by the partner key so a claim on an old delivery can still find it, and so leadership’s five-year reports still work. They don’t belong in the operational core: that would make Salesforce RouteDesk’s retirement home, and chapter 7 showed what Work Orders at volume cost. And the route plans and the coordinators’ drafts? Eight years of yesterday’s plans have no value once the deliveries are done. But I don’t decide that alone. ⟲

The opposite mistake is “we don’t need the old stuff.” Who decided? Legal, finance, operations, service, compliance? The data architect shouldn’t invent retention policy during a migration; we translate the business and regulatory requirement into architecture. Before excluding data, establish whether it must be kept, for how long, where, who needs access, and whether its relationships and source identifiers must survive. Eight years of Recipients’ names, addresses and phone numbers is exactly that kind of question: archiving them isn’t the same as keeping them forever. The goal isn’t to migrate less. It’s to know why every class of data is moving, or isn’t. ⟲

Test knowledge. Migrate what the new system needs to operate, not everything the old one held. Expect a scenario with years of legacy history: the answer is usually to migrate active and recent records and archive the rest outside Salesforce where it stays reachable, with the retention decision made by the business, not by the migration team. ⟲

Where the Preparation Happens

Before the steps, the place. All of this preparation happens outside Salesforce, in a working database of its own: Postgres, SQL Server, Oracle, MySQL, even SQLite for a small job, whatever the team knows. Not in Salesforce, and not in a spreadsheet that gets emailed around. I call it the preparation data store, or the preparation store for short. It sits in between: the source feeds it, and it feeds Salesforce. ⟲

点击放大

The preparation data store sits in between. Every step in this module happens inside it. ⟲

The extract lands there raw. The standardizing, cleaning, enriching, deduping and validating all run there, as code. The quarantine is a table, the counts are queries, and the whole thing can be run again from the top. Some tools connect a database like this straight to Salesforce, copying data down and sending changes back; others export files for a data loader. There are many ways to load data. The principle doesn’t change: prepare it outside, then load the result. ⟲

And it holds more than the source. Pull down the relevant parts of the target org too. Why? Because dedupe has to compare against what’s already in Salesforce, and when the survivor of a merge is a record that’s already there, the new children need its key to link to it. You can’t decide the merge without both sides in front of you. For RouteDesk, the preparation store holds the RouteDesk extract and a copy of what Salesforce already has: the Retail Partner Accounts, the Products and Service Territories, the claim Cases with their delivery references, and the Work Orders the new integration has already created, because the partners don’t stop sending manifests for our cutover weekend. ⟲

Then you practice. Run the preparation, load a sandbox, reconcile, find the rule that was wrong, fix it, run it all again. By the time we reach production, the preparation has run many times, and it’s boring. That’s the goal. ⟲

我的顺序：标准化、清理、补充、去重、验证

When I’m preparing data for migration, I work in this order, and the order matters. All five steps happen in the preparation data store. ⟲

Standardize. Get equivalent values into one form. One source has CA, California and Calif.; another has US, USA and United States. A company comes in as Steve Plumbing, Steve's Plumbing and Steve's Plumbing LLC. Phone numbers arrive as 5555550142, (555) 555-0142 and +1 555 555 0142. Before we compare records or apply matching rules, we need to know which differences are formatting and which are meaningful. ⟲

Names are the classic trap. I had a system with first and last name in one field, and the Salesforce contact needs them apart. “Daniel Reyes” splits easily. Then you get “Mr. Daniel Reyes,” “Daniel Reyes PhD,” “Daniel Reyes III,” and names with two family names, such as Roberto González Suárez, where González isn’t a middle name: split that wrong and you’re in trouble. Build the patterns (two words, three words, a title, a suffix), run the splits, and have the customer validate the results. ⟲

**清理。**处理错误的、不可用的或过时的东西：无效的代码、不可能的日期、拼写错误、占位值、存放着与其含义不符的数据的字段。有意识地映射选项列表的值：遗留的潜在客户状态 Cold，在目标中可能变成 Closed。当列表很长时（我见过 200 个值），就建一张转换表，让业务为每个源值填写目标值。Salesforce 对选项列表的验证很严格，所以要在它们到达之前抓住这些问题，而不是等验证规则来告诉你源数据里有什么。

RouteDesk’s “quality varies by DC” shows up right here. Each DC set up its own status codes over eight years, so the same outcome arrives in nine spellings. The transformation table maps every one of them to the Work Order’s status values in Salesforce: ⟲

DC	RouteDesk says	Work Order status
DC 1	DLV	Completed
DC 4	Delivered - OK	Completed
DC 7	DONE/INST	Completed (the install is on its line item)
DC 1	NH	Cannot Complete (nobody home)
DC 4	Refused	Cannot Complete
DC 7	CXL	Canceled

The left two columns come from profiling the extract; the right column comes from the business, not from us. Completed, Cannot Complete and Canceled are three of the standard Work Order status values (WorkOrder （在新标签页中打开）, Object Reference, Winter ‘27, checked 2026-10-27). Notice the third row: one RouteDesk code carried two facts, the delivery and the install, and the target model keeps them apart. ⟲

Enrich. Sometimes missing information can be reliably added: a normalized address, a postal code from city and state, a county, a geolocation, a mapping from a legacy code to the new enterprise taxonomy, an enterprise identifier. Enrichment needs provenance. If we add or change information, I want to know where it came from and why I trust it. Some of RouteDesk’s older deliveries don’t name the Retail Partner at all, because each DC served one partner and everybody knew. The DC and the order number’s format tell us which partner it was. That’s enrichment from a rule we can show, not a guess. ⟲

**去重。**然后找出代表同一个现实事物的记录。为什么不从这里开始？因为匹配脏数据更难：Steve's Plumbing 和 STEVES PLUMBING LLC 在标准化之后要容易比较得多。先在待导入的数据内部去重，再和 Salesforce 里已有的数据比较。第 6 章的规则依然适用：**合并是破坏性的；关联不是。**不要因为一个模糊匹配的分数看起来很有说服力，就把记录合并掉。

Validate. Finally, test the transformed data against the target: required information present, reference values valid, relationships resolvable, keys unique where they should be, values fitting the model, authority rules preserved. Only then do I want to talk seriously about loading. And don’t expect the import tool to catch everything. Salesforce’s own Trailhead project on the NPSP importer makes the point: it catches invalid picklist values and missing required fields, but if a spreadsheet turned a postal code like 02134 into the number 2134, the importer loads the four digits (Perform an Import Dry Run （在新标签页中打开）, Trailhead, checked 2026-10-27). That’s one more reason the preparation lives in a database with typed columns, not in a spreadsheet. ⟲

点击放大

Five steps, in order. A record that fails one goes somewhere visible, with its reason. ⟲

Test knowledge. Data quality is fixed before the load, not after. Know the preparation steps (standardize, clean, enrich, deduplicate, validate) and why the order matters: you can’t match records reliably until their values are in one form. Picklist values are mapped with a transformation table the business signs off, because Salesforce rejects values a restricted picklist doesn’t have. ⟲

在迁移之前清理

诱惑是“先把所有东西都放进 Salesforce，之后再清理”。我不喜欢把这当作默认做法。一旦坏数据进了生产环境，它就参与到生产中：用户看到它，自动化、报表、集成和智能体都看到它，重复记录开始聚集相关记录，清理就变得更难。在可行的地方，在数据进入目标之前就改进它。并不是每一个历史上的瑕疵都必须修复；那是一个成本收益的决定。但“我们以后再清理”不是迁移策略。它是带着上线日期的技术债。

And not every record deserves the same effort. An active customer with open orders, open cases, current contracts and billing relationships is different from one who bought something once nine years ago. Both may need to be kept. For the critical, active data I may require stricter validation, more enrichment, closer duplicate review and detailed reconciliation; for low-value history, preserving traceability may matter more than making every record perfect. Architecture is partly deciding where quality effort creates value. For RouteDesk, the 6,400 deliveries the crews will drive to on Monday get the strictest checks. The 4.8 million going to the archive need their keys and their dates right; nobody will fix eight years of typos in delivery notes. ⟲

保留源身份，并按键加载

最容易犯的错误之一，就是失去了把 Salesforce 记录追溯回来源的能力。如果遗留客户 CUST-847291 变成了客户 001…，我依然想知道它来自 CUST-847291，用于对账、排查问题、重新加载、审计、匹配子记录、回滚分析，以及上线后冒出来的各种问题。新的 Salesforce ID 在 Salesforce 内部很重要；它并不会抹去源身份。这就是第 9 章的外部 ID 原则。迁移和集成在身份上交汇。

At Steve Trucking they meet in one field. Every Work Order already carries the partner’s key, Partner_Delivery_Key__c, an External ID marked unique, holding values like REDROCK-8472914-1 (chapter 9, module 2). RouteDesk kept the partner’s order number on each delivery, so the migration builds the same key and upserts on it, exactly as the integration does. That matters on cutover weekend: if Redrock resends a manifest for Tuesday after we’ve loaded Tuesday from RouteDesk, the integration finds the migrated Work Order and updates it instead of creating a second one. RouteDesk’s own delivery number comes along too, in a plain field, so anyone can trace a Work Order back to the record it came from. ⟲

So don’t rebuild relationships by name (“find the Account whose Name is Acme Distribution”). If the legacy contact carries Legacy_Account_ID = CUST-847291 and the Salesforce Account carries that identifier as an External ID, the relationship is rebuilt deterministically. The Bulk API does this in the load file itself: a column header such as WorkOrder.Partner_Delivery_Key__c says “find my parent by this indexed field,” and Salesforce looks up the parent’s ID for you (Relationship Fields in a Header Row （在新标签页中打开）, Bulk API 2.0 and Bulk API Developer Guide, checked 2026-10-27). Keys turn “I think this child belongs here” into “I know which parent this came from,” and that matters more as the Number of Zeros grows. ⟲

Relationships also create sequence. If contacts reference accounts, the accounts must exist first; if line items reference orders and products, those come first. So migration isn’t one giant load. It’s reference data, parents, children, junctions, then dependent history, in an order the target data model dictates. That’s one more reason the data architect belongs in migration planning: the model tells us how the migration has to be assembled. Here’s RouteDesk’s open work, on Checkpoint 1’s model. ⟲

点击放大

Wave 1: what the Work Orders will point to has to exist first. Most of it already does. ⟲

点击放大

Wave 2: the Work Orders, upserted by the partner key. ⟲

点击放大

Wave 3: the children, each finding its Work Order by the same key. ⟲

点击放大

Wave 4: the claim Cases already in Salesforce get their link to the delivery. The model sets the order. ⟲

Test knowledge. Keep each legacy record’s key in an External ID field, load parents before children, and let each child find its parent by that key: an upsert on the External ID, and a relationship column in the load file (Parent.External_Id__c) instead of looking up Salesforce IDs. Reloads then update instead of duplicating, and every record traces back to its source. ⟲

被合并的记录需要一个子记录策略

这是人们低估的问题。分析发现遗留客户 A、B 和 C 是同一个客户，所以目标里只有一个客户。好。但是 A 有 12 个个案，B 有 4 个订单，C 有 3 个联系人。如果在概念上合并了父记录，却没有重新设计子记录的映射，你就解决了父记录，却弄断了关系。每一个去重决定都需要一个子记录策略。

RouteDesk has its own version. When a partner revised a manifest on the day, a coordinator sometimes keyed the delivery in again instead of editing it. Now RouteDesk has two deliveries with the same partner order number: one with the old window and two stops, one with the new window and the crew’s notes. Salesforce will have one Work Order, because the partner key is unique. Which window wins, and what happens to the stops and notes on the other one? ⟲

首先是字段：当两条记录匹配时，哪些值胜出？空白对一个值很简单。冲突就不简单了：Steven 还是 Stephen，Salesforce 里的电子邮件还是加载数据里的那个？选定一个存留记录，逐个字段做决定，然后尽早把样本案例摆到业务面前，让这些选择上留下他们的指纹。

Then the children. I see three options: add the children to the survivor, don’t load the merged record’s children, or load the merged record as inactive, linked to the survivor, with its children kept on it. ⟲

点击放大

Three ways, none free. Notice the third one at RouteDesk: the inactive duplicate can’t reuse the partner key, because the survivor already holds it, so it needs a key of its own. ⟲

Whichever you choose, it happens in the preparation store, before anything loads. That’s where the survivor is picked, sometimes a record that’s already in Salesforce, pulled down with its key. That’s where each child gets the key of the parent it will point to. And that’s where the merged record either keeps its children, hands them over or is left out. Salesforce receives the result of the merge, not the job of doing it. ⟲

我怎么选？取决于数据有多关键，以及我们是否需要追溯到加载了什么。还要把风险和合并本身的收益放在一起权衡。在零售客户名单里把两个不同的人的购买历史连在一起，只是一个小麻烦；在一位患者的记录上显示另一位患者的用药，则是严重的泄露。错误匹配的代价越高，合并就要越保守。无论你怎么决定，每个子记录还能追溯到它最初的来源吗？迁移去重不是“对客户运行重复匹配”。整个关系图都很重要。

我曾经站在另一边。一家我从大学时代就在那里买东西的零售商在迁移它的客户数据，我们一看，Steve Simpson 在大约六个电子邮件地址和街道地址下出现：我大学时的地址、我租过的房子、之后的几个地方。我们应该合并它们吗？外面还有别的 Steve Simpson。业务决定，把我的旧历史连在一起，不值得冒把我和错误的 Steve Simpson 合并的风险。这就是每一次合并都必须回答的问题：把数据合在一起的收益是什么，选错人的风险又是什么？

Test knowledge. Deduplicate before the load, within the incoming data and against what’s already in Salesforce, with matching rules and a survivor chosen field by field. Expect the follow-up question: what happens to the merged record’s child records? Re-parent them to the survivor, leave them out (and archive them), or keep them on an inactive linked record. Each has a cost. ⟲

可重复的转换，保留原始来源

遗留状态 A 变成 Active，I 变成 Inactive，S 变成 Suspended。这个映射存放在哪里？不在某个人的记忆里，不在一个被以不同方式复制到三个文件里的 Excel 公式里，也不是周五晚上的一个手动步骤。如果明天重新加载，我们应该得到相同的结果，所以映射、标准化和清理规则、转换、去重决定和键的生成，都必须是可重现的。迁移过程就是代码，即使其中有些部分并不是真的用编程语言写的。

And don’t destroy the starting point. Keep the original extract in raw tables, exactly as it came out, and never change them. Each step writes its result to a new staged table: standardized, cleaned, deduplicated, load-ready. When something looks wrong, I want to know whether it was wrong in the source, changed by our transformation, changed by the load, or changed by Salesforce automation afterward, and with every table kept I can walk back through them and find out. Overwrite your only copy of the source while cleaning it and you lose the evidence. ⟲

I learned how much this pays off on a support migration. A company was moving its support desk from Zendesk into Salesforce, and Zendesk’s tickets were very similar to Salesforce Cases, but not exact. So I loaded every Zendesk export into a SQL database as raw tables, one per Zendesk structure: organizations, users, tickets, custom fields, comments, attachments. Then I built interim tables that got closer and closer to the Salesforce structure, with the field and picklist mappings kept as tables of their own. Then I loaded Salesforce from those tables and brought the Salesforce IDs back. In the end every row had three things: its original Zendesk key, the transformations that had been applied to it, which were never one way, and its Salesforce key. That’s what let me do partial loads and reloads whenever I needed to. ⟲

Here’s the same design for RouteDesk, one step at a time. ⟲

点击放大

Extract: one raw table per RouteDesk structure, each row with its RouteDesk key. These tables never change. ⟲

点击放大

Generate: new tables shaped for Salesforce, built from the raw ones with the mapping tables. The raw tables are still there. ⟲

点击放大

Load: the Work Orders upserted by the partner key, then their children. ⟲

点击放大

Keys back: each Salesforce ID is written to its row. Now every row knows where it came from, what was done to it and where it landed. ⟲

So no transformation is allowed to lose fidelity. If a step throws information away (truncates a note, drops a code it didn’t recognize, keeps one of two conflicting values without saying which), I can’t trace back through it, and I can’t repeat the run and get the same answer. Keep the raw tables, keep the staged tables, keep what each load sent and what came back. Then you can rerun the whole thing from the raw extract at any time, and you have the history of every load. This is migration’s version of lineage: preserve where the data came from and what you did to it. ⟲

Sometimes the Staging Is Inside Salesforce

The preparation store isn’t the only place to stage. In a few special cases, the last stop before the real objects is a plain custom object inside Salesforce: one flat row per source record, no automation, loaded fast. Then a batch process works through the rows and builds the real records. I’ve used it when Salesforce’s own logic had to create the records and was too slow to load through: a scheduling process that took a few seconds per appointment. Module 3 comes back to that case. ⟲

Salesforce uses the same pattern in its own products, and it’s worth learning from. The Nonprofit Success Pack loads a spreadsheet into its NPSP Data Import object first. A dry run checks for matches without creating anything. Then the importer creates the accounts, contacts and donations, and writes each new record’s ID back onto the row it came from (How the Import Process Works （在新标签页中打开）, Salesforce Help, checked 2026-10-27). That’s a reference, not a rule: staging inside Salesforce is the special case, not the way to load everything. ⟲

For RouteDesk, a one-time move with heavy cleaning and merging, the preparation store outside Salesforce does the work, and the load sends the result. ⟲

坏记录需要有个去处

在 500,000 条记录中，497,800 条通过了验证，2,200 条没有。悄悄地丢掉它们？不行。把垃圾硬塞进必填字段？不行。在每条历史记录都完美之前让项目停下来？大概也不行。我要一条隔离和修复的路径，记录下哪条源记录失败了、为什么、哪条规则拒绝了它、是否必须在切换之前修复、谁负责决定、能否推迟。这样，异常就成了可见的架构工作，而不是隐藏的数据丢失。

Before you call a record bad, look at the rule that rejected it. Sometimes the record is fine and the rule is wrong. Salesforce’s Well-Architected framework puts it plainly: “data architecture decisions determine the populations that become visible—and invisible,” and a required email address “excludes populations that don’t have reliable internet access or personal email addresses” (Fairness （在新标签页中打开）, checked 2026-10-27). RouteDesk has thousands of deliveries where the Recipient gave only a phone number. If the new Work Order requires an email, those aren’t bad records. They’re real people the rule would make invisible. Fix the rule, not the person. ⟲

然后在加载之前证明转换。我们从多少条源记录开始，有意排除了多少条，合并了多少条重复，多少条已经就绪，多少条被隔离，多少个父子关系能够解析，控制合计是多少？如果数字在加载之前对不上账，加载得更快也无济于事。模块 4 会用数量、合计、抽查和汇总报表来证明迁移，但证明从这里开始。

AI 可以帮忙清理。它无权编造真相。

AI 在迁移中很有用：建议映射、找出可疑的值、把潜在的重复分组、发现异常、生成转换代码、解释被拒记录中的模式。但如果一个补充流程判定“这家公司可能在亚利桑那”，“可能”是不够的。如果它判定两个客户看起来足够相似、可以合并，请记住第 6 章：一次错误的匹配，可能比漏掉一次匹配造成更大的损害。用 AI 来加快调查。不要让它悄悄地制造权威的企业数据。

**考试之外：AI 改变了什么。**在迁移过程中，AI 可以大大加快数据剖析、映射、异常检测和候选匹配。对于创建、合并或修改权威业务数据的决定，要保留确定性的规则、来源记录和人工审查。

架构师在这里决定什么

• 根据业务价值和保留要求，哪些源数据被迁移、归档或排除。
• Where preparation happens (a preparation store outside Salesforce, a staging object inside it, or both), and which parts of the target org are pulled down to merge against. ⟲
• 数据在进入目标之前如何被标准化、清理、补充、去重和验证。
• 哪些源标识符和血缘被保留下来，让每一条重要的目标记录都可以被追溯和对账。
• The load order the target data model dictates, and the keys each child uses to find its parent. ⟲
• 去重决定如何在整个关系图中处理字段和子记录，并根据关键程度、可追溯性和错误合并的风险来权衡。
• 在任何生产加载开始之前，哪些转换和异常处理规则必须是可重复的。

不要用加载的行数来衡量迁移

“我们加载了 500,000 条中的 500,000 条记录”告诉我的是加载工具运作正常。我想知道的是：我们移动的是正确的数据吗，改进了需要改进的东西吗，保住了身份和关系吗，安全地合并了重复吗？我们能解释排除了什么、重现转换、把一条 Salesforce 记录追溯到它的来源、证明结果吗？先做这些工作。然后我们再操心能加载得多快。

延伸探索

• Salesforce, General Guidelines for Data Loads （在新标签页中打开） and Relationship Fields in a Header Row （在新标签页中打开）, Bulk API 2.0 and Bulk API Developer Guide, checked 2026-11-01. ⟲
• Salesforce, WorkOrder （在新标签页中打开）, Object Reference for the Salesforce Platform, Winter ‘27 (API version 68.0), checked 2026-11-01. ⟲
• Salesforce Help, How the Import Process Works （在新标签页中打开） (the Nonprofit Success Pack’s staging object), checked 2026-11-01. ⟲
• Hands-on: the Trailhead trail Import Data With Nonprofit Success Pack (NPSP) （在新标签页中打开） walks through the whole staging pattern in a practice org: a template, staging rows, a dry run, fixing the failed rows, then the import. It runs in a Trailhead Playground; Trailhead notes that as of December 2025, NPSP is no longer offered as a preconfigured package in production orgs. Checked 2026-10-27. ⟲
• Salesforce Architects, Well-Architected, Fairness （在新标签页中打开）, checked 2026-11-01. ⟲
• In this course: Master Data and Identity (matching, survivorship, link vs merge), Data Quality and Governance, and Keys and Write Ownership (the partner key). ⟲
• Trailhead, Perform an Import Dry Run （在新标签页中打开）, checked 2026-11-01. ⟲