Tự động hóa trong lúc tải

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)

In a plant room, the valves beside a pump stand closed and its cover is off, while a bypass pipe with an open valve carries the flow around it. — Hình ảnh được tạo bằng AI

Mô-đun 3 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: Tải dữ liệu ở khối lượng lớn · Tiếp theo: Cuối tuần chuyển giao

Câu hỏi mô-đun này trả lời: Điều gì nên xảy ra với tự động hóa của Salesforce trong lúc dữ liệu chuyển đổi đang được tải?

RouteDesk’s records are ready: about 707,000 of them, prepared, sorted by parent, rehearsed. You start the load, and Salesforce starts doing exactly what you configured it to do. Flows fire, triggers run, validation rules evaluate, emails send, tasks get created, rollups calculate, integrations launch, events publish. Your 707,000-record migration isn’t performing 707,000 operations anymore. It’s performing 707,000 records multiplied by everything each record causes. That’s a different migration. ⟲

Start With the Picture

Here’s the landscape again, the weekend RouteDesk retires. The migration arrow is amber. Now look at what else leaves Salesforce when a Work Order is created or changes status. ⟲

Nhấp để phóng to

One arrow in. Three more arrows out, for every record, unless we decide otherwise. ⟲

Every one of those arrows was designed in chapter 9 for a delivery that just happened: a status changed, so tell the partner and Snowflake; a delivery finished, so count it for invoicing; a delivery is tomorrow, so text the Recipient. The load creates 196,400 Work Orders in one weekend, and about 190,000 of them arrive already completed. To the automation, each one looks like a delivery that just happened. ⟲

Tự động hóa không biết đó là một đợt chuyển đổi

Salesforce sees a record transaction. It doesn’t know “this is historical data loaded during a controlled cutover.” A flow sees a new Account and does what it was built to do: creates an onboarding task, sends a welcome email, publishes an event, updates a related record, calls another system. Correct when a sales rep creates one account on Tuesday afternoon. Completely wrong when a migration creates 800,000 historical accounts on Saturday night. Same operation, different business context. At Steve Trucking, a Work Order arriving with a status of Completed looks exactly like a crew finishing a delivery five minutes ago. ⟲

Vì vậy với một đợt chuyển đổi lớn, tôi bắt đầu từ điều này: tự động hóa nghiệp vụ thông thường không nên chạy mù quáng trên dữ liệu được tải. Điều đó không có nghĩa là “tắt hết mọi thứ”. Nó có nghĩa là mỗi tự động hóa quan trọng đều nhận được một quyết định có chủ đích, và tôi không muốn câu trả lời được phát hiện ra vì production đã gửi 400.000 email.

Ba lựa chọn: Không cần nó, mô phỏng nó, hoãn nó

For each automation, I ask what it does and what happens if it doesn’t run, and then I put it in one of three categories. ⟲

Không cần nó (loại bỏ). Hành vi đó không nên xảy ra với bản ghi được chuyển đổi. Những khách hàng chúng ta đã có tám năm không cần “Chào mừng đến với công ty chúng tôi!” Chèn một tài khoản, nó gửi một email; tải một triệu tài khoản, và tôi không cần một triệu email.

Mô phỏng nó. Tự động hóa không nên chạy, nhưng kết quả nó tạo ra vẫn cần có. Một flow khi tạo tài khoản tính ra Customer Segment. Các tài khoản được chuyển đổi cần một phân khúc hợp lệ, nhưng chạy cả flow năm triệu lần thì tốn kém hoặc có tác dụng phụ. Vì vậy chúng ta tính phân khúc trong phép chuyển đổi và tải kết quả. Chúng ta không phớt lờ quy tắc nghiệp vụ; chúng ta đã làm phần việc của tự động hóa ngay trong lần tải.

Hoãn nó. Kết quả là cần thiết, nhưng không phải bên trong giao dịch tải. Hãy tải với tự động hóa đã tắt và một cờ được đặt, rồi kích hoạt một tiến trình theo lô để bắt kịp: tính lại, tạo các bản ghi phụ thuộc, phát những gì các hệ thống phía sau cần. Hoãn lại có thể làm cho việc tải nhanh hơn và dễ kiểm soát hơn mà không phải từ bỏ kết quả.

Và đôi khi bạn cứ để nó bật. Với một lần tải nhỏ hơn mà doanh nghiệp muốn quy trình thông thường của mình chạy, hãy để hệ thống làm việc của nó. Đó cũng là một lựa chọn, miễn là nó được chọn có chủ đích.

Dù bạn chọn gì, đây là quy tắc tôi dạy: bất cứ khi nào bạn tắt một tự động hóa, bạn đang nhận toàn bộ trách nhiệm về việc logic nghiệp vụ đó không xảy ra. Bạn cần hiểu mọi tự động hóa trước khi quyết định.

Nhấp để phóng to

Three questions, four answers, one decision per automation. ⟲

Test knowledge. For each automation on a large load, decide: not needed for migrated data (bypass it), needed but its result can be set in the data (simulate it in the transformation), needed but not inside the load (defer it to a batch afterward), or needed inside the load (let it run). Expect a scenario where blindly running automation creates unwanted emails, tasks or integration calls, and one where turning it off silently loses a required result. ⟲

“Tắt tự động hóa” không phải là toàn bộ chiến lược

Kế hoạch ghi “tắt tự động hóa”. Tự động hóa nào? Bằng cách nào, ai làm, khi nào? Làm sao chúng ta biết nó đã tắt, và làm sao biết nó đã bật lại? Những kết quả nào nó thường tạo ra vẫn phải tồn tại sau đó? Chuyện gì xảy ra nếu người dùng đang ở trong hệ thống khi nó tắt, hoặc đợt chuyển đổi thất bại giữa chừng? Tắt một thứ là một hành động vận hành. Kiến trúc cần toàn bộ vòng đời: trạng thái bình thường, trạng thái chuyển đổi, trở lại bình thường, và bằng chứng rằng chúng ta đã trở lại.

And before you decide what to switch off, find out what’s still switched on. Old automation runs on migrated records too. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025, but “your active Workflow Rules and Process Builder processes continue to run as they did before” (Workflow Rules & Process Builder End of Support (mở trong thẻ mới), Salesforce Help, checked 2026-10-27). Well-Architected points out the cost: an org “carrying dozens of Process Builders left over from prior implementations … pays to evaluate every one of them on every relevant record save,” and its advice is to “migrate remaining Process Builders to Flow; don’t just deactivate them” (Resource and Cost Optimization (mở trong thẻ mới), checked 2026-10-27). A migration is a good reason to clear them out first, so 707,000 records aren’t run through automation nobody remembers. ⟲

Build the Bypass In From the Start

Lập trường mạnh hơn của tôi: tự động hóa quan trọng nên có một cơ chế bỏ qua có kiểm soát ngay cả khi không có đợt chuyển đổi nào được lên kế hoạch. Chuyển đổi không phải là lý do duy nhất bạn sẽ cần đến nó. Khắc phục quy mô lớn, sửa dữ liệu, điền bù dữ liệu, sửa chữa tích hợp, khôi phục khẩn cấp: đôi khi bạn phải chạy một thao tác có kiểm soát mà không có mọi phần của tự động hóa thông thường. Nếu cách duy nhất là sửa flow trên production, vô hiệu hóa trigger hay xóa một quy tắc xác thực, thì chúng ta đã làm cho công việc vận hành trở nên nguy hiểm một cách không cần thiết. Và bạn không thể đơn giản tắt một trigger trên production: đó là một lần triển khai, kèm các bài kiểm thử của nó.

The standard answer is a bypass (some teams call it a kill switch): the first thing the trigger or flow does is check a switch, and skip itself if the switch is on. Decide the scope: a global switch for the whole org, one per object, one per automation, or one for particular users, such as the data load user or anyone holding a permission. Put it in your flows as well as your triggers. Flows are easy to deactivate, but a user-specific switch lets everyone else keep working. I consider flows visual programming: whether you’re writing code or programming visually, you’re still programming, and programs need this. ⟲

And here’s the part teams miss: the bypass is part of the original design. It isn’t something you build the week you need it. Every trigger and flow gets its bypass when it’s first built. It’s tested both ways, switched on and switched off, like any other behavior. And it goes to production with the automation, long before any migration, so on cutover weekend it’s already there, already tested, and ready to switch on. A bypass written in a hurry for the load is new, untested code going into production on the riskiest weekend of the project. Salesforce’s Record-Triggered Automation decision guide is just as firm: “A well-architected Salesforce organization requires a consistent and reliable mechanism to bypass automation. This is not an optional feature, but a core operational requirement” (Record-Triggered Automation (mở trong thẻ mới), Salesforce Architects decision guide, checked 2026-10-27). ⟲

Salesforce says the same thing in its own words. Its Well-Architected list of automation anti-patterns includes “Flows must be manually deactivated prior to bulk data loads” (Automation Patterns (mở trong thẻ mới), Operational Excellence, checked 2026-10-27). If your load plan says “deactivate these twelve flows on Friday night,” that’s the anti-pattern. ⟲

Test knowledge. Build a bypass into triggers and flows when they’re first built (a check of a custom permission, a custom setting or custom metadata at the start), test it on and off, and deploy it ahead of time, so large loads can skip them without editing or deactivating anything in production. Scope it: by object, by automation, or by user, such as the migration user. Deactivating flows by hand before a bulk load is an anti-pattern in Salesforce’s own Well-Architected guidance. ⟲

What a Bypass Looks Like

So what does a bypass actually look like? Three parts: a place to keep the switch, a check at the top of every trigger and flow, and the same check in the validation rules you decide to relax. Salesforce gives you three places to keep it, and each one decides who the switch applies to. ⟲

Where the switch lives	Who it applies to	Good for
A custom permission, granted by a permission set	Only the users who hold it	The usual migration bypass: give it to the migration user for the load, take it away after
A hierarchy custom setting	The whole org, one profile, or one user	A global “automation off” for everyone, or a switch for one profile or one user
A custom metadata record per automation	Everyone, for that one automation	Switching off one specific automation, deployed and versioned like code

The hierarchy custom setting is the one that does global, profile and user in one place. Salesforce’s description: it “checks the organization, profile, and user settings for the current user and returns the most specific, or lowest, value” (Define Custom Settings (mở trong thẻ mới), Salesforce Help, checked 2026-10-27). Set it off for the org, on for the migration user, and the migration user gets the bypass while everyone else gets normal automation. For most other configuration Salesforce now steers you to custom metadata instead, which deploys with your code; I’d use that for the per-automation switches. ⟲

In Apex, the check is the first thing the trigger does. Here’s what it could look like on the Work Order, with a hierarchy custom setting called Automation_Bypass__c and a custom permission called Bypass_Automation: ⟲

trigger WorkOrderTrigger on WorkOrder (after insert, after update) {
    // The hierarchy custom setting: the user's value, else the profile's, else the org's
    Automation_Bypass__c settings = Automation_Bypass__c.getInstance();

    // Bypass if the setting says so, or if this user holds the custom permission
    Boolean bypass = settings.Disable_Triggers__c == true
        || FeatureManagement.checkPermission('Bypass_Automation');

    if (bypass) {
        return;   // no side effects; the record still saves
    }

    WorkOrderStatusOut.publish(Trigger.new, Trigger.oldMap);
}

getInstance() returns the setting “for the current user,” merged from the lowest level that’s defined (Custom Settings Methods (mở trong thẻ mới)), and FeatureManagement.checkPermission “checks whether a custom permission is enabled” (FeatureManagement Class (mở trong thẻ mới); both Apex Reference Guide, Winter ‘27, checked 2026-10-27). ⟲

And one switch per automation, so the bypass is scoped instead of “skip everything.” A custom metadata type, Automation_Switch__mdt, with one record per automation: ⟲

public with sharing class WorkOrderStatusOut {
    public static void publish(List<WorkOrder> orders, Map<Id, WorkOrder> oldOrders) {
        // One record per automation; switched off here, it's off everywhere it's deployed
        Automation_Switch__mdt sw = Automation_Switch__mdt.getInstance('WorkOrder_Status_Out');
        if (sw != null && sw.Is_Off__c) {
            return;
        }
        // ... publish the status change for the partners
    }
}

getInstance(developerName) reads one custom metadata record by its name (Custom Metadata Type Methods (mở trong thẻ mới), Apex Reference Guide, checked 2026-10-27). ⟲

In a flow, it’s the same idea: the first element is a decision. ⟲

Nhấp để phóng to

The check comes first. Switched on, the flow steps aside. ⟲

The decision’s condition reads the same two switches, through flow’s global variables: $Permission is “the custom permission access of the user running the flow,” and $Setup reads hierarchy custom settings (Global Variables Resource (mở trong thẻ mới), Salesforce Help, checked 2026-10-27). As a formula resource: ⟲

{!$Permission.Bypass_Automation} || {!$Setup.Automation_Bypass__c.Disable_Flows__c}

In a validation rule, the bypass is one more condition. Here’s R12’s install rule, with the migration user allowed through (the field names are examples): ⟲

AND(
  NOT($Permission.Bypass_Automation),
  ISPICKVAL(Status, "Completed"),
  Install_Required__c,
  NOT(Install_Checklist_Complete__c)
)

Validation rules reference a custom permission as $Permission.Custom_Permission_Name (How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (mở trong thẻ mới), Salesforce Help, checked 2026-10-27). ⟲

Salesforce’s decision guide calls custom permissions “the modern, scalable standard for implementing bypass logic,” and notes a bypass can be granted to one user, “or even temporarily with a specific expiration date/time” (Record-Triggered Automation (mở trong thẻ mới), checked 2026-10-27). That’s the migration window, built into the grant. ⟲

These are examples to adapt, not a framework to paste in: build yours, test it in a sandbox, and test that the switch turns back off. And remember what you’ve built. A bypass is a permission to skip business rules. Grant it to the migration user for the migration window, record who has it, and take it away when the load is done (module 4 puts that in the runbook). ⟲

Test knowledge. Know the three places to keep a bypass and who each applies to: a custom permission (only the users whose permission sets grant it; checked with $Permission in flows and validation rules, FeatureManagement.checkPermission in Apex), a hierarchy custom setting (the org, a profile or a user, the most specific value winning; $Setup in flows and formulas, getInstance() in Apex), and custom metadata (one switch per automation, deployable). ⟲

Bỏ qua không có nghĩa là “bỏ qua mọi thứ”

Một cơ chế bỏ qua không có nghĩa là người dùng chuyển đổi phớt lờ mọi quy tắc trong Salesforce. Một tự động hóa nên được bỏ qua, một cái khác vẫn phải chạy; một quy tắc xác thực bảo vệ một bất biến cơ bản vẫn quan trọng, một thông báo thì không; một tích hợp phía sau cần được chặn lại, một quan hệ bắt buộc vẫn cần được kiểm tra. Vì vậy tôi muốn những cơ chế bỏ qua có chủ đích và có phạm vi, không phải Migration_Mode__c = true nên chẳng gì còn quan trọng. Con đường chuyển đổi vẫn có quy tắc, chỉ là những quy tắc phù hợp với chuyển đổi.

Và cơ chế bỏ qua nên đại diện cho một bối cảnh vận hành, không phải một sự tình cờ. Một danh tính chuyển đổi chuyên dụng (mô-đun 2), một custom permission, siêu dữ liệu cấu hình, một cờ tính năng, hoặc một sự kết hợp có thể nhận diện công việc chuyển đổi đã được phê duyệt. Danh tính có thể là một phần của kiểm soát, nhưng tôi không muốn mọi tự động hóa bị mã hóa cứng thành User.Name = 'Migration User'. Như vậy rất dễ gãy. Hãy diễn đạt ý định: nếu đây là một thao tác chuyển đổi đã được phê duyệt, hãy bỏ qua tác dụng phụ này.

Quy tắc xác thực cần sự phán đoán

“Close Date là bắt buộc khi một Opportunity ở trạng thái Closed Won” là một bất biến dữ liệu thật; hãy giữ nó cho các cơ hội lịch sử. Một quy tắc bắt buộc một trường của quy trình hiện tại được đưa vào ba năm trước thì khác: các bản ghi từ mười năm trước chưa bao giờ có nó, và bịa ra một giá trị làm dữ liệu tệ hơn. Câu hỏi không phải là “chúng ta có tắt quy tắc xác thực không?” Mà là những quy tắc nào đại diện cho sự thật dữ liệu bền vững, và những quy tắc nào đại diện cho quy trình tương tác của ngày hôm nay? Đó là câu hỏi của kiến trúc sư dữ liệu.

Steve Trucking has one of each. Every Work Order must have a Retail Partner: that’s enduring truth, and it stays on for the load; a RouteDesk delivery without one goes to quarantine (module 1). But requirement R12 says an install can’t be closed without a completed checklist and specific photos, the water line, the drain line, the level. That’s today’s process, built for crews with the new mobile app. RouteDesk’s completed installs never had those photos. Bypass that rule for the migration identity, and load them as completed. Don’t invent photos. ⟲

Dấu hiệu đáng ngờ cần để ý: đích yêu cầu một giá trị, nguồn không có, nên “cứ điền ‘Unknown’ vào hết”. Nếu Unknown là một giá trị được phê duyệt thực sự mô tả trạng thái, được. Nếu chúng ta chèn giá trị giả để vượt qua xác thực, chúng ta đang làm hỏng dữ liệu để chiều lòng ứng dụng. Tôi thà thiết kế một ngoại lệ chuyển đổi, một trường lịch sử cho phép null, một quy tắc chuyển đổi hay một giá trị trạng thái cũ, còn hơn giả vờ rằng chúng ta biết một điều mình không biết.

Tự động hóa nhân Số chữ số 0 lên

Tải 2 triệu tài khoản; tự động hóa tạo 2 tác vụ cho mỗi tài khoản: 4 triệu tác vụ. Có chủ đích, hay là một tai nạn? Rồi mỗi tác vụ kích hoạt một flow khác, tự động hóa trên tài khoản cập nhật một bản ghi cha, phát một sự kiện, tính lại một thứ khác. Hiệu năng của đợt chuyển đổi không phải là Bulk API chèn tài khoản nhanh đến đâu. Khối công việc thực sự là đồ thị giao dịch mà những lần chèn đó tạo ra. Số chữ số 0 được nhân lên qua tự động hóa.

Now zoom in on RouteDesk’s three red arrows and count. ⟲

Nhấp để phóng to

Every record, times everything it sets off. ⟲

Chapter 9 turned on Change Data Capture for Work Orders, so Snowflake’s subscriber receives a change event for every create. That’s about 196,400 events in one weekend, and without an add-on the daily allocation for delivered events is 50,000 in Performance and Unlimited Editions, counted per subscriber (Change Data Capture Allocations (mở trong thẻ mới), checked 2026-10-27). The partners would get status messages for about 190,000 deliveries they closed weeks ago. The finance ERP would count deliveries it has already invoiced, and the partners would be billed twice. And Recipients would get texts about deliveries that already happened. ⟲

Nhấp để phóng to

Keep only the outcomes you need: one backfill, texts for the open deliveries, nothing to partners or finance. ⟲

Tác dụng phụ bên ngoài còn tệ hơn. Email khách hàng, yêu cầu thanh toán, sự kiện được các hệ thống production tiêu thụ, lệnh gọi ERP, phiếu hỗ trợ, cập nhật marketing: những hệ thống đó không biết đó là dữ liệu chuyển đổi, và một khi thông điệp đã rời Salesforce, việc hoàn tác có thể là bất khả thi. Chương 9 cho chúng ta hợp đồng dữ liệu tích hợp; trong khi lập kế hoạch chuyển đổi, hãy quyết định mũi tên nào được hoạt động, mũi tên nào bị chặn, và mũi tên nào được thay bằng một lần đồng bộ sau khi chuyển giao. Quyết định đó thuộc về kế hoạch chuyển giao.

Dữ liệu dẫn xuất, chia sẻ, và đối tượng trung gian

Trường tổng hợp và các giá trị dẫn xuất khác: tải một bản ghi cha, rồi hàng triệu bản ghi con, và tính lại sau mỗi bản ghi con? Có thể. Thường thì tải mọi thứ rồi tính một lần sẽ rẻ hơn nhiều. Câu hỏi là kết quả dẫn xuất có phải được duy trì theo từng bản ghi trong suốt đợt chuyển đổi không, hay có thể được thiết lập sau khi dữ liệu phụ thuộc đã đầy đủ. Đó lại là cùng quyết định không cần / mô phỏng / hoãn.

Chia sẻ cũng là dữ liệu dẫn xuất. Việc tạo và chuyển giao bản ghi kích hoạt tính toán quy tắc chia sẻ, và với một lần tải lớn, điều đó có thể dẫn đến những lần đánh giá rất lâu hoặc hết thời gian chờ. Salesforce cho phép quản trị viên hoãn phép tính chia sẻ (quy tắc chia sẻ và tư cách thành viên nhóm) rồi tiếp tục sau, nhưng tính năng này không bật mặc định: Bộ phận hỗ trợ Salesforce bật nó. Khi tiếp tục, bạn phải chạy một lần tính lại toàn bộ, và một số thay đổi chia sẻ vẫn được tính ngay lập tức để bảo vệ tính toàn vẹn dữ liệu (Defer Sharing Calculations (mở trong thẻ mới)). Hãy lên kế hoạch cho nó, và lên kế hoạch cho thời gian tính lại.

Deferring has limits of its own. The catch-up usually runs as batch Apex, and that shares the org’s daily allowance of asynchronous Apex executions: “250,000 or the number of applicable user licenses in your org multiplied by 200, whichever is greater.” Only five batch jobs can be queued or active at once, with up to 100 more waiting in the flex queue (Execution Governors and Limits (mở trong thẻ mới), Apex Developer Guide, Winter ‘27, checked 2026-10-27). Your catch-up competes with every other batch job in the org, so schedule it, and size it. ⟲

Test knowledge. Large loads trigger sharing recalculation. Salesforce Support can enable deferred sharing calculations (sharing rules and group membership), which you resume and recalculate after the load. Deferred work usually runs as batch Apex, within the daily asynchronous Apex limit and five concurrent batch jobs. ⟲

And sometimes the logic you need is simply too slow to load through. This is the special case module 1 mentioned. A process that takes a second or two per record is fine for users; for hundreds of thousands of records in a cutover window it means days, and trying to simulate an intricate object model in the load can mean a dozen tables. The technique I use: load into a staging object first, a light custom object with no automation that holds the import fields and lookups, then let a batch process work through it, calling the platform’s own logic to build the real records. The status on each staging row lets the batch work in chunks, pause and resume, and the original import fields stay alongside the records they created for tracing. You get the data in fast and catch up on the processing afterward. ⟲

Thiết kế cho trạng thái cuối cùng, và viết nó ra

Mục tiêu không phải là “chạy tự động hóa của production”. Mà là đạt đến đúng trạng thái production, và hai điều đó không giống nhau. Xử lý thông thường cho một tài khoản mới tính ra một phân loại, tạo một tác vụ tiếp nhận, gửi một thông báo và phát sang một hệ thống khác. Với một tài khoản lịch sử được chuyển đổi, trạng thái cuối cùng đúng có thể là: phân loại có, tác vụ tiếp nhận không, thông báo chào mừng không, phát ra ngoài có thể, tùy theo kế hoạch đồng bộ. Chạy mù quáng tự động hóa thông thường là tái tạo một quy trình không được thiết kế cho chuyển đổi.

Với một đợt chuyển đổi nghiêm túc, hãy viết nó ra thành một bảng kê tự động hóa:

Tự động hóa	Hành vi thông thường	Quyết định cho chuyển đổi	Kết quả chuyển đổi cần có
Status out to partners	Send each status change to Redrock, Keystone, Brightwave	Don’t need it	None: the partners already have it
Change Data Capture to Snowflake	A change event per Work Order	Defer	One backfill of status history after the load
Delivery counts to finance	Count each completed delivery for invoicing	Don’t need it	None: already invoiced; reconcile the count instead
Day-before text	Text the Recipient with a tracking link	Run deliberately, open deliveries only	Monday’s Recipients get the link; none for delivered ones
Work Order status	Set by the crews’ app	Simulate	Status mapped in the preparation data store
Install checklist and photos (R12)	Block closing an install without them	Bypass for the migration identity	Completed installs load as completed; no invented photos
Every Work Order has a partner	Reject a Work Order without one	Keep	Missing partner: quarantined before the load

Giờ quyết định đã hiện rõ: chúng ta có thể rà soát nó, kiểm thử nó, diễn tập nó và xác minh nó sau lần tải.

Diễn tập cơ chế bỏ qua, rồi bật lại

Đừng để production là lần đầu tiên bạn dùng chế độ chuyển đổi. Lần diễn tập nên kiểm thử danh tính chuyển đổi, các kiểm soát bỏ qua, các tự động hóa vẫn hoạt động, các kết quả được mô phỏng, các tiến trình được hoãn và việc trở lại chế độ bình thường, rồi kiểm tra: có gì chạy mà lẽ ra không nên chạy không, có gì không xảy ra mà lẽ ra phải xảy ra không, trạng thái cuối cùng có khớp với kiến trúc không? Đó là lý do lần diễn tập cần cấu hình tự động hóa thật, hoặc gần nhất có thể.

Bật lại là một bước của việc chuyển giao: tường minh, có người chịu trách nhiệm được nêu tên, thời gian dự kiến và bước xác minh. Không phải “nhớ bật lại các flow nhé”. Hệ thống chưa sẵn sàng cho người dùng cho đến khi hoạt động bình thường được khôi phục và xác minh (mô-đun 4 đưa điều đó vào runbook).

And beware the catch-up storm. We suppressed downstream synchronization while loading RouteDesk’s records; now we switch the integration back on. Does it see five million “new” records and try to send them all? Maybe the downstream system already received them another way, maybe only changes after the cutover watermark should go, maybe it needs a controlled initial sync. The automation decision and the integration decision have to work together. Turning automation back on isn’t enough: know what it will do when it wakes up. For Steve Trucking, the status flows and the Change Data Capture subscriber should see only the changes made after cutover, never the weekend’s load. ⟲

AI làm cho thiết kế cơ chế bỏ qua quan trọng hơn

Giờ thêm vào những tác tử phản ứng với một trường hợp mới, một tài khoản thay đổi, một sự kiện được phát hay một tác vụ trong hàng đợi. Một đợt chuyển đổi tạo ra các khuôn mẫu dữ liệu ở quy mô máy móc; chúng ta có muốn tác tử phản ứng với mọi bản ghi được chuyển đổi không? Có lẽ không, nếu là do vô tình. Các quy trình do tác tử kích hoạt thuộc về cùng bảng kê với flow, trigger, thông báo, tích hợp và sự kiện, và nếu bối cảnh chuyển đổi nên chặn chúng, hãy thiết kế điều đó một cách có chủ đích.

Ngoài kỳ thi: AI thay đổi điều gì. Tác tử là một loại tác dụng phụ khác, loại có thể tự phản ứng với dữ liệu được chuyển đổi. Hãy đối xử với các hành động do tác tử kích hoạt như mọi tự động hóa khác: quyết định cho chạy, mô phỏng, hoãn hay chặn chúng, và kiểm thử quyết định đó khi diễn tập.

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

Những tự động hóa nào chạy, không cần, được mô phỏng hay được hoãn cho từng loại dữ liệu chuyển đổi, biết rằng tắt một tự động hóa nghĩa là nhận trách nhiệm về logic nghiệp vụ của nó.
Những quy tắc xác thực nào đại diện cho sự thật dữ liệu bền vững, và những quy tắc nào là quy tắc của quy trình hiện tại cần cách xử lý riêng cho chuyển đổi.
How scoped bypasses are designed into every automation from the start, tested on and off, and deployed long before they’re needed, without an unrestricted “skip everything” path. ⟲
Dữ liệu dẫn xuất, việc tính lại chia sẻ và logic nền tảng chậm được xử lý thế nào: sau lần tải, được hoãn, hay qua một đối tượng trung gian.
Những tác dụng phụ bên ngoài và tích hợp nào bị chặn hay được bắt kịp có chủ đích, và việc diễn tập và chuyển giao chứng minh thế nào rằng tự động hóa thông thường đã được khôi phục an toàn.

Hãy biến nó thành một quyết định

Đợt chuyển đổi không thành công chỉ vì mọi flow đã chạy, mọi trigger đã kích hoạt và mọi quy tắc xác thực đã thực thi. Đó là hành vi giao dịch thông thường, còn chuyển đổi có một nhiệm vụ khác: đưa dữ liệu vào kiến trúc mới, giữ gìn những sự thật quan trọng, tạo ra các giá trị dẫn xuất chúng ta cần, tránh những tác dụng phụ sai, giữ hệ thống trong tầm kiểm soát, rồi đưa nó trở lại bình thường. Với mỗi tự động hóa: không cần nó, mô phỏng nó, hoãn nó, hoặc cố ý để nó chạy. Nhưng hãy biến nó thành một quyết định. Đừng để năm triệu bản ghi quyết định thay bạn.

Tìm hiểu thêm

Salesforce Help, Defer Sharing Calculations (mở trong thẻ mới) and Workflow Rules & Process Builder End of Support (mở trong thẻ mới), checked 2026-11-01. ⟲
Salesforce Help, Define Custom Settings (mở trong thẻ mới), Global Variables Resource (mở trong thẻ mới) (Flow) and How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (mở trong thẻ mới); Apex Reference Guide, FeatureManagement Class (mở trong thẻ mới), Custom Settings Methods (mở trong thẻ mới) and Custom Metadata Type Methods (mở trong thẻ mới), Winter ‘27; all checked 2026-11-01. ⟲
Salesforce Architects, decision guide, Record-Triggered Automation (mở trong thẻ mới) (“Bypassing Automation”), checked 2026-11-01. ⟲
Salesforce Architects, Well-Architected, Automation Patterns (mở trong thẻ mới) and Resource and Cost Optimization (mở trong thẻ mới), checked 2026-11-01. ⟲
Salesforce, Apex Developer Guide, Execution Governors and Limits (mở trong thẻ mới), Winter ‘27 (API version 68.0), and Change Data Capture Developer Guide, Change Data Capture Allocations (mở trong thẻ mới), checked 2026-11-01. ⟲
Trong khóa học này: Tích hợp và di chuyển dữ liệu (hợp đồng dữ liệu tích hợp) và Thiết kế cho quy mô lớn.