Yükleme Sırasında Otomasyon

🌐 19 dilde daha mevcut

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

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku Bu bölüm İngilizcede değişti ve henüz yeniden çevrilmedi. (61)

Data Architect kursunun 10. bölümü olan Taşıma ve Eşitleme bölümündeki 5 modülden 3.‘sü. Her modül kendi başına okunabilir. Önceki: Hacimde Yükleme · Sonraki: Geçiş Hafta Sonu

Bu modülün yanıtladığı soru: Taşıma verisi yüklenirken Salesforce otomasyonuna ne olmalı?

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

Büyütmek için tıklayın

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

Otomasyon Bunun Bir Taşıma Olduğunu Bilmez

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

Bu yüzden büyük bir taşıma için buradan başlarım: normal iş otomasyonu yüklemeye karşı körü körüne çalışmamalıdır. Bu “her şeyi kapat” demek değil. Her önemli otomasyonun bilinçli bir karar alması demek ve yanıtın üretim 400.000 e-posta gönderdiği için keşfedilmesini istemem.

Üç Seçenek: Gerekmez, Benzet, Ertele

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

Gerekmez (kaldır). Taşınan kayıtlar için bu davranış olmamalı. Sekiz yıldır bizimle olan müşterilerin “Şirketimize hoş geldiniz!” mesajına ihtiyacı yok. Bir hesap ekleyin, bir e-posta gönderir; bir milyon hesap yükleyin, bir milyon e-postaya ihtiyacım yok.

Benzet. Otomasyon çalışmamalı, ama yarattığı sonuç yine de gerekli. Hesap oluşturulurken çalışan bir flow Customer Segment’i türetir. Taşınan hesapların geçerli bir segmente ihtiyacı var, ama tüm flow’u beş milyon kez çalıştırmak pahalı ya da yan etkileri var. Bu yüzden segmenti dönüşümde hesaplar ve sonucu yükleriz. İş kuralını görmezden gelmedik; otomasyonun işini yüklemede yaptık.

Ertele. Sonuç gerekli, ama yükleme işleminin içinde değil. Otomasyon kapalı ve bir bayrak ayarlıyken yükleyin, sonra yetişmek için bir toplu süreci tetikleyin: yeniden hesaplayın, bağımlı kayıtları oluşturun, aşağı akış sistemlerinin ihtiyaç duyduğunu yayımlayın. Ertelemek, sonuçtan vazgeçmeden yüklemeyi daha hızlı ve daha kontrol edilebilir yapabilir.

Ve bazen açık bırakırsınız. İş biriminin normal sürecinin çalışmasını istediği daha küçük bir yükleme için sistemin yaptığını yapmasına izin verin. Bu da bir seçimdir, yeter ki gerçekten bir seçim olsun.

Hangisini seçerseniz seçin, öğrettiğim kural şu: bir otomasyonu her kapattığınızda, o iş mantığının gerçekleşmemesinin tüm sorumluluğunu üstlenirsiniz. Karar vermeden önce her otomasyonu anlamanız gerekir.

Büyütmek için tıklayın

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

“Otomasyonu Devre Dışı Bırak” Stratejinin Tamamı Değildir

Plan “otomasyonu devre dışı bırak” diyor. Hangi otomasyonu? Nasıl, kim, ne zaman? Kapalı olduğunu nasıl biliyoruz ve yeniden açıldığını nasıl bileceğiz? Normalde ürettiği hangi sonuçlar sonrasında yine var olmalı? Kapalıyken kullanıcılar sistemdeyse ya da taşıma yarıda başarısız olursa ne olur? Bir şeyi kapatmak operasyonel bir eylemdir. Mimari tüm yaşam döngüsüne ihtiyaç duyar: normal durum, taşıma durumu, normale dönüş ve döndüğümüzün kanıtı.

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 (yeni sekmede açılır), 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 (yeni sekmede açılır), 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

Daha güçlü görüşüm: önemli otomasyonun, planlanmış bir taşıma olmasa bile kontrollü bir atlama yolu olmalıdır. Taşıma ona ihtiyaç duyacağınız tek neden değil. Büyük düzeltmeler, veri düzeltme, geriye dönük doldurmalar, entegrasyon onarımı, acil kurtarma: bazen normal otomasyonun her parçası olmadan kontrollü bir işlem çalıştırmanız gerekir. Tek yol üretimde flow’u düzenlemek, tetikleyiciyi devre dışı bırakmak veya bir doğrulama kuralını silmekse, operasyonel işi gereksiz yere tehlikeli hâle getirmişizdir. Ve üretimde bir tetikleyiciyi öylece kapatamazsınız: bu, testleriyle birlikte bir dağıtımdır.

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 (yeni sekmede açılır), 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 (yeni sekmede açılır), 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 (yeni sekmede açılır), 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 (yeni sekmede açılır)), and FeatureManagement.checkPermission “checks whether a custom permission is enabled” (FeatureManagement Class (yeni sekmede açılır); 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 (yeni sekmede açılır), Apex Reference Guide, checked 2026-10-27). ⟲

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

Büyütmek için tıklayın

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 (yeni sekmede açılır), 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 (yeni sekmede açılır), 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 (yeni sekmede açılır), 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). ⟲

Atlama “Her Şeyi Atla” Değildir

Atlama, taşıma kullanıcısının Salesforce’taki her kuralı yok sayması anlamına gelmez. Bir otomasyon atlanmalı, diğeri yine çalışmalı; temel bir değişmezi koruyan bir doğrulama kuralı hâlâ önemli, bir bildirim değil; aşağı akış bir entegrasyonun bastırılması gerekiyor, zorunlu bir ilişkinin hâlâ kontrol edilmesi gerekiyor. Bu yüzden Migration_Mode__c = true, dolayısıyla hiçbir şey önemli değil yerine, bilinçli ve kapsamı belirli atlamalar isterim. Taşıma yolunun yine kuralları var, yalnızca taşımaya uygun olanlar.

Ve atlama bir kazayı değil, operasyonel bir bağlamı temsil etmelidir. Özel bir taşıma kimliği (modül 2), özel bir izin, yapılandırma meta verisi, bir özellik bayrağı ya da bunların bir bileşimi onaylı taşıma işini tanıyabilir. Kimlik kontrolün bir parçası olabilir, ama her otomasyonun User.Name = 'Migration User' diye sabit kodlanmasını istemem. Bu kırılgandır. Niyeti ifade edin: bu onaylı bir taşıma işlemiyse bu yan etkiyi atla.

Doğrulama Kuralları Muhakeme İster

“Bir Opportunity Closed Won olduğunda Close Date zorunludur” gerçek bir veri değişmezidir; tarihsel fırsatlar için koruyun. Üç yıl önce getirilmiş güncel süreç alanını zorunlu kılan bir kural farklıdır: on yıl önceki kayıtlarda o alan hiç olmadı ve bir değer uydurmak veriyi kötüleştirir. Soru “doğrulama kurallarını kapatıyor muyuz?” değil. Hangi kurallar kalıcı veri gerçeğini, hangileri bugünün etkileşimli sürecini temsil ediyor? Bu bir veri mimarı sorusudur.

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

Dikkat edilmesi gereken koku: hedef bir değer istiyor, kaynakta yok, o zaman “her şeye ‘Unknown’ koyalım”. Unknown durumu gerçekten tanımlayan onaylı bir değerse sorun yok. Doğrulamayı geçmek için sahte değerler ekliyorsak, uygulamayı tatmin etmek için veriyi bozuyoruz demektir. Bilmediğimiz bir şeyi biliyormuş gibi yapmak yerine bir taşıma istisnası, boş bırakılabilir bir tarihsel alan, bir dönüşüm kuralı ya da eski bir durum değeri tasarlamayı tercih ederim.

Otomasyon Sıfır Sayısı’nı Çoğaltır

2 milyon hesap yükleyin; otomasyon her biri için 2 görev oluşturur: 4 milyon görev. Kasıtlı mı, kaza mı? Sonra her görev başka bir flow’u tetikler, hesap otomasyonu bir üst kaydı günceller, bir olay yayımlar, başka bir şeyi yeniden hesaplar. Taşıma performansı, Bulk API’nin hesapları ne kadar hızlı eklediği değildir. Gerçek iş yükü, bu eklemelerin yarattığı işlem grafiğidir. Sıfır Sayısı otomasyon yoluyla çoğalır.

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

Büyütmek için tıklayın

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 (yeni sekmede açılır), 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. ⟲

Büyütmek için tıklayın

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

Harici yan etkiler daha kötüdür. Müşteri e-postaları, fatura talepleri, üretim sistemlerinin tükettiği olaylar, ERP çağrıları, destek talepleri, pazarlama güncellemeleri: o sistemler bunun taşıma verisi olduğunu bilmez ve mesaj Salesforce’tan çıktığında onu geri almak imkânsız olabilir. 9. bölüm bize entegrasyon veri sözleşmesini verdi; taşıma planlaması sırasında o oklardan hangilerinin çalışabileceğine, hangilerinin bastırılacağına ve hangilerinin geçişten sonra bir eşitlemeyle değiştirileceğine karar verin. Bu karar geçiş planına aittir.

Türetilmiş Veri, Paylaşım ve Hazırlık Nesnesi

Toplamalar ve diğer türetilmiş değerler: bir üst kayıt yükleyin, sonra milyonlarca alt kayıt ve her alt kayıttan sonra yeniden hesaplayın? Belki. Çoğu zaman her şeyi yükleyip bir kez hesaplamak çok daha ucuzdur. Soru, türetilmiş sonucun taşıma sırasında kayıt kayıt sürdürülmesi mi gerektiği, yoksa bağımlı veri tamamlandıktan sonra mı kurulabileceğidir. Bu aynı gerekmez / benzet / ertele kararıdır.

Paylaşım da türetilmiş veridir. Kayıt oluşturmak ve aktarmak paylaşım kuralı hesaplamasını tetikler ve büyük bir yüklemede bu çok uzun değerlendirmeler veya zaman aşımları demek olabilir. Salesforce bir yöneticinin paylaşım hesaplamalarını ertelemesine (paylaşım kuralları ve grup üyeliği) ve sonra sürdürmesine izin verir, ama özellik varsayılan olarak açık değildir: Salesforce Destek etkinleştirir. Sürdürdüğünüzde tam bir yeniden hesaplama çalıştırmanız gerekir ve veri bütünlüğünü korumak için bazı paylaşım değişiklikleri yine anında hesaplanır (Defer Sharing Calculations (yeni sekmede açılır)). Bunu planlayın ve yeniden hesaplama süresini de planlayın.

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 (yeni sekmede açılır), 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. ⟲

Son Durum İçin Tasarlayın ve Yazın

Amaç “üretim otomasyonunu çalıştırmak” değil. Amaç doğru üretim durumuna ulaşmaktır ve bunlar aynı şey değil. Yeni bir hesap için normal işleme bir sınıflandırma türetir, bir hoş geldin görevi oluşturur, bir bildirim gönderir ve başka bir sisteme yayımlar. Taşınmış tarihsel bir hesap için doğru son durum şu olabilir: sınıflandırma evet, hoş geldin görevi hayır, hoş geldin bildirimi hayır, harici yayın belki, eşitleme planına bağlı olarak. Normal otomasyonu körü körüne çalıştırmak, taşıma için tasarlanmamış bir süreci yeniden üretir.

Ciddi bir taşıma için bunu bir otomasyon envanteri olarak yazın:

Otomasyon	Normal davranış	Taşıma kararı	Gerekli taşıma sonucu
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

Artık karar görünür: onu inceleyebilir, test edebilir, prova edebilir ve yüklemeden sonra doğrulayabiliriz.

Atlamayı Prova Edin, Sonra Yeniden Açın

Taşıma modunu ilk kez üretimde kullanmayın. Prova taşıma kimliğini, atlama kontrollerini, aktif kalan otomasyonları, benzetilen sonuçları, ertelenen süreçleri ve normal moda dönüşü test etmeli, sonra kontrol etmeli: olmaması gereken bir şey tetiklendi mi, olması gereken bir şey olmadı mı, son durum mimariyle eşleşiyor mu? Bu yüzden provanın gerçek otomasyon yapılandırmasına ya da ona mümkün olduğunca yakın bir şeye ihtiyacı vardır.

Yeniden etkinleştirmek bir geçiş adımıdır: açık, adı belli bir sahibi, beklenen bir süresi ve doğrulaması olan. “Flow’ları yeniden açmayı unutma” değil. Normal işleyiş geri getirilip doğrulanana kadar sistem kullanıcılara hazır değildir (modül 4 bunu çalıştırma kılavuzuna koyar).

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

Yapay Zekâ Atlama Tasarımını Daha Önemli Kılar

Şimdi yeni bir vakaya, değişmiş bir hesaba, yayımlanmış bir olaya veya kuyruktaki bir göreve tepki veren ajanları ekleyin. Bir taşıma makine ölçeğinde veri kalıpları yaratır; ajanların taşınan her kayda tepki vermesini istiyor muyuz? Muhtemelen kazara değil. Ajanların tetiklediği süreçler, flow’lar, tetikleyiciler, bildirimler, entegrasyonlar ve olaylarla aynı envantere aittir ve taşıma bağlamı onları bastırmalıysa bunu bilinçli olarak tasarlayın.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Ajanlar başka türden bir yan etkidir; taşınan veriye özerk olarak tepki verebilirler. Ajanların tetiklediği eylemleri diğer otomasyonlar gibi ele alın: çalıştırılacaklarına, benzetileceklerine, erteleneceklerine veya bastırılacaklarına karar verin ve kararı provada test edin.

Mimarın Burada Karar Verdikleri

• Taşınan her veri sınıfı için hangi otomasyonların çalıştığı, gerekmediği, benzetildiği veya ertelendiği; birini kapatmanın onun iş mantığını üstlenmek demek olduğunu bilerek.
• Hangi doğrulama kurallarının kalıcı veri gerçeğini temsil ettiği ve hangilerinin taşımaya özgü ele alınması gereken güncel süreç kuralları olduğu.
• 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. ⟲
• Türetilmiş verinin, paylaşım yeniden hesaplamasının ve yavaş platform mantığının nasıl ele alındığı: yüklemeden sonra, ertelenerek ya da bir hazırlık nesnesi aracılığıyla.
• Hangi harici yan etkilerin ve entegrasyonların bastırıldığı veya bilinçli olarak yetiştirildiği ve prova ile geçişin normal otomasyonun güvenle geri getirildiğini nasıl kanıtladığı.

Bir Karar Hâline Getirin

Taşıma, her flow çalıştığı, her tetikleyici ateşlendiği ve her doğrulama kuralı yürütüldüğü için başarılı değildir. Bu normal işlem davranışıdır ve taşımanın farklı bir işi var: veriyi yeni mimariye taşımak, önemli gerçekleri korumak, ihtiyaç duyduğumuz türetilmiş değerleri oluşturmak, yanlış yan etkilerden kaçınmak, sistemi kontrol edilebilir tutmak, sonra onu normale döndürmek. Her otomasyon için: gerekmez, benzet, ertele ya da bilinçli olarak çalışmasına izin ver. Ama bunu bir karar hâline getirin. Beş milyon kaydın sizin yerinize karar vermesine izin vermeyin.

Daha Fazlası

• Salesforce Help, Defer Sharing Calculations (yeni sekmede açılır) and Workflow Rules & Process Builder End of Support (yeni sekmede açılır), checked 2026-11-01. ⟲
• Salesforce Help, Define Custom Settings (yeni sekmede açılır), Global Variables Resource (yeni sekmede açılır) (Flow) and How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (yeni sekmede açılır); Apex Reference Guide, FeatureManagement Class (yeni sekmede açılır), Custom Settings Methods (yeni sekmede açılır) and Custom Metadata Type Methods (yeni sekmede açılır), Winter ‘27; all checked 2026-11-01. ⟲
• Salesforce Architects, decision guide, Record-Triggered Automation (yeni sekmede açılır) (“Bypassing Automation”), checked 2026-11-01. ⟲
• Salesforce Architects, Well-Architected, Automation Patterns (yeni sekmede açılır) and Resource and Cost Optimization (yeni sekmede açılır), checked 2026-11-01. ⟲
• Salesforce, Apex Developer Guide, Execution Governors and Limits (yeni sekmede açılır), Winter ‘27 (API version 68.0), and Change Data Capture Developer Guide, Change Data Capture Allocations (yeni sekmede açılır), checked 2026-11-01. ⟲
• Bu kursta: Entegrasyon ve Veri Hareketi (entegrasyon veri sözleşmesi) ve Ölçek İçin Tasarlamak.