A automação durante a carga

🌐 Também em 19 idiomas

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

Imagem gerada com IA

Traduzido com IA. Ainda não revisto pela comunidade. Ler em inglês Esta secção mudou em inglês e ainda não foi traduzida de novo. (61)

Módulo 3 de 5 do capítulo Migração e sincronização, capítulo 10 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Carregar com volume · Próximo: O fim de semana da transição

A pergunta que este módulo responde: O que deveria acontecer com a automação do Salesforce enquanto os dados da migração estão a ser carregados?

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

Clique para ampliar

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

A automação não sabe que é uma migração

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

Então, numa migração grande, parto disto: a automação normal de negócio não deveria correr às cegas contra a carga. Isso não significa “desligue tudo”. Significa que cada automação importante recebe uma decisão deliberada, e não quero descobrir a resposta porque a produção mandou 400.000 e-mails.

Três escolhas: não precisa, simule, adie

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

Não precisa (elimine). O comportamento não deveria acontecer para os registos migrados. Clientes que temos há oito anos não precisam de um “Bem-vindo à nossa empresa!”. Insira uma conta e ela envia um e-mail; carregue um milhão de contas, e eu não preciso de um milhão de e-mails.

Simule. A automação não deveria correr, mas o resultado que ela cria continua a ser necessário. Um flow na criação da conta deriva o segmento do cliente. As contas migradas precisam de um segmento válido, mas correr o flow inteiro cinco milhões de vezes é caro ou tem efeitos colaterais. Então calculamos o segmento na transformação e carregamos o resultado. Não ignoramos a regra de negócio; fizemos o trabalho da automação na carga.

Adie. O resultado é necessário, mas não dentro da transação de carga. Carregue com a automação desligada e uma marca definida, depois dispare um processo em lote para pôr em dia: recalcular, criar os registos dependentes, publicar o que os sistemas posteriores precisam. Adiar pode tornar a carga mais rápida e mais controlável sem abrir mão do resultado.

E às vezes a deixa ligada. Numa carga menor, em que o negócio quer que o seu processo normal corra, deixe o sistema fazer o que ele faz. Isso também é uma escolha, desde que seja uma escolha.

Seja qual for a escolha, esta é a regra que eu ensino: sempre que desliga uma automação, assume toda a responsabilidade por aquela lógica de negócio não acontecer. Precisa de entender cada automação antes de decidir.

Clique para ampliar

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

“Desativar a automação” não é a estratégia inteira

O plano diz “desativar a automação”. Qual automação? Como, quem, quando? Como sabemos que está desligada, e como sabemos que voltou a ligar? Quais resultados que ela normalmente produz ainda precisam de existir depois? O que acontece se houver utilizadores no sistema enquanto ela está desligada, ou se a migração falhar no meio? Desligar algo é uma ação operacional. A arquitetura precisa do ciclo de vida inteiro: estado normal, estado de migração, volta ao normal e a prova de que voltamos.

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” (Fim do suporte ao Criador de processos e às Regras de fluxo de trabalho (abre num novo separador), 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 (abre num novo separador), 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

A minha posição mais forte: a automação importante deveria ter um bypass controlado mesmo quando nenhuma migração está planeada. A migração não é o único motivo de si precisar de um. Grandes correções, ajustes de dados, preenchimentos retroativos, reparo de integrações, recuperação de emergência: às vezes precisa de executar uma operação controlada sem cada peça da automação normal. Se o único forma é editar o flow em produção, desativar o trigger ou eliminar uma regra de validação, tornamos o trabalho operacional perigoso sem necessidade. E não pode simplesmente desligar um trigger em produção: isso é uma implantação, com os seus testes.

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

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

Clique para ampliar

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 (abre num novo separador), 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 (abre num novo separador), 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 (abre num novo separador), 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). ⟲

Um bypass não é “pule tudo”

Um bypass não significa que o utilizador de migração ignora todas as regras do Salesforce. Uma automação deve ser pulada, outra precisa de continuar a correr; uma regra de validação que protege uma invariante fundamental continua a importar, uma notificação não; uma integração posterior precisa de ser suprimida, uma relação obrigatória ainda precisa de ser verificado. Então quero bypasses intencionais e com alcance definido, não Migration_Mode__c = true e, portanto, nada importa. O caminho da migração ainda tem regras, só as adequadas à migração.

E o bypass deveria representar um contexto operacional, não um acidente. Uma identidade de migração dedicada (módulo 2), uma permissão personalizada, metadados de configuração, um sinalizador de recurso, ou uma combinação disso, podem reconhecer o trabalho de migração aprovado. A identidade pode fazer parte do controlo, mas não quero toda a automação com User.Name = 'Migration User' cravado no código. Isso é frágil. Expresse a intenção: se esta é uma operação de migração aprovada, pule este efeito colateral.

As regras de validação precisam de discernimento

“A data de fechamento é obrigatória quando uma oportunidade está Closed Won” é uma invariante real dos dados; mantenha-a para as oportunidades históricas. Uma regra que exige um campo do processo atual introduzido há três anos é diferente: os registos de dez anos atrás nunca o tiveram, e inventar um valor piora os dados. A pergunta não é “desligamos as regras de validação?”. É quais regras representam uma verdade duradoura dos dados, e quais representam o processo interativo de hoje? Essa é uma pergunta de arquiteto de dados.

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

O sinal de alerta a vigiar: o destino exige um valor, a origem não o tem, então “coloca ‘Desconhecido’ em tudo”. Se Desconhecido é um valor aprovado que descreve de verdade o estado, tudo bem. Se estamos a inserir valores falsos para passar na validação, estamos a corromper os dados para satisfazer a aplicação. Prefiro projetar uma exceção de migração, um campo histórico que aceite nulo, uma regra de transformação ou um valor de estado legado a fingir que sabemos algo que não sabemos.

A automação multiplica o Número de Zeros

Carregue 2 milhões de contas; a automação cria 2 tarefas para cada uma: 4 milhões de tarefas. Intencional, ou um acidente? Depois cada tarefa dispara outro flow, a automação da conta atualiza um pai, publica um evento, recalcula outra coisa. O desempenho da migração não é o quão rápido a Bulk API insere contas. A carga de trabalho real é o grafo de transações que esses inserts criam. O Número de Zeros multiplica-se pela automação.

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

Clique para ampliar

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 (abre num novo separador), 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. ⟲

Clique para ampliar

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

Os efeitos colaterais externos são piores. E-mails para clientes, solicitações de cobrança, eventos consumidos por sistemas de produção, chamadas ao ERP, tickets de suporte, atualizações de marketing: esses sistemas não sabem que são dados de migração, e, depois que a mensagem sai do Salesforce, desfazê-la pode ser impossível. O capítulo 9 nos deu o contrato de dados da integração; durante o planeamento da migração, decida quais dessas setas podem operar, quais são suprimidas e quais são substituídas por uma sincronização depois da transição. Essa decisão vai no plano de transição.

Dados derivados, partilha e o objeto de staging

Totalizações e outros valores derivados: carregar um pai, depois milhões de filhos, e recalcular depois de cada filho? Talvez. Muitas vezes é bem mais barato carregar tudo e calcular uma vez. A pergunta é se o resultado derivado precisa de ser mantido registo a registo durante a migração, ou se pode ser estabelecido depois que os dados dependentes estiverem completos. É a mesma decisão de não precisa / simule / adie.

A partilha também é um dado derivado. Criar e transferir registos dispara o cálculo das regras de partilha, e numa carga grande isso pode significar avaliações muito longas ou tempos esgotados. O Salesforce permite que um administrador adie os cálculos de partilha (as regras de partilha e as associações a grupos) e os retome depois, mas o recurso não vem ativado por omissão: o Suporte do Salesforce o ativa. Ao retomar, precisa de correr um recálculo completo, e algumas mudanças de partilha continuam a ser calculadas no momento para proteger a integridade dos dados (Defer Sharing Calculations (abre num novo separador)). Planeie isso, e planeie o tempo do recálculo.

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 (abre num novo separador), 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. ⟲

Projete para o estado final, e registre por escrito

O objetivo não é “correr a automação de produção”. É chegar ao estado de produção correto, e não são a mesma coisa. O processamento normal de uma conta nova deriva uma classificação, cria uma tarefa de boas-vindas, envia uma notificação e publica noutro sistema. Para uma conta histórica migrada, o estado final certo pode ser: classificação sim, tarefa de boas-vindas não, notificação de boas-vindas não, publicação externa talvez, dependendo do plano de sincronização. Rodar às cegas a automação normal reproduz um processo que não foi projetado para a migração.

Numa migração séria, registre por escrito como um inventário de automações:

Automação	Comportamento normal	Decisão de migração	Resultado necessário na migração
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

Agora a decisão é visível: podemos revisá-la, testá-la, ensaiá-la e verificá-la depois da carga.

Ensaie o bypass, depois religue tudo

Não faça da produção a primeira vez que usa o modo de migração. O ensaio deveria testar a identidade de migração, os controlos de bypass, as automações que continuam ativas, os resultados simulados, os processos adiados e a volta ao modo normal, e depois verificar: disparou algo que não deveria, deixou de acontecer algo que deveria, o estado final corresponde à arquitetura? Por isso o ensaio precisa da configuração real da automação, ou da mais próxima possível.

Religar é uma etapa da transição: explícita, com um responsável nomeado, um horário previsto e verificação. Não “lembre de religar os flows”. O sistema não está pronto para os utilizadores até a operação normal ser restabelecida e verificada (o módulo 4 coloca isso no 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. ⟲

A IA torna o design do bypass mais importante

Agora acrescente agentes que reagem a um caso novo, a uma conta alterada, a um evento publicado ou a uma tarefa numa fila. Uma migração cria padrões de dados à escala de máquina; queremos agentes a reagir a cada registo migrado? Provavelmente não por acidente. Os processos disparados por agentes pertencem ao mesmo inventário que os flows, os triggers, as notificações, as integrações e os eventos, e, se o contexto de migração deve suprimi-los, projete isso de propósito.

Além do exame: o que a IA muda. Os agentes são outro tipo de efeito colateral, um que pode reagir de forma autónoma aos dados migrados. Trate as ações disparadas por agentes como qualquer outra automação: decida se correm, são simuladas, adiadas ou suprimidas, e teste a decisão no ensaio.

O que um arquiteto decide aqui

• Quais automações correm, não são necessárias, são simuladas ou adiadas para cada classe de dados migrados, a saber que desligar uma significa assumir a sua lógica de negócio.
• Quais regras de validação representam uma verdade duradoura dos dados, e quais são regras do processo atual que precisam de um tratamento específico para a migração.
• 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. ⟲
• Como os dados derivados, o recálculo da partilha e a lógica lenta da plataforma são tratados: depois da carga, adiados ou por meio de um objeto de staging.
• Quais efeitos colaterais externos e integrações são suprimidos ou postos em dia de propósito, e como o ensaio e a transição provam que a automação normal foi restabelecida com segurança.

Faça disso uma decisão

A migração não tem sucesso porque cada flow correu, cada trigger disparou e cada regra de validação foi executada. Esse é o comportamento normal das transações, e a migração tem outro trabalho: levar os dados para a nova arquitetura, preservar as verdades que importam, criar os valores derivados de que precisamos, evitar efeitos colaterais falsos, manter o sistema sob controlo e depois devolvê-lo ao normal. Para cada automação: não precisa, simule, adie, ou deixe correr de propósito. Mas faça disso uma decisão. Não deixe cinco milhões de registos decidirem por si.

Para saber mais

• Salesforce Help, Defer Sharing Calculations (abre num novo separador) and Fim do suporte ao Criador de processos e às Regras de fluxo de trabalho (abre num novo separador), checked 2026-11-01. ⟲
• Salesforce Help, Define Custom Settings (abre num novo separador), Global Variables Resource (abre num novo separador) (Flow) and How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (abre num novo separador); Apex Reference Guide, FeatureManagement Class (abre num novo separador), Custom Settings Methods (abre num novo separador) and Custom Metadata Type Methods (abre num novo separador), Winter ‘27; all checked 2026-11-01. ⟲
• Salesforce Architects, decision guide, Record-Triggered Automation (abre num novo separador) (“Bypassing Automation”), checked 2026-11-01. ⟲
• Salesforce Architects, Well-Architected, Automation Patterns (abre num novo separador) and Resource and Cost Optimization (abre num novo separador), checked 2026-11-01. ⟲
• Salesforce, Apex Developer Guide, Execution Governors and Limits (abre num novo separador), Winter ‘27 (API version 68.0), and Change Data Capture Developer Guide, Change Data Capture Allocations (abre num novo separador), checked 2026-11-01. ⟲
• Neste curso: Integração e movimentação de dados (o contrato de dados da integração) e Projetar para a escala.