Automatisierung während des Ladens

🌐 Auch in 19 Sprachen

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

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen Dieser Abschnitt hat sich im Englischen geändert und wurde noch nicht neu übersetzt. (61)

Modul 3 von 5 im Kapitel Migration und Synchronisierung, Kapitel 10 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Laden bei hohem Volumen · Weiter: Das Umstellungswochenende

Die Frage, die dieses Modul beantwortet: Was sollte mit der Salesforce-Automatisierung passieren, während Migrationsdaten geladen werden?

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

Zum Vergrößern klicken

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

Die Automatisierung weiß nicht, dass es eine Migration ist

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

Für eine größere Migration beginne ich also hiermit: Normale Geschäftsautomatisierung sollte nicht blind gegen den Ladevorgang laufen. Das heißt nicht „alles ausschalten“. Es heißt, dass jede wichtige Automatisierung eine bewusste Entscheidung bekommt, und ich will die Antwort nicht entdecken, weil die Produktion 400.000 E-Mails verschickt hat.

Drei Möglichkeiten: nicht gebraucht, simulieren, zurückstellen

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

Nicht gebraucht (entfernen). Das Verhalten sollte für migrierte Datensätze nicht stattfinden. Kunden, die wir seit acht Jahren haben, brauchen kein „Willkommen in unserem Unternehmen!“. Fügen Sie einen Account ein, er sendet eine E-Mail; laden Sie eine Million Accounts, und ich brauche keine Million E-Mails.

Simulieren. Die Automatisierung sollte nicht laufen, aber das Ergebnis, das sie erzeugt, wird trotzdem gebraucht. Ein Flow beim Anlegen eines Accounts leitet das Kundensegment ab. Migrierte Accounts brauchen ein gültiges Segment, aber den ganzen Flow fünf Millionen Mal auszuführen, ist teuer oder hat Nebenwirkungen. Also berechnen wir das Segment in der Transformation und laden das Ergebnis. Wir haben die Geschäftsregel nicht ignoriert; wir haben die Arbeit der Automatisierung im Ladevorgang erledigt.

Zurückstellen. Das Ergebnis wird gebraucht, aber nicht innerhalb der Ladetransaktion. Laden Sie mit ausgeschalteter Automatisierung und gesetztem Kennzeichen, und stoßen Sie dann einen Batch-Prozess an, der nachholt: neu berechnen, abhängige Datensätze anlegen, veröffentlichen, was nachgelagerte Systeme brauchen. Zurückstellen kann das Laden schneller und besser steuerbar machen, ohne das Ergebnis aufzugeben.

Und manchmal lassen Sie sie an. Bei einem kleineren Ladevorgang, bei dem das Geschäft will, dass sein normaler Prozess läuft, lassen Sie das System tun, was es tut. Auch das ist eine Entscheidung, solange es eine Entscheidung ist.

Was Sie auch wählen, das ist die Regel, die ich lehre: Jedes Mal, wenn Sie eine Automatisierung ausschalten, übernehmen Sie die volle Verantwortung dafür, dass diese Geschäftslogik nicht passiert. Sie müssen jede Automatisierung verstehen, bevor Sie entscheiden.

Zum Vergrößern klicken

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

„Automatisierung deaktivieren“ ist nicht die ganze Strategie

Der Plan sagt „Automatisierung deaktivieren“. Welche Automatisierung? Wie, wer, wann? Woher wissen wir, dass sie aus ist, und woher, dass sie wieder an ist? Welche Ergebnisse, die sie normalerweise erzeugt, müssen danach trotzdem existieren? Was passiert, wenn Benutzer im System sind, während sie aus ist, oder die Migration auf halbem Weg scheitert? Etwas auszuschalten ist eine operative Handlung. Die Architektur braucht den ganzen Lebenszyklus: Normalzustand, Migrationszustand, Rückkehr zum Normalbetrieb und den Beweis, dass wir zurückgekehrt sind.

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” (Ende der Unterstützung für Workflow-Regeln und Prozessgenerator (öffnet in einem neuen Tab), 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 (öffnet in einem neuen Tab), 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

Meine stärkere Position: Wichtige Automatisierung sollte eine kontrollierte Umgehung haben, auch wenn keine Migration geplant ist. Migration ist nicht der einzige Grund, warum Sie eine brauchen werden. Große Nachbesserungen, Datenkorrekturen, Nachbefüllungen, Reparaturen an Integrationen, Notfallwiederherstellung: Manchmal müssen Sie eine kontrollierte Operation ohne jedes Stück normaler Automatisierung ausführen. Wenn der einzige Weg ist, den Flow in der Produktion zu bearbeiten, den Trigger zu deaktivieren oder eine Validierungsregel zu löschen, haben wir operative Arbeit unnötig gefährlich gemacht. Und einen Trigger können Sie in der Produktion nicht einfach ausschalten: Das ist ein Deployment, mit seinen Tests.

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 (öffnet in einem neuen Tab), 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 (öffnet in einem neuen Tab), 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 (öffnet in einem neuen Tab), 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 (öffnet in einem neuen Tab)), and FeatureManagement.checkPermission “checks whether a custom permission is enabled” (FeatureManagement Class (öffnet in einem neuen Tab); 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 (öffnet in einem neuen Tab), Apex Reference Guide, checked 2026-10-27). ⟲

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

Zum Vergrößern klicken

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 (öffnet in einem neuen Tab), 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 (öffnet in einem neuen Tab), 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 (öffnet in einem neuen Tab), 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). ⟲

Eine Umgehung ist nicht „alles überspringen“

Eine Umgehung heißt nicht, dass der Migrationsbenutzer jede Regel in Salesforce ignoriert. Eine Automatisierung soll umgangen werden, eine andere muss trotzdem laufen; eine Validierungsregel, die eine grundlegende Invariante schützt, zählt weiterhin, eine Benachrichtigung nicht; eine nachgelagerte Integration muss unterdrückt werden, eine Pflichtbeziehung muss trotzdem geprüft werden. Ich will also Umgehungen, die beabsichtigt und begrenzt sind, nicht Migration_Mode__c = true, also zählt nichts mehr. Der Migrationsweg hat weiterhin Regeln, nur die für die Migration passenden.

Und die Umgehung sollte einen operativen Kontext darstellen, keinen Zufall. Eine eigene Migrationsidentität (Modul 2), eine benutzerdefinierte Berechtigung, Konfigurationsmetadaten, ein Feature-Flag oder eine Kombination davon können genehmigte Migrationsarbeit erkennen. Die Identität kann Teil der Kontrolle sein, aber ich will nicht, dass jede Automatisierung fest auf User.Name = 'Migration User' codiert ist. Das ist brüchig. Drücken Sie die Absicht aus: Wenn das eine genehmigte Migrationsoperation ist, überspringe diese Nebenwirkung.

Validierungsregeln brauchen Urteilsvermögen

„Das Abschlussdatum ist erforderlich, wenn eine Opportunity gewonnen ist“ ist eine echte Dateninvariante; behalten Sie sie für historische Opportunities. Eine Regel, die ein vor drei Jahren eingeführtes Feld des aktuellen Prozesses erzwingt, ist etwas anderes: Datensätze von vor zehn Jahren hatten es nie, und einen Wert zu erfinden macht die Daten schlechter. Die Frage lautet nicht „Schalten wir Validierungsregeln aus?“ Sie lautet: Welche Regeln stehen für eine dauerhafte Wahrheit der Daten, und welche für den interaktiven Prozess von heute? Das ist eine Frage der Datenarchitektur.

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

Das Warnzeichen, auf das Sie achten sollten: Das Ziel verlangt einen Wert, die Quelle hat ihn nicht, also „setzen wir einfach überall ‚Unbekannt‘ ein“. Wenn Unbekannt ein genehmigter Wert ist, der den Zustand wirklich beschreibt, gut. Wenn wir falsche Werte einfügen, um an der Validierung vorbeizukommen, verfälschen wir die Daten, um die Anwendung zufriedenzustellen. Ich entwerfe lieber eine Migrationsausnahme, ein historisches Feld, das leer sein darf, eine Transformationsregel oder einen Wert für einen Altzustand, als so zu tun, als wüssten wir etwas, das wir nicht wissen.

Automatisierung vervielfacht die Anzahl der Nullen

Laden Sie 2 Millionen Accounts; die Automatisierung legt je 2 Aufgaben an: 4 Millionen Aufgaben. Beabsichtigt oder ein Versehen? Dann startet jede Aufgabe einen weiteren Flow, die Account-Automatisierung aktualisiert einen Elterndatensatz, veröffentlicht ein Ereignis, berechnet etwas anderes neu. Die Leistung einer Migration ist nicht, wie schnell die Bulk API Accounts einfügt. Die echte Arbeitslast ist der Transaktionsgraph, den diese Einfügungen erzeugen. Die Anzahl der Nullen vervielfacht sich durch Automatisierung.

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

Zum Vergrößern klicken

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 (öffnet in einem neuen Tab), 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. ⟲

Zum Vergrößern klicken

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

Externe Nebenwirkungen sind schlimmer. E-Mails an Kunden, Abrechnungsanfragen, Ereignisse, die von Produktionssystemen verbraucht werden, ERP-Aufrufe, Supporttickets, Marketingaktualisierungen: Diese Systeme wissen nicht, dass es Migrationsdaten sind, und sobald die Nachricht Salesforce verlassen hat, ist das Rückgängigmachen vielleicht unmöglich. Kapitel 9 hat uns den Integrations-Datenvertrag gegeben; entscheiden Sie während der Migrationsplanung, welche dieser Pfeile arbeiten dürfen, welche unterdrückt werden und welche nach der Umstellung durch eine Synchronisierung ersetzt werden. Diese Entscheidung gehört in den Umstellungsplan.

Abgeleitete Daten, Freigabe und das Staging-Objekt

Rollups und andere abgeleitete Werte: einen Elterndatensatz laden, dann Millionen Kinder, und nach jedem Kind neu berechnen? Vielleicht. Oft ist es viel günstiger, alles zu laden und einmal zu berechnen. Die Frage ist, ob das abgeleitete Ergebnis während der Migration Datensatz für Datensatz gepflegt werden muss oder festgelegt werden kann, wenn die abhängigen Daten vollständig sind. Das ist dieselbe Entscheidung: nicht gebraucht, simulieren, zurückstellen.

Auch die Freigabe sind abgeleitete Daten. Das Anlegen und Übertragen von Datensätzen löst die Berechnung von Freigaberegeln aus, und bei einem großen Ladevorgang kann das sehr lange Auswertungen oder Zeitüberschreitungen bedeuten. Salesforce lässt eine Administratorin Freigabeberechnungen zurückstellen (Freigaberegeln und Gruppenmitgliedschaft) und danach fortsetzen, aber die Funktion ist nicht standardmäßig aktiv: Der Salesforce-Support aktiviert sie. Beim Fortsetzen müssen Sie eine vollständige Neuberechnung ausführen, und manche Freigabeänderungen werden zum Schutz der Datenintegrität trotzdem sofort berechnet (Defer Sharing Calculations (öffnet in einem neuen Tab)). Planen Sie es, und planen Sie die Zeit für die Neuberechnung.

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 (öffnet in einem neuen Tab), 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. ⟲

Entwerfen Sie für den Endzustand, und schreiben Sie ihn auf

Das Ziel ist nicht „Produktionsautomatisierung laufen lassen“. Es ist, beim richtigen Produktionszustand anzukommen, und das ist nicht dasselbe. Die normale Verarbeitung für einen neuen Account leitet eine Klassifizierung ab, legt eine Onboarding-Aufgabe an, sendet eine Benachrichtigung und veröffentlicht an ein anderes System. Für einen migrierten historischen Account kann der richtige Endzustand sein: Klassifizierung ja, Onboarding-Aufgabe nein, Willkommensbenachrichtigung nein, externe Veröffentlichung vielleicht, je nach Synchronisierungsplan. Normale Automatisierung blind laufen zu lassen, reproduziert einen Prozess, der nicht für die Migration entworfen wurde.

Für eine ernsthafte Migration schreiben Sie es als Automatisierungsinventar auf:

Automatisierung	Normales Verhalten	Migrationsentscheidung	Erforderliches Migrationsergebnis
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

Jetzt ist die Entscheidung sichtbar: Wir können sie prüfen, testen, proben und nach dem Laden überprüfen.

Proben Sie die Umgehung, dann schalten Sie wieder ein

Machen Sie die Produktion nicht zum ersten Einsatz des Migrationsmodus. Die Probe sollte die Migrationsidentität, die Umgehungskontrollen, die aktiv bleibenden Automatisierungen, die simulierten Ergebnisse, die zurückgestellten Prozesse und die Rückkehr in den Normalmodus testen und dann prüfen: Ist etwas gestartet, das nicht hätte starten sollen, ist etwas nicht passiert, das hätte passieren sollen, entspricht der Endzustand der Architektur? Deshalb braucht die Probe die echte Automatisierungskonfiguration oder eine, die so nah wie praktikabel daran ist.

Das Wiedereinschalten ist ein Umstellungsschritt: ausdrücklich, mit einer benannten verantwortlichen Person, einer erwarteten Zeit und einer Überprüfung. Nicht „Denkt daran, die Flows wieder einzuschalten“. Das System ist nicht bereit für Benutzer, bis der Normalbetrieb wiederhergestellt und überprüft ist (Modul 4 nimmt das ins Runbook auf).

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

KI macht den Entwurf von Umgehungen wichtiger

Jetzt kommen Agenten dazu, die auf einen neuen Kundenvorgang, einen geänderten Account, ein veröffentlichtes Ereignis oder eine Aufgabe in einer Warteschlange reagieren. Eine Migration erzeugt Datenmuster im Maschinenmaßstab; wollen wir, dass Agenten auf jeden migrierten Datensatz reagieren? Wahrscheinlich nicht aus Versehen. Von Agenten ausgelöste Prozesse gehören in dasselbe Inventar wie Flows, Trigger, Benachrichtigungen, Integrationen und Ereignisse, und wenn der Migrationskontext sie unterdrücken soll, entwerfen Sie das bewusst.

Über die Prüfung hinaus: Was KI ändert. Agenten sind eine weitere Art von Nebenwirkung, eine, die selbstständig auf migrierte Daten reagieren kann. Behandeln Sie von Agenten ausgelöste Aktionen wie jede andere Automatisierung: Entscheiden Sie, ob sie laufen, simuliert, zurückgestellt oder unterdrückt werden, und testen Sie die Entscheidung in der Probe.

Was Architekt:innen hier entscheiden

• Welche Automatisierungen für jede Klasse migrierter Daten laufen, nicht gebraucht, simuliert oder zurückgestellt werden, im Wissen, dass das Ausschalten einer Automatisierung heißt, für ihre Geschäftslogik verantwortlich zu sein.
• Welche Validierungsregeln für eine dauerhafte Wahrheit der Daten stehen und welche Regeln des aktuellen Prozesses eine migrationsspezifische Behandlung brauchen.
• 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. ⟲
• Wie abgeleitete Daten, die Neuberechnung der Freigabe und langsame Plattformlogik behandelt werden: nach dem Laden, zurückgestellt oder über ein Staging-Objekt.
• Welche externen Nebenwirkungen und Integrationen unterdrückt oder bewusst nachgeholt werden, und wie Probe und Umstellung beweisen, dass die normale Automatisierung sicher wiederhergestellt wurde.

Machen Sie es zu einer Entscheidung

Die Migration ist nicht erfolgreich, weil jeder Flow lief, jeder Trigger startete und jede Validierungsregel ausgewertet wurde. Das ist normales Transaktionsverhalten, und Migration hat eine andere Aufgabe: die Daten in die neue Architektur bringen, die Wahrheiten bewahren, die zählen, die abgeleiteten Werte erzeugen, die wir brauchen, falsche Nebenwirkungen vermeiden, das System steuerbar halten und es dann in den Normalbetrieb zurückbringen. Für jede Automatisierung: nicht gebraucht, simulieren, zurückstellen oder bewusst laufen lassen. Aber machen Sie es zu einer Entscheidung. Lassen Sie nicht fünf Millionen Datensätze sie für Sie treffen.

Weiterlesen

• Salesforce Help, Defer Sharing Calculations (öffnet in einem neuen Tab) and Ende der Unterstützung für Workflow-Regeln und Prozessgenerator (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Salesforce Help, Define Custom Settings (öffnet in einem neuen Tab), Global Variables Resource (öffnet in einem neuen Tab) (Flow) and How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (öffnet in einem neuen Tab); Apex Reference Guide, FeatureManagement Class (öffnet in einem neuen Tab), Custom Settings Methods (öffnet in einem neuen Tab) and Custom Metadata Type Methods (öffnet in einem neuen Tab), Winter ‘27; all checked 2026-11-01. ⟲
• Salesforce Architects, decision guide, Record-Triggered Automation (öffnet in einem neuen Tab) (“Bypassing Automation”), checked 2026-11-01. ⟲
• Salesforce Architects, Well-Architected, Automation Patterns (öffnet in einem neuen Tab) and Resource and Cost Optimization (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• Salesforce, Apex Developer Guide, Execution Governors and Limits (öffnet in einem neuen Tab), Winter ‘27 (API version 68.0), and Change Data Capture Developer Guide, Change Data Capture Allocations (öffnet in einem neuen Tab), checked 2026-11-01. ⟲
• In diesem Kurs: Integration und Datenbewegung (der Integrations-Datenvertrag) und Für Skalierung entwerfen.