Otomasi Selama Pemuatan

🌐 Juga tersedia dalam 19 bahasa

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

Gambar dibuat dengan AI

Diterjemahkan dengan AI. Belum ditinjau oleh komunitas. Baca dalam bahasa Inggris Bagian ini telah berubah dalam bahasa Inggris dan belum diterjemahkan ulang. (61)

Modul 3 dari 5 dalam bab Migrasi dan Sinkronisasi, bab 10 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Memuat dalam Volume Besar · Berikutnya: Akhir Pekan Cutover

Pertanyaan yang dijawab modul ini: Apa yang seharusnya terjadi pada otomasi Salesforce selama data migrasi dimuat?

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

Klik untuk memperbesar

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

Otomasi Tidak Tahu Ini Migrasi

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

Jadi untuk migrasi besar saya mulai dari sini: otomasi bisnis normal tidak boleh berjalan membabi buta terhadap pemuatan. Itu tidak berarti “matikan semuanya.” Artinya setiap otomasi penting mendapat keputusan yang disengaja, dan saya tidak ingin jawabannya ditemukan karena produksi mengirim 400.000 email.

Tiga Pilihan: Tidak Perlu, Simulasikan, Tunda

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

Tidak perlu (hilangkan). Perilaku itu tidak boleh terjadi untuk rekaman yang dimigrasikan. Pelanggan yang sudah bersama kita delapan tahun tidak butuh “Selamat bergabung di perusahaan kami!” Sisipkan satu akun, ia mengirim satu email; muat sejuta akun, dan saya tidak butuh sejuta email.

Simulasikan. Otomasinya tidak boleh berjalan, tetapi hasil yang diciptakannya tetap dibutuhkan. Sebuah flow saat pembuatan akun menurunkan Customer Segment. Akun yang dimigrasikan butuh segmen yang valid, tetapi menjalankan seluruh flow lima juta kali itu mahal atau punya efek samping. Jadi kita menghitung segmennya di transformasi dan memuat hasilnya. Kita tidak mengabaikan aturan bisnisnya; kita mengerjakan tugas otomasi itu di dalam pemuatan.

Tunda. Hasilnya dibutuhkan, tetapi tidak di dalam transaksi pemuatan. Muat dengan otomasi mati dan sebuah penanda terpasang, lalu picu proses batch untuk mengejar: hitung ulang, buat rekaman yang bergantung, terbitkan apa yang dibutuhkan sistem hilir. Menunda bisa membuat pemuatan lebih cepat dan lebih terkendali tanpa mengorbankan hasilnya.

Dan kadang Anda membiarkannya menyala. Untuk pemuatan kecil di mana bisnis ingin proses normalnya berjalan, biarkan sistem melakukan apa yang biasa dilakukannya. Itu juga pilihan, selama memang dipilih.

Apa pun pilihan Anda, inilah aturan yang saya ajarkan: setiap kali Anda mematikan sebuah otomasi, Anda memikul tanggung jawab penuh atas logika bisnis yang tidak terjadi itu. Anda perlu memahami setiap otomasi sebelum memutuskan.

Klik untuk memperbesar

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

“Matikan Otomasi” Bukan Seluruh Strateginya

Rencananya berbunyi “matikan otomasinya.” Otomasi yang mana? Bagaimana, siapa, kapan? Bagaimana kita tahu ia mati, dan bagaimana kita tahu ia menyala lagi? Hasil mana yang biasanya diciptakannya harus tetap ada sesudahnya? Apa yang terjadi jika pengguna ada di sistem selama ia mati, atau migrasinya gagal di tengah jalan? Mematikan sesuatu adalah tindakan operasional. Arsitekturnya butuh seluruh siklus hidupnya: status normal, status migrasi, kembali ke normal, dan bukti bahwa kita sudah kembali.

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 (terbuka di tab baru), 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 (terbuka di tab baru), 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

Posisi saya yang lebih tegas: otomasi yang penting harus punya bypass terkendali bahkan ketika tidak ada migrasi yang direncanakan. Migrasi bukan satu-satunya alasan Anda akan membutuhkannya. Perbaikan besar, koreksi data, backfill, perbaikan integrasi, pemulihan darurat: kadang Anda harus menjalankan operasi terkendali tanpa setiap bagian otomasi normal. Jika satu-satunya cara adalah mengedit flow di produksi, menonaktifkan trigger, atau menghapus aturan validasi, kita membuat pekerjaan operasional berbahaya tanpa perlu. Dan Anda tidak bisa begitu saja mematikan trigger di produksi: itu deployment, dengan test-nya.

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 (terbuka di tab baru), 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 (terbuka di tab baru), 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 (terbuka di tab baru), 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 (terbuka di tab baru)), and FeatureManagement.checkPermission “checks whether a custom permission is enabled” (FeatureManagement Class (terbuka di tab baru); 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 (terbuka di tab baru), Apex Reference Guide, checked 2026-10-27). ⟲

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

Klik untuk memperbesar

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 (terbuka di tab baru), 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 (terbuka di tab baru), 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 (terbuka di tab baru), 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). ⟲

Bypass Bukan “Lewati Semuanya”

Bypass tidak berarti pengguna migrasi mengabaikan setiap aturan di Salesforce. Satu otomasi harus dilewati, yang lain harus tetap berjalan; aturan validasi yang melindungi invarian mendasar tetap penting, notifikasi tidak; integrasi hilir perlu diredam, hubungan wajib tetap perlu diperiksa. Jadi saya ingin bypass yang disengaja dan dibatasi cakupannya, bukan Migration_Mode__c = true, sehingga tak ada yang penting lagi. Jalur migrasi tetap punya aturan, hanya aturan yang sesuai untuk migrasi.

Dan bypass harus mewakili konteks operasional, bukan kebetulan. Identitas migrasi khusus (modul 2), custom permission, metadata konfigurasi, feature flag, atau kombinasinya bisa mengenali pekerjaan migrasi yang disetujui. Identitas bisa menjadi bagian dari kontrolnya, tetapi saya tidak ingin setiap otomasi di-hard-code ke User.Name = 'Migration User'. Itu rapuh. Ungkapkan maksudnya: jika ini operasi migrasi yang disetujui, lewati efek samping ini.

Aturan Validasi Butuh Pertimbangan

“Close Date wajib diisi ketika sebuah Opportunity berstatus Closed Won” adalah invarian data yang nyata; pertahankan untuk opportunity historis. Aturan yang mewajibkan bidang proses-saat-ini yang diperkenalkan tiga tahun lalu berbeda: rekaman dari sepuluh tahun lalu tidak pernah punya bidang itu, dan mengarang nilainya membuat data lebih buruk. Pertanyaannya bukan “apakah kita mematikan aturan validasi?” Melainkan aturan mana yang mewakili kebenaran data yang langgeng, dan mana yang mewakili proses interaktif hari ini? Itu pertanyaan arsitek data.

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

Gejala yang perlu diwaspadai: target mewajibkan sebuah nilai, sumbernya tidak punya, jadi “isi saja ‘Unknown’ di semuanya.” Jika Unknown adalah nilai yang disetujui dan benar-benar menggambarkan statusnya, tidak masalah. Jika kita menyisipkan nilai palsu agar lolos validasi, kita merusak data demi memuaskan aplikasi. Saya lebih suka merancang pengecualian migrasi, bidang historis yang boleh kosong, aturan transformasi, atau nilai status lama daripada berpura-pura tahu sesuatu yang tidak kita ketahui.

Otomasi Melipatgandakan Jumlah Nol

Muat 2 juta akun; otomasi membuat 2 tugas untuk masing-masing: 4 juta tugas. Disengaja, atau kecelakaan? Lalu setiap tugas memicu flow lain, otomasi akun memperbarui sebuah induk, menerbitkan event, menghitung ulang sesuatu yang lain. Kinerja migrasi bukan seberapa cepat Bulk API menyisipkan akun. Beban kerja sebenarnya adalah graf transaksi yang diciptakan penyisipan itu. Jumlah Nol berlipat ganda lewat otomasi.

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

Klik untuk memperbesar

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 (terbuka di tab baru), 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. ⟲

Klik untuk memperbesar

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

Efek samping eksternal lebih buruk. Email pelanggan, permintaan penagihan, event yang dikonsumsi sistem produksi, panggilan ERP, tiket dukungan, pembaruan pemasaran: sistem-sistem itu tidak tahu itu data migrasi, dan begitu pesannya meninggalkan Salesforce, membatalkannya mungkin mustahil. Bab 9 memberi kita kontrak data integrasi; selama perencanaan migrasi, putuskan panah mana yang boleh beroperasi, mana yang diredam, dan mana yang diganti dengan sinkronisasi setelah cutover. Keputusan itu tempatnya di rencana cutover.

Data Turunan, Berbagi, dan Objek Staging

Roll-up dan nilai turunan lainnya: muat sebuah induk, lalu jutaan anak, dan hitung ulang setelah setiap anak? Mungkin. Sering kali jauh lebih murah memuat semuanya lalu menghitung sekali. Pertanyaannya adalah apakah hasil turunannya harus dijaga rekaman demi rekaman selama migrasi, atau bisa ditetapkan setelah data yang bergantung lengkap. Itu keputusan tidak perlu / simulasikan / tunda yang sama.

Berbagi juga data turunan. Membuat dan memindahkan rekaman memicu perhitungan aturan berbagi, dan pada pemuatan besar itu bisa berarti evaluasi yang sangat lama atau kehabisan waktu. Salesforce memungkinkan admin menunda perhitungan berbagi (aturan berbagi dan keanggotaan grup) dan melanjutkannya sesudahnya, tetapi fitur ini tidak aktif secara bawaan: Dukungan Salesforce yang mengaktifkannya. Ketika melanjutkan, Anda harus menjalankan penghitungan ulang penuh, dan sebagian perubahan berbagi tetap dihitung seketika untuk melindungi integritas data (Defer Sharing Calculations (terbuka di tab baru)). Rencanakan, dan rencanakan waktu penghitungan ulangnya.

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 (terbuka di tab baru), 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. ⟲

Rancang untuk Status Akhir, dan Tuliskan

Tujuannya bukan “jalankan otomasi produksi.” Tujuannya tiba di status produksi yang benar, dan keduanya tidak sama. Pemrosesan normal untuk akun baru menurunkan sebuah klasifikasi, membuat tugas orientasi, mengirim notifikasi, dan menerbitkan ke sistem lain. Untuk akun historis yang dimigrasikan, status akhir yang benar mungkin: klasifikasi ya, tugas orientasi tidak, notifikasi selamat datang tidak, penerbitan eksternal mungkin, bergantung pada rencana sinkronisasi. Menjalankan otomasi normal membabi buta hanya mereproduksi proses yang tidak dirancang untuk migrasi.

Untuk migrasi yang serius, tuliskan sebagai inventaris otomasi:

Otomasi	Perilaku normal	Keputusan migrasi	Hasil migrasi yang dibutuhkan
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

Sekarang keputusannya terlihat: kita bisa meninjaunya, mengujinya, melatihnya, dan memverifikasinya setelah pemuatan.

Latih Bypass-nya, Lalu Nyalakan Kembali

Jangan jadikan produksi kali pertama Anda memakai mode migrasi. Latihannya harus menguji identitas migrasi, kontrol bypass, otomasi yang tetap aktif, hasil yang disimulasikan, proses yang ditunda, dan kembalinya mode normal, lalu memeriksa: adakah yang berjalan padahal tidak seharusnya, adakah yang gagal terjadi padahal seharusnya, apakah status akhirnya sesuai arsitektur? Itulah sebabnya latihan butuh konfigurasi otomasi yang sesungguhnya, atau sedekat mungkin dengannya.

Menyalakan kembali adalah langkah cutover: eksplisit, dengan pemilik bernama, waktu yang diharapkan, dan verifikasi. Bukan “ingat untuk menyalakan flow lagi.” Sistemnya belum siap untuk pengguna sampai operasi normal dipulihkan dan diverifikasi (modul 4 memasukkannya ke 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 Membuat Desain Bypass Makin Penting

Sekarang tambahkan agen yang bereaksi terhadap kasus baru, akun yang berubah, event yang diterbitkan, atau tugas dalam antrean. Migrasi menciptakan pola data dalam skala mesin; apakah kita ingin agen bereaksi terhadap setiap rekaman yang dimigrasikan? Mungkin tidak secara tidak sengaja. Proses yang dipicu agen tempatnya di inventaris yang sama dengan flow, trigger, notifikasi, integrasi, dan event, dan jika konteks migrasi harus meredamnya, rancang itu dengan sengaja.

Di luar ujian: apa yang diubah AI. Agen adalah jenis efek samping lain, yang bisa bereaksi secara otonom terhadap data yang dimigrasikan. Perlakukan tindakan yang dipicu agen seperti otomasi lainnya: putuskan apakah dijalankan, disimulasikan, ditunda, atau diredam, dan uji keputusannya saat latihan.

Yang Diputuskan Arsitek di Sini

• Otomasi mana yang berjalan, tidak perlu, disimulasikan, atau ditunda untuk setiap kelas data yang dimigrasikan, dengan kesadaran bahwa mematikannya berarti memikul logika bisnisnya.
• Aturan validasi mana yang mewakili kebenaran data yang langgeng, dan mana yang aturan proses-saat-ini yang butuh perlakuan khusus migrasi.
• 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. ⟲
• Bagaimana data turunan, penghitungan ulang berbagi, dan logika platform yang lambat ditangani: setelah pemuatan, ditunda, atau lewat objek staging.
• Efek samping eksternal dan integrasi mana yang diredam atau dikejar dengan sengaja, dan bagaimana latihan dan cutover membuktikan otomasi normal sudah dipulihkan dengan aman.

Jadikan Itu Keputusan

Migrasi tidak berhasil karena setiap flow berjalan, setiap trigger menyala, dan setiap aturan validasi dieksekusi. Itu perilaku transaksi normal, dan migrasi punya tugas yang berbeda: memindahkan data ke arsitektur baru, menjaga kebenaran yang penting, menciptakan nilai turunan yang kita butuhkan, menghindari efek samping yang keliru, menjaga sistem tetap terkendali, lalu mengembalikannya ke normal. Untuk setiap otomasi: tidak perlu, simulasikan, tunda, atau sengaja biarkan berjalan. Tetapi jadikan itu keputusan. Jangan biarkan lima juta rekaman yang memutuskannya untuk Anda.

Jelajahi

• Salesforce Help, Defer Sharing Calculations (terbuka di tab baru) and Workflow Rules & Process Builder End of Support (terbuka di tab baru), checked 2026-11-01. ⟲
• Salesforce Help, Define Custom Settings (terbuka di tab baru), Global Variables Resource (terbuka di tab baru) (Flow) and How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (terbuka di tab baru); Apex Reference Guide, FeatureManagement Class (terbuka di tab baru), Custom Settings Methods (terbuka di tab baru) and Custom Metadata Type Methods (terbuka di tab baru), Winter ‘27; all checked 2026-11-01. ⟲
• Salesforce Architects, decision guide, Record-Triggered Automation (terbuka di tab baru) (“Bypassing Automation”), checked 2026-11-01. ⟲
• Salesforce Architects, Well-Architected, Automation Patterns (terbuka di tab baru) and Resource and Cost Optimization (terbuka di tab baru), checked 2026-11-01. ⟲
• Salesforce, Apex Developer Guide, Execution Governors and Limits (terbuka di tab baru), Winter ‘27 (API version 68.0), and Change Data Capture Developer Guide, Change Data Capture Allocations (terbuka di tab baru), checked 2026-11-01. ⟲
• Di kursus ini: Integrasi dan Perpindahan Data (kontrak data integrasi) dan Merancang untuk Skala.