Chuyển đổi dữ liệu trước hết là một dự án chất lượng

🌐 Cũng có bằng 19 ngôn ngữ khác

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

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh Phần này đã thay đổi trong bản tiếng Anh và chưa được dịch lại. (81)

Mô-đun 1 trong 5 của chương Chuyển đổi và đồng bộ dữ liệu, chương 10 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: chương trước, Tích hợp và di chuyển dữ liệu · Tiếp theo: Tải dữ liệu ở khối lượng lớn

Câu hỏi mô-đun này trả lời: Điều gì nên xảy ra với dữ liệu trước khi bạn bắt đầu tải nó vào Salesforce?

Một dự án chuyển đổi dữ liệu có thể đánh lừa bạn. Bạn có dữ liệu ở đây, bạn cần nó ở đằng kia, nên ai đó bắt đầu nói về Data Loader, Bulk API, tệp CSV, kích thước lô và thứ tự tải. Những thứ đó quan trọng. Chúng không phải là nơi tôi bắt đầu. Câu hỏi đầu tiên của tôi là: chính xác thì chúng ta sắp di chuyển cái gì? Nếu nguồn chứa khách hàng trùng lặp, địa chỉ không hợp lệ, giá trị lỗi thời, quan hệ bị đứt và mười lăm năm dữ liệu không ai cần, Salesforce sẽ vui vẻ trở thành ngôi nhà mới cho tất cả. Tải nhanh hơn không sửa được điều đó. Chuyển đổi dữ liệu trước hết là một dự án chất lượng.

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. ⟲

Nhấp để phóng to

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. ⟲

Di chuyển dữ liệu xấu nhanh hơn không phải là thành công

Hệ thống cũ có 500.000 bản ghi khách hàng, và chúng ta chuyển 500.000 bản ghi khách hàng. Chúng ta đã thành công chưa? Có thể. Nếu 40.000 là bản trùng, 75.000 đã không hoạt động mười năm, hàng nghìn bản ghi có mã bang không hợp lệ, một số không có mã định danh dùng được, một số bản ghi con trỏ đến bản ghi cha không còn tồn tại, và một số trường có nghĩa khác nhau tùy vào thời điểm bản ghi được tạo thì sao? Báo cáo vẫn có thể ghi 500.000 nguồn, 500.000 đích, tải được 100 phần trăm, và dự án vẫn có thể là một thất bại. Tính đầy đủ quan trọng, nhưng tự nó không chứng minh được chất lượng.

Vì vậy trước khi thiết kế việc tải, tôi muốn hiểu nguồn. Dữ liệu nào tồn tại, và nó có nghĩa là gì? Nó cũ đến đâu, đáng tin đến đâu, những trường nào thực sự được dùng, những giá trị nào hợp lệ, những quan hệ nào tồn tại, những mã định danh nào tôi có thể tin? Cái gì nên sống sót qua đợt chuyển đổi, và cái gì không? Đây là lúc các chương trước được đem ra dùng: chương 4 dạy chúng ta về bản đồ hệ thống doanh nghiệp, chương 5 dạy rằng chất lượng phải được thiết kế, chương 6 dạy về danh tính và thẩm quyền. Chuyển đổi dữ liệu áp dụng tất cả những điều đó vào một khối dữ liệu đã có. Nó không chỉ là di chuyển các dòng. Nó là quyết định những phần nào của quá khứ xứng đáng trở thành một phần của kiến trúc tương lai.

Chuyển, lưu trữ hay loại bỏ, và biết vì sao

Một bảng kê chuyển đổi cần ít nhất ba câu trả lời: chuyển, lưu trữ, hay loại bỏ theo chính sách. Chi tiết giao dịch năm năm tuổi có thể cần được giữ để tuân thủ mà không phải nằm trong mô hình dữ liệu đang hoạt động; dữ liệu tạm thời lỗi thời có thể vừa không có yêu cầu lưu giữ vừa không có giá trị; lịch sử có thể thuộc về một kho lưu trữ tìm kiếm được. Nguyên tắc vòng đời của chương 7 là “thiết kế lối ra”, và chuyển đổi dữ liệu là thời điểm hoàn hảo để áp dụng nó. Đừng mang mọi bản ghi theo chỉ vì nó có ở đó.

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

Nhấp để phóng to

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. ⟲

Nhấp để phóng to

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. ⟲

Thứ tự của tôi: chuẩn hóa, làm sạch, làm giàu, khử trùng lặp, xác thực

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. ⟲

Làm sạch. Xử lý những gì sai, không dùng được hoặc lỗi thời: mã không hợp lệ, ngày không thể có, lỗi chính tả, giá trị giữ chỗ, trường chứa dữ liệu không khớp với ý nghĩa của nó. Ánh xạ giá trị danh sách chọn một cách có chủ đích: một trạng thái khách hàng tiềm năng cũ là Cold có thể trở thành Closed ở đích. Khi danh sách dài (tôi đã thấy 200 giá trị), hãy xây một bảng chuyển đổi và để doanh nghiệp điền giá trị đích cho từng giá trị nguồn. Salesforce xác thực danh sách chọn một cách nghiêm ngặt, nên hãy bắt các giá trị này trước khi chúng đến, và đừng chờ quy tắc xác thực cho bạn biết nguồn của bạn chứa gì.

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 (mở trong thẻ mới), 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. ⟲

Khử trùng lặp. Rồi tìm những bản ghi đại diện cho cùng một thứ ngoài đời thực. Vì sao không bắt đầu từ đây? Vì khớp dữ liệu bẩn khó hơn: Steve's Plumbing và STEVES PLUMBING LLC dễ so sánh hơn nhiều sau khi chuẩn hóa. Hãy khử trùng lặp trong chính dữ liệu đến, rồi so với những gì đã có trong Salesforce. Quy tắc của chương 6 vẫn áp dụng: gộp là phá hủy; liên kết thì không. Đừng gộp các bản ghi chỉ vì một điểm số khớp mờ trông có vẻ thuyết phục.

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 (mở trong thẻ mới), Trailhead, checked 2026-10-27). That’s one more reason the preparation lives in a database with typed columns, not in a spreadsheet. ⟲

Nhấp để phóng to

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. ⟲

Làm sạch trước khi di chuyển

Cám dỗ là “hãy đưa mọi thứ vào Salesforce trước rồi dọn dẹp sau”. Tôi không thích điều đó làm mặc định. Một khi dữ liệu xấu đã ở trên production, nó tham gia vào production: người dùng thấy nó, tự động hóa, báo cáo, tích hợp và tác tử thấy nó, các bản trùng bắt đầu gom bản ghi liên quan, và việc dọn dẹp khó hơn. Ở nơi khả thi, hãy cải thiện dữ liệu trước khi nó vào đích. Không phải mọi khiếm khuyết lịch sử đều phải sửa; đó là một quyết định chi phí-lợi ích. Nhưng “chúng ta sẽ dọn sau” không phải là một chiến lược chuyển đổi. Đó là nợ kỹ thuật có ngày ra mắt.

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. ⟲

Giữ danh tính nguồn, và tải theo khóa

Một trong những sai lầm dễ mắc nhất là đánh mất khả năng truy vết một bản ghi Salesforce về nơi nó đến. Nếu khách hàng cũ CUST-847291 trở thành Account 001…, tôi vẫn muốn biết nó đến từ CUST-847291, để đối chiếu, xử lý sự cố, tải lại, kiểm toán, khớp bản ghi con, phân tích hoàn tác và trả lời những câu hỏi đến sau khi ra mắt. ID Salesforce mới quan trọng bên trong Salesforce; nó không xóa danh tính nguồn. Đây là nguyên tắc External ID của chương 9. Chuyển đổi dữ liệu và tích hợp gặp nhau ở danh tính.

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 (mở trong thẻ mới), 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. ⟲

Nhấp để phóng to

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

Nhấp để phóng to

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

Nhấp để phóng to

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

Nhấp để phóng to

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. ⟲

Bản ghi bị gộp cần một chiến lược cho bản ghi con

Đây là vấn đề người ta hay đánh giá thấp. Phân tích phát hiện các khách hàng cũ A, B và C là cùng một khách hàng, nên đích có một Account. Được. Nhưng A có 12 trường hợp, B có 4 đơn hàng và C có 3 liên hệ. Gộp các bản ghi cha về mặt khái niệm mà không thiết kế lại ánh xạ của bản ghi con, và bạn đã giải quyết bản ghi cha nhưng làm đứt các quan hệ. Mỗi quyết định khử trùng lặp đều cần một chiến lược cho bản ghi con.

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? ⟲

Trước hết là các trường: khi hai bản ghi khớp nhau, giá trị nào thắng? Một giá trị trống đối đầu với một giá trị thì dễ. Một xung đột thì không: Steven hay Stephen, email trong Salesforce hay email trong lần tải? Hãy chọn một bản ghi giữ lại và quyết định theo từng trường, rồi đưa các trường hợp mẫu cho doanh nghiệp xem sớm để dấu vân tay của họ có trên các lựa chọn.

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. ⟲

Nhấp để phóng to

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. ⟲

Tôi chọn thế nào? Điều đó tùy thuộc vào mức độ quan trọng của dữ liệu và việc chúng ta có cần truy vết ngược về những gì đã tải hay không. Và hãy cân nhắc rủi ro so với lợi ích của việc gộp ngay từ đầu. Nối lịch sử mua hàng của nhầm hai người trong danh sách khách hàng bán lẻ là một điều phiền toái; hiển thị thuốc của bệnh nhân này trên hồ sơ của bệnh nhân khác là một vi phạm nghiêm trọng. Hậu quả của một lần khớp sai càng lớn, việc gộp càng phải thận trọng. Dù bạn quyết định thế nào, mỗi bản ghi con có còn truy vết được về nguồn gốc ban đầu của nó không? Khử trùng lặp trong chuyển đổi không phải là “chạy so khớp trùng lặp trên Accounts”. Toàn bộ đồ thị quan hệ đều quan trọng.

Tôi đã từng ở phía bên kia của chuyện này. Một nhà bán lẻ mà tôi đã mua hàng từ thời đại học đang chuyển đổi dữ liệu khách hàng, và khi chúng tôi xem xét, Steve Simpson xuất hiện dưới khoảng nửa tá địa chỉ email và địa chỉ nhà: địa chỉ thời đại học của tôi, căn nhà tôi thuê, những nơi sau đó. Có nên gộp chúng không? Ngoài kia còn có những Steve Simpson khác. Doanh nghiệp quyết định rằng việc nối lịch sử cũ của tôi lại với nhau không đáng với rủi ro gộp tôi với nhầm một Steve Simpson khác. Đó là câu hỏi mà mọi lần gộp phải trả lời: lợi ích của việc đưa dữ liệu lại với nhau là gì, và rủi ro của việc chọn nhầm người là gì?

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. ⟲

Phép chuyển đổi lặp lại được, nguồn thô được giữ lại

Trạng thái cũ A trở thành Active, I trở thành Inactive, S trở thành Suspended. Ánh xạ đó nằm ở đâu? Không phải trong trí nhớ của ai đó, không phải trong một công thức Excel bị chép khác nhau vào ba tệp, không phải một bước thủ công vào tối thứ Sáu. Nếu ngày mai chúng ta tải lại, chúng ta nên có cùng kết quả, nên ánh xạ, quy tắc chuẩn hóa và làm sạch, phép chuyển đổi, quyết định khử trùng lặp và việc tạo khóa đều phải tái lập được. Quy trình chuyển đổi là code, ngay cả khi một số phần không thực sự được viết bằng ngôn ngữ lập trình.

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. ⟲

Nhấp để phóng to

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

Nhấp để phóng to

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

Nhấp để phóng to

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

Nhấp để phóng to

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 (mở trong thẻ mới), 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. ⟲

Bản ghi xấu cần có nơi để đi

Trong 500.000 bản ghi, 497.800 qua được xác thực và 2.200 thì không. Lặng lẽ bỏ chúng đi? Không. Ép dữ liệu rác vào các trường bắt buộc? Không. Dừng dự án cho đến khi mọi bản ghi lịch sử đều hoàn hảo? Có lẽ là không. Tôi muốn một con đường cách ly và khắc phục, ghi lại bản ghi nguồn nào thất bại, vì sao, quy tắc nào từ chối nó, nó có phải được sửa trước khi chuyển giao không, ai chịu trách nhiệm quyết định và nó có thể hoãn lại không. Giờ các ngoại lệ là công việc kiến trúc hiện rõ thay vì dữ liệu bị mất một cách âm thầm.

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 (mở trong thẻ mới), 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. ⟲

Rồi hãy chứng minh phép chuyển đổi trước khi tải. Chúng ta bắt đầu với bao nhiêu bản ghi nguồn, đã cố ý loại trừ bao nhiêu, bao nhiêu bản trùng được hợp nhất, bao nhiêu đã sẵn sàng, bao nhiêu bị cách ly, bao nhiêu quan hệ cha-con phân giải được, và các tổng kiểm soát là bao nhiêu? Nếu các con số không đối chiếu được trước khi tải, tải nhanh hơn cũng chẳng giúp gì. Mô-đun 4 chứng minh đợt chuyển đổi bằng số lượng, tổng, kiểm tra ngẫu nhiên và báo cáo tổng hợp, nhưng việc chứng minh bắt đầu từ đây.

AI có thể giúp làm sạch. Nó không được bịa ra sự thật.

AI hữu ích trong chuyển đổi dữ liệu: gợi ý ánh xạ, tìm giá trị đáng ngờ, nhóm các bản trùng tiềm năng, phát hiện bất thường, tạo code chuyển đổi, giải thích các khuôn mẫu trong bản ghi bị từ chối. Nhưng nếu một quy trình làm giàu dữ liệu quyết định “công ty này có lẽ ở Arizona”, thì “có lẽ” là không đủ. Và nếu nó quyết định hai khách hàng trông đủ giống nhau để gộp, hãy nhớ chương 6: một lần khớp sai có thể gây hại nhiều hơn một lần khớp thiếu. Hãy dùng AI để tăng tốc việc điều tra. Đừng để nó âm thầm sản xuất dữ liệu doanh nghiệp có thẩm quyền.

Ngoài kỳ thi: AI thay đổi điều gì. AI có thể tăng tốc đáng kể việc lập hồ sơ dữ liệu, ánh xạ, phát hiện bất thường và khớp ứng viên trong một đợt chuyển đổi. Hãy giữ quy tắc tất định, nguồn gốc và sự rà soát của con người quanh những quyết định tạo, gộp hoặc thay đổi dữ liệu nghiệp vụ có thẩm quyền.

Kiến trúc sư quyết định gì ở đây

• Dữ liệu nguồn nào được chuyển, lưu trữ hay loại trừ, theo giá trị nghiệp vụ và yêu cầu lưu giữ.
• 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. ⟲
• Dữ liệu được chuẩn hóa, làm sạch, làm giàu, khử trùng lặp và xác thực thế nào trước khi vào đích.
• Những mã định danh nguồn và dòng dõi dữ liệu nào được giữ lại, để mọi bản ghi đích quan trọng đều truy vết và đối chiếu được.
• The load order the target data model dictates, and the keys each child uses to find its parent. ⟲
• Các quyết định khử trùng lặp xử lý trường và bản ghi con thế nào trên toàn bộ đồ thị quan hệ, cân nhắc mức độ quan trọng, khả năng truy vết và rủi ro của một lần gộp sai.
• Những quy tắc chuyển đổi và xử lý ngoại lệ nào phải lặp lại được trước khi bất kỳ lần tải production nào bắt đầu.

Đừng đo chuyển đổi dữ liệu bằng số dòng đã tải

“Chúng tôi đã tải 500.000 trên 500.000 bản ghi” cho tôi biết công cụ tải đã chạy. Tôi muốn biết: chúng ta có di chuyển đúng dữ liệu không, có cải thiện những gì cần cải thiện không, có giữ được danh tính và quan hệ không, có hợp nhất bản trùng một cách an toàn không? Chúng ta có giải thích được những gì đã loại trừ, tái lập được phép chuyển đổi, truy vết được một bản ghi Salesforce về nguồn, và chứng minh được kết quả không? Hãy làm phần việc đó trước. Rồi chúng ta mới lo chuyện tải nhanh đến đâu.

Tìm hiểu thêm

• Salesforce, General Guidelines for Data Loads (mở trong thẻ mới) and Relationship Fields in a Header Row (mở trong thẻ mới), Bulk API 2.0 and Bulk API Developer Guide, checked 2026-11-01. ⟲
• Salesforce, WorkOrder (mở trong thẻ mới), Object Reference for the Salesforce Platform, Winter ‘27 (API version 68.0), checked 2026-11-01. ⟲
• Salesforce Help, How the Import Process Works (mở trong thẻ mới) (the Nonprofit Success Pack’s staging object), checked 2026-11-01. ⟲
• Hands-on: the Trailhead trail Import Data With Nonprofit Success Pack (NPSP) (mở trong thẻ mới) 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 (mở trong thẻ mới), 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 (mở trong thẻ mới), checked 2026-11-01. ⟲