L'automazione durante il caricamento

🌐 Disponibile anche in 19 lingue

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

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese Questa sezione è cambiata in inglese e non è ancora stata tradotta di nuovo. (61)

Modulo 3 di 5 del capitolo Migrazione e sincronizzazione, capitolo 10 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Caricare ad alto volume · Successivo: Il fine settimana di cutover

La domanda a cui risponde questo modulo: Cosa deve succedere all’automazione di Salesforce mentre si caricano i dati della migrazione?

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

Clicca per ingrandire

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

L’automazione non sa che è una migrazione

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

Quindi, per una migrazione importante, parto da qui: l’automazione di business normale non deve girare alla cieca sul caricamento. Non significa “spegni tutto”. Significa che ogni automazione importante riceve una decisione voluta, e non voglio scoprire la risposta perché la produzione ha inviato 400.000 email.

Tre scelte: non serve, simulala, rimandala

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

Non serve (eliminala). Il comportamento non deve avvenire per i record migrati. Clienti che abbiamo da otto anni non hanno bisogno di “Benvenuto nella nostra azienda!”. Inserisci un account, invia un’email; carica un milione di account, e non mi serve un milione di email.

Simulala. L’automazione non deve girare, ma il risultato che produce serve comunque. Un flow alla creazione dell’account ricava il segmento cliente. Gli account migrati hanno bisogno di un segmento valido, ma eseguire l’intero flow cinque milioni di volte è costoso o ha effetti collaterali. Quindi calcoliamo il segmento nella trasformazione e carichiamo il risultato. Non abbiamo ignorato la regola di business; abbiamo fatto il lavoro dell’automazione nel caricamento.

Rimandala. Il risultato serve, ma non dentro la transazione di caricamento. Carica con l’automazione spenta e un indicatore impostato, poi attiva un processo batch per recuperare: ricalcolare, creare i record dipendenti, pubblicare ciò di cui hanno bisogno i sistemi a valle. Rimandare può rendere il caricamento più veloce e più controllabile senza rinunciare al risultato.

E a volte la lasci accesa. Per un caricamento più piccolo in cui il business vuole che giri il suo processo normale, lascia che il sistema faccia ciò che fa. Anche questa è una scelta, purché sia una scelta.

Qualunque cosa tu scelga, questa è la regola che insegno: ogni volta che spegni un’automazione, ti prendi la piena responsabilità di quella logica di business che non succede. Devi capire ogni automazione prima di decidere.

Clicca per ingrandire

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

“Disattivare l’automazione” non è tutta la strategia

Il piano dice “disattivare l’automazione”. Quale automazione? Come, chi, quando? Come sappiamo che è spenta, e come sappiamo che è stata riaccesa? Quali risultati che produce normalmente devono comunque esistere dopo? Cosa succede se gli utenti sono nel sistema mentre è spenta, o se la migrazione fallisce a metà? Spegnere qualcosa è un’azione operativa. L’architettura ha bisogno dell’intero ciclo di vita: stato normale, stato di migrazione, ritorno alla normalità, e la prova che ci siamo tornati.

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” (Fine del supporto di Regole di flusso di lavoro e Process Builder (si apre in una nuova scheda), 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 (si apre in una nuova scheda), 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

La mia posizione più forte: un’automazione importante deve avere un bypass controllato anche quando non è prevista alcuna migrazione. La migrazione non è l’unico motivo per cui te ne servirà uno. Grandi correzioni, rettifiche di dati, backfill, riparazioni di integrazioni, ripristini d’emergenza: a volte devi eseguire un’operazione controllata senza ogni pezzo dell’automazione normale. Se l’unico modo è modificare il flow in produzione, disattivare il trigger o eliminare una regola di convalida, abbiamo reso il lavoro operativo inutilmente pericoloso. E non puoi semplicemente spegnere un trigger in produzione: è un deployment, con i suoi test.

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 (si apre in una nuova scheda), 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 (si apre in una nuova scheda), 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 (si apre in una nuova scheda), 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 (si apre in una nuova scheda)), and FeatureManagement.checkPermission “checks whether a custom permission is enabled” (FeatureManagement Class (si apre in una nuova scheda); 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 (si apre in una nuova scheda), Apex Reference Guide, checked 2026-10-27). ⟲

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

Clicca per ingrandire

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 (si apre in una nuova scheda), 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 (si apre in una nuova scheda), 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 (si apre in una nuova scheda), 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). ⟲

Un bypass non è “salta tutto”

Un bypass non significa che l’utente di migrazione ignori ogni regola di Salesforce. Un’automazione va bypassata, un’altra deve comunque girare; una regola di convalida che protegge un invariante fondamentale conta ancora, una notifica no; un’integrazione a valle va soppressa, una relazione obbligatoria va comunque verificata. Quindi voglio bypass intenzionali e circoscritti, non Migration_Mode__c = true, quindi niente conta più. Il percorso di migrazione ha ancora delle regole, solo quelle adatte alla migrazione.

E il bypass deve rappresentare un contesto operativo, non un incidente. Un’identità dedicata alla migrazione (modulo 2), un’autorizzazione personalizzata, metadati di configurazione, un feature flag, o una combinazione, possono riconoscere il lavoro di migrazione approvato. L’identità può far parte del controllo, ma non voglio ogni automazione codificata su User.Name = 'Migration User'. È fragile. Esprimi l’intenzione: se è un’operazione di migrazione approvata, salta questo effetto collaterale.

Le regole di convalida richiedono giudizio

“La data di chiusura è obbligatoria quando un’opportunità è chiusa e vinta” è un vero invariante dei dati; tienilo per le opportunità storiche. Una regola che impone un campo del processo attuale introdotto tre anni fa è diversa: i record di dieci anni fa non l’hanno mai avuto, e inventare un valore peggiora i dati. La domanda non è “spegniamo le regole di convalida?”. È quali regole rappresentano una verità duratura dei dati, e quali il processo interattivo di oggi? È una domanda da architetto dei dati.

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

Il segnale d’allarme da tenere d’occhio: la destinazione richiede un valore, la sorgente non ce l’ha, quindi “mettiamo ‘Sconosciuto’ dappertutto”. Se Sconosciuto è un valore approvato che descrive davvero lo stato, va bene. Se inseriamo valori falsi per passare la convalida, stiamo corrompendo i dati per accontentare l’applicazione. Preferisco progettare un’eccezione di migrazione, un campo storico che accetta valori vuoti, una regola di trasformazione o un valore di stato legacy, piuttosto che fingere di sapere qualcosa che non sappiamo.

L’automazione moltiplica il Numero di Zeri

Carica 2 milioni di account; l’automazione crea 2 attività ciascuno: 4 milioni di attività. Voluto o un incidente? Poi ogni attività attiva un altro flow, l’automazione dell’account aggiorna un padre, pubblica un evento, ricalcola qualcos’altro. Le prestazioni di una migrazione non sono la velocità con cui la Bulk API inserisce account. Il vero carico di lavoro è il grafo di transazioni che quegli inserimenti creano. Il Numero di Zeri si moltiplica attraverso l’automazione.

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

Clicca per ingrandire

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 (si apre in una nuova scheda), 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. ⟲

Clicca per ingrandire

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

Gli effetti collaterali esterni sono peggio. Email ai clienti, richieste di fatturazione, eventi consumati da sistemi di produzione, chiamate all’ERP, ticket di supporto, aggiornamenti di marketing: quei sistemi non sanno che sono dati di migrazione, e una volta che il messaggio ha lasciato Salesforce, annullarlo può essere impossibile. Il capitolo 9 ci ha dato il contratto dati dell’integrazione; durante la pianificazione della migrazione, decidi quali di quelle frecce possono operare, quali vengono soppresse e quali vengono sostituite da una sincronizzazione dopo il cutover. Quella decisione appartiene al piano di cutover.

Dati derivati, condivisione e l’oggetto di staging

Roll-up e altri valori derivati: caricare un padre, poi milioni di figli, e ricalcolare dopo ogni figlio? Forse. Spesso è molto più economico caricare tutto e calcolare una volta. La domanda è se il risultato derivato debba essere mantenuto record per record durante la migrazione, o possa essere stabilito quando i dati dipendenti sono completi. È la stessa decisione: non serve, simula, rimanda.

Anche la condivisione è un dato derivato. Creare e trasferire record attiva il calcolo delle regole di condivisione, e su un grande caricamento questo può significare valutazioni lunghissime o timeout. Salesforce permette a un amministratore di rimandare i calcoli di condivisione (regole di condivisione e appartenenza ai gruppi) e di riprenderli dopo, ma la funzionalità non è attiva per impostazione predefinita: la attiva l’assistenza Salesforce. Alla ripresa devi eseguire un ricalcolo completo, e alcune modifiche di condivisione vengono comunque calcolate subito per proteggere l’integrità dei dati (Defer Sharing Calculations (si apre in una nuova scheda)). Pianificalo, e pianifica il tempo del ricalcolo.

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 (si apre in una nuova scheda), 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. ⟲

Progetta per lo stato finale, e mettilo per iscritto

L’obiettivo non è “eseguire l’automazione di produzione”. È arrivare allo stato di produzione corretto, e non sono la stessa cosa. L’elaborazione normale di un nuovo account ricava una classificazione, crea un’attività di onboarding, invia una notifica e pubblica verso un altro sistema. Per un account storico migrato, lo stato finale giusto può essere: classificazione sì, attività di onboarding no, notifica di benvenuto no, pubblicazione esterna forse, a seconda del piano di sincronizzazione. Eseguire alla cieca l’automazione normale riproduce un processo che non è stato progettato per la migrazione.

Per una migrazione seria, mettilo per iscritto come inventario dell’automazione:

Automazione	Comportamento normale	Decisione di migrazione	Risultato di migrazione richiesto
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

Ora la decisione è visibile: possiamo rivederla, testarla, provarla e verificarla dopo il caricamento.

Prova il bypass, poi riaccendi

Non fare della produzione il primo utilizzo della modalità migrazione. La prova deve testare l’identità di migrazione, i controlli di bypass, le automazioni che restano attive, i risultati simulati, i processi rimandati e il ritorno alla modalità normale, poi verificare: si è attivato qualcosa che non doveva, non è successo qualcosa che doveva, lo stato finale corrisponde all’architettura? Per questo la prova ha bisogno della vera configurazione dell’automazione, o di una il più vicina possibile.

Riaccendere è un passaggio del cutover: esplicito, con un responsabile nominato, un orario previsto e una verifica. Non “ricordatevi di riaccendere i flow”. Il sistema non è pronto per gli utenti finché il funzionamento normale non è ripristinato e verificato (il modulo 4 lo mette nel 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. ⟲

L’IA rende più importante la progettazione dei bypass

Ora aggiungi agenti che reagiscono a un nuovo caso, a un account modificato, a un evento pubblicato o a un’attività in una coda. Una migrazione crea schemi di dati su scala di macchina; vogliamo che gli agenti reagiscano a ogni record migrato? Probabilmente non per caso. I processi attivati dagli agenti appartengono allo stesso inventario di flow, trigger, notifiche, integrazioni ed eventi, e se il contesto di migrazione deve sopprimerli, progettalo di proposito.

Oltre l’esame: cosa cambia l’IA. Gli agenti sono un altro tipo di effetto collaterale, uno che può reagire in autonomia ai dati migrati. Tratta le azioni attivate dagli agenti come qualsiasi altra automazione: decidi se eseguirle, simularle, rimandarle o sopprimerle, e testa la decisione nella prova.

Cosa decide qui un architetto

• Quali automazioni girano, non servono, vengono simulate o rimandate per ogni categoria di dati migrati, sapendo che spegnerne una significa rispondere della sua logica di business.
• Quali regole di convalida rappresentano una verità duratura dei dati, e quali regole del processo attuale hanno bisogno di un trattamento specifico per la migrazione.
• 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. ⟲
• Come vengono gestiti dati derivati, ricalcolo della condivisione e logica lenta della piattaforma: dopo il caricamento, rimandati, o tramite un oggetto di staging.
• Quali effetti collaterali esterni e quali integrazioni vengono soppressi o recuperati di proposito, e come prova e cutover dimostrano che l’automazione normale è stata ripristinata in sicurezza.

Fanne una decisione

La migrazione non ha successo perché ogni flow è girato, ogni trigger è scattato e ogni regola di convalida è stata eseguita. Quello è il normale comportamento transazionale, e la migrazione ha un altro compito: portare i dati nella nuova architettura, preservare le verità che contano, creare i valori derivati che ci servono, evitare falsi effetti collaterali, mantenere il sistema controllabile, poi riportarlo alla normalità. Per ogni automazione: non serve, simulala, rimandala, o lasciala girare di proposito. Ma fanne una decisione. Non lasciare che la prendano cinque milioni di record al posto tuo.

Per approfondire

• Salesforce Help, Defer Sharing Calculations (si apre in una nuova scheda) and Fine del supporto di Regole di flusso di lavoro e Process Builder (si apre in una nuova scheda), checked 2026-11-01. ⟲
• Salesforce Help, Define Custom Settings (si apre in una nuova scheda), Global Variables Resource (si apre in una nuova scheda) (Flow) and How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (si apre in una nuova scheda); Apex Reference Guide, FeatureManagement Class (si apre in una nuova scheda), Custom Settings Methods (si apre in una nuova scheda) and Custom Metadata Type Methods (si apre in una nuova scheda), Winter ‘27; all checked 2026-11-01. ⟲
• Salesforce Architects, decision guide, Record-Triggered Automation (si apre in una nuova scheda) (“Bypassing Automation”), checked 2026-11-01. ⟲
• Salesforce Architects, Well-Architected, Automation Patterns (si apre in una nuova scheda) and Resource and Cost Optimization (si apre in una nuova scheda), checked 2026-11-01. ⟲
• Salesforce, Apex Developer Guide, Execution Governors and Limits (si apre in una nuova scheda), Winter ‘27 (API version 68.0), and Change Data Capture Developer Guide, Change Data Capture Allocations (si apre in una nuova scheda), checked 2026-11-01. ⟲
• In questo corso: Integrazione e movimento dei dati (il contratto dati dell’integrazione) e Progettare per la scala.