# architect Guias de decisão (decision-guides) - Full Documentation

<!-- document id=5dc78cf08a278735aeff6d0903986aec2df5392ac8d32f2cc92f804b90c56c16 url=/architect/current/pt-br/decision-guides/guides/event-driven.md -->

# Usar as ferramentas e os padrões certos para arquiteturas conduzidas por evento

As arquiteturas conduzidas por evento dão suporte à produção e ao consumo eficientes de eventos, que comunicam alterações de estado do sistema ou do aplicativo. Essas arquiteturas permitem conexões flexíveis entre sistemas e dão suporte a processos e atualizações quase em tempo real que funcionam entre sistemas. Embora seja fácil ver as vantagens de arquiteturas conduzidas por evento, os detalhes da implementação nem sempre são tão claros. Quais recursos você precisa considerar em padrões de arquitetura conduzidos por evento? Quais problemas específicos esses padrões solucionam? Quais considerações especiais se aplicam às suas soluções e quais são os padrões ideais para lidar com elas?

## Visão geral do guia

Este guia apresenta padrões usados para criar arquiteturas ideais conduzidas por evento ao trabalhar com tecnologias do Salesforce. Ele também discute ferramentas de controle disponíveis no Salesforce e fornece recomendações de ferramentas para uma seleção de casos de uso. Para obter informações sobre integrações em nível de dados envolvendo o Salesforce, consulte nosso [Guia de decisão de integração de dados](/docs/architect/pt-br/decision-guides/guide/data-integration).

## Capturas

- **Use arquiteturas conduzidas por evento para processos que não exigem respostas síncronas a solicitações.** Os padrões descritos neste guia são projetados para consistência de dados, escalabilidade e reutilização, o que ajuda a manter o débito técnico a um mínimo conforme o panorama de aplicativos da sua organização evolui. (Consulte [Bem-construído – Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html) para obter mais informações.)

- **Se o MuleSoft ou outra solução Enterprise Service Bus (ESB) fizer parte do seu panorama existente, use-o sempre que possível.** Essas soluções são projetadas para dar suporte a padrões de arquitetura conduzidos por evento e têm recursos poderosos que permitem reutilizar integrações em toda a sua empresa.

- **Use a API Pub/Sub para qualquer padrão de publicação/assinatura futuro em vez de criar seus próprios manipuladores de evento usando outras APIs, incluindo a API de streaming.** Agora que a API Pub/Sub está disponível ao público em geral, use-a para qualquer novo padrão de publicação/assinatura. Planeje migrar as comunicações de evento existentes usando outras APIs de plataforma, como a API de streaming ou serviços do Apex personalizados, para a API Pub/Sub quando for viável.

- **Os eventos de plataforma e a Captura de dados de alteração (CDC) são os mecanismos preferidos para publicar alterações de registro e campo que precisam ser consumidas por outros sistemas.** Não recomendamos usar PushTopic e eventos genéricos para novas implementações. A Salesforce continuará oferecendo suporte a eventos genéricos e PushTopic nos recursos funcionais atuais, mas não planeja fazer mais investimentos nessa tecnologia.

## Produtos no escopo

<table style="border:none;width:100%">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Plataforma Salesforce"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0">A <a href="https://www.salesforce.com/platform/agentforce-platform">Plataforma Salesforce</a> é uma plataforma abrangente baseada em IA que une funcionários, agentes de IA autônomos, dados da empresa e aplicativos em um único sistema confiável para aumentar a produtividade e a experiência do cliente. Ele permite a criação de uma "empresa ativa" conectando aplicativos Customer 360, Data Cloud e Slack para automação completa.</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: MuleSoft logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/mulesoft-new.png" alt="MuleSoft"></td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0">O <a href="https://www.salesforce.com/mulesoft/">MuleSoft</a> é a plataforma de integração líder da Salesforce que permite que as organizações conectem aplicativos, dados e dispositivos em ambientes locais e na nuvem. O MuleSoft é uma plataforma que dá aos TI as plataformas para desbloquear dados entre sistemas, desenvolver estruturas de integração e automação escalonáveis e criar experiências diferenciadas e conectadas rapidamente.</td>
    </tr>
  </tbody>
</table>

## Pontos de decisão

Arquiteturas conduzidas por evento (EDAs) são recomendadas para cenários que exigem notificações quase em tempo real, distribuição de carga de processamento para mensagens de alto volume ou complexas e integração de sistemas como IoT e dispositivos móveis que exigem resiliência de conectividade por meio de fila. No entanto, os EDAs não devem ser implementados para processos que exigem respostas humanas síncronas imediatas, pois são projetados para execução assíncrona. Eles também não são adequados se os dados de origem mudarem com tanta frequência que um padrão mais simples, como processamento em lote, seria suficiente.

### Quando usar uma arquitetura conduzida por evento

Aqui estão vários cenários comuns que geralmente são adequados para uma arquitetura conduzida por evento:

<table style="width:100%">
<thead>
<tr><th scope="col">Ponto de decisão</th><th scope="col">Diretrizes</th></tr>
</thead>
<tbody>
<tr><td><strong>Notificações quase em tempo real</strong></td><td>Os padrões de arquitetura conduzidos por evento, como publish/subscribe, fanout e streaming, tendem a funcionar bem em cenários em que vários aplicativos precisam ser notificados sobre alterações de status ou atualizações de registro quase em tempo real.</td></tr>
<tr><td><strong>Processamento paralelo</strong></td><td>Padrões como publicar/assinar tendem a funcionar bem em cenários em que grandes volumes de dados ou mensagens altamente complexas exigem a distribuição da carga de processamento entre vários sistemas.</td></tr>
<tr><td><strong>Leitura de alto volume</strong></td><td>Os padrões de Mensagens passadas e Enfileiramento são comumente usados em cenários em que as organizações têm surtos, e o volume de mensagens que estão sendo produzidas pode exceder a capacidade dos assinantes de processá-los imediatamente.</td></tr>
<tr><td><strong>Gravações de alto volume</strong></td><td>Os padrões de streaming e enfileiramento funcionam bem em muitos cenários em que as organizações têm aumento no número de mensagens produzidas.</td></tr>
<tr><td><strong>Enviar os mesmos dados para diferentes sistemas</strong></td><td>Embora a publicação/assinatura tende a ser uma solução bastante comum para organizações que precisam enviar os mesmos dados para vários sistemas, ela pode ser tratada pela maioria dos padrões abordados aqui. Certifique-se de revisá-los em detalhes para encontrar o melhor ajuste.</td></tr>
<tr><td><strong>Introdução frequente de novos sistemas ou dispositivos</strong></td><td>Os padrões de publicar/assinar, transmitir e enfileirar tendem a funcionar bem para cenários em que o panorama geral tende a estar em fluxo, com novos sistemas e dispositivos sendo adicionados regularmente. Nesse cenário, um novo sistema ou dispositivo simplesmente precisa se tornar um assinante do barramento de evento ou associado a uma fila para começar a receber mensagens, em vez de exigir uma integração de ponto a ponto personalizada.</td></tr>
<tr><td><strong>Dispositivos de IoT</strong></td><td>Como os dispositivos de IoT geralmente fornecem atualizações frequentes e também podem gerar uma onda de mensagens em alguns cenários, os padrões de streaming e enfileiramento tendem a funcionar bem ao integrá-los a um panorama de TI.</td></tr>
<tr><td><strong>Dispositivos e sistemas móveis offline</strong></td><td>Dispositivos móveis que precisam trabalhar em áreas com acesso à Internet de baixa qualidade ou não existente ou sistemas que podem estar offline no momento em que as mensagens são entregues se beneficiarão do padrão de enfileiramento, que permite que eles se conectem às filas e recuperem todas as mensagens relevantes quando estiverem online novamente.</td></tr>
</tbody>
</table>

A maioria das organizações grandes tem paisagens de TI complexas que têm uma combinação de sistemas com diferentes recursos. É possível ou provável que sua organização tenha sistemas legados que não oferecem suporte a integrações conduzidas por evento. Você também pode ter casos de uso em que integrações conduzidas por evento não fazem sentido, mesmo que os sistemas tenham suporte para elas (por exemplo, transferências de arquivos SFTP de terceiros). Se você dar um passo para trás e olhar para o panorama de TI da sua organização como um todo, provavelmente, como acontece com outras soluções de arquitetura, você usará uma mistura de padrões para dar suporte a diferentes cenários. Quando você decidir tornar o evento conduzido sua abordagem preferida para integrações, pense nela como outra ferramenta na sua caixa de ferramentas. Ele pode e deve ser usado nos cenários certos, mas não é uma abordagem a ser imposta a todos os sistemas. O desenvolvimento de uma estratégia de integração abrangente ajudará a determinar quando os padrões descritos neste guia podem ou não ser adequados.

### Quando não usar uma arquitetura conduzida por evento

Muitos cenários exigem arquiteturas conduzidas por evento, e em alguns cenários, as arquiteturas conduzidas por evento funcionarão mesmo que não sejam as mais adequadas. Porém, em alguns cenários, arquiteturas conduzidas por evento simplesmente não devem ser usadas. Aqui estão algumas perguntas do ponto de decisão para ajudá-lo a identificar estes cenários:

<table style="width:100%">
<thead>
<tr><th scope="col">Ponto de decisão</th><th scope="col">Orientação/perguntas a fazer</th></tr>
</thead>
<tbody>
<tr><td><strong>Requisitos operacionais</strong></td><td>Há uma necessidade comercial genuína para alguma das funcionalidades descritas na seção [Quando usar uma arquitetura conduzida por evento](#quando usar-uma arquitetura conduzida por evento)?</td></tr>
<tr><td><strong>Requisitos técnicos</strong></td><td>A integração que você está projetando é um ajuste óbvio para um padrão diferente, como virtualização de dados, lote ou solicitação/resposta? Em outras palavras, você está tentando caber um pino quadrado em um buraco redondo?</td></tr>
<tr><td><strong>Processos que exigem que os seres humanos aguardem respostas</strong></td><td>Qualquer integração que envolva uma espera humana por uma resposta do sistema de destino não é adequada para arquiteturas conduzidas por evento, pois elas são projetadas para execução assíncrona e não podem garantir um tempo de resposta. Considere se processos como esse são ideais para sua organização antes de implementar soluções técnicas. Consulte [Bem-arquiteto – Excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) para obter mais informações.</td></tr>
<tr><td><strong>Alteração frequente dos dados de origem</strong></td><td>Se os dados no seu sistema de origem mudarem com tanta frequência que atualizações periódicas sejam suficientes, você provavelmente poderá simplificar sua arquitetura usando [patrons em lote](https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm) em vez de padrões conduzidos por evento.</td></tr>
<tr><td><strong>Requisitos de execução</strong></td><td>A maioria dos sistemas envolvidos em sua solução oferece suporte a arquiteturas conduzidas por evento? O que seria necessário para usar arquiteturas conduzidas por evento com os sistemas que não oferecem suporte a elas (por exemplo, upgrades, personalizações ou middleware)? Que nível de esforço seria necessário para cumprir esses requisitos?</td></tr>
<tr><td><strong>Estabilidade da estrutura de mensagens</strong></td><td>Com que frequência suas estruturas de mensagens precisarão mudar? Quais sistemas serão afetados por essa alteração e qual será o processo de remediação?</td></tr>
<tr><td><strong>Governança organizacional</strong></td><td>Você tem uma estrutura de governança em vigor para garantir que todas as partes interessadas sejam informadas e possam considerar alterações em estruturas de mensagens, acionadores e outras decisões relacionadas a arquitetura e processo?</td></tr>
<tr><td><strong>Habilidades necessárias</strong></td><td>Sua equipe tem experiência com arquiteturas conduzidas por evento e sabe como dar suporte a elas?</td></tr>
</tbody>
</table>

## Casos de uso

Há uma variedade de padrões de arquitetura conduzidos por evento. Alguns são padrões de finalidade geral que podem ser aplicados em casos de uso que não têm requisitos especiais além de serem conduzidos por evento; por exemplo, consulte [Bem-Arquiteto - Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html). Outros padrões são aplicáveis aos casos de uso específicos discutidos aqui, como integrações que envolvem grandes volumes de dados ou cenários que exigem retenção de mensagens mais longa.

### Padrões em uma visão geral

A tabela abaixo compara os atributos dos padrões descritos neste documento. Use-o como uma referência rápida quando precisar identificar possíveis padrões para um determinado caso de uso.

<table style="width:100%">
<thead>
<tr><th scope="col">Padrão</th><th scope="col">Quase em tempo real</th><th scope="col">Cópia de mensagem única</th><th scope="col">Entrega de garantia</th><th scope="col">Reduzir o tamanho da mensagem</th><th scope="col">Transformar dados</th></tr>
</thead>
<tbody>
<tr><td>Publicar/Assinar</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Fanout</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Mensagens passadas</td><td>✓</td><td></td><td>✓</td><td>✓</td><td>✓</td></tr>
<tr><td>Streaming</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
<tr><td>Enfileiramento</td><td>✓</td><td>✓</td><td>✓</td><td></td><td></td></tr>
</tbody>
</table>

### Ferramentas para arquitetura conduzida por evento

O Salesforce oferece várias ferramentas para ajudá-lo a lidar com seus casos de uso conduzidos por evento. Esta tabela contém uma visão geral de alto nível das ferramentas disponíveis.

<table style="width:100%">
<thead>
<tr><th scope="col"></th><th scope="col">Ferramenta</th><th scope="col">Descrição</th><th scope="col">Habilidades necessárias</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Anypoint Platform</a></td><td>Plataforma que habilita a integração de dados usando camadas de APIs.</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector de Pub/Sub do Salesforce</a></td><td>Conector para a API Pub/Sub, que fornece uma única interface para publicar e assinar eventos de plataforma, eventos de monitoramento de evento em tempo real e eventos de captura de dados de alteração.</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Conector que habilita o envio e o recebimento de mensagens para filas e tópicos para qualquer serviço de mensagens que implementa a especificação Java Message Service (JMS).</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Conector para mover dados entre o Apache Kafka e aplicativos e serviços corporativos.</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Conector do MuleSoft Anypoint Solace</a></td><td>Um conector para agentes de evento Solace PubSub+ com integração de API nativa usando o SDK Java JCSMP</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Um serviço de mensagens na nuvem de vários locatários que permite que os clientes realizem mensagens assíncronas avançadas entre seus aplicativos.</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Conector MQTT do MuleSoft Anypoint</a></td><td>Uma extensão do MuleSoft em conformidade com o protocolo v3.x MQTT (Transporte de telemetria de enfileiramento de mensagem).</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Conector do MuleSoft Anypoint AMQP</a></td><td>Um conector que permite que seu aplicativo publique e consuma mensagens usando um agente em conformidade com AMQP 0.9.1.</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">API acionada por evento (ASync) do MuleSoft Anypoint</a></td><td>Idioma agnóstico do setor que dá suporte à publicação de APIs conduzidas por evento separando-as em camadas de evento, canal e transporte.</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Serviço de mensagens de nuvem multilocatário que permite que os clientes realizem mensagens assíncronas avançadas entre seus aplicativos.</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">MuleSoft Anypoint Data Streams</a></td><td>Estrutura disponível no MuleSoft Anypoint para publicar e assinar dados de streaming.</td><td>Código profissional</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Complemento do Heroku que fornece o Apache Kafka como um serviço com integração de plataforma completa à plataforma Heroku.</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Captura de dados de alteração</a></td><td>Registro de eventos de alteração, que publica alterações em registros do Salesforce. As alterações incluem a criação de um novo registro, atualizações em um registro existente, exclusão de um registro e cancelamento da exclusão de um registro.</td><td>Baixo código para Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Mensagens de saída</a></td><td>Ações que enviam mensagens XML a pontos de extremidade externos quando os valores de campo são atualizados no Salesforce.</td><td>Código baixo</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventos de plataforma</a></td><td>Mensagens seguras e escalonáveis que contêm dados de evento personalizados.</td><td>Baixo código para Pro-code</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>API que habilita assinaturas para eventos de plataforma, eventos de Captura de dados de alteração e/ou eventos de Monitoramento de evento em tempo real.</td><td>Código profissional</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Retransmissões de evento</a></td><td>Permite que eventos de plataforma e eventos de captura de dados de alteração sejam enviados do Salesforce para o Amazon EventBridge. Observe que as Retransmissões de evento se conectam apenas ao AWS Eventbridge.</td><td>Código baixo</td></tr>
<tr><th scope="row"></th><td></td><td></td><td></td></tr>
</tbody>
</table>

### Publicar/Assinar

Quando um registro crítico muda de estado em um aplicativo principal, por exemplo, o status de um pedido muda de "Processando" para "Enviado", vários outros sistemas provavelmente precisam de uma notificação quase em tempo real para realizar suas respectivas tarefas. Uma necessidade de negócios específica surge quando o volume dessas alterações é alto e as mensagens são complexas, tornando as integrações de ponto a ponto tradicionais pesadas e difíceis de manter. Estabelecer conexões frágeis e personalizadas para cada aplicativo dependente leva a débitos técnicos e impede a capacidade da organização de escalar rapidamente. É necessária uma abordagem de integração robusta para gerenciar essas sincronizações de dados frequentes sem acoplar o sistema de origem diretamente a cada sistema consumidor.

#### O padrão Publicar/Assinar

O diagrama abaixo mostra um padrão de publicação/assinatura típico com vários editores e assinantes compartilhando dados por meio de um barramento de evento. Esse padrão fundamental forma a base para os padrões mais específicos que podem ser encontrados em todo o restante deste guia. Algumas características principais desse padrão são:

- Não há conexão direta entre editores e assinantes. Os editores simplesmente enviam mensagens para um barramento de evento, que as transmite para qualquer outro sistema que queira escutá-las.

- O mesmo sistema pode ser um editor e um assinante.

- Os sistemas podem publicar ou assinar vários tipos de eventos.

- Como acontece com todos os padrões neste guia, o padrão publish / subscribe se enquadra em uma categoria geral de padrão de integração conhecida como invocação de procedimento remoto (RPI) ou simplesmente ["apagar e esquecer".](/docs/architect/pt-br/fundamentals/guide/integration-patterns#chamada-de-processo-remoto--atirar-e-esquecer)

<!-- Image: Publish/subscribe pattern diagram (Level 2) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Publish - Subscribe L2.png" alt="Este diagrama de Nível 2 mostra um exemplo do padrão publish/subscribe que inclui vários editores, vários assinantes e vários eventos sendo entregues por meio de canais em um barramento de eventos.Nesse padrão, o mesmo sistema pode ser um editor e um assinante e um sistema pode assinar vários eventos.">

#### Ferramentas relevantes para o padrão Publicar/Assinar

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Fluxo e comportamento de evento</th><th colspan="2" scope="colgroup">Considerações sobre carga útil</th></tr>
<tr><th scope="col">Ferramentas disponíveis</th><th scope="col"></th><th scope="col">Habilidades necessárias</th><th scope="col">Publicar via</th><th scope="col">Assinar via</th><th scope="col">Período de repetição</th><th scope="col">Estrutura de carga útil</th><th scope="col">Limites de carga útil</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/general/">Anypoint Platform</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector de Pub/Sub do Salesforce</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Conector do MuleSoft Anypoint Solace</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Conector MQTT do MuleSoft Anypoint</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Conector do MuleSoft Anypoint AMQP</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/release-notes/platform/event-driven-api">API acionada por evento (ASync) do MuleSoft Anypoint</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Código profissional</td><td>APIs, alterações de registro no Heroku Postgres</td><td>N/A</td><td>1 a 6 semanas</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuário definido</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuário definido</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Captura de dados de alteração</a></td><td>Baixo código para Pro-code</td><td>Alterações de registro</td><td>Apex, APIs, Componentes da Web Lightning (LWC)</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging.htm">Mensagens de saída*</a></td><td>Código baixo</td><td>Regras de fluxo e fluxo de trabalho</td><td>N/A</td><td>24 horas</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_wsdl.htm">Usuário definido</a></td><td>100 notificações por mensagem</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventos de plataforma</a></td><td>Baixo código para Pro-code</td><td>APIs, Apex, Fluxo</td><td>Apex, APIs, Flow, LWC</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuário definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Código profissional</td><td>API ou APIs Pub/Sub, Apex, Fluxo</td><td>API Pub/Sub</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Usuário definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Retransmissões de evento**</a></td><td>Código baixo</td><td>Eventos de plataforma, Captura de dados de alteração</td><td>API</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuário definido</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*A Salesforce continuará oferecendo suporte a mensagens de saída nos recursos funcionais atuais, mas não planeja fazer mais investimentos nessa tecnologia. **Retransmissões de evento se conectam apenas ao AWS EventBridge</td></tr>
</tbody>
</table>

### Fanout

Quando uma organização precisa enviar atualizações instantâneas a um grande número de aplicativos clientes, como notificações por push ou mensagens SMS para dispositivos móveis, o processo tradicional de criar transmissões exclusivas para cada destinatário se torna rapidamente um gargalinho de escalabilidade. A necessidade de negócio principal, neste caso, é a distribuição rápida e de alto desempenho de uma única informação, como um alerta de conta ou um aviso de alteração crítica de serviço, para vários aplicativos de ponto de extremidade simultaneamente. Uma abordagem simplificada para cumprir esse requisito envolve rotear todas as mensagens por uma única fila, que atua como o ponto central de informações de evento para todos os sistemas de consumo. Essa abordagem melhora o desempenho eliminando a necessidade de gerenciar muitas cópias de mensagem separadas.

#### O padrão do Fanout

Com o padrão de efusão, as mensagens são entregues para um ou vários destinos (ou seja, escutando clientes ou assinantes) por meio de uma única fila de mensagens. Os assinantes recuperam a mesma mensagem da fila, em vez de sua própria cópia exclusiva. (Observe que, embora isso melhore o desempenho, também pode tornar mais difícil verificar se um assinante específico recebeu ou não a mensagem.)

<!-- Image: Fanout pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Fanout L3.png" alt="Esse diagrama de implementação e documentação de Nível 3 mostra um exemplo do padrão do fanout. Ele mostra um evento sendo publicado e gravado em uma única fila quando um registro é modificado por meio de uma interação do usuário, fluxo ou trabalho em lote. O sistema do assinante tem vários serviços que recebem o mesmo evento da fila de mensagens.">

#### Ferramentas relevantes para o padrão do Fanout

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Fluxo e comportamento de evento</th><th colspan="2" scope="colgroup">Considerações sobre carga útil</th></tr>
<tr><th scope="col">Ferramentas disponíveis</th><th scope="col"></th><th scope="col">Habilidades necessárias</th><th scope="col">Publicar via</th><th scope="col">Assinar via</th><th scope="col">Período de repetição</th><th scope="col">Estrutura de carga útil</th><th scope="col">Limites de carga útil</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/jms-connector/latest/">MuleSoft Anypoint JMS Connector</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector de Pub/Sub do Salesforce</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://github.com/SolaceProducts/pubsubplus-connector-mule-docs/blob/main/doc/user-guide.md">Conector do MuleSoft Anypoint Solace</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Conector MQTT do MuleSoft Anypoint</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Conector do MuleSoft Anypoint AMQP</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Código profissional</td><td>APIs, alterações de registro no Heroku Postgres</td><td>N/A</td><td>1 a 6 semanas</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuário definido</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuário definido</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Captura de dados de alteração</a></td><td>Baixo código para Pro-code</td><td>Alterações de registro</td><td>Apex, APIs, Componentes da Web Lightning (LWC)</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventos de plataforma</a></td><td>Baixo código para Pro-code</td><td>APIs, Apex, Fluxo</td><td>Apex, APIs, Flow, LWC</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuário definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Código profissional</td><td>API Pub/Sub ou Apex, APIs, Fluxo</td><td>API Pub/Sub</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Usuário definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Retransmissões de evento*</a></td><td>Código baixo</td><td>Eventos de plataforma, Captura de dados de alteração</td><td>API</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuário definido</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Retransmissões de evento enviam dados apenas para o AWS EventBridge</td></tr>
</tbody>
</table>

### Mensagens passadas

Alguns cenários de evento são caracterizados por um influxo significativo de volume de mensagens que ameaça sobrecarregar a capacidade dos processos de sincronização e transformação ou por uma lógica complexa de várias etapas necessária para processar e transformar dados de evento.

Alguns exemplos incluem:

- **Picos sazonais de volume:** Pode haver picos de volume que os varejistas online veem quando uma seleção de seus produtos está "na temporada". Quando grandes números de clientes estão fazendo compras ao mesmo tempo, o número de eventos gerados pode exceder temporariamente a capacidade dos processos de sincronização e transformação. Consulte [Bem-construído – Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html#scalability-and-capacity-planning) para obter mais informações.

- **Gerenciamento de caso ou reivindicações:** As empresas baseadas em serviço podem enfrentar aumentos no número de casos ou reivindicações durante interrupções.

- **Transformações de dados complexas:** Organizações que exigem lógica complexa para transformar mensagens costumam se preocupar com eventos sendo gerados mais rapidamente do que podem ser transformados.

#### O padrão de mensagens passadas

Esse padrão lida com o desafio de as mensagens serem geradas mais rapidamente do que podem ser transformadas. Ele garante que grandes volumes de mensagens e manipulações de dados necessárias possam ser tratadas com confiança, incorporando uma plataforma de mensagens de streaming e segmentando a lógica de processamento de mensagens em componentes dedicados.

O padrão de Mensagens passadas funciona segmentando a lógica de processamento de mensagens em vários componentes:

- Um componente lida com o roteamento de mensagens, determinando as transformações necessárias e o destino final.

- Um conjunto separado de componentes lida com diferentes camadas de transformação de mensagem (por exemplo, mapeamentos de campo, relacionamentos de objeto etc.).

- O último componente grava a mensagem final modificada.

<!-- Image: Passed messages pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Passed Messages L3.png" alt="Esse diagrama de implementação e documentação de Nível 3 mostra um exemplo de um fluxo de processo para o padrão de mensagens passadas que inclui um editor, um assinante e uma mensagem.A mensagem é dividida em várias partes, que são transformadas individualmente e então montadas novamente antes de serem enviadas ao assinante.">

#### Ferramentas relevantes para o padrão de mensagens passadas

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Fluxo e comportamento de evento</th><th colspan="2" scope="colgroup">Considerações sobre carga útil</th></tr>
<tr><th scope="col">Ferramentas disponíveis</th><th scope="col"></th><th scope="col">Habilidades necessárias</th><th scope="col">Publicar via</th><th scope="col">Assinar via</th><th scope="col">Período de repetição</th><th scope="col">Estrutura de carga útil</th><th scope="col">Limites de carga útil</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector de Pub/Sub do Salesforce</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Código profissional</td><td>APIs, alterações de registro no Heroku Postgres</td><td>N/A</td><td>1 a 6 semanas</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuário definido</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuário definido</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Captura de dados de alteração</a></td><td>Baixo código para Pro-code</td><td>Alterações de registro</td><td>Apex, APIs, Componentes da Web Lightning (LWC)</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventos de plataforma</a></td><td>Baixo código para Pro-code</td><td>APIs, Apex, Fluxo</td><td>Apex, APIs, Flow, LWC</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuário definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Código profissional</td><td>API ou APIs Pub/Sub, Fluxo do Apex</td><td>API Pub/Sub</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Usuário definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Retransmissões de evento*</a></td><td>Código baixo</td><td>Eventos de plataforma, Captura de dados de alteração</td><td>API</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuário definido</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Retransmissões de evento enviam dados apenas para o AWS EventBridge</td></tr>
</tbody>
</table>

### Streaming

Alguns produtores geram um fluxo contínuo de eventos. Um exemplo comum é o streaming de mídia, que envolve interações do usuário que ocorrem naturalmente como eventos separados. Vários sistemas devem reagir ao mesmo comportamento do usuário simultaneamente sem bloquear a experiência de streaming principal.

Considere os eventos para uma plataforma de streaming de música. Essas podem incluir:

- Rastrear eventos iniciados/pausados/pularam

- Eventos de sessão de escuta com carimbos de data e hora

- Eventos de criação/modificação da lista de reprodução

- Eventos de compartilhamento social

- Download para escuta offline

#### O padrão de streaming

No padrão de streaming, os assinantes acessam cada fluxo de evento e processam os eventos na ordem exata em que são recebidos. Cópias únicas de cada fluxo de mensagens são enviadas a cada assinante, tornando possível entregar conteúdo específico do assinante e identificar quais assinantes recebem quais fluxos.

<!-- Image: Streaming pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Streaming - L3.png" alt="Esse diagrama de implementação e documentação de Nível 3 mostra um exemplo do padrão de streaming que mostra um fluxo de eventos sendo publicados, que os assinantes que estão ouvindo os fluxos recebem e processam de acordo.">

#### Ferramentas relevantes para o padrão de streaming

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Fluxo e comportamento de evento</th><th colspan="2" scope="colgroup">Considerações sobre carga útil</th></tr>
<tr><th scope="col">Ferramentas disponíveis</th><th scope="col"></th><th scope="col">Habilidades necessárias</th><th scope="col">Publicar via</th><th scope="col">Assinar via</th><th scope="col">Período de repetição</th><th scope="col">Estrutura de carga útil</th><th scope="col">Limites de carga útil</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mule-runtime/latest/streaming-about">MuleSoft Anypoint Data Streams</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector de Pub/Sub do Salesforce</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Código profissional</td><td>APIs, alterações de registro no Heroku Postgres</td><td>N/A</td><td>1 a 6 semanas</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuário definido</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuário definido</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Código profissional</td><td>API ou APIs Pub/Sub, Fluxo do Apex</td><td>API Pub/Sub</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Usuário definido</a></td><td>1 MB</td></tr>
</tbody>
</table>

#### Gerenciamento de pedido de evento transmitido

Para que um fluxo faça sentido, todos os seus eventos e suas mensagens associadas precisam estar na ordem correta. Se você originar os dados em um fluxo de sistemas diferentes, precisará incorporar lógica de pedido adicional como parte do processo de design.

### Fila

Os casos de uso de enfileiramento são onipresentes. Os exemplos incluem:

- **Conexões de internet de baixa qualidade:** Organizações de serviço de campo ou outras organizações em que as equipes com dispositivos móveis precisam trabalhar em áreas com acesso à Internet de baixa qualidade ou intermitente se beneficiam do enfileiramento, pois os aplicativos nesses dispositivos podem se conectar às filas e recuperar todas as mensagens relevantes quando a conectividade é restaurada.

- **Buffering de mensagem:** Quando o volume de mensagens ocasionalmente excede a capacidade de processamento de um assinante e a latência aumentada não cria problemas adicionais, as filas podem ser uma margem para armazenar mensagens em excesso e evitar a perda de dados.

- **Gerenciamento de transporte:** Organizações de logística que precisam monitorar suas frotas podem usar esse padrão para visualizar as rotas que cada veículo está seguindo quase em tempo real e garantir que os motoristas estejam sendo o mais eficientes possível.

- **Dispositivos de IoT:** Os fabricantes costumam usar sistemas que geram fluxos de dados rápidos, e esses fluxos podem ter efeitos a jusante em sistemas adicionais. Esse padrão pode ser usado para identificar sequências de eventos que exigem intervenção humana antes que ocorram falhas catastróficas em vários sistemas.

#### O padrão de enfileiramento

No padrão de enfileiramento, os produtores enviam mensagens para filas, que mantêm as mensagens até que os assinantes as recuperem. A maioria das filas de mensagens segue a ordem de primeira entrada e primeira saída (FIFO) e exclui todas as mensagens após a recuperação. Cada assinante tem uma fila exclusiva, que exige etapas de configuração adicionais, mas permite garantir a entrega e identificar quais assinantes receberam quais mensagens.

<!-- Image: Queuing pattern diagram (Level 3) -->
<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/Event Driven Architecture Diagrams - Queuing L3.png" alt="Esse diagrama de implementação e documentação de Nível 3 mostra um exemplo do padrão de enfileiramento que mostra um evento sendo publicado e gravado em uma fila quando um registro é modificado.Os assinantes recebem cópias do evento de suas filas associadas e fazem as atualizações apropriadas em seus próprios registros.">

#### Ferramentas relevantes para o padrão de enfileiramento

<table style="width:100%">
<thead>
<tr><th colspan="2" scope="colgroup"></th><th colspan="4" scope="colgroup">Fluxo e comportamento de evento</th><th colspan="2" scope="colgroup">Considerações sobre carga útil</th></tr>
<tr><th scope="col">Ferramentas disponíveis</th><th scope="col"></th><th scope="col">Habilidades necessárias</th><th scope="col">Publicar via</th><th scope="col">Assinar via</th><th scope="col">Período de repetição</th><th scope="col">Estrutura de carga útil</th><th scope="col">Limites de carga útil</th></tr>
</thead>
<tbody>
<tr><th scope="row">MuleSoft</th><td><a href="https://docs.mulesoft.com/mq/">MuleSoft Anypoint MQ</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/4.3/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/salesforce-pubsub-connector/latest/">Conector de Pub/Sub do Salesforce</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/kafka-connector/latest/">MuleSoft Anypoint Apache Kafka Connector</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mq/mq-connectors">MuleSoft Anypoint MQ Connector</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/mqtt3-connector/latest/">Conector MQTT do MuleSoft Anypoint</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row"></th><td><a href="https://docs.mulesoft.com/amqp-connector/latest/">Conector do MuleSoft Anypoint AMQP</a></td><td>Código profissional</td><td>APIs</td><td>APIs</td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy">Configurado</a></td><td><a href="https://docs.mulesoft.com/mule-runtime/latest/about-mule-message">Usuário definido</a></td><td>Nenhum</td></tr>
<tr><th scope="row">Salesforce Platform</th><td><a href="https://elements.heroku.com/addons/heroku-kafka">Apache Kafka on Heroku</a></td><td>Código profissional</td><td>APIs, alterações de registro no Heroku Postgres</td><td>N/A</td><td>1 a 6 semanas</td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuário definido</a></td><td><a href="https://kafka.apache.org/documentation/#messageformat">Usuário definido</a></td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm">Captura de dados de alteração</a></td><td>Baixo código para Pro-code</td><td>Alterações de registro</td><td>Apex, APIs, Componentes da Web Lightning (LWC)</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_message_structure.htm">Predefinido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_intro.htm">Eventos de plataforma</a></td><td>Baixo código para Pro-code</td><td>APIs, Apex, Fluxo</td><td>Apex, APIs, Flow, LWC</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuário definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Pub/Sub API</a></td><td>Código profissional</td><td>API ou APIs Pub/Sub, Apex, Fluxo</td><td>API Pub/Sub</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/platform/pub-sub-api/overview">Usuário definido</a></td><td>1 MB</td></tr>
<tr><th scope="row"></th><td><a href="https://help.salesforce.com/s/articleView?id=sf.ev_relay_intro.htm">Retransmissões de evento*</a></td><td>Código baixo</td><td>Eventos de plataforma, Captura de dados de alteração</td><td>API</td><td>3 dias</td><td><a href="https://developer.salesforce.com/docs/atlas.en-us.232.0.platform_events.meta/platform_events/platform_events_define_ui.htm">Usuário definido</a></td><td>1 MB</td></tr>
<tr><td colspan="8">*Retransmissões de evento enviam dados apenas para o AWS EventBridge</td></tr>
</tbody>
</table>

#### Gerenciamento de memória e armazenamento

Devido à natureza assíncrona do padrão de enfileiramento, pode haver um longo atraso entre a adição de uma mensagem a uma fila e a recuperação dessa mensagem. As filas exigem memória ou espaço de armazenamento para conter suas mensagens, portanto, elas não podem crescer indefinidamente, o que significa que um assinante que está offline indefinidamente pode causar uma falha se mensagens suficientes se acumularem na fila. O buffering de mensagens poderá ter o mesmo efeito se os tempos de processamento do assinante ficarem longos demais, fazendo com que grandes volumes de mensagens se acumulem nas filas. Para mitigar esses riscos, realize uma análise completa dos requisitos de armazenamento para todas as filas de mensagens e, se necessário, projete processos que limparão e desabilitarão as filas se as mensagens não forem recuperadas dentro de um tempo definido ou quando atingirem um volume predeterminado.

## Considerações não funcionais

Além das considerações funcionais listadas nas seções anteriores, também há considerações não funcionais a serem consideradas na sua decisão.

### Migração de integrações de ponto a ponto

Mesmo que você esteja totalmente convencido de que uma arquitetura orientada por evento é a melhor para sua organização, pode estar começando com uma paisagem que já tem um grande número de integrações de ponto a ponto. Obter financiamento para um projeto para substituir todas as suas integrações de uma só vez pode ser difícil e talvez nem sequer seja possível usar uma arquitetura conduzida por evento diretamente com alguns sistemas legados. Nesses cenários, você pode adotar uma abordagem incremental para migrar para uma arquitetura mais solta, convertendo primeiro os aplicativos mais críticos para os negócios, então convertendo outros sistemas conforme eles são atualizados ou substituídos em projetos futuros. Essa abordagem facilita a adição de novos aplicativos ao barramento de eventos e permite que sua paisagem de TI geral permaneça escalonável e resiliente à medida que os sistemas continuam sendo adicionados ao longo do tempo.

### Compromissos em sistemas soltos

Como arquitetos, sabemos que toda arquitetura vem com desvantagens. Uma arquitetura conduzida por evento não é exceção. Embora uma paisagem repleta de sistemas soltos seja altamente escalonável e resiliente, há algumas vantagens a serem consideradas também:

- **Estratégia global de integração:** Independentemente das ferramentas e padrões que você decide usar, é importante começar criando uma estratégia para como os dados serão compartilhados entre os vários sistemas no panorama da sua organização. Essa estratégia deve incluir as metas da sua organização para seus dados, como os dados podem ser compartilhados e padrões usados, além de fontes de dados, destinos, estruturas e requisitos de propriedade e acesso.

- **Suporte para sistemas legados:** Sua organização pode ter sistemas legados que simplesmente não oferecem suporte a padrões de arquitetura conduzidos por evento. Embora seja possível criar soluções alternativas (por exemplo, com um processo que atua como um passo a passo assinando eventos e então enviando a saída para o sistema de destino por meio de um meio diferente de transferência de dados), talvez você queira considerar outros métodos de integração neste caso.

- **Alterações estruturais em mensagens:** Depois que a estrutura da mensagem inicial é definida e acordada entre editores e assinantes, pode ser difícil alterar, principalmente se os assinantes forem externos. Há várias maneiras de lidar com esse problema. Você pode usar pontos de extremidade com controle de versão, mas certifique-se de definir e comunicar um ciclo de vida claro para cada versão para que seus desenvolvedores não tenham que manter muitas versões simultaneamente. Se o Apache Kafka no Heroku fizer parte da sua paisagem, você também poderá considerar um registro de esquema ou uma ferramenta semelhante, mas certifique-se de que os outros sistemas na sua paisagem também dêem suporte a ele (e o usem).

- **Falta de visibilidade entre editores e assinantes:** Na maioria dos padrões de arquitetura conduzidos por evento, os editores não estão cientes do status de seus assinantes. Portanto, se um editor enviar uma mensagem crítica enquanto todos os assinantes estiverem offline, talvez a mensagem nunca seja entregue. Você pode resolver esse problema usando a funcionalidade de reprodução ou adicionando assinantes redundantes que são executados em servidores separados para todas as mensagens críticas.

- **Botões de desempenho:** À medida que uma arquitetura conduzida por evento cresce, o barramento de evento pode se tornar um gargalos para a entrega de mensagens se ele ficar sobrecarregado com muitos editores tentando enviar mensagens a muitos assinantes ao mesmo tempo. Você pode lidar com isso aumentando os recursos de memória e processamento alocados ao barramento de evento ou usando vários barramentos de evento para processar diferentes tipos de mensagens em paralelo.

## Melhores práticas relacionadas

Além da orientação já fornecida, considere também as práticas recomendadas a seguir.

### Implementar arquiteturas conduzidas por evento

Antes de implementar uma arquitetura conduzida por evento, considere se você realmente precisa usar uma no primeiro lugar. A seção anterior descreve cenários de negócios comuns que são adequados a cada padrão de arquitetura conduzida por evento. Você também pode ler mais em [Bem-Arquiteto - Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html). Revise os desafios a serem considerados ao implementar Arquiteturas conduzidas por evento para determinar se os padrões que você tem em mente são mais adequados para seus casos de uso específicos.

Observe que, embora a maioria dos cenários abordados neste guia envolva integrações, as arquiteturas conduzidas por evento também podem ser usadas para enviar mensagens em uma única organização do Salesforce por meio do uso de eventos de plataforma, por exemplo. Lembre-se de quaisquer [limites de alocação de evento](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) aplicáveis ao projetar processos que usam eventos de plataforma como um sistema de mensagens interno.

### Evitando antipadrões

Frequentemente, antipadrões em arquiteturas conduzidas por evento vêm do uso de eventos como uma solução alternativa para comunicações internas em uma organização do Salesforce. Antipadrões comuns incluem:

- **Publicar eventos de acionadores do Apex associados ao mesmo objeto de evento:** Isso resultará em um loop de acionador infinito.

- **Publicar eventos do Apex antes da conclusão de uma transação DML:** Se uma transação falhar e reverter, quaisquer eventos publicados que tenham o comportamento Publicar publicação imediata não serão incluídos no comportamento de reversão.

- **Publicar eventos no Fluxo para orquestrar a automação subsequente:** A melhor maneira de coordenar a lógica entre várias automações é usar [subfluxos](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm) ou [Flow Orchestrator](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm).

- **Criando dependências de tempo de execução:** Não publique eventos para facilitar a comunicação entre pacotes sem tomar as [etapas](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8) adequadas para eliminar as dependências de tempo de execução.

- **Cargas úteis desnecessariamente grandes:** Ao fazer solicitações, é melhor enviar e receber a menor quantidade possível de dados na carga útil. Cada ação de um usuário pode potencialmente gerar várias solicitações, e é importante que elas sejam processadas de maneira eficiente. Enviar mais dados do que o necessário pode contribuir para desacelerar o transporte e aumentar o tempo de processamento.

- **Manuseio não seletivo de eventos de solicitação:** Quando há vários componentes ouvindo um evento de aplicativo, os desenvolvedores devem garantir que o manipulador de evento seja executado apenas quando for realmente desejado e útil. Por exemplo, no Console do Lightning, os componentes contidos em guias que não estão focalizadas ainda podem estar ouvindo, embora não estejam visíveis. Um desenvolvedor pode usar várias técnicas, como usar um item de utilitário em segundo plano como o único ouvinte ou chamar getEnclosingTabId() para determinar se essa instância do componente está delimitada na guia focada para garantir que cada evento seja tratado apenas quando ele for pretendido.

- **Usando o comportamento de publicação de Eventos de plataforma incorretamente:** Os Eventos de plataforma têm dois comportamentos de publicação: Publicar imediatamente e Publicar após confirmação. Pode ser útil usar eventos de plataforma em tempo real para casos de uso, como Registro, em que você deseja publicar o evento de registro independentemente de a transação ser bem-sucedida ou confirmada. No entanto, use Publicar imediatamente com muito cuidado com eventos de plataforma em tempo real. Os eventos podem ser consumidos por assinantes na mesma transação e causar bloqueios de linha ou outras condições de corrida.

### Projetar eventos efetivos

Ao implementar uma arquitetura conduzida por evento, uma das chaves para o sucesso é definir padrões para como os eventos em si são projetados. Os detalhes variarão dependendo dos casos de uso da sua organização, mas aqui estão algumas diretrizes gerais:

- **Determine a estrutura ideal para suas cargas úteis de evento.** Embora tamanhos menores de mensagem reduzam os tempos de processamento, bombardear assinantes com volumes enormes de mensagens pode causar gargalos de desempenho. Talvez seja necessário iterar em seus tamanhos e estruturas de carga útil para encontrar o saldo certo. O MuleSoft e ferramentas ESB semelhantes oferecem a capacidade de projetar cargas úteis personalizadas nas mensagens associadas aos seus eventos, o que pode ajudá-lo a visualizar estruturas de dados para melhorar o desempenho no lado do assinante. (Consulte [Bem-construído – Confiabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html) para obter mais informações.)

- **Pense em seus processos de ponta a ponta.** Certifique-se de que você não esteja criando cenários de "loop infinito", que podem ser difíceis de rastrear depois que as integrações forem implementadas. Um exemplo disso seria dois sistemas que publicam eventos quando os registros são atualizados, ao mesmo tempo que escutam os eventos uns dos outros, que acionam eventos publicados adicionais quando são processados.

  Você pode corrigir esse tipo de antipadrão adicionando lógica a ambos os sistemas que garante que as alterações feitas como resultado de um evento sendo consumido não resultem na publicação de um novo evento. Você também deve documentar todos os seus eventos, seus acionadores associados e os sistemas a jusante que podem ser afetados. Use esta documentação como referência durante sessões de design para ajudar a capturar loops intermináveis e cenários semelhantes o mais cedo possível. (Consulte [Bem-construído - Excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) para obter mais informações.)

- **Usar convenções de nomenclatura comuns entre sistemas.** Convenções de nomenclatura consistentes são uma prática recomendada para todo o desenvolvimento de software, incluindo arquiteturas conduzidas por evento. Reserve tempo para documentar um conjunto de padrões para nomes de evento, estruturas, objetos associados e processos de tratamento de erros para garantir a consistência entre sistemas. (Consulte [Bem-arquitetado - Excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) para obter mais informações.)

## Recursos

<table style="width:100%">
<thead>
<tr><th scope="col">Padrão</th><th scope="col">Recursos</th></tr>
</thead>
<tbody>
<tr><td>Publicar/Assinar</td><td><a href="/docs/architect/pt-br/well-architected/guide/reliability.html">Salesforce bem-construído - Confiabilidade</a><br><a href="/docs/architect/pt-br/well-architected/guide/operational-excellence.html">Salesforce bem-construído - Excelência operacional</a><br><a href="https://medium.com/salesforce-architects/achieve-architectural-efficiency-with-event-relays-c8d4ec7f07af">Blog Post: Alcance eficiência arquitetônica com retransmissões de evento</a><br><a href="https://medium.com/salesforce-architects/announcing-pub-sub-api-generally-available-3980c9eaf0b7">Blog Post: Anúncio da API Pub/Sub disponível ao público em geral</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/moving-from-restful-to-eventful/">Blog Post: Mudar de RESTful para EVENTFUL</a><br><a href="https://blogs.mulesoft.com/dev-guides/event-driven-architectures-asyncapi/">Blog Post: Arquiteturas conduzidas por evento e a especificação da AsyncAPI</a><br><a href="https://youtu.be/0WJjmmw1ryM">Vídeo: Publicar / Assinar guia passo a passo</a> do padrão</td></tr>
<tr><td>Fanout</td><td><a href="https://developer.salesforce.com/blogs/2021/08/how-to-work-within-platform-events-delivery-limits">Blog Post: Como trabalhar dentro dos limites de entrega de eventos da plataforma</a><br><a href="https://youtu.be/zSncRUcucEU">Vídeo: Guia passo a passo</a> do padrão do Fanout</td></tr>
<tr><td>Mensagens passadas</td><td><a href="https://youtu.be/U87nErhMuqw">Vídeo: Guia passo a passo do padrão de mensagens passadas</a></td></tr>
<tr><td>Streaming</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">Blog Post: Projetar gravações de alto volume no Salesforce</a><br><a href="https://youtu.be/-_1CDUI40fY">Vídeo: Guia passo a passo</a> do padrão de streaming<br><a href="https://docs.mulesoft.com/mule-runtime/4.3/streaming-about">Documentação: Streaming em aplicativos Mule</a></td></tr>
<tr><td>Fila</td><td><a href="https://medium.com/salesforce-architects/designing-for-high-volume-writes-in-salesforce-285689a08100">Blog Post: Projetar gravações de alto volume no Salesforce</a><br><a href="https://blogs.mulesoft.com/dev-guides/api-design/event-payment-apis/">Blog Post: Como projetar arquiteturas de pagamento com APIs com evento</a><br><a href="https://youtu.be/jQvSKbMRbh0">Vídeo: Guia passo a passo</a> do padrão de enfileiramento</td></tr>
</tbody>
</table>

<!-- document id=23d86a69d453e0a7c21f1971b671fb115204c81aff7bad3facfb678e02cda29d url=/architect/current/pt-br/decision-guides/guides/record-triggered.md -->

# Automação acionada por registro

A Salesforce Platform avançou continuamente sua arquitetura de automação para atender às demandas de processos de negócios complexos. Gerações anteriores, as Regras de fluxo de trabalho e o Criador de processos, forneciam as etapas iniciais na lógica conduzida por evento, expandindo os recursos de automação para lógica conduzida por evento e ampliando o alcance para uma gama mais ampla de criadores.

Essa evolução culminou em uma arquitetura consolidada de alto desempenho centrada em dois pilares complementares: Fluxo acionado por registro e acionadores do Apex.

## Visão geral do guia

Este documento fornece a estrutura e as diretrizes para tomar decisões fundamentadas ao projetar automações de acionador. Ele balanceia os requisitos de caso de uso com relação a três principais pontos de decisão que o conduzirão para escolher a abordagem certa para automação acionada por alterações em registros do Salesforce.

## Produtos no escopo

<table style="border:none">
  <tbody>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Fluxo</td>
      <td style="vertical-align:middle;border:none;padding:0.25rem 0">O <a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Fluxo Salesforce</a> é uma ferramenta avançada de automação de apontar e clicar que permite aos usuários criar processos comerciais complexos, telas e lógica visualmente usando o Flow Builder, sem escrever código. Ele automatiza tarefas como atualizações de dados, envio de emails e orientação de usuários, oferecendo flexibilidade por meio de tipos como Fluxos de tela (interação do usuário) e Fluxos acionados (eventos de registro/agendamento).</td>
    </tr>
    <tr style="border:none">
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0">Apex</td> 
      <td style="vertical-align:middle;border:none;padding:0.25rem 0">O <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a> é uma linguagem de programação proprietária e orientada a objetos para a plataforma Salesforce, semelhante a Java, usada para criar lógica de negócios personalizada, automatizar processos e estender as principais funcionalidades do CRM além das ferramentas declarativas.</td>
    </tr>
  </tbody>
</table>

## Capturas

A criação de automação acionada por registro escalonável, mantida e de desempenho no Salesforce Platform requer uma abordagem disciplinada e orientada por arquitetura. A escolha entre o Fluxo e o Apex, e a implementação de cada um, é guiada por um conjunto claro de princípios. Esses pontos resumem esses princípios e servem como as regras fundamentais para o design de automação moderna.

- **Escolha a ferramenta certa para o trabalho com base na densidade de automação do Salesforce Object.**

  - Use o Fluxo acionado por registro para objetos do Salesforce para automações de **baixa densidade**.

  - Aumente a lógica de fluxo acionado por registro com o Apex invocável para automações de **densidade média**.

  - Use acionadores do Apex para objetos do Salesforce para automações de **alta densidade**.

- **Tome cuidado ao acionar processos assíncronos.**  
  Essa regra se aplica se você está invocando processos assíncronos em um fluxo acionado por registro ou enfileirando um trabalho enfileirável do Apex. Embora esse padrão possa ser tentador para descarregar o trabalho, ele pode introduzir cenários complexos de tratamento de erros e aumentar o risco de atingir os limites do regulador.

- **Use um ponto de entrada por objeto do Salesforce.**  
  Para um determinado Objeto do Salesforce, use um mecanismo como seu ponto de entrada para automação. Tente evitar misturar acionadores de Fluxo e Apex como pontos de entrada para o mesmo Objeto.

## Pontos de decisão

Há três principais pontos de decisão a serem considerados:

- Implementação declarativa versus programática
- Densidade de automação
- A matriz de seleção de densidade

### Implementação declarativa versus programática

O Fluxo e o Apex compartilham um conjunto comum de recursos fundamentais. Cada ferramenta pode consultar registros, executar lógica condicional, atribuir variáveis e realizar operações DML, como criar, atualizar e excluir registros, sequenciados para execução em uma ordem especificada.

No entanto, essa sobreposição funcional não implica que as ferramentas sejam intercambiáveis. A escolha da arquitetura não é sobre _se_ uma tarefa pode ser realizada, mas sobre _como_ ela é realizada e quais são as implicações a longo prazo para o desempenho, a escalabilidade e a capacidade de manutenção. O Fluxo se destaca em clareza declarativa e velocidade de implementação para processos simples, enquanto o Apex fornece o controle granular e a potência bruta necessárias para soluções complexas.

### Densidade de automação

A **densidade de automação** é a carga colocada em um objeto do Salesforce específico. Ele serve como uma heurística para determinar a implementação ideal do objeto. Conforme a densidade de automação aumenta, aumenta a probabilidade de violar limites transacionais.

Calcule a densidade de automação inspecionando três dimensões específicas de volume e complexidade:

- **Quantidade de automação:** O número bruto de entradas de metadados de automação exclusivas (fluxos, ações de acionador e assim por diante) que são executadas durante um único evento de Linguagem de manipulação de dados (DML).

- **Volume de registro:** Os registros por transação processados por meio de carregamentos de API ou processamento em lote pesado, em que o desempenho se torna crítico.

- **Despansão da dependência:** Uma medida das operações de DML a jusante acionadas pela operação CRUD inicial. Ele quantifica a profundidade do gráfico em que uma atualização se encaixa em atualizações em objetos relacionados (por exemplo, caso → conta → contato → totalização personalizada).

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/automation-density.png" alt="Dimensões de densidade de automação">

Conforme o escopo e a complexidade do seu aplicativo Salesforce aumentam, confirme-se com um único ponto de entrada principal: Fluxo acionado por registro ou Acionadores do Apex. Evite particionar automações entre vários mecanismos em um único objeto do Salesforce, pois isso leva à má capacidade de manutenção e à fragmentação da governança.

### A matriz de seleção de densidade

Use essa matriz para determinar o padrão de arquitetura necessário para seu objeto do Salesforce.

- O **Fluxo acionado por registro** é a solução preferida para baixa densidade de automação. Ele oferece um equilíbrio de poder e acessibilidade ideal para automações diretas e independentes umas das outras.

- **O padrão híbrido (Fluxo acionado por registro com Apex invocável)** é uma escolha poderosa e manejável para automações de média densidade com complexidade crescente. Esse padrão permite que as equipes mantenham a coreografia ordenada no Fluxo declarativo enquanto delegam operações pesadas em computação ao Apex, equilibrando acessibilidade e desempenho.

- Os acionadores **Apex** fornecem os blocos de construção necessários para uma base arquitetônica sólida para suportar automações de alta densidade. O desempenho, o controle granular e a abstração e o polimorfismo orientados a objetos do Apex são mais adequados para gerenciar a complexidade e a escala desses cenários.

<table>
  <thead>
    <tr>
      <th scope="col" style="width:8%">Nível de densidade</th>
      <th scope="col" style="width:18%">Quantidade de automação</th>
      <th scope="col">Volume de dados (tamanho do lote)</th>
      <th scope="col">Sprawl de dependência</th>
      <th scope="col">Padrão arquitetônico</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Baixo</b></td>
      <td><b>&lt; 15</b><br>
        Automações</td>
      <td><b>Padrão</b><br>
        Interações de interface do usuário orientadas pelo usuário ou cargas de API pequenas (1 a 200 registros)</td>
      <td><b>Discreto</b><br>
        Lógica independente. 0 a 1 operações de DML a jusante no mesmo objeto ou em um objeto relacionado.</td>
      <td><b>Fluxo acionado por registro</b></td>
    </tr>
    <tr>
      <td><b>Médio</b></td>
      <td><b>15–30</b><br>
        Automações</td>
      <td><b>Moderar</b><br>
        Processamento em lote padrão (com lógica que requer massificação cuidadosa)</td>
      <td><b>Acoplado</b><br>
        Pai/filho atualiza de 2 a 4 operações de DML a jusante. Risco de recursão</td>
      <td><b>Padrão híbrido</b><br>
        Fluxo + Apex invocável</td>
    </tr>
    <tr>
      <td><b>Alto</b></td>
      <td><b>> 30</b><br>
        Automações</td>
      <td><b>Alto</b><br>
        Grandes volumes de dados com carregamentos de API em massa (2.000 a 10.000 registros)</td>
      <td><b>Complexo e Recursivo</b><br>
        Gráfico de dependência profunda (5 operações DML a jusante). Risco de loops de recursão triangular</td>
      <td><b>Apex Trigger Metadata Framework</b></td>
    </tr>
  </tbody>
</table>
As decisões de arquitetura do mundo real exigem que você pondera todas as dimensões da densidade de automação coletivamente. Considere o possível escopo futuro ao selecionar um mecanismo de automação para um determinado objeto do Salesforce.

Além disso, considere o número total diário de operações de DML, pois o Salesforce impõe o gerenciamento compartilhado de recursos em um ambiente de vários locatários e os [limites de governador](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm) para evitar que as automações de fuga monopolizem recursos compartilhados. Objetos do Salesforce com alto volume diário de DML exigem seleção de automação cuidadosa. Por exemplo, limites assíncronos para tempo de CPU (60.000 ms) e tamanho de heap (12 MB) são maiores que limites síncronos. Além disso, o limite de 24 horas para toda a organização em execuções assíncronas (calculado como 250 mil, ou 200 vezes suas licenças de usuário) exige a consideração do DML diário total em seu design arquitetônico para evitar exceções de tempo de execução.

## Comparação de produto

O Fluxo acionado por registro é a principal ferramenta declarativa da plataforma para automação acionada por registro. A facilidade de uso do fluxo e as proteções de plataforma integradas permitem que as equipes criem facilmente soluções escalonáveis e confiáveis. É a escolha ideal para a maioria das equipes criando soluções na plataforma Salesforce.

Apex é a linguagem de programação proprietária da plataforma, fortemente tipada e orientada a objetos. Use Apex para objetos do Salesforce com alta densidade de automação e para casos de uso que exigem alto desempenho, lógica sofisticada ou controle granular sobre transações.

Para ajudar no processo de tomada de decisão, esta matriz fornece uma comparação direta de Fluxo e Apex entre os principais recursos de arquitetura.

<table>
  <thead>
    <tr>
      <th scope="col">Capacidade</th>
      <th scope="col">Fluxo acionado por registro</th>
      <th scope="col">Acionador do Apex</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Velocidade de entrega e manutenção</b></td>
      <td><b>Recomendado</b><br>
        A interface de usuário visual do Flow Builder permite que administradores e outros criadores declarativos criem e modifiquem automações mais rapidamente do que escrever, testar e implementar Apex code. Essa interface permite que uma gama mais ampla de membros da equipe ofereça valor comercial e reduza a dependência de recursos de desenvolvedor especializados para tarefas simples.</td>
      <td><b>Requer conhecimento</b><br>
        O Apex exige que desenvolvedores de software habilitados para implementar, testar e manter o código.</td>
    </tr>
    <tr>
      <td><b>Modularidade</b></td>
      <td><b>Disponível</b><br>
        Fluxos acionados por registro são modulares por padrão. Em vez de lógica monolítica, as equipes criam fluxos separados para requisitos específicos e os coreografam juntas usando o Explorador do Acionador de fluxo. Essa modularidade permite a modificação isolada e a extensão simples, reduzindo significativamente o custo de propriedade de longo prazo.</td>
      <td><b>Disponível</b><br>
        O Apex é dividido em módulos funcionais por design. Cada classe do Apex tem como objetivo implementar um único módulo de funcionalidade.</td>
    </tr>
    <tr>
      <td><b>Visibilidade e governança</b></td>
      <td><b>Recomendado</b><br>
        A natureza visual do Fluxo fornece uma representação intuitiva da lógica de negócios. O Explorador do acionador de fluxo fornece uma visualização consolidada de todos os fluxos em um objeto, tornando mais fácil para arquitetos e administradores entenderem, governarem e solucionarem problemas sem lerem código.</td>
      <td><b>Requer conhecimento</b><br>
        Usar uma estrutura de metadados para organizar acionadores é vantajoso, mas o Apex exige uma equipe de desenvolvimento disciplinada para manter o código organizado e mantido.</td>
    </tr>
    <tr>
      <td><b>Processamento de dados em massa de alto desempenho</b></td>
      <td><b>Não recomendado</b><br>
        Há um maior risco de atingir os limites do controlador ao lidar com lógica complexa ou grandes volumes de dados.</td>
      <td><b>Recomendado</b><br>
        O Apex code é executado mais próximo dos serviços centrais da plataforma e oferece aos desenvolvedores um controle aprimorado sobre a otimização de consultas, o tratamento de dados e a eficiência algorítmica. Isso resulta em melhor desempenho e escala, especialmente em cenários complexos que envolvem grandes volumes de dados.</td>
    </tr>
    <tr>
      <td><b>Lógica robusta e estruturas de dados</b></td>
      <td><b>Disponível</b><br>
        O <a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">Elemento Transformação de Fluxo</a> pode ajudar com algumas tarefas complexas de processamento. No entanto, o Fluxo não tem estruturas de dados Mapear e Definir nativas, tornando o processamento de dados complexo complicado e computacionalmente ineficiente.</td>
      <td><b>Recomendado</b><br>
        O Apex oferece acesso total a loops Map, Set e Programmatic para manipulação de dados altamente eficiente e segura em massa. Como uma linguagem de programação com recursos completos, o Apex também oferece acesso a construções lógicas complexas, estruturas de dados e padrões de design que podem ajudar a resolver problemas de negócios complexos de forma mantida e eficiente. O Apex inclui uma rica biblioteca padrão de funções avançadas (por exemplo, BusinessHours, Crypto) que atualmente não estão disponíveis em ferramentas declarativas.</td>
    </tr>
    <tr>
      <td><b>Controlo da transação</b></td>
      <td><b>Não disponível</b><br>
        O fluxo não fornece acesso a operações de DML `Database.savepoint`, `Database.rollback` ou parcialmente bem-sucedidas para confirmações ou reversões de transações parciais.</td>
      <td><b>Disponível</b><br>
        O Apex fornece controle completo e granular sobre a integridade da transação e cenários complexos de recuperação de erros.</td>
    </tr>
    <tr>
      <td><b>Distribuição de email</b></td>
      <td><b>Recomendado</b><br>
        Enviar alertas por email pré-configurados de um fluxo acionado por registro é fácil e escalonável. Alertas por email personalizados podem ser elaborados e distribuídos no tempo de execução. Emails personalizados estão sujeitos a <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">limites diários de envio de email</a>.</td>
      <td><b>Disponível</b><br>
        O Apex pode gerar e enviar mensagens de email personalizadas. Todos os emails enviados do Apex estão sujeitos aos <a href="https://help.salesforce.com/s/articleView?id=000381534&type=1">limites diários de envio de email</a>.</td>
    </tr>
    <tr>
      <td><b>Aplicando salvaguardas de plataforma</b></td>
      <td><b>Recomendado</b><br>
        O fluxo inclui proteções integradas, como massificação automática e novas tentativas automáticas. Essas proteções aumentam a velocidade de valorização e impedem armadilhas de desempenho que exigem codificação manual complexa.</td>
      <td><b>Implementação manual necessária</b><br>
        Proteções como massificação devem ser codificadas explicitamente (por exemplo, gerenciar coleções e evitar SOQL dentro de loops). As novas tentativas automáticas não são nativas de acionadores e exigem a implementação de uma lógica personalizada complexa.</td>
    </tr>
    <tr>
      <td><b>Processamento assíncrono</b></td>
      <td><b>Disponível</b><br>
        O Fluxo oferece mecanismos fáceis para automações que exigem uma transação separada em um caminho assíncrono. Essas automações estão sujeitas a limites diários.</td>
      <td><b>Disponível</b><br>
        O Apex permite o controle total por meio da Captura de dados de alteração e eventos enfileiráveis que são tratados por um assinante de acionador desacoplado.</td>
    </tr>
    <tr>
      <td><b>Processamento agendado</b></td>
      <td><b>Recomendado</b><br>
        Os caminhos agendados do fluxo fornecem uma funcionalidade de agendamento exclusiva e eficiente (por exemplo, "desligar 3 dias antes da data de fechamento"). Essa funcionalidade inclui cancelamento automático e reagendamento se os dados do registro mudarem. Essas automações estão sujeitas a limites diários.</td>
      <td><b>Não disponível</b><br>
        Um acionador do Apex não pode agendar nativamente um evento temporal específico do registro com cancelamento automático. Embora o Apex agendado exista, é um mecanismo fundamentalmente diferente que é executado em um horário específico e não é agendado durante o processamento de um registro individual como parte de um acionador.</td>
    </tr>
    <tr>
      <td><b>Ordenamento e coreografia</b></td>
      <td><b>Disponível</b><br>
        O Explorador do acionador de fluxo permite que os administradores definam uma ordem de execução relativa para vários fluxos no mesmo objeto.</td>
      <td><b>Disponível</b><br>
        Uma estrutura de acionador fornece controle granular sobre a ordem exata das automações.</td>
    </tr>
    <tr>
      <td><b>Atualizações de campo de mesmo registro</b></td>
      <td><b>Disponível (antes de salvar)</b><br>
        O Fluxo acionado por registro é a opção declarativa de melhor desempenho para atualizar o registro acionador antes da confirmação DML inicial.</td>
      <td><b>Disponível (antes de salvar)</b><br>
        O Apex oferece o melhor desempenho com pouca sobrecarga.</td>
    </tr>
    <tr>
      <td><b>CRUD de objeto cruzado</b></td>
      <td><b>Disponível (depois de salvar)</b><br>
        O fluxo é adequado para operações de DML de objeto cruzado simples e de baixa complexidade.</td>
      <td><b>Disponível (depois de salvar)</b><br>
        O Apex oferece controle superior sobre a remoção de duplicação, o tratamento de erros e o desempenho para operações DML entre objetos.</td>
    </tr>
    <tr>
      <td><b>Deduplicação de cálculos caros</b></td>
      <td><b>Disponível</b><br>
        O fluxo se destaca na eliminação de consultas redundantes e instruções DML por meio de massificação automática. No entanto, o estado não pode ser armazenado em cache ou compartilhado entre diferentes acionadores de fluxo ou entre várias invocações do mesmo fluxo em uma transação. Essa limitação pode se tornar importante em cenários de desempenho extremo.</td>
      <td><b>Recomendado</b><br>
        O Apex fornece mecanismos para desduplicar operações caras. Os desenvolvedores podem aproveitar o armazenamento em cache transacional usando propriedades e variáveis estáticas e o armazenamento em cache no nível da plataforma usando o Cache da plataforma para armazenar e reutilizar dados. Essas técnicas são importantes para reduzir o consumo de limites de controlador transacional, como consultas SOQL, e garantir alto desempenho e escalabilidade.</td>
    </tr>
    <tr>
      <td><b>Tratamento de erros personalizados</b></td>
      <td><b>Disponível</b><br>
        O elemento CustomError pode bloquear uma operação de salvamento e exibir uma mensagem ao usuário.</td>
      <td><b>Recomendado</b><br>
        O método <code>addError()</code> fornece mensagens de erro condicionais e em nível de campo flexíveis.</td>
    </tr>
  </tbody>
</table>

## Casos de uso

Para enfatizar melhor como usar os pontos de decisão para orientar suas decisões, considere os seguintes casos de uso e pontos de análise associados.

### Recomendações de melhor ajuste

Esta tabela fornece recomendações gerais de "melhor ajuste" para casos de uso gerais com base nos recursos apresentados. Finalmente, você considerará considerações adicionais para chegar a um melhor ajuste para seus cenários específicos, como aqueles incluídos na seção _Melhores práticas relacionadas_ deste documento. Lá, você aprenderá mais sobre quando uma determinada combinação de Fluxo e Apex fornece a melhor abordagem.

<table>
  <thead>
    <tr>
      <th scope="col">Caso de uso</th>
      <th scope="col">Descrição</th>
      <th scope="col" style="width:16%">Melhor ajuste</th>
      <th scope="col" style="width:38%">Racionalidade</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Processamento em lote de alto desempenho</b></td>
      <td>Qualquer automação que precise processar milhares de registros de maneira eficiente</td>
      <td>Apex</td>
      <td>O Apex fornece APIs avançadas para interface com a plataforma e velocidade bruta.</td>
    </tr>
    <tr>
      <td><b>Processamento de dados complexo</b></td>
      <td>Cenários que exigem manipulação de dados avançada</td>
      <td>Apex</td>
      <td>O Apex fornece estruturas de dados, como Mapa e Conjunto, que não estão disponíveis nativamente no Fluxo e podem ser essenciais para escrever um código de alto desempenho e seguro em massa.</td>
    </tr>
    <tr>
      <td><b>Controle transacional</b></td>
      <td>Controlar mecanismos como pontos de salvamento, reversões e confirmações parciais</td>
      <td>Apex</td>
      <td>O Apex fornece acesso a mecanismos como Database.savepoint e Database.rollback e tem a capacidade de processar operações DML parcialmente bem-sucedidas.</td>
    </tr>
    <tr>
      <td><b>Validação personalizada sofisticada</b></td>
      <td>Validação de dados em vários campos em um registro</td>
      <td>Apex</td>
      <td>Embora o Fluxo possa impedir uma gravação com o elemento `CustomError', ele não está disponível em todos os tipos de fluxo, incluindo subfluxos. O método Apex <code>addError()</code> fornece várias mensagens de erro específicas do campo que podem ser adicionadas a um registro a qualquer momento durante o processamento do acionador.</td>
    </tr>
    <tr>
      <td><b>Lógica moderadamente complexa em um processo simples</b></td>
      <td>Lógica e manipulação de dados de complexidade moderada, simplificada por uma biblioteca padrão de funções avançadas, que ocorre como parte de um processo não complicado</td>
      <td>Fluxo + Apex</td>
      <td>O Fluxo acionado por registro atua como a camada de orquestração, enquanto operações de alta complexidade são encapsuladas no Apex invocável.</td>
    </tr>
    <tr>
      <td><b>Lógica simples a moderadamente complexa</b></td>
      <td>Manipulação de dados de baixa a moderada complexidade, com atualizações de acionador para os objetos de dados primários e relacionados</td>
      <td>Fluxo</td>
      <td>O fluxo costuma ser a opção recomendada, pois é baseado em um modelo declarativo que o torna acessível a administradores e desenvolvedores.</td>
    </tr>
    <tr>
      <td><b>Notificações e mensagens de saída</b></td>
      <td>Enviar emails e mensagens de saída</td>
      <td>Fluxo</td>
      <td>O fluxo torna o envio de alertas por email e mensagens de saída em alterações de registro fácil e altamente escalonável.</td>
    </tr>
    <tr>
      <td><b>Processamento agendado</b></td>
      <td>Automação em uma data futura e dinâmica (por exemplo, três dias antes de uma data de fechamento)</td>
      <td>Fluxo</td>
      <td>Os caminhos agendados fornecem um poder exclusivo ao Fluxo, pois a plataforma gerencia automaticamente o agendamento, o cancelamento e o reagendamento desses caminhos se os dados do registro mudarem.</td>
    </tr>
  </tbody>
</table>

### Processamento dimensionável: Casos de uso assíncronos em profundidade

A escalabilidade é uma consideração crítica ao projetar sua implementação. Quando a lógica de negócios de uma automação acionada por registro se torna complexa, de longa duração ou envolve grandes volumes de dados, os limites principais do controlador da Salesforce Platform se tornam uma restrição arquitetônica. Operações como atualizações de dados em massa, chamadas de API complexas ou cálculos pesados aumentam o risco de violar limites, como o tempo total de CPU ou o número de instruções DML em uma única transação de banco de dados. Uma falha em um acionador síncrono devido a uma exceção de limite fará com que toda a transação de salvamento do usuário seja revertida, resultando em má experiência do usuário e possível perda de dados. Esse risco inerente exige um padrão arquitetônico para descarregar trabalho complexo.

A automação assíncrona se torna essencial nesse caso. Usando mecanismos assíncronos, os arquitetos podem efetivamente desconectar o trabalho de longa duração ou de alto volume da transação de salvamento de registro síncrona principal. Salva com rapidez e confiabilidade, enquanto o processamento pesado é delegado a uma transação gerenciada por plataforma separada que é executada mais tarde. A desacoplamento melhora a estabilidade, evita falhas de transação e é essencial para criar aplicativos corporativos dimensionáveis. A plataforma oferece várias ferramentas especializadas para isso, cada uma com benefícios e compensações distintos em termos de confiabilidade, volume e complexidade.

### Caminho assíncrono do fluxo

O caminho Executar de modo assíncrono em um fluxo acionado por registro fornece o mecanismo mais simples para lógica assíncrona "apagar e esquecer". Esse caminho é executado em uma transação separada depois que a transação de salvamento de registro original foi confirmada com sucesso no banco de dados.

- **Caso de uso ideal**: Isso é adequado para tarefas que não exigem execução imediata ou tratamento de erros personalizados. Exemplos incluem enviar uma notificação por email, criar uma tarefa de acompanhamento ou fazer uma chamada simples para um sistema externo.

- **Limitações**: Esse mecanismo compartilha os mesmos limites de controlador diários de outras entrevistas de fluxo assíncronas. Ele não foi projetado para processamento de alto volume.

### Captura de dados de alteração (CDC)

A Captura de dados de alteração (CDC) é um padrão de alto rendimento, escalonável e resiliente para lidar com lógica assíncrona acionada por uma mudança de registro em cenários de alto volume. Nesse modelo, a única responsabilidade do acionador é salvar o registro de modo síncrono. A plataforma então publica uma mensagem de evento detalhada que contém as alterações do registro em um barramento de evento de alto volume. Um acionador do Apex dedicado separado assina esse evento de alteração. Ele realiza trabalhos complexos, de longa duração ou assíncronos.

- **Benefício**: Esse padrão desconecta o processo assíncrono da transação do usuário inicial. Uma falha no processamento assíncrono não fará com que o salvamento do registro do usuário seja revertido. O padrão também fornece um fluxo de eventos durável que vários assinantes internos ou sistemas externos podem consumir, e os eventos podem ser repetidos por até 72 horas, proporcionando uma forte resiliência.

- **Limitações**: As mensagens de evento CDC não contêm o estado anterior do registro, o equivalente a um `Trigger.oldMap` do Apex. A carga útil do evento inclui os novos valores de campo, mas não os valores dos quais ele mudou. Isso torna difícil implementar lógica com base em uma transição de estado específica (por exemplo, executar apenas se o `Status__c` mudou de "Pensando" para "Aprovado"). Você pode mitigar isso consultando o histórico de campo do objeto no assinante do evento, mas isso aumenta a complexidade do processo e o rastreamento de histórico de campo pode não estar disponível para o campo específico de interesse. Isso pode limitar os tipos de automação que você pode descarregar para a CDC.

Por padrão, o CDC pode ser habilitado em no máximo cinco objetos do Salesforce. As organizações que precisam de mais podem comprar uma licença complementar que remova esse limite e aumenta as alocações de entrega de eventos.

### Apex enfileirável de um acionador

Encolher um trabalho do Apex enfileirável diretamente de um acionador deve ser considerado um padrão arriscado, usado apenas quando o controle fornecido pelo Apex é necessário (por exemplo, para lógica complexa ou mecanismos de repetição personalizados), e o CDC não é uma opção viável.

Se o Apex enfileirável for necessário, a implementação deverá incluir salvaguardas adequadas:

- **Verificações de limite**: O código deve verificar o número de trabalhos já enfileirados na transação antes de tentar adicionar outro.

  ```
  if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... }
  ```

- **Contextualização**: O código deve detectar se está sendo executado em um contexto assíncrono, como um trabalho em lote (`System.isBatch()`), e modificar seu comportamento para cumprir o limite mais rígido de um trabalho por transação nesse contexto.

### Considerações de limite para o Apex assíncrono acionado

A invocação do Apex assíncrono de um acionador síncrono introduz riscos de estabilidade. Para evitar o impacto no nível da organização (por exemplo, exceder limites), esse padrão requer um design e testes rigorosos.

- O limite diário para execuções assíncronas do Apex (`Batch`, `Queueable`, `@Future`) é compartilhado entre a organização (geralmente 250.000 ou um cálculo baseado em licenças de usuário). Um carregamento de dados em massa de 20 mil registros fará com que um acionador seja executado em blocos de 200, resultando em 100 invocações de acionador separadas, ainda mais se o tamanho do lote em massa for inferior a 200 registros. Se cada chamada enfileirar um trabalho assíncrono, uma parte significativa do limite diário de um único carregamento de dados poderá ser consumida. Esse consumo pode prejudicar outros processos de negócios críticos de recursos assíncronos.

- Os limites do controlador para enfileirar trabalhos são drasticamente diferentes dependendo do contexto. A partir de um acionador acionado por uma ação do usuário na interface do usuário (uma transação _síncrona_), até 50 trabalhos enfileiráveis podem ser enfileirados. No entanto, a partir de um acionador acionado no método de `execute` de uma classe do Apex em lote (uma transação _assíncrona_), apenas um trabalho enfileirável pode ser enfileirado. Não levar em conta essa diferença é um ponto de falha comum e crítico, levando a erros de `LimitException` durante operações de dados grandes.

- Chamar Apex programável (`System.schedule`) ou Apex em lote (`Database.executeBatch`) diretamente de um contexto de acionador constitui um antipadrão. Esses métodos não foram projetados para serem chamados do contexto do acionador. Isso levará a um consumo rápido da alocação assíncrona do Apex, resultando em exceções de limite.

### Escolher o padrão assíncrono certo

Cada mecanismo assíncrono tem compensações específicas em relação ao desempenho, limites do controlador e confiabilidade. Use essa árvore de decisão como guia para ajudá-lo a navegar por essas opções e escolher o mecanismo certo para seu caso de uso.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/async-pattern.png" alt="Árvore de decisão de padrão assíncrono">

### A alternativa de trabalho agendado

Como o fluxograma indica, quando você está enfrentando operações de DML de alto volume, mas não pode usar a Captura de dados de alteração (talvez devido a limites de objeto), a melhor escolha arquitetônica é muitas vezes evitar um processo invocado por acionador completamente.

Em vez disso, considere usar um processo agendado. Isso pode ser um Fluxo agendado ou Apex agendado. As etapas necessárias são:

1. Realize uma atualização simples e de baixo custo no acionador síncrono. Por exemplo, defina um campo de `Status__c` como "processamento pendente" ou insira um registro relacionado a baixo custo, como uma publicação do Chatter, para indicar que o registro precisa ser processado.

2. Crie um trabalho agendado, seja um fluxo agendado ou Apex agendado, que é executado periodicamente, como a cada 15 minutos ou a cada hora.

3. Tenha a consulta de trabalho agendada para todos os registros no estado pendente, execute a lógica complexa em um contexto controlado e de alto volume e atualize os registros conforme processados.

Esse padrão desconecta totalmente o processamento pesado do salvamento síncrono do usuário, não está sujeito ao limite de um trabalho por transação de um lote acionado pelo acionador e fornece uma solução altamente escalonável e regulável para requisitos não em tempo real.

Se a latência de um trabalho agendado não for aceitável para os requisitos de negócios e você ainda estiver impedido de usar o CDC ou uma fila acionada pelo acionador, isso indicará uma incompatibilidade arquitetônica significativa. Nesse ponto, diferentes mecanismos devem ser considerados. Reavaliar o design do aplicativo principal pode levar a determinadas conclusões, como:

- Comprar o complemento para remover limites de objeto da CDC.

- Desafiar fundamentalmente o requisito de negócios para determinar se o processamento quase em tempo real é realmente um "must-have" ou se a latência de um trabalho agendado é uma compensação aceitável para a estabilidade da plataforma.

## Considerações não funcionais

Além dos pontos de decisão, você precisará considerar considerações não funcionais, como complexidade e padrões.

### Complexidade

O nível de complexidade em uma implementação faz parte do custo total de propriedade de uma solução, bem como sua capacidade de se adaptar a mudanças nos requisitos de negócios. A complexidade pode afetar qualquer implementação se as práticas recomendadas não forem seguidas. Na seção Práticas recomendadas _relacionadas_ deste documento, há recomendações para reduzir a complexidade da sua solução, incluindo estes padrões:

- Padrão híbrido: Apex invocável para lógica complexa no fluxo

- Usando uma estrutura de metadados para acionadores do Apex

- Mega-fluxos vs. vários fluxos

### Processos e padrões

A documentação é tão importante quanto a automação em si. Não apenas garante a capacidade de manutenção, mas também é essencial para IA e ferramentas baseadas em agente. A documentação ajuda você a entender e gerenciar seus processos de negócios.

**Em fluxo**

- Estabeleça uma convenção de nomenclatura consistente para todos os elementos e variáveis.

- Use o campo Descrição do fluxo para explicar seu propósito geral, critérios de acionador e resultado pretendido.

- Use o campo Descrição em cada elemento individual (por exemplo, `Get Records`, `Action`, `Transform`). Essa prática é a melhor maneira de transmitir a intenção. É especialmente importante para ações e subfluxos invocáveis, em que a descrição é o principal lugar para explicar a lógica complexa realizada pela ação.

**No Apex**

- Comente seu código claramente para explicar o _porquê_ por trás de sua lógica, não apenas o _o quê_.

- Se estiver usando uma estrutura conduzida por metadados, garanta que seus registros de metadados incluam e preencham um campo de Descrição legível por humanos para explicar o que cada classe de manipulador faz e quando ela deve ser executada.

DevOps e controle de origem fazem parte de um ciclo de vida de desenvolvimento maduro. Sempre use uma ferramenta de controle de código-fonte, como Git para projetos do Salesforce. As classes do Apex e os Fluxos do Salesforce são metadados que definem sua lógica de negócios e devem ser controlados e gerenciados com controle de versão.

No contexto do gerenciamento de automações acionadas por registro, um pipeline DevOps moderno oferece benefícios essenciais.

- **Verificações de qualidade automatizadas:** Ferramentas como o [Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview) podem ser configuradas para ser executadas automaticamente em seu pipeline. A análise estática pode detectar padrões problemáticos em ambas as ferramentas de automação antes de serem promovidas, sinalizando problemas como elementos de `Get Records` ineficientes dentro de um loop de Fluxo ou consultas de `SOQL` dentro de um loop do Apex, que são causas comuns de degradação do desempenho.

- **Prevenção de regressão:** Conforme sua densidade de automação aumenta, uma mudança para um Fluxo ou classe do Apex pode ter consequências indesejadas para outras automações no mesmo objeto. Uma estratégia de teste DevOps robusta, em que os testes automatizados do Apex são executados em relação a qualquer alteração proposta, é a maneira mais confiável de garantir que uma nova versão do Fluxo não quebre a lógica do Apex existente (e vice-versa).

- **Colaboração e visibilidade:** O controle de origem é a "única fonte da verdade". Permite que administradores e desenvolvedores trabalhem em automação para o mesmo objeto em paralelo. Ela também fornece uma trilha de auditoria inestimável: Quando um processo de produção é interrompido, você pode ver instantaneamente _quem_ alterou a automação, _quando_ ela foi alterada e — através de mensagens de compromisso — _por que_ ela foi alterada.

Para equipes com uma combinação de administradores e desenvolvedores, o [DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5) fornece uma interface unificada para ajudar a organizar todas essas etapas, tornando um processo de desenvolvimento escalonável e baseado em controle de código-fonte acessível a todos na equipe.

Essa disciplina combinada de documentação e DevOps garante a integridade e a manutenção de longo prazo da sua organização, o que beneficiará todos os arquitetos e administradores que o seguem.

## Melhores práticas relacionadas

O guia de decisão acima é melhor usado antes de planejar sua implementação. Ele tem como objetivo ajudá-lo a escolher o melhor produto para seus casos de uso. Após a seleção do produto, é importante entender as práticas recomendadas existentes para sua implementação.

### Explorar o padrão híbrido: Apex invocável para lógica complexa no fluxo

O princípio _Uma ferramenta por objeto_ é crucial para gerenciar a automação de alta densidade, mas não o interprete como uma escolha binária entre uma pilha puramente declarativa ou puramente programática. Um padrão arquitetônico mais eficaz e mantido aproveita um modelo híbrido: Posicione o Fluxo acionado por registro como a camada de orquestração enquanto encapsula operações de alta complexidade no Apex invocável.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/hybrid-pattern.png" alt="Diagrama de padrão híbrido">

#### A Camada de orquestração: Fluxo

O Fluxo acionado por registro serve como a camada de orquestração para o processo de negócios. Ele é o proprietário dos critérios de entrada e do contexto de execução (o _o que_ e _quando_). Ao reter a lógica de decisão e o roteamento nessa camada, a topologia de processo da arquitetura permanece transparente e gerenciável por meio do Explorador do acionador de fluxo, impedindo que a lógica de negócios crítica seja ocultada no código.

#### O componente complexo: Apex invocável

Um exemplo comum de um componente complexo é a implementação de cálculos de Acordo de nível de serviço (SLA) para registros de Caso. Como o objeto BusinessHours e sua lógica relacionada, essenciais para cálculos precisos que excluem horas de trabalho e feriados, não estão acessíveis nativamente no Fluxo, uma classe do Apex dedicada é usada. Essa classe, muitas vezes chamada de algo como `ServiceLevelAgreementCalculator`, é projetada com um único método estático, anotado com `@InvocableMethod`, para calcular o horário comercial decorrido, determinar se o SLA é "Dentro da meta" ou "Fechado" e retornar uma saída estruturada. Essa abordagem encapsula a lógica complexa e de alto desempenho no Apex, ao mesmo tempo que permite que ela seja executada e integrada na camada de orquestração declarativa de um fluxo acionado por registro.

Depois que a classe `ServiceLevelAgreementCalculator` do Apex for definida, ela estará disponível para uso em um fluxo acionado por registro:

Esse padrão demonstra uma separação rígida das preocupações. A camada declarativa é usada para gerenciar o ciclo de vida da transação e a orquestração enquanto o código é usado para execução de alta complexidade. Ao tratar o código como um utilitário funcional em vez da base, equilibramos o desempenho e a capacidade de manutenção.

#### Principais ganhos com o padrão híbrido

**Modularidade**: A decisão afasta-se da singularidade de usar o Apex ou o Fluxo para todo o processo. Em vez disso, a arquitetura encapsula a lógica complexa em unidades separadas, seguras em massa e testáveis de modo independente. Essas unidades funcionam como componentes reutilizáveis consumidos pela camada declarativa, garantindo as escalas de automação sem complicar o design arquitetônico.

**Reusabilidade**: A lógica é desacoplada do evento de acionador. Uma unidade de código bem projetada (como uma `InvocableMethod`) é escrita uma vez, mas aproveitada em vários pontos de entrada: Fluxos acionados por registro, fluxos de tela ou integrações externas. Essa reutilização de código elimina o desenvolvimento redundante.

**Manutenção**: A lógica de fluxo de processo permanece visível e gerenciável no Fluxo declarativo. Essa centralização reduz drasticamente a sobrecarga de depuração e garante que a ordem de execução do sistema seja determinista e transparente.

#### Limitações e compensações do padrão híbrido

Embora o modelo híbrido de usar o Apex invocável do fluxo seja poderoso, não é uma abordagem unidimensional. Os arquitetos devem estar cientes das limitações e compensações específicas antes de se comprometerem com uma solução híbrida.

- **Nenhum suporte antes de salvar**: Esta é a limitação mais crítica. Ações invocáveis estão disponíveis apenas no contexto após salvar (fluxos para ações e registros relacionados). Eles não podem ser usados no contexto de alto desempenho antes de salvar (fluxos para atualizações de campo rápido). Portanto, esse padrão não pode ser usado para delegar atualizações de campo do mesmo registro. Faça esse trabalho de alto desempenho usando elementos de Fluxo nativos em um fluxo antes de salvar ou em um acionador do Apex antes do contexto.

- **Sem suporte após a exclusão cancelada:** Atualmente, o Fluxo acionado por registro não oferece suporte ao contexto após a exclusão cancelada. Se um objeto do Salesforce tiver um requisito de negócio para executar a automação quando um registro for restaurado da lixeira, um acionador do Apex será a única solução.

- ** Sobrecarga de desempenho em cenários de alto volume:** A transição do tempo de execução do Fluxo para o tempo de execução do Apex não é uma operação de custo zero. Embora geralmente seja rápido, o ato de cair em uma Ação invocável do tempo de execução do Fluxo não é tão rápido computacionalmente quanto a execução nativa que permanece inteiramente dentro de um acionador do Apex. Para a maioria das automações de média densidade, essa sobrecarga é uma compensação insignificante e útil para a maior acessibilidade. No entanto, para cenários de alto desempenho e alto volume, uma estrutura somente do Apex terá uma vantagem de velocidade de computação bruta.

### Estratégias para automação legada

Embora a heurística de densidade de automação forneça orientação definitiva para uma arquitetura de greenfield mais recente, a realidade dos ambientes corporativos do Salesforce costuma ser mais detalhada. Em organizações maduras, é comum encontrar fluxos acionados por registro e acionadores do Apex que operam no mesmo objeto do Salesforce. Esse cenário é distinto do padrão híbrido explicado anteriormente: Aqui, os fluxos e acionadores do Apex não são acoplados nem projetados para trabalharem juntos.

Essa coexistência geralmente é resultado de funcionalidades de plataforma em evolução ou débito técnico legado. Embora esse seja um estado operacional tolerado, os arquitetos devem tratá-lo como uma compensação calculada em vez de um estado final.

A orquestração fragmentada gera uma sobrecarga significativa de governança e manutenção, tornando as atividades de desenvolvimento, teste e tratamento de incidentes desagrupadas e complicadas. Isso leva a um maior Tempo para resolução (TTR) e complexidade operacional.

- Para novos objetos do Salesforce, siga o princípio de densidade de automação como o guia principal.

- Para Objetos do Salesforce existentes com uma pegada híbrida e acionador Apex duplo e pontos de entrada de fluxo acionados por registro, avalie a densidade e, em seguida, arquite para o refator para um estado híbrido mantido.

  - Para baixa densidade, o Apex refator aciona fluxos acionados por registro e especifica a ordem de execução, levando-os a um único ponto de entrada de automação.

  - Para densidade média, o complexo do refator faz megafluxos em um subconjunto de fluxos com a ordem de execução certa. Introduza acionadores do Apex apenas quando absolutamente necessário, por exemplo, para dar suporte após a exclusão de contexto cancelada.

  - Para alta densidade, implemente acionadores do Apex.

### Usando uma estrutura de metadados para acionadores do Apex

Conforme os processos de negócios de uma organização na Salesforce Platform amadurecem, o volume e a complexidade da automação acionada por registro aumentam inevitavelmente. Uma prática recomendada fundamental é manter _um acionador do Apex por objeto do Salesforce_. Essa regra é crítica porque a plataforma não garante a ordem de execução de vários acionadores no mesmo objeto para o mesmo evento. Essa limitação pode levar a comportamentos não deterministas, condições de corrida e problemas de depuração difíceis.

No entanto, aderir ao princípio de _um acionador_ introduz um desafio arquitetônico: como gerenciar e orquestrar toda a lógica de negócios invocada desse único ponto de entrada de maneira mantida e escalonável.

#### As limitações dos manipuladores do acionador clássico

A primeira evolução dessa arquitetura foi o padrão do Manipulador de acionador clássico. Nesta abordagem, o acionador Apex único delega toda a sua lógica a uma classe de manipulador correspondente (por exemplo, `OpportunityTriggerHandler`). Esse método separa a lógica do arquivo de acionador e fornece aos desenvolvedores controle determinístico sobre a ordem de execução dentro dos métodos da classe manipuladora (por exemplo, `afterInsert()`).

Embora seja uma melhoria, esse padrão geralmente leva a classes de manipulador monolíticas. Ao longo do tempo, à medida que mais requisitos de negócios são adicionados, a classe se torna grande, difícil de gerenciar e difícil de testar em isolamento. A ordem de execução de todos os processos individuais é codificada em um único método, tornando a classe propensas a conflitos de mesclagem, aumentando dramaticamente a sobrecarga de governança e manutenção em um ambiente corporativo grande.

#### A solução: Uma estrutura do acionador conduzida por metadados

Para resolver os problemas centrais da modularidade e da orquestração, os arquitetos mudam para uma **Quadro do acionador conduzido por metadados**. Este é um salto arquitetônico significativo que separa a própria lógica de automação da configuração de _como_ e _quando_ ela é executada.

Essa estrutura é baseada em três principais vantagens:

- **Particionamento:** Em vez de uma única classe de manipulador, a lógica de negócios principal é dividida em classes do Apex pequenas e atômicas (por exemplo, uma classe de `RecalculateAccountValues` ou uma classe de `NotifySalesLeads`), com cada classe aderindo ao _Princípio de Responsabilidade Única_. Essa modularidade facilita o teste, a depuração e a compreensão da lógica isoladamente.

- **Ordem e coreografia:** A ordem de execução não é mais codificada no Apex. Em vez disso, é definido declarativamente por registros de configuração, geralmente armazenados em um tipo de metadados personalizado (por exemplo, `TriggerAction__mdt`). Isso permite que os administradores reordene, adicione ou remova ações de automação simplesmente modificando um registro de metadados, o que não requer uma implantação ou alteração de código.

- **Funcionalidade de bypass:** A estrutura fornece uma funcionalidade de desvio granular padronizada. Cada ação de automação pode ser configurada por meio de seu registro de metadados para ser desativada globalmente ou ignorada para usuários administrativos específicos referenciando uma permissão personalizada.

O acionador Apex único para o objeto então serve apenas como um supervisor dinâmico. Ele não contém lógica de negócios, mas instancia uma classe central de `MetadataTriggerHandler`. Esse manipulador consulta os registros de metadados personalizados para determinar dinamicamente a sequência de execução e invocar as classes atômicas Apex corretas na ordem prescrita. A automação é unificada sob uma única camada transparente e governável.

### Removendo operações caras na transação

Uma vantagem importante do uso do Apex em uma estrutura robusta é a capacidade de gerenciar o estado transacional e otimizar o desempenho eliminando o trabalho redundante. Conforme a lógica se acumula, é comum que diferentes automações no pedido de salvamento executem de modo independente as mesmas operações caras, consumindo limites valiosos do regulador e aumentando o tempo de operação de DML.

A estrutura é arquitetada para lidar com isso com duas estratégias principais:

- **Gerenciamento de estado compartilhado:** No escopo de uma única transação do Apex, propriedades estáticas e variáveis são aproveitadas para armazenar dados em cache. Isso garante que uma operação cara, como uma consulta de `SOQL` para uma configuração de configuração, seja executada apenas uma vez, mesmo que a lógica de automação seja invocada várias vezes em diferentes registros ou fases do acionador. O consumo dos limites transacionais é significativamente reduzido.

- **Utilização de cache da plataforma:** Para ir além do simples armazenamento em cache dentro da transação, use o cache da plataforma para evitar consultar todo o banco de dados para determinados dados. Esse cache gerenciado na memória é ideal para recuperar dados que não sejam primitivos, sejam lidos com frequência na base de códigos e sejam imutáveis ao longo de uma transação (por exemplo, perfis, papéis, horário comercial). Usando a interface de `Cache.CacheBuilder`, o sistema verifica o cache primeiro e realiza a consulta de banco de dados apenas se os dados não estiverem presentes, maximizando o desempenho e a escalabilidade.

### Usar antes de salvar para atualizações de mesmo registro

Sempre use uma atualização antes de salvar quando sua automação precisar apenas alterar os valores de campo no registro que inicia a transação. Isso se aplica tanto a atualizações de campo rápido no Fluxo (que são executadas antes de salvar) quanto à lógica antes do contexto nos Acionadores do Apex (antes da inserção, antes da atualização).

Esse padrão tem desempenho, independentemente da ferramenta usada, pois evita uma segunda operação DML e um ciclo de salvamento recursivo. As alterações são feitas no registro na memória _antes_ de ele ser vinculado ao banco de dados e são salvas como parte da transação original. A sobrecarga de um segundo salvamento, que, caso contrário, reexecutaria todo o pedido de salvamento e acionaria toda a automação novamente, é eliminada.

### Evitando recursão não controlada

A recursão não controlada é uma armadilha comum em acionadores após a atualização, em que a lógica de um acionador realiza uma atualização de DML que, por sua vez, faz o mesmo acionador ser disparado novamente. Isso cria um loop infinito que termina com uma exceção de limite do regulador. Embora sinalizadores booleanos estáticos ou coleções de IDs de registro processados tenham sido usados historicamente para evitar essa recursão, um padrão mais preciso e robusto é criar a lógica por meio da comparação de valores de campo entre as versões novas e antigas do próprio registro.

Execute a lógica apenas se um campo específico de interesse tiver realmente mudado. Isso impede que o acionador execute sua lógica em operações de DML subsequentes na mesma transação em que os dados críticos permanecem inalterados.

#### Controlar a recursão no fluxo acionado por registro

Em um fluxo acionado por registro, evite a recursão não controlada definindo o fluxo para ser executado apenas quando o registro for atualizado para atender aos requisitos de condição:

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/recursion-flow.png" alt="Controlando a recursão no fluxo acionado por registro">

Se você optar por usar uma fórmula de critérios de entrada em seu fluxo, poderá evitar a recursão de escape comparando a variável global `$Record` (que representa os novos valores) com a variável global `$RecordPrior` (que representa os valores originais antes do salvamento). Por exemplo, para garantir que um fluxo seja executado apenas se o campo Valor em uma oportunidade tiver sido alterado, use isto nos critérios de entrada:

```
$Record.Amount != $Record__Prior.Amount
```

#### Controlando a recursão no Apex

Compare os valores de campo da nova versão do registro, `Trigger.new`, com os valores de campo da versão antiga do registro, `Trigger.oldMap`, para ver se a alteração específica que você está procurando ocorreu. Essa abordagem garante que a automação seja idempotente e seja executada apenas quando necessário, tornando o sistema mais eficiente e evitando loops recursivos catastróficos.

### Ignorar automação

Uma organização do Salesforce bem arquitetada requer um mecanismo consistente e confiável para contornar a automação. Esse não é um recurso opcional, mas um requisito operacional essencial para manter a integridade dos dados e habilitar tarefas administrativas.

Uma estrutura de desvio é essencial para alguns cenários:

- Ao carregar grandes volumes de dados, acionar acionadores para cada registro pode desacelerar drasticamente o processo, causar exceções de limite e criar registros relacionados e notificações incorretos. Um desvio permite que os dados sejam inseridos de maneira limpa e eficiente.

- Um usuário de integração pode precisar sincronizar dados de um sistema externo de registro. A automação que normalmente é acionada para uma alteração iniciada pelo usuário (por exemplo, enviar um email, criar uma tarefa) pode ser indesejável ou redundante quando a alteração se origina de outro sistema.

- Os administradores ou a equipe de suporte podem precisar realizar atualizações corretivas em registros. Um mecanismo de ignorar permite que eles façam essas alterações sem acionar a automação de negócios padrão, o que pode ter consequências indesejadas.

**Permissões personalizadas**: O padrão moderno e escalonável para implementar a lógica de desvio é permissões personalizadas. Esses métodos são superiores aos métodos mais antigos por diversos motivos:

- **Flexibilidade:** As permissões personalizadas podem ser atribuídas aos usuários por meio de conjuntos de permissões. Essa prática está alinhada ao moderno modelo de segurança e acesso do Salesforce, permitindo uma atribuição granular e flexível. Um desvio pode ser concedido a um usuário específico ou mesmo temporariamente com uma data/hora de expiração específica.

- **Manutenção:** O uso de permissões personalizadas evita que perfis de codificação permanente ou usuários entrem na lógica de automação. Se o papel de um usuário mudar ou um novo perfil precisar ignorar o acesso, a alteração será uma simples atribuição de Conjunto de permissões, não uma modificação de código ou fluxo que exija uma implantação.

- **Escalabilidade:** As permissões personalizadas fornecem uma estrutura dimensionável para gerenciar exceções em uma base de usuários complexa. Eles podem ser atribuídos a usuários por meio de conjuntos de permissões, grupos de conjuntos de permissões ou perfis. Sua associação a um conjunto de permissões ou perfil também é representável nos metadados de origem.

**Padrões de implementação**: Aplique um padrão de desvio consistente a todas as automações acionadas por registro na organização.

**Pular um fluxo acionado por registro**: A maneira mais eficiente de ignorar um fluxo é impedi-lo de ser executado. Isso é feito adicionando uma condição aos critérios de entrada do fluxo.

- No elemento Iniciar do fluxo acionado por registro, defina Requisitos da condição como Fórmula avaliada como verdadeira.

  - No construtor de fórmula, incorpore uma verificação para a permissão personalizada usando a variável global `$Permission`. Combine a verificação com seus critérios de entrada existentes.

    - Padrão de fórmula:

    ```
    ( ) && NOT($Permission.Bypass_This_Flow)
    ```

  - Esse padrão garante que o fluxo seja executado somente se o usuário _não_ tiver a permissão personalizada especificada atribuída. Essa verificação é realizada antes mesmo da criação da entrevista de fluxo, tornando-a a abordagem com melhor desempenho.

**Excluindo uma estrutura de acionador do Apex**: No Apex, integre a lógica de desvio diretamente na estrutura de acionador orientada por metadados, permitindo um controle granular.

- O tipo de metadados personalizados `TriggerAction__mdt` deve incluir um campo de texto, por exemplo, `BypassPermission__c`.

  - Na classe `MetadataTriggerHandler`, antes de executar uma ação dinamicamente, o código deve ler o valor desse campo.

  - Se o campo for preenchido, o manipulador usará o método `FeatureManagement.checkPermission()` para determinar se o usuário em execução atual tem a permissão personalizada especificada.

  - Se `checkPermission()` retornar verdadeiro, o manipulador ignora essa ação específica e avança para a próxima na sequência.

  - Esse padrão é poderoso porque permite tanto um bypass global (se todos os registros de `TriggerAction__mdt` referenciarem a mesma permissão) quanto um bypass granular por ação (se diferentes registros referenciarem permissões diferentes ou se alguns não tiverem permissão de bypass).

### Mega-fluxos vs. vários fluxos

É um antipadrão consolidar toda a automação de um objeto em um único megafluxo maciço. Consolidar em um fluxo versus dividir a lógica em vários fluxos bem condicionados não tem um impacto significativo no desempenho. Os ganhos de desempenho mais significativos vêm de:

- Usar fluxos antes de salvar para atualizações de campo do mesmo registro.

- Escrever condições de entrada precisas para garantir que os fluxos sejam excluídos da execução em alterações que não afetam seu caso de uso específico.

O [Flow Trigger Explorer](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer) permite atribuir um valor de ordem a cada fluxo em um objeto, garantindo uma ordem de execução sequencial.

<img style="border:1px solid #e5e5e5;margin:2rem 0rem" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/record-triggered/trigger-explorer.png" alt="Explorador de acionadores de fluxo">

## Recursos

<table>
  <thead>
    <tr>
      <th scope="col">Apex</th>
      <th scope="col">Fluxo</th>
      <th scope="col">Operações</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">O que é Apex?</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_integration_intro.htm">Apex Utilities</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_about.htm&type=5">Sobre automação com o Salesforce Flow</a></li>
          <li><a href="https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer">Conheça o Explorador do acionador de fluxo</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_ref_elements_transform.htm&language=en_US&type=5">Elemento de transformação de fluxo</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/guide/code-analyzer.html">Analisador de código do Salesforce</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5">DevOps Center</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

<!-- document id=e232dbdb70e30ff95245754954946c766d31785ca09507fc7066c737ebe86792 url=/architect/current/pt-br/decision-guides/guides/determining-agentic-vs-traditional-workflow-automation.md -->

# Determinação da automação de fluxo de trabalho agente e tradicional

Com o Agentforce, as empresas agora podem desbloquear novos paradigmas de trabalho automatizado que não podem ser facilmente reduzidos a regras. Esses novos recursos incluem resolver a intenção do cliente de conversas não estruturadas, coordenar processos de várias partes entre sistemas e responder a condições operacionais em tempo real. Fluxos de trabalho agentes usam automação projetada para justificar os resultados em vez de executar etapas predefinidas. Para atender a essa demanda, é necessária uma plataforma que opere em todo o espectro de complexidade de automação e uma estrutura que mostre onde cada recurso se encaixa.

O Agentforce combina a Camada de Trust do Einstein, o Mecanismo de raciocínio, o script do agente, o Fluxo, o Apex e o Data 360 em uma única plataforma unificada. Essa combinação lida com tudo, da automação de acionador de registro simples à orquestração complexa de vários agentes em voz, visão, documentos e telemetria em tempo real. A MuleSoft estende essa plataforma com o tecido, a governança e a orquestração entre sistemas da MuleSoft necessários para conectar fluxos de trabalho agentes em uma empresa. O Agentforce Operations (anteriormente Agentforce Supply Chain) aplica essas capacidades às demandas específicas dos processos operacionais e de manufatura.

## Visão geral do guia

Este guia apresenta a estrutura e as diretrizes de Densidade de orquestração para tomar decisões bem informadas nesse cenário de produto. A estrutura oferece aos arquitetos uma abordagem repetível para selecionar as ferramentas e padrões certos usando níveis de densidade para casos de uso de automação inteligente na Salesforce Platform.

## Produtos no escopo

| Produto               | Descrição                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
| :-------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Agentforce            | [Agentforce](https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5) é a plataforma do Salesforce para criar e implantar agentes de IA. Ele usa o mecanismo Atlas para acionar ações baseadas dinamicamente em tempo real por meio do Apex e do Data 360.                                                                                                                                                                                                                                                                                                                           |
| Script do agente          | O [Agent Script](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html) é uma linguagem declarativa específica de domínio (DSL) usada no Agentforce Builder para definir fluxos de trabalho, regras de negócios e lógica conversacional para agentes                                                                                                                                                                                                                                                                                                                                         |
| Grade Agentforce       | O [Agentforce Grid](https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5) é uma interface nativa de IA sem tipo de planilha para projetar e operar rapidamente fluxos de trabalho de IA em escala.                                                                                                                                                                                                                                                                                                                                                                     |
| Operações do Agentforce | [Agentforce Operations](https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5) (anteriormente Agentforce Supply Chain) é uma plataforma de orquestração colaborativa de gerenciamento de fluxo de trabalho baseada em IA projetada para simplificar e automatizar processos de negócios de back office.                                                                                                                                                                                                                                                                           |
| MuleSoft              | A [MuleSoft](/docs/architect/pt-br/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html) é uma plataforma aberta, unificada e abrangente para integração empresarial e governança de agentes. Por meio da conectividade conduzida por API e do MuleSoft Agent Fabric e do Agent Broker, ela serve como a estrutura de integração, a camada de governança e a base de orquestração entre sistemas para conectar fluxos de trabalho agentes em toda a empresa                                                                                                                                                         |
| Fluxos e Apex        | O [Salesforce Flow](https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5) é uma poderosa ferramenta de automação de apontar e clicar para criar processos comerciais complexos visualmente sem código. O [Salesforce Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm) é uma linguagem de programação proprietária e orientada a objetos para a plataforma Salesforce, semelhante a Java. Era usado para criar lógica de negócios personalizada, automatizar processos e estender as principais funcionalidades de CRM além das ferramentas declarativas. |

## Capturas

O Agentforce representa uma mudança fundamental na forma como o trabalho é feito na Salesforce Platform, da automação baseada em regras aos fluxos de trabalho baseados em raciocínio. Para desbloquear seu potencial, os arquitetos devem tomar decisões bem-informadas sobre onde os agentes se encaixam, como são compostos e o que orquestram. Os princípios a seguir fornecem uma diretriz repetível para decisões de agente.

- **Use a ferramenta certa para a tarefa certa.** Use a densidade da orquestração com base no caminho de execução, na combinação de modalidades e na complexidade da meta para determinar a solução mais adequada.

  - Use a **Automação tradicional** com fluxos e Apex para trabalho determinístico baseado em regras, em que o resultado pode ser totalmente definido e definido por um conjunto de regras. A automação tradicional resulta em um caminho de execução estático, que garante resultados previsíveis e repetíveis e é crucial para a capacidade de auditoria. Escolha a automação tradicional para tarefas que exigem conformidade rígida e adesão legal.

  - Use **Agentforce Grid** para casos de uso de inferência em massa com complexidade de orquestração baixa a média. Esse padrão usa o raciocínio generativo de turno único para classificar, pontuar ou resumir dados em um alto volume de registros de CRM, garantindo execução de alta taxa de transferência com capacidade de auditoria imediata.

  - Use o **Agentforce com script do agente** para tarefas que têm metas abertas em que o resultado desejado é conhecido, mas o caminho de execução exato não pode ser especificado no momento do design. Aplique esse padrão a requisitos que exigem raciocínio por meio de determinismo guiado para garantir resultados previsíveis e rastreáveis.

  - Use **Agentforce Operations** para simplificar e automatizar processos de negócios colaborativos com o gerenciamento habilitado por IA para fluxos de trabalho da cadeia de abastecimento.

- **Evite aplicar fluxos de trabalho agentes a casos de uso de baixa densidade de orquestração**. Avalie as compensações entre automação tradicional e agência para requisitos funcionais e não funcionais. A automação tradicional pode oferecer a escala, a confiabilidade e o desempenho necessários para seu caso de uso.

- **Adotar uma abordagem híbrida de Automação do agente**, que combine a Automação Agentforce e tradicional com Fluxos e Apex, quando essa sinergia oferece maior valor do que usar a automação agente ou tradicional isoladamente.

## Pontos de decisão

O Salesforce sObject é tradicionalmente o principal ponto de entrada para automação de registro. O sistema executa a lógica com base em regras, começando imediatamente após um evento de Linguagem de manipulação de dados (DML), como inserir, atualizar ou excluir. Para decidir entre ferramentas para uma automação eficiente acionada por [registro](/docs/architect/pt-br/decision-guides/guide/record-triggered.html), introduzimos a [Densidade de automação](/docs/architect/pt-br/decision-guides/guide/record-triggered#automation-density.html) como um meio de medir a complexidade do sistema, considerando a quantidade de automação, o volume de registro e a disseminação da dependência. A automação tradicional é limitada pelo extenso pré-trabalho necessário para colocar os dados em uma estrutura estruturada, em conformidade com o esquema e baseada em regras.

A automação agente atualiza a automação tradicional usando a intenção do usuário ou dados não estruturados como a entrada em que o raciocínio pode ser aplicado para alcançar um resultado desejado. Os arquitetos devem decidir quando aproveitar o raciocínio probabilístico para dados não estruturados multimodais e quando aplicar fluxos de trabalho determinísticos guiados para mitigar o risco de resultados imprevisíveis.

Quando o requisito muda da execução de etapas baseadas em regras para o raciocínio em relação aos resultados, os arquitetos precisam de uma estrutura padronizada para avaliar a profundidade do raciocínio e a complexidade da meta da solução proposta.

### Densidade de orquestração

A densidade de orquestração é a medida da complexidade em um fluxo de trabalho agente. Três fatores determinam a densidade da orquestração: caminho de execução, complexidade da meta e combinação de modalidades. Embora a densidade de automação meça a complexidade física das regras e do volume do sistema, a densidade de orquestração mede a complexidade de raciocínio do caminho do agente em direção a uma meta. Use a densidade da orquestração composta para avaliar seus requisitos de design e mapear para o padrão arquitetônico.

- **Caminho de execução**: O grau em que o fluxo de trabalho pode ser totalmente delimitado e especificado no momento do design. Um fluxo de trabalho totalmente especificado significa que o fluxo de trabalho define cada ramificação e resultado resultante em um caminho de execução predeterminado. Um fluxo de trabalho não especificável tem um caminho que pode surgir durante o tempo de execução por meio do raciocínio com base em dados e instruções contextuais.
- **Complexidade da meta**: O número de resultados distintos, pontos de decisão e variações de caminho que o fluxo de trabalho deve resolver no tempo de execução. Um fluxo de trabalho de baixa complexidade lida com uma única tarefa contida com um resultado predeterminado, enquanto uma meta de alta complexidade abrange vários estágios com metas concorrentes ou conflitantes com casos de borda que não podem ser previstos no momento do design.
- **Mistura de modalidades**: A gama de tipos de entrada que um fluxo de trabalho deve processar e as formas de saída que ele deve produzir. Uma combinação de modalidade baixa lê campos padrão do CRM e produz atualizações de registro. Uma modalidade média consome uma combinação de campos de CRM estruturados e dados estáticos não estruturados, como corpos de email ou transcrições de caso, para produzir atualizações de registro. Uma combinação de alta modalidade consome fluxos dinâmicos em tempo real, como áudio ao vivo ou telemetria, e produz saídas multimodais em vários sistemas externos.

![Diagrama de estrutura de Densidade de orquestração mostrando o caminho de execução, a complexidade da meta e os eixos de mistura de modalidade](https://architect.salesforce.com/ns-assets/determining-agentic-automation-orchestration-density-framework.png)

### Sequenciamento de fator

Determinar o nível de densidade de orquestração adequado requer avaliação sequencial do caminho de execução, da complexidade da meta e da combinação de modalidades. Inspecione o caminho de execução primeiro. Se um caminho for totalmente especificável, comece com a automação tradicional. Usar uma solução Agente apenas para orquestrar e executar um caminho determinístico sem nenhum requisito de raciocínio é um antipadrão. Isso leva à disseminação do agente (proliferação excessiva e não gerenciada do agente de IA) e declínio do agente (saída gerada por IA desnecessária de baixa qualidade), resultando em retornos de valor ruins.

Para caminhos parciais ou não especificáveis, continue avaliando a complexidade da meta. Se a complexidade da meta for bem definida, mas determinados nós ao longo do caminho precisarem de avaliações probabilísticas, considere chamar agentes do Fluxo ou do Apex para atender à necessidade localizada específica. Em vez disso, se as etapas no caminho de execução precisarem de um ou mais requisitos conduzidos por IA em um grande conjunto de registros, considere a Grade do Agentforce. A Grade oferece suporte a fluxos de trabalho baseados em planilhas de várias etapas por meio de várias colunas de IA ou agente. É mais adequado para execução orientada por linha em massa. Essa abordagem garante que o fluxo de trabalho permaneça de alto desempenho e auditável, invocando raciocínio probabilístico apenas quando o caminho não puder ser predefinido.

À medida que a complexidade da meta aumenta com as dimensões concorrentes (por exemplo, determinar o pagamento de uma declaração de seguro junto com detecção de fraudes, conformidade com apólices e satisfação do cliente) e caminhos de execução não especificáveis, considere o Agentforce com Agent Script para determinismo guiado em sua automação. Para casos de uso entre empresas que envolvem o Salesforce e sistemas de terceiros, use o MuleSoft Fabric e o Agent Broker.

Por fim, avalie a combinação de modalidades para identificar os recursos técnicos necessários, como conexão multimodal ou integração especializada. A combinação de modalidades funciona como um seletor de funcionalidade, não como uma calculadora de densidade. Ajuda a determinar a infraestrutura necessária para lidar com a forma de entrada e saída da solução sem alterar sua lógica de orquestração fundamental.

### A matriz de seleção de densidade

Use essa matriz para determinar o padrão arquitetônico para sua automação agente. Equilibre a automação tradicional e agente selecionando a abordagem que resolve seu problema de automação.

- **Automação tradicional (baixa densidade de orquestração):** Use a automação tradicional quando o processo for acionado por uma alteração de registro, os dados forem estruturados, a lógica for baseada em regras e predefinida e o resultado for previsível (por exemplo, cálculos de preço padrão ou criação automática de tarefa).
- **Agentforce Grid (densidade de orquestração baixa a média):** Use o Agentforce Grid quando as tarefas de IA em massa em registros existentes precisarem ser processadas (por exemplo, resuma os últimos 50 casos para cada Conta nesta lista, calcule a pontuação de sentimento e mantenha a pontuação no campo de caso).
- **Orquestração híbrida (Automação aumentada de alta qualidade):** Use orquestração híbrida ao automatizar um processo de negócios complexo de ponta a ponta (por exemplo, processamento de declarações ou integração) que exija as capacidades de planejamento da IA, mas a integridade da transação do Fluxo e do Apex.
- **Agentforce Agent Script (alta complexidade de intenção):** Use o Script do agente quando o ponto de entrada estiver não estruturado (por exemplo, chat, email e voz) e a resolução exigir uma conversa ou a capacidade de lidar com solicitações de usuário ambíguas.

| Nível de densidade     | Caminho de execução                                                                                                     | Complexidade da meta                                                                               | Mix de modalidades                                                                                                                | Padrão arquitetônico                                                                                                                                          |
| :---------------- | :----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Baixo**           | Totalmente especificável                                                                                                  | **Baixo:** Tarefa única contida com resultados predefinidos.                                     | **Modalidade única:** Leitura e grava registros de objeto do Salesforce estruturado.                                                 | Automação acionada por registro. Se o caso de uso tiver pelo menos uma tarefa de raciocínio, use Ações do agente no fluxo de trabalho.                                              |
| **Baixo - Médio** | Especificável totalmente ou parcialmente                                                                                     | **Baixo:** Série de etapas com resultados predefinidos.                                           | **Modalidades mistas:** A entrada ou a saída pode ter uma combinação de dados estruturados e não estruturados.                                   | Use Inferências em lote do Agentforce Grid para tarefas em massa em registros existentes com ação agente.                                                                |
| **Médio**        | Especificável totalmente ou parcialmente. O caminho de execução é predefinido, mas as etapas intermediárias precisam de raciocínio.           | **Médio:** Série de etapas baseadas em Apex ou Fluxo com resultados variáveis.                        | **Modalidades mistas:** A entrada ou a saída pode ter uma combinação de dados estruturados e não estruturados de baixo volume.                        | Híbrido (Agentforce + Apex/Flow): Use Agentforce para raciocínio e planejamento de alta densidade, Agent Script para determinismo guiado e Apex/Flow para orquestração. |
| **Alto**          | Parcial ou não especificável. A meta é predefinida, mas as etapas intermediárias precisam do contexto do tempo de execução e da intenção do usuário. | **Alto:** Várias metas concorrentes com grandes necessidades de raciocínio exigem resultados determinísticos. | **Modalidades mistas:** A entrada ou a saída pode ter uma combinação de dados estruturados de alto volume e não estruturados que chegam em tempo real. | Use o Script do agente para balancear o controle determinístico com o raciocínio. Use o MuleSoft Agent Fabric para MCPs de terceiros ou A2A para colaboração complexa de vários agentes.  |

## Comparação de produto

| Capacidade                     | Automação tradicional (Flow/Apex)                                                                                        | Grade Agentforce                                                                                                                               | Agentforce                                                                                                                             | Agentforce com script do agente                                                                                                                           |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Tipo lógico e determinismo**   | **Determinista:** Usa lógica fixada if-then-else. O caminho de execução é 100% previsível com base no estado do registro.           | **Misto:** Determinística por meio de etapas estruturadas, enquanto etapas de IA individuais podem ser probabilísticas.                                                 | **Probabilística:** Usa o raciocínio de vários turnos para determinar o melhor caminho para uma meta.                                                 | **Determinismo guiado:** Usa o raciocínio para planejar o caminho e permite a execução em caminhos de nó determinísticos.                                              |
| **Velocidade de entrega**          | **Recomendado (fluxo):** Ferramentas visuais permitem a criação rápida de lógica acionada por registro sem código.                         | **Recomendado para automação de IA repetitiva:** Maneira mais rápida de aplicar a lógica de IA em conjuntos de registros existentes sem criar novos fluxos.           | **Recomendado:** Para configuração de mapeamento de Subagentes (anteriormente Tópicos), Instruções e Habilidade para um domínio ou problema específico. | **Recomendado:** Para mapeamento avançado de gráficos baseados em estado e lógica de borda.                                                                            |
| **Modalidade de entrada**             | **Apenas recomendado para estruturado:** Limitado a campos de CRM e coleções de registros relacionados.                                | **Recomendado para semi-estruturado:** Processa o texto em massa (descrições, transcrições) de campos de registro.                                      | **Recomendado para Multi-modal:** Processa linguagem natural, voz e visão (dados não estruturados).                                    | **Recomendado para alta densidade:** Sintetiza entradas multimodais com dados de estado do sistema em tempo real.                                                     |
| **Profundidade de raciocínio (planejamento)** | **Não disponível:** A lógica é imperativa; ela não pode "pensar" nem planejar etapas dinamicamente. No entanto, os dados podem ser enviados aos agentes. | **Baixo:** Inferência de etapa única aplicada em um conjunto de registros (IA em lote).                                                                        | **Média/Alta:** Usa loops de raciocínio (Reason-Act-Observe) para resolver a intenção complexa.                                                  | **Governado:** O raciocínio é restrito à navegação em um gráfico predefinido de estados de negócios.                                                            |
| **Modularidade e reutilizabilidade**   | **Recomendado:** Modular por padrão por meio de subfluxos e classes do Apex.                                                        | **Limitado:** A lógica geralmente é vinculada à linha de grade específica. As configurações de coluna e os fluxos de trabalho modelados podem ser reutilizados em todo o conjunto de linhas. | **Disponível:** Habilidades (Fluxos/Apex) são reutilizadas em diferentes Subagentes (anteriormente Tópicos) e agentes conectados.                     | **Recomendado:** Nós no Gráfico do agente são unidades funcionais distintas e reutilizáveis.                                                                     |
| **Transacção e controle DML**  | **Recomendado (Apex):** Controle total de Savepoints, reversões e massificação.                                       | **Disponível:** Cada linha é processada de modo independente, portanto, o escopo de execução é por registro.                                                         | **Limitado:** As ações são executadas como etapas individuais e desacopladas em uma sessão.                                                         | **Recomendado:** Usa nós de Fluxo/Apex para servir como âncoras determinísticas para todos os DMLs. O suporte ao controle de transação distribuído entre agentes é limitado. |
| **Manuseio de ambiguidade**         | **Não disponível:** Requer caminhos predefinidos. Entradas inesperadas levam a falhas ou erros estáticos.                        | **Limitado:** A qualidade da saída depende da fundamentação do aviso. O fluxo de trabalho não pode solicitar esclarecimento interativamente.                             | **Recomendado:** Lida com estados "conhecidos" fazendo perguntas ou selecionando habilidades alternativas.                                           | **Disponível:** Usa "Nós de fallback" para gerenciar falhas de raciocínio ou tempos limite de processo.                                                                 |
| **Visibilidade e governança**    | **Recomendado:** O Explorador do acionador de fluxo fornece um mapa visual de toda a lógica acionada por registro.                               | **Disponível:** A IU baseada em grade fornece visibilidade clara dos resultados no nível da linha e dá suporte à auditoria das saídas.                           | **Disponível:** Os Registros de monitoramento fornecem transparência sobre como o agente tomou decisões.                                                 | **Requer conhecimento:** Exige o monitoramento dos logs de inferência de LLM e de traversal do Gráfico.                                                           |
| **Desempenho & Escala**        | **Recomendado** Otimizado para processamento de registro síncrono de alto volume.                                                  | Processamento eficiente de tarefas de IA em massa em grandes volumes de dados **recomendado**.                                                                | Dependente do tempo de inferência, **sensível à latência**; impróprio para atualizações em massa de alta densidade.                                           | **Moderado** Adequado para tarefas complexas de horizonte longo, mas com maior sobrecarga.                                                                         |

## Casos de uso

Esta tabela fornece recomendações gerais de melhor ajuste para vários casos de uso.

| Caso de uso                                                    | Descrição                                                                                                                                                                                                                                | Melhor ajuste                                                                                                                                                                                                                           | Racionalidade                                                                                                                                                                                                                                                                                                                                                                                           |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Processamento de registro**                                       | Automação acionada por um evento DML em um objeto do Salesforce estruturado em que cada ramificação e resultado podem ser totalmente definidos no momento do design.                                                                                                  | Use o fluxo acionado por registro. Esta é uma automação tradicional de baixa densidade.                                                                                                                                                           | Densidade de orquestração baixa. Modalidade única (campos de CRM estruturados) e uma única meta contida com um caminho de execução previsível e auditável.                                                                                                                                                                                                                                                        |
| **Controle transacional com lógica complexa**                | Automação que requer pontos de salvamento, reversões, confirmações parciais ou manipulação de dados segura em massa em grandes volumes de registros.                                                                                                                    | Use o Apex para automação determinística tradicional de baixa densidade.                                                                                                                                                                    | Densidade de orquestração baixa. O Apex oferece controle total sobre a integridade da transação, a remoção de duplicação de cálculos caros e o armazenamento em cache no nível da plataforma – recursos que não estão disponíveis no Fluxo.                                                                                                                                                                                                         |
| **Lógica moderadamente complexa dentro de um processo estruturado**    | Automação em que o processo geral é baseado em regras, mas as etapas individuais exigem cálculo ou manipulação de dados além do recurso declarativo.                                                                                            | Use Fluxo com Apex invocável para lógica determinística de baixa densidade.                                                                                                                                                                  | Densidade de orquestração baixa. O Apex invocável encapsula operações de alta complexidade como componentes reutilizáveis e seguros em massa.                                                                                                                                                                                                                                          |
| **Processamento agendado e temporário**                       | Automação que deve ser executada em uma data futura calculada dinamicamente com relação a um evento de registro.                                                                                                                                           | Use a automação tradicional (fluxos acionados por registro) para processamento determinístico de baixa densidade.                                                                                                                                      | Densidade de orquestração baixa. Os [caminhos agendados de fluxo](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5) fornecem agendamento automático, cancelamento e reagendamento se os dados de registro mudarem - não disponíveis nativamente em acionadores do Apex.                                                                                                            |
| **Inferência de registro em massa**                                   | Aplicar uma única etapa de raciocínio de IA uniformemente em um grande conjunto de registros existentes para gerar uma classificação, resumo ou pontuação.                                                                                                      | Use Agentforce Grid para inferência em lote e para usar recursos agentes repetitivos em escala.                                                                                                                                       | Densidade média da orquestração. Inferência em lote com modalidade única em escala: o agente lê campos de registro estruturados e grava uma saída uniforme de volta em cada registro. Baixa complexidade da meta com um padrão de inferência repetitivo.                                                                                                                                                                   |
| **Resolução de entrada não estruturada**                           | Automação em que o ponto de entrada é uma solicitação de linguagem natural, email ou conversa que deve ser interpretada, classificada e resolvida por meio de raciocínio.                                                                               | Use Agentforce para resolução de entrada não estruturada, orientada por intenção e de média densidade.                                                                                                                                                   | Densidade média da orquestração. Modalidade mista: o agente consome entrada conversacional não estruturada e, em seguida, produz respostas de texto ou atualizações de registro estruturado. A meta exige resolver a intenção do usuário em um conjunto limitado de resultados.                                                                                                                                                            |
| **Lógica moderadamente complexa dentro de um processo probabilístico** | Automação em que o processo geral é baseado em regras, mas as etapas individuais exigem recursos de IA, como resumo ou recuperação RAG.                                                                                                            | Use o Fluxo com Apex invocável e modelos de prompt para processos determinísticos de baixa densidade que exigem recursos de IA.                                                                                                               | Densidade média da orquestração. O fluxo atua como a camada de orquestração enquanto os [Modelos de prompts](https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api), o agente de serviço [Agentforce e o agente Funcionário Agentforce](https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5) são expostos como ações invocáveis. |
| **Orquestração de processo guiada**                            | Automação abrangendo fluxos de trabalho de várias etapas em que a conclusão de uma ação aciona ações adicionais                                                                                                                                  | Use [Agent Script com ações](https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining) para caminhos de execução não especificados de alta densidade que exigem orquestração de processo guiada. | Alta densidade de orquestração – modalidade mista entre entrada e saída. Resultados concorrentes e casos de ponta que não podem ser totalmente previstos no momento do design. O Script do agente fornece determinismo guiado.                                                                                                                                                                                                  |
| **Orquestração de processo entre sistemas**                      | Automação que coordena um processo de negócios de várias etapas em vários sistemas de back-end em que nenhum sistema possui o fluxo de ponta a ponta                                                                                                      | Use a API de processo do MuleSoft com o Agente Broker para orquestração de processos entre sistemas de média e alta densidade.                                                                                                                          | Alta densidade de orquestração – As APIs de processo encapsulam uma lógica de negócios complexa de várias etapas para que os agentes não precisem entender a orquestração por trás de operações como processamento de pedidos ou verificações de inventário. O [Agent Broker](https://www.mulesoft.com/ai/agent-broker) dinamicamente sequencia e chama os agentes e ferramentas necessários de uma única meta de linguagem natural.                               |
| **Abstração do sistema de segundo plano**                              | Orquestração em que os agentes devem interagir com sistemas legados, bancos de dados ou plataformas SaaS de terceiros sem conectividade nativa do Agentforce.                                                                                            | Use o MuleSoft com o Conector de MCP para encapsular sistemas legados e fornecer contexto do modelo.                                                                                                                                              | Densidade média da orquestração. As APIs do sistema oferecem uma interface abstrata e segura para sistemas de registro, garantindo que os fluxos de trabalho agentes sejam desacoplados da complexidade de back-end. O Conector de MCP transforma aplicativos MuleSoft em servidores em conformidade com MCP para descoberta e invocação imediatas.                                                                                                  |
| **Processamento de documentos de alto volume e tratamento de exceções**  | Automação que lê, interpreta e reconcilia documentos estruturados e semiestruturados recebidos com relação a registros existentes em escala – lidando com variações, correspondências parciais e exceções com intervenção manual adequada.          | Use Operações Agentforce para processamento de documentos de grande volume de intenção e de média densidade.                                                                                                                                       | Densidade média de orquestração com modalidade de entrada semiestruturada. A complexidade da meta conduzida por regras de correspondência, caminhos de exceção e limites de aprovação por documento. Requer raciocínio por registro, não inferência de turno único uniforme.                                                                                                                                                                |
| **Orquestração multifator entre fornecedores**                | A automação requer colaboração entre agentes especializados criados em diferentes plataformas ou fornecedores.                                                                                                                                      | Use o MuleSoft com conector A2A e tecido do agente para orquestração de vários agentes em diferentes sistemas.                                                                                                                           | Densidade de orquestração média a alta. O Conector A2A habilita fluxos de trabalho de vários agentes entre pares com governança e confiabilidade em nível corporativo, independentemente de onde cada agente é criado ou hospedado.                                                                                                                                                                                             |
| **Conversão de documento não estruturado em fluxo de trabalho**            | Automação em que processos operacionais definidos em origens não estruturadas (SOPs, documentos de regra do fornecedor ou diagramas de processo) devem ser convertidos em fluxos de trabalho agentes executáveis sem codificação manual.                                     | Use Operações Agentforce para documentos não estruturados emergentes de alta densidade para conversão de fluxo de trabalho.                                                                                                                                | Alta densidade com uma alta combinação de modalidades na entrada. Ingere PDFs, documentos do Word e diagramas baseados em imagem. A complexidade da meta determinada pelo escopo e pela ramificação do processo ingerido. O caminho de execução não pode ser especificado no momento do design.                                                                                                                                                           |
| **Orquestração multifator**                               | Automação que abrange a integração coordenada de partes externas: coleta de dados necessários, verificação de conformidade, gerenciamento de aprovações e atualização de sistemas de registro em muitos rastreamentos de integração simultâneos.                         | Use as Operações do Agentforce para orquestrações com múltiplas partes de média a alta densidade orientadas por intenção.                                                                                                                         | Várias etapas de verificação e aprovação interdependentes devem ser resolvidas sequencialmente antes da conclusão da integração. A combinação de modalidades inclui registros estruturados, documentos não estruturados e comunicações de parte externa.                                                                                                                                                                                 |
| **Intervenção de ativos preditivos**                           | Automação em que um mecanismo preditivo ingere telemetria em tempo real para identificar condições de falha futuras e aciona uma resposta de back-office de várias etapas coordenada.                                                                      | Use Operações do Agentforce e Agentforce para Manufatura para intervenção de ativo preditiva de alta densidade.                                                                                                                         | O Data Cloud lida com telemetria de IoT de alta modalidade e detecção de anomalia. Em seguida, o Agentforce Operations orquestra o fluxo de trabalho de back-office de modalidade média, gerenciando registros de serviço de campo, dados de inventário e comunicações com o cliente, resolvendo o processo de ponta a ponta.                                                                                                                                |
| **Gerenciamento de comunicação do fornecedor em grande escala**           | Automação gerenciando comunicações estruturadas e semistruturadas em andamento em uma grande base de fornecedores, incluindo confirmações de pedido, alterações de data de entrega e notificações de exceção.                                            | Use Operações Agentforce para inferências em lote para um gerenciamento de comunicação do fornecedor de média densidade.                                                                                                                              | Quando as comunicações são uniformes entre os fornecedores, use Agentforce Grid para processamento em lote. Quando as respostas exigem raciocínio contextual por relacionamento de fornecedor, escale para densidade média com Operações Agentforce.                                                                                                                                                                         |
| **Gerenciamento de leads (roteamento inteligente e de alta velocidade)**       | Automação que ingere respostas de marketing em tempo real, usa pontuação de IA e aprimoramento do Data Cloud para qualificação e usa fluxos para atribuição inteligente e roteamento de leads de alta qualidade para a equipe de vendas apropriada. | Use Automação tradicional (Fluxo) + Data Cloud e IA para roteamento inteligente de leads de alta velocidade de média densidade.                                                                                                                     | Requer alta velocidade (velocidade para lead < 1 minuto) e roteamento complexo orientado por dados com base na pontuação de lead de IA, nível de trabalho e histórico de atividades. Usa Fluxos para lógica de atribuição determinística rápida, ampliada por IA probabilística e Data Cloud para qualificação e aprimoramento de leads.                                                                                                                   |
| **Nutrição de lead**                                          | Nutre leads de baixa pontuação até que estejam prontos para uma conversa de vendas.                                                                                                                                                                    | Use o Lead Nurturing Agent para direcionar e melhorar leads de baixa qualidade para automação de média a alta densidade.                                                                                                                      | Envia emails personalizados com vários contatos baseados em dados de lead e histórias de sucesso do cliente. Ele lida com respostas de email e usa o Fluxo para transferência.                                                                                                                                                                                                                                                  |
| **Qualificação de lead de entrada**                              | Qualifica e promove leads de entrada de pontuação mais alta de modo autônomo.                                                                                                                                                                            | Use o Agente de fomento de leads para qualificar e engajar leads.                                                                                                                                                                              | Executa a saída de email de múltiplos contatos, o agendamento de reunião, as perguntas e respostas do produto e o tratamento de objeções. Ele pode operar em um modo "enviar como vendedor", enviando emails por meio do proprietário do lead atribuído.                                                                                                                                                                                                              |

## Usar mapeamento de caso

![Usar diagrama de mapeamento de caso mostrando vários cenários de automação em diferentes níveis de densidade de orquestração](https://architect.salesforce.com/ns-assets/determining-agentic-automation-use-case-mapping.png)

## Considerações não funcionais

**Latency**

Fluxos síncronos acionados por registro são executados dentro da transação da plataforma e concluídos em milissegundos. O tempo de inferência do Agentforce depende do Mecanismo de raciocínio do Atlas e é dimensionado com profundidade de raciocínio e complexidade da modalidade. O Agentforce não é adequado para processamento de registro síncrono de alto volume em que a latência é uma restrição primária.

**Custo**

O custo de raciocínio de um fluxo de trabalho agente deve ser justificado em relação ao valor comercial do resultado. Para tarefas de alto volume e baixa densidade de orquestração em que existe um caminho determinístico, a automação tradicional ou a Grade Agentforce pode ser mais econômica do que um fluxo de trabalho agente de ponta a ponta. Certifique-se de que o design acomode o padrão de repetição certo com limites e quebradores de max-retry explícitos. Essa proteção limita o risco de sobrecarga de custo associado ao processamento em massa.

**Limites do governador**

Avalie fluxos de trabalho agentes de alto volume em relação aos limites diários da plataforma para execução assíncrona. As operações em lote do Agentforce Grid seguem os limites de transação de plataforma padrão. Para automação envolvendo objetos do Salesforce, considere o número total diário de operações DML, pois o Salesforce impõe o gerenciamento compartilhado de recursos em um ambiente de vários locatários e os [limites de governador](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm?_ga=2.244979463.387753096.1774889755-1655953164.1772207150) para evitar que as automações de fuga monopolizem recursos compartilhados.

**Auditabilidade e conformidade**

A automação tradicional produz trilhas de execução totalmente auditáveis por meio do Explorador do acionador de fluxo e dos logs do Apex. Os padrões de ponta a ponta ou híbridos baseados no Agentforce produzem registros de raciocínio que proporcionam transparência na tomada de decisão do agente, mas exigem conhecimento especializado para interpretar. O determinismo guiado por meio do Script do agente é o padrão recomendado para setores regulamentados em que a capacidade de auditoria de execução completa é um requisito de conformidade.

**Escalação**

Fluxos de trabalho agentes que operam em alta densidade devem incorporar portões de aprovação ou escalação humanos explícitos para ações com consequências irreversíveis, como transações financeiras, envios regulatórios ou compromissos do fornecedor. Os controles condicionais de Script do agente fornecem o mecanismo para impor esses portões de modo determinístico em um fluxo de trabalho de outra forma agente.

## Melhores práticas relacionadas

**Priorize a simplicidade no seu design de orquestração**. Comece no nível mínimo de orquestração que pode atingir a meta, valide-a sob carregamento real e itere. Cada agente adicional, transferência ou dependência em sua cadeia apresenta uma nova superfície que pode produzir comportamento inconsistente.

Em seu caminho de execução especificável, em nós em que o raciocínio é necessário, comece a integrar um agente. Siga as práticas recomendadas para criar agentes no Agentforce. Evite empacotar vários subagentes (antes chamados de "tópicos") e nunca adicione instruções. Os agentes implantados em casos de uso de automação podem se dar ao luxo de ser magros, pois não são a única interface. Escolha o primitivo certo para encadeamento. Um padrão de orquestração (delegação) tem um controle mais rígido sobre a sequência de execução e pode delegar subtarefas a especialistas. Evite padrões coreografados (handoff). Se você precisar implementar um design de transferência, forneça ao agente receptor a meta, o contexto e o estado para que ele possa otimizar globalmente, em vez de objetivos locais.

**Evite ações ou ferramentas se espalharem**. As ações são onde o raciocínio do agente é realizado, e seu design determina se elas produzem resultados confiáveis ou falhas. Cada ação deve retornar uma resposta estruturada e observável que o agente de IA possa usar para planejar o próximo turno da conversa.

Ter mais de uma ação (e diferentes construções de saída) para realizar a mesma tarefa diminui a capacidade do agente de raciocinar ou escolher a ferramenta certa para o trabalho. Isso pode fazer com que o agente perca nuances. Sobrepor definições de ação corre o risco de uma classificação incorreta. Verifique se sua biblioteca de ações é auditada, com controle de versão e está de acordo com o escopo Subagente (antigo Tópico).

**Definir metas observáveis.** Defina a meta como um resultado observável, não apenas um procedimento. Uma meta vaga convida o agente a desviar. Aumente com um caminho de execução especificável. Use o Gráfico do agente com raciocínio híbrido para modelar a meta como um nó de gráfico com estado explícito. O tempo de execução rastreia a posição atual do agente no fluxo de trabalho e a restaura após entradas tangenciais; ele não perde a meta quando recebe informações adicionais na janela de contexto.

**Teste e avalie**. Implemente uma estrutura de teste e avaliação robusta para validar o raciocínio de nós probabilísticos e a saída de automações agentes. Verifique os caminhos de execução em relação a um caminho de resultado esperado para garantir que o modelo chegue ao resultado correto. Evite falhas silenciosas em que um agente relatou falso sucesso ou entrou em um loop infinito ou não recuperável declarando os resultados nas etapas de execução. Use o rastreamento de [sessão](https://help.salesforce.com/s/articleView?id=ai.generative_ai_session_trace_about.htm&type=5) para inspecionar interações turn-by-turn, execuções de mecanismo de raciocínio, ações, entradas/saídas de prompt e gateway, mensagens de erro e respostas finais.

## Recursos

<table>
  <thead>
    <tr>
      <th scope="col">Agentforce</th>
      <th scope="col">Automação tradicional</th>
      <th scope="col">Integração</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5">Agente</a></li>
          <li><a href="https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html">Script do agente</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5">Agentforce Grid</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5">Operações Agentforce</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5">Agente de serviço e agente de funcionários da Agentforce</a></li>
          <li><a href="https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining">Script do agente com ações</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5">Fluxo do Salesforce</a></li>
          <li><a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm">Salesforce Apex</a></li>
          <li><a href="https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5">Caminhos agendados do fluxo</a></li>
          <li><a href="https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api">Modelos de prompt</a></li>
        </ul>
      </td>
      <td>
        <ul>
          <li><a href="/docs/architect/pt-br/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html">MuleSoft</a></li>
          <li><a href="https://www.mulesoft.com/ai/agent-broker">Agente corretor</a></li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

**Sobre o autor**

Arvind Palaniswamy é um arquiteto de engenharia de software no escritório do arquiteto principal, uma equipe bem arquitetada. Ele gosta de estruturar sistemas complexos nas suas formas mais simples usando os primeiros princípios. Ele entende engenharia, operações e negócios por meio de décadas de experiência e educação em MS/MBA (Kellogg).

<!-- document id=83002f7700bdb73cede0341c7c0c304709318a3dca9abb3e8ae451e68be313e5 url=/architect/current/pt-br/decision-guides/guides/build-forms.md -->

# Formulários de construção

Existem várias opções para criar formulários na Plataforma Agentforce 360, e elas abrangem um continuum de abordagens de baixo código a pro-código. Em uma extremidade do continuum, os Formulários dinâmicos no Criador de aplicativo Lightning e os fluxos de tela no Flow Builder podem ser usados para soluções com pouco código. Por outro lado, a estrutura do Componente da Web Lightning (LWC) é usada para soluções de pro-código. No continuum, as ferramentas podem ser combinadas de várias maneiras usando fluxos de tela estendidos por LWCs e formulários voltados para o cliente criados usando o OmniStudio.

## Visão geral do guia

Este guia apresenta uma estrutura de decisão e orientação sobre a criação de formulários para soluções de IU. Especificamente, ele usa uma dúzia de pontos de decisão não funcionais e de tempo de execução para selecionar adequadamente a melhor tecnologia para um determinado caso de uso.

## Capturas

- **Quando você estiver criando layouts de criação/editação/visualização para páginas do Lightning, use Formulários dinâmicos.** Para prosseguir, recomendamos usar _Formulários dinâmicos_ no Criador de aplicativo _Lightning_ para configurar páginas de detalhes de registro.

- **Se precisar criar, criar ou editar um formulário para um objeto, use Páginas _Lightning_ e _Formulários dinâmicos_.** Esta é a maneira mais fácil de criar formulários na Plataforma Agentforce 360. Ele também fornece funcionalidades adicionais (por exemplo, controle de visibilidade de campo).

- **Se você estiver criando um formulário de várias páginas ou um assistente e não tiver requisitos rígidos de usuário ou identidade visual, use um Fluxo de tela.** Os Fluxos de tela fornecem uma estrutura de navegação linear para orquestrar vários formulários. Você pode usar LWCs para criar sua própria estrutura para navegar entre formulários, mas recomendamos deixar o Fluxo fazer o trabalho para que você possa se concentrar nos formulários em si, em vez de se concentrar no estado do formulário.

- **Se precisar de lógica ou ações adicionais para dar suporte ao formulário, use um Fluxo de tela, OmniStudio ou LWCs.** Cada uma dessas ferramentas oferece diferentes maneiras de aprimorar sua solução permitindo que ela se expanda além da criação ou edição de um único registro. Neste caso, o termo pode se referir _mais_ a lógica avançada (por exemplo, ramificação ou iteração), ou pode se referir a ações como integração com sistemas externos, envio de emails ou envio de notificações por push para o aplicativo móvel de um usuário.

- **Se você tiver requisitos sofisticados de UX ou precisar gerenciar dinamicamente mais do que a visibilidade da interface do usuário, use o LWC ou o Omniscript.** Para os requisitos que podem ser atendidos usando layouts baseados em tema e coluna, você pode criar seus formulários diretamente em um criador de código baixo. No entanto, o controle granular sobre o estilo do formulário requer a flexibilidade do LWC. Se você for um cliente de Indústrias e precisar de uma identidade visual perfeita para pixels ou tiver dados hierárquicos complexos, use o OmniStudio, que permite criar formulários de nível de consumidor que podem lidar com lógica de negócios e transformações de dados complexas.

- **Se você precisar implementar a automação de teste, use o LWC.** Você pode escrever testes de unidade para qualquer LWC, independentemente de onde você os incorpora. Isso permite criar uma estratégia de teste mais robusta, que pode incluir testes em massa com vários registros, bem como testes negativos.

- **Você não está sujeito a decisões “ou/ou”.** Você pode combinar várias opções para alcançar a melhor solução para seus casos de uso (por exemplo, se precisar do sistema de navegação integrado do Fluxo e da flexibilidade de estilo total que o LWC oferece, você poderá usá-los juntos).

## Ferramentas no escopo

As seguintes ferramentas são comumente usadas para implementar e estender experiências de formulário.

### Descrições da ferramenta

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;">Formulários dinâmicos</th>
<th colspan="1" rowspan="1">Os <a href="https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_migrate.htm&language=en_US&type=5">formulários dinâmicos</a> no Criador de aplicativo <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_app_builder_overview.htm&type=5">Salesforce Lightning</a> dividem componentes monolíticos de Detalhes do registro em campos e seções configuráveis individuais. Esse recurso permite que os administradores criem páginas flexíveis e de alto desempenho colocando campos em qualquer lugar e usando regras de visibilidade para mostrar ou ocultar componentes com base em perfil de usuário, dispositivo ou dados, o que ajuda a reduzir a bagunça de página.</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Um Salesforce <a href="https://help.salesforce.com/s/articleView?id=platform.create_forms_with_screen_flow_components.htm&type=5">Screen Flow</a> é uma ferramenta de automação interativa no <a href="https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5">Flow Builder</a> que exige a entrada do usuário para percorrer processos de negócios personalizados e passo a passo. Diferentemente dos fluxos de segundo plano automatizados, os Fluxos de tela fornecem uma interface do usuário semelhante a assistente para coletar dados, exibir informações ou executar ações por meio de <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_page_overview.htm&type=5">Páginas do Lightning</a>, botões ou aplicativos personalizados sem escrever código.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">O Salesforce <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omnistudio_standard.htm&type=5">Omnistudio</a> é um conjunto de ferramentas de baixo código projetado para criar rapidamente experiências digitais guiadas específicas do setor e processos de negócios complexos. Ele permite que os desenvolvedores criem interfaces de usuário perfeitas para pixel (por exemplo, fluxos de trabalho guiados e painéis dinâmicos) usando componentes de arrastar e soltar, como <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_flexcardsbasics_8118.htm&type=5">Flexcards</a> e <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omniscripts_8355.htm&type=5">OmniScripts</a>. Com o OmniStudio, você pode criar LWCs de modo declarativo.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Componentes da Web Lightning</strong></td>
<td colspan="1" rowspan="1">Os Componentes da Web do Salesforce <a href="https://developer.salesforce.com/developer-centers/lightning-web-components">Lightning</a> são elementos HTML leves e personalizados criados usando HTML, CSS e JavaScript moderno e projetados para serem executados nativamente em navegadores para obter um desempenho superior na IU do Salesforce. Eles permitem que os desenvolvedores criem interfaces de usuário personalizadas que coexistem com componentes <a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Aura</a>, o que aumenta o desenvolvimento por meio de padrões da indústria e um ecossistema de componentes detalhado.</td></tr></table>

### Conjuntos de habilidades de ferramentas e requisitos de licença

Esta tabela descreve as ferramentas disponíveis para criar formulários por meio do Salesforce, junto com suas habilidades necessárias e considerações de licença.

**Nota:** Vamos nos aprofundar nos recursos específicos com suporte para cada ferramenta, como escolher entre ferramentas baseadas em cliques e ferramentas baseadas em código e quando combiná-las em uma seção posterior.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Configuração</th>
<th colspan="1" rowspan="1">Requisitos de licença adicionais</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Código inferior</td>
<td colspan="1" rowspan="1">Nenhum</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Código inferior</td>
<td colspan="1" rowspan="1">Nenhum</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Código inferior + Código profissional</td>
<td colspan="1" rowspan="1">Pacote de Indústrias</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela mais Componentes da Web Lightning</strong></td>
<td colspan="1" rowspan="1">Código inferior + Código profissional</td>
<td colspan="1" rowspan="1">Nenhum</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Componentes da Web Lightning</strong></td>
<td colspan="1" rowspan="1">Código profissional</td>
<td colspan="1" rowspan="1">Nenhum</td></tr></table>

## Pontos de decisão

Há vários pontos de decisão a serem considerados ao fazer seleções de produto e ferramenta. Esta tabela descreve vários pontos de decisão e fornece orientação de alto nível.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;">Ponto de decisão</th>
<th colspan="1" rowspan="1">Diretrizes</th></tr>
<tr><td colspan="2" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Categorias de casos de uso de tempo de execução</strong></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Escopo e navegação do formulário</strong></td>
<td colspan="1" rowspan="1">Determine se todos os campos no formulário caberão de modo lógico em uma única tela ou se os usuários precisarão navegar entre várias telas.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Local</strong></td>
<td colspan="1" rowspan="1">Identifique os locais em que você deseja integrar o formulário, que podem variar de dentro de um aplicativo Salesforce a um aplicativo móvel a um site externo.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Controlador</strong></td>
<td colspan="1" rowspan="1">Identifique as ações ou a lógica que devem ser realizadas nos bastidores enquanto os usuários estão interagindo com seu formulário, incluindo transformações de dados e integrações com sistemas externos.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Validação</strong></td>
<td colspan="1" rowspan="1">Determine se você tem requisitos adicionais de validação de entrada que vão além da validação no nível do sistema padrão que o Salesforce fornece.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Design de interação</strong></td>
<td colspan="1" rowspan="1">Identifique os tipos de interações ou condições que devem acionar respostas dinâmicas no seu formulário.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Estilização</strong></td>
<td colspan="1" rowspan="1">Determine o nível de sofisticação necessário para seus requisitos de estilo e CSS desejados.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Layout</strong></td>
<td colspan="1" rowspan="1">Identifique os requisitos de layout do formulário (por exemplo, o número necessário de colunas, guias e acordeões) e a capacidade de exibir blocos de dados repetidos.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Tradução</strong></td>
<td colspan="1" rowspan="1">Determine se o formulário deve ser localizado para outros idiomas.</td></tr>
<tr><td colspan="2" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Considerações não funcionais</strong></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Segurança</strong></td>
<td colspan="1" rowspan="1">Determine se o formulário deve verificar o acesso do usuário antes de realizar determinadas operações, se você deseja controlar quem pode acessar o formulário e se deseja controlar onde o formulário pode ser integrado.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong> Impacto do objeto</strong></td>
<td colspan="1" rowspan="1">Determine se seu formulário operará em um único objeto ou em vários objetos.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Automação de testes de UI</strong></td>
<td colspan="1" rowspan="1">Determine se seus processos DevOps exigem que seu formulário seja submetido a testes de unidade automatizados ou a testes completos automatizados.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Metricas</strong></td>
<td colspan="1" rowspan="1">Identifique como você gostaria de rastrear o uso do formulário, incluindo visualizações de página, quantidade de tempo gasto no formulário, taxas de conclusão e taxas de sucesso.</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Empacotamento e implantação</strong></td>
<td colspan="1" rowspan="1">Determine como você deseja distribuir ou implementar seu formulário após ele ter sido criado.</td></tr></table>

**Nota:** Em tabelas de comparação de decisão subsequentes, há um punhado de valores associados a qualquer par de ferramentas e recursos:

- **Disponível:** A ferramenta/recurso funciona com considerações básicas.

- **Não disponível:** Não há planos para adicionar suporte nos próximos doze meses.

- **Não ideal:** Essa ferramenta/recurso pode funcionar, mas não é a ferramenta ideal.

- **Não aplicável:** A ferramenta não se aplica ao caso de uso específico.

## Casos de uso

Use esses cenários para comparar as opções de ferramentas com base em escopo, UX e necessidades operacionais.

### Escopo e navegação do formulário

Se você puder obter todas as suas entradas de usuário de um formulário de tela única, comece com Formulários dinâmicos. Lembre-se de que os Formulários dinâmicos em páginas de registro podem usar o recurso Caminho para dar suporte a processos comerciais preparados.

#### Perguntas a fazer

- Você precisa de uma única tela ou o usuário precisará navegar entre várias telas para concluir uma tarefa?

- Você deseja que seus usuários vejam uma descrição visual de quanto tempo eles estão no processo ao preencher seu formulário? Seus usuários precisarão preencher as informações em cada tela em uma ordem específica ou deverão poder alternar entre as telas conforme necessário?

Se você precisar de mais funcionalidades do que o que os Formulários dinâmicos oferecem, escolher entre Fluxo, OmniStudio e LWC dependerá de algumas perguntas adicionais:

- Está OK para exibir uma barra de navegação na parte inferior do formulário? Se o Fluxo de tela e a experiência de navegação do OmniScript fornecerem uma UX indesejada, focalize o LWC.

- O que precisa ocorrer por trás do formulário? Se você precisar que o comportamento seja configurável por um administrador, use um Fluxo. Para relacionamentos complexos de vários objetos, use _OmniScript_ ou _LWC_.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Tela única</th>
<th colspan="1" rowspan="1">Formulário de várias telas</th>
<th colspan="1" rowspan="1">Indicadores de progresso</th>
<th colspan="1" rowspan="1">Navegação rápida entre etapas/tela</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não ideal</td>
<td colspan="1" rowspan="1">Não ideal</td>
<td colspan="1" rowspan="1">Não ideal</td></tr></table>

Se você escolher Fluxo ou OmniStudio, poderá também precisar criar um LWC para obter a UX certa. Se você já estiver criando um LWC para estilizar seu formulário corretamente, considere se é necessário [integrar esse componente a um Fluxo](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_flow).

**Navegação em estilo Wizard**

Por outro lado, se sua solução parecer um assistente, em que o usuário navega entre várias telas, considere Fluxo ou OmniStudio. Os fluxos e o OmniStudio apresentam um modelo de navegação integrado, de modo que você não precisa criar e manter LWCs agrupados. A navegação é linear, com ações avançadas, ações retroativas e um mecanismo para salvar o formulário para mais tarde. Você também pode criar um formulário com navegação não linear se for adequado às suas finalidades.

O OmniStudio oferece uma vantagem de navegação principal fornecendo indicadores de progresso da navegação padrão que detectam etapas no formulário. A visualização de etapa exibe automaticamente onde um usuário está em um formulário de várias etapas. Diferentemente do Fluxo, ele permite aos usuários alternar entre as telas clicando em várias etapas ao longo do formulário.

Quer você esteja criando formulários de tela única ou de várias telas, é importante garantir que seus formulários sejam simplificados para que sejam fáceis de navegar para seus usuários.

### Fator de forma

Se você estiver incorporando um formulário em uma página de registro padrão do Lightning, qualquer uma das ferramentas que estamos comparando funcionará; no entanto, no momento, os Formulários dinâmicos estão disponíveis apenas no desktop. Se você quiser fornecer uma experiência que permita aos usuários acessar formulários de outros locais, talvez seja necessário considerar opções alternativas.

#### Perguntas a fazer

- Os usuários precisarão de acesso ao formulário por desktop, dispositivo móvel ou ambos?

- Os usuários devem poder acessar o formulário de qualquer lugar no seu aplicativo por meio de uma barra de utilitários?

- Deseja habilitar ações rápidas para que os usuários possam preencher seu formulário sem precisar sair da página em que estão?

- Seu formulário precisa estar disponível em um site externo?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Página de registro do Lightning</th>
<th colspan="1" rowspan="1">Página inicial do Lightning ou página de aplicativo</th>
<th colspan="1" rowspan="1">Sites do Experience Cloud do Aura</th>
<th colspan="1" rowspan="1">Sites do Experience Cloud do LWR</th>
<th colspan="1" rowspan="1">Snap-ins integrados</th>
<th colspan="1" rowspan="1">Barra de utilitários</th>
<th colspan="1" rowspan="1">Ação específica do objeto</th>
<th colspan="1" rowspan="1">Ação global</th>
<th colspan="1" rowspan="1">Aplicativo Salesforce móvel*</th>
<th colspan="1" rowspan="1">Field Service Mobile</th>
<th colspan="1" rowspan="1">SDK móvel</th>
<th colspan="1" rowspan="1">Sites e aplicativos externos</th>
<th colspan="1" rowspan="1">LWC personalizado</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível**</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não ideal</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="14" rowspan="1" style="border-right: 1px solid #d8dde6;">* Fluxos e LWCs têm suporte no aplicativo Salesforce móvel, mas não têm suporte para todas as maneiras de integrar fluxos e LWCs (por exemplo, ações específicas de objeto têm suporte em dispositivos móveis, mas itens da barra de utilitários não).<br><br>**O aplicativo Salesforce Field Service Mobile inclui a captura de dados, uma solução de formulários offline desenvolvida no mecanismo de Fluxo com um tempo de execução offline dedicado, com suporte para os recursos mais recentes do Fluxo. O aplicativo também inclui os Fluxos do Field Service Mobile legados, que são executados em um mecanismo offline personalizado mais antigo e não oferecem suporte a muitos dos recursos de Fluxo mais recentes.</td></tr></table>

Como requer contexto de registro, o recurso Formulários dinâmicos é compatível apenas com páginas de registro do Lightning. No entanto, não há suporte para Formulários dinâmicos em páginas do Experience Cloud.

Você pode criar Fluxos que exigem um contexto de registro ou Fluxos que funcionam globalmente. Em outras palavras, você pode integrar Fluxos em vários locais. Para Fluxos contextuais de registro, os locais podem incluir: Páginas de registro do Lightning, páginas de registro do Experience Cloud, ações específicas de um objeto ou implantações de Ações e recomendações. Para Fluxos globais, os locais podem incluir: a barra de utilitários, outras páginas do Lightning ou do Criador de experiências, Snap ou aplicativos externos. No momento, não há suporte para Fluxos como ações globais, mas você pode colocar _Fluxos_ em um componente _Aura_ como solução alternativa.

O OmniStudio permite que você crie FlexCards e OmniScripts composíveis que você pode colocar _quase_ em qualquer lugar em que você possa colocar um Fluxo, mas enquanto eles são composíveis, eles não são empacotáveis.

O LWC oferece um alto grau de reutilizabilidade para criar componentes que podem ser associados a metas por meio de metadados no Salesforce, em Comunidades e em projetos de código aberto. Os componentes do LWC também podem ser integrados em seu próprio site usando o [Lightning Out 2.0](https://developer.salesforce.com/docs/platform/lwc/guide/lightning-out-intro.html).
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-locationnoheader.png" alt="Lightning Out on External Sites" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Os componentes do LWC também podem iniciar Fluxos com o componente [Lightning-Flow](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation).

O OmniStudio se destaca na exposição de conteúdo a sites externos por meio do recurso OmniOut. Com o OmniStudio e o OmniOut, você pode compilar seus formulários do OmniScript e componentes do FlexCard em componentes padrão e então executá-los fora da plataforma em sites ou aplicativos de terceiros.

No momento, nenhuma das tecnologias de formulário abordadas neste guia tem suporte oficial em modelos do Mobile SDK. Se o Mobile SDK for essencial para seu caso de uso, recomendamos criar seu formulário nativamente em seu aplicativo móvel ou criar uma página do Visualforce, considerando o formato.

### Lógica

Os Formulários dinâmicos são perfeitos se você precisar usar os valores em seu formulário para criar ou atualizar um registro. Você precisará aproveitar o Fluxo, o OmniStudio ou o LWC para recursos fora desse escopo, incluindo criar camadas de decisão ou iteração ou gerar publicações ou emails do Slack usando as entradas do formulário.

#### Perguntas a fazer

- Quais ações ou lógica precisam ser realizadas nos bastidores?

- Você precisa usar valores de um registro relacionado?

- Seu formulário precisará concluir suas operações em uma única transação ou entre várias transações?

- Você precisa se integrar a sistemas externos?

- Quais são seus requisitos para reutilizabilidade e modularidade?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Registro e ações</th>
<th colspan="1" rowspan="1">Gerenciamento de dados hierárquico</th>
<th colspan="1" rowspan="1">Operar em uma transação</th>
<th colspan="1" rowspan="1">Operar entre várias transações</th>
<th colspan="1" rowspan="1">Integração</th>
<th colspan="1" rowspan="1">Design e reutilização modulares</th>
<th colspan="1" rowspan="1">Empacotamento</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr></table>

O Fluxo oferece ações padrão para publicar no Slack, enviar emails e interagir com documentos do Quip, e você não precisa escrever código para nenhuma dessas operações. O LWC oferece interações avançadas com registros únicos e objetos relacionados por meio de adaptadores de conexão que interagem com a [API Interface do usuário](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm). O LWC também pode interagir com vários registros usando o cabo para [getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html).
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-controllernoheader.png" alt="LWC Interaction via Wire Adapters" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

O OmniStudio usa procedimentos de integração e o Data Mapper para obter e transformar dados (tanto externos quanto internos para o Salesforce). Devido a inúmeras funções sem código, ele se destaca em nivelar e expandir conjuntos de dados com vários níveis de relacionamentos.

O Fluxo, o OmniStudio e o LWC são todos integrados ao Apex, de modo que você pode fechar facilmente qualquer lacuna na solução escolhida (por exemplo, se precisar filtrar registros de um LWC, você pode usar o adaptador de conexão para Apex para criar consultas SOQL complexas. Se você está preocupado com histórias baseadas em cliques, considere usar o Fluxo ou o OmniStudio como uma alternativa viável a um controlador do Apex para suas necessidades no lado do servidor.

Você também deve considerar se deseja confirmar ações imediatamente ou adiá-las para uma parte específica do formulário. Isso é especialmente relevante se você estiver usando um formulário de várias páginas. O fluxo facilita a combinação de entradas de vários formulários (tela de fluxo) e a sua utilização posteriormente no assistente (fluxo) para realizar determinadas operações, o que é exatamente como recomendamos projetar Fluxos. Executar ações no fim (no caso de os usuários alternarem entre as telas para alterar suas respostas).

#### Controlar operações

As transações e os [limites de governador](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) são parte integrante da Plataforma Agentforce 360. Se o seu caso de uso for bastante simples, talvez não seja tão importante controlar a transação em que uma determinada operação ocorre. No entanto, há alguns casos de uso em que você pode querer combinar várias operações em uma única [transação](/docs/architect/pt-br/fundamentals/guide/architecture-basics#transações) em vez de realizá-las entre várias transações.

Aqui estão alguns exemplos:

- **Rollback:** Digamos que seu formulário crie vários registros nos bastidores. Se a criação de um terceiro registro falhar, os dois primeiros registros deverão ser revertidos? Se cada uma de suas ações for independente uma da outra, você poderá executá-las como transações separadas. No entanto, se eles dependem um do outro – e você deseja que a falha de um também reverta os outros – você deve implementá-los como uma única transação. Se seu formulário estiver em Fluxo, você poderá usar o elemento Reverter no caminho de falha para reverter sua transação e garantir a integridade dos dados.

- **Impacto a jusante nos limites do regulador:** Quando seu formulário cria ou atualiza um registro, é importante considerar quais são as implicações a jusante dessa operação:

  - Quais processos, regras de fluxo de trabalho, acionadores de fluxo, acionadores do Apex ou outros itens no pedido de salvamento podem ser acionados com base nas alterações de registro propostas?

  - Como essas alterações coletivas afetam os limites do controlador que estão sendo consumidos nessa transação?

  - Se uma alteração de registro específica puder resultar em muitas alterações a jusante que afetam seus limites, talvez seja melhor considerar isolar essa alteração de registro em sua própria transação.

- **Processamento em lote:** Talvez seja necessário colocar várias atualizações em lote (mesmo dentro de um contexto de UI). Digamos que seu formulário de várias telas itere em um grande grupo de registros. Em vez de confirmar uma atualização de registro após cada tela, espere até coletar as atualizações de todos os registros e envie uma solicitação para atualizar todos os registros.

Quando você usa Formulários dinâmicos para criar ou editar um registro, está realizando apenas uma operação, e essa operação é sempre o início de uma transação líquida e nova.

Ao criar um fluxo de tela, você tem controle significativo sobre o que ocorre em uma determinada transação. Telas e ações locais atuam como limites entre transações. Aqui está um resumo de alto nível de como as transações são gerenciadas na arquitetura de fluxo de tela.

1. O usuário final interage com uma tela e clica em **Avançar**.

2. O cliente publica uma solicitação de entrada para a API.

3. A API recebe a solicitação e abre uma conexão de transação e banco de dados. Em seguida, a API chama o mecanismo de Fluxo para invocar a solicitação.

4. O mecanismo de Fluxo assume e segue o caminho adequado na definição de fluxo até atingir uma tela ou nó de ação local. Em seguida, o mecanismo retorna informações sobre esse nó para a API.

5. A API cria um objeto de resposta que contém os detalhes da próxima tela a ser renderizada e retorna esse objeto ao cliente. Nesse ponto, as alterações de banco de dados são confirmadas (por execução do [pedido de salvamento](/docs/architect/pt-br/fundamentals/guide/architecture-basics#manipulação-de-banco-de-dados)) e a conexão e transação do banco de dados são fechadas.

6. O cliente usa a resposta da API para renderizar a próxima tela com a qual o usuário interage.

7. Comece na etapa 1 e repita o processo.

Em outras palavras, as telas _quebram_ transações. Quando isso ocorre, quaisquer ações pendentes ou DML são confirmados, a transação anterior é fechada e uma nova transação começa.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow1.png" alt="multi-screen flow" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
Lembre-se de que os elementos de design específicos (que operações você agrupa em uma determinada transação) dependem de você.

Aqui estão alguns exemplos:
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow2.png" alt="screen flow with separate transactions" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

- Ao começar, você verá um fluxo que coleta entradas em várias telas e, em seguida, executa várias ações em uma transação.
- O próximo fluxo realiza cada operação em uma transação separada.
- Os fluxos também podem usar Reverter registros para permitir que você reverta uma transação inteira se uma única operação falhar em uma série de operações de banco de dados.
  <image src="https://architect.salesforce.com/ns-assets/guide-forms-flow3.png" alt="Screen Flow with multiple create records" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
  Digamos que você tenha um fluxo que crie registros, atualize registros e crie registros adicionais (ilustrado no próximo fluxo).

Nesse cenário, se os dois primeiros elementos forem bem-sucedidos e o último falhar, as duas primeiras operações DML ainda criarão e atualizarão os registros apropriados, mas o terceiro não.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow4.png" alt="Screen Flow with Rollback" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
Ao usar o elemento Reverter registros, você pode garantir que toda a transação seja revertida se todas as três operações precisarem ocorrer coletivamente (como visto no fluxo final).

**Nota:** Para obter mais detalhes, consulte [Fluxos em transações](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm) e [Multiplicação de fluxo em transações](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm).

Sua capacidade de controlar a transação de um LWC é baseada nos serviços subjacentes que o LWC está usando para realizar suas operações. Se você estiver usando o componente de base Lightning, a operação subjacente (criar ou atualizar o registro) ocorrerá em uma transação independente quando o formulário for enviado.

Em geral, estas regras se aplicam:

- Cada chamada à API da IU é isolada dentro de sua própria transação.

- Se você precisar realizar várias operações em uma única transação, envie as entradas para uma tecnologia no lado do servidor (por exemplo, um controlador do Apex ou um Fluxo). Lembre-se de que as regras de transação normais para essa tecnologia ainda se aplicam.

#### Integrações externas

O Fluxo, o OmniStudio e o LWC oferecem suporte a eventos de plataforma (para a [arquitetura orientada por evento](/docs/architect/pt-br/decision-guides/guide/event-driven)) e integrações de API. Além do Apex code personalizado, o Fluxo e o OmniStudio têm mecanismos de suporte declarativo que também podem ser integrados às APIs.

Se precisar se conectar a uma API do MuleSoft ou bot de RPA, use os Serviços do MuleSoft, pois isso gera um Serviço externo.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-mulesoftnoheader.png" alt="External integrations via MuleSoft" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Se a API tiver um esquema OpenAPI, crie um Serviço externo.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-openapi-noheader.png" alt="External Integrations via OpenAPI" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

Para todas as outras instâncias, use o recurso **Chamada HTTP** (desenvolvido por serviços externos) no Fluxo ou a **Ação HTTP** no OmniStudio.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-integrations-callouts-noheader.png" alt="External integrations via HTTP" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

O OmniStudio oferece um conjunto avançado de recursos de integração que podem chamar sistemas externos usando procedimentos de integração para transformar dados por meio do Data Mapper.

Independentemente de você usar Apex code personalizado ou um serviço externo para implementação, uma **chamada** ainda é uma chamada.

Isto é o que você precisa saber.

- A processamento de uma chamada pode levar um tempo significativo.

- Quando uma chamada é executada de modo síncrono, ela é realizada enquanto uma transação de banco de dados está aberta.

- O Salesforce não permite que você mantenha uma transação de banco de dados aberta se tiver alguma operação de banco de dados pendente.

Lembre-se de que a principal limitação é o perigo de deixar os dados em um estado inconsistente, que ocorre quando você executa uma operação de **criação**, **atualização** ou **exclusão** e, em seguida, executa uma **chamada** dentro da mesma transação. Esse padrão não é permitido devido à terceira consideração mencionada acima, que existe devido às duas primeiras considerações.

No Fluxo, você pode ignorar essa limitação interrompendo a transação. Lembre-se de que telas e ações locais reintroduzem o contexto do navegador. Embora você possa usar telas e ações locais ao trabalhar com chamadas externas, recomendamos ativar o **Controle de transação** nas configurações avançadas invocáveis. O Controle de transação permite encerrar automaticamente a transação antes de uma chamada ser feita. Para habilitar o Controle de transação, selecione "**Sempre iniciar uma nova transação**" na seção **Avançado** da ação invocada.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-flow5.png" alt="External Integrations via Callouts" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
O LWC ajuda a simplificar o impacto das chamadas na transação. Em outras palavras, execute suas operações de dados usando o Lightning Data Service (LDS) e, em seguida, use um controlador do Apex para fazer a chamada externa. Como a chamada LDS é isolada dentro de sua própria transação (separada da chamada do Apex), isso o protege contra inconsistências de dados resultantes.

#### Reusabilidade e modularidade

Formulários dinâmicos não oferecem suporte à reutilização. Cada uma é vinculada a uma página de registro do Lightning específica para um objeto específico; no entanto, você pode atribuir essa página de registro do Lightning a vários aplicativos, perfis e assim por diante.

Da mesma forma que você pode escrever bibliotecas, utilitários e componentes que podem ser usados em vários componentes, você também pode aplicar padrões de design semelhantes ao criar fluxos aproveitando o poder dos **subfluxos**. Para fazer isso, salve seus fluxos em grupos modulares menores e, em seguida, chame-os de outros fluxos usando o elemento **Subfluxo**. Se o seu design exigir isso, você poderá criar um fluxo que seja útil sozinho e como um subfluxo.

O OmniStudio é criado inerentemente para modularidade. Mapeadores de dados, OmniScripts, FlexCards e Procedimentos de integração são criados de modo independente, mas também podem funcionar de modo intercambiável. Os FlexCards também podem ser criados como componentes do LWC que podem ser integrados a outros LWCs, OmniScripts, páginas de registro e sites do Experience Cloud.

Fluxos de tela, OmniScripts e LWCs podem ser criados para reutilização e incorporados em vários locais, incluindo sites externos e aplicativos do Lightning Out. Ao projetar suas soluções para serem composíveis, você também obtém benefícios de adaptabilidade e estabilidade.

### Validação

Todas as tecnologias usadas para criar ou atualizar registros devem cumprir a validação no nível do sistema, sejam elas regras de validação clássicas ou validações personalizadas integradas em um acionador do Apex. Independentemente da tecnologia usada para realizar alterações de registro, todas as alterações devem passar pela ordem de salvamento. Isso significa que, além das regras de validação, as alterações de registro também são processadas por vários fluxos antes ou depois de salvar, acionadores antes ou depois, regras de escalação, regras de atribuição e assim por diante.

**Nota:** Se ainda não o fez, revise e marque como favorito a [ordem de execução](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) do Apex.

#### Perguntas a fazer

- Seu formulário tem requisitos adicionais além da validação no nível do sistema?

- Você precisa definir campos obrigatórios ou somente leitura dinamicamente no formulário?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Respeitar validação no nível do sistema</th>
<th colspan="1" rowspan="1">Validação em nível de campo personalizada específica para este formulário</th>
<th colspan="1" rowspan="1">Validação em nível de campo personalizada</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr></table>

Geralmente, entradas em uma tela de fluxo ou etapa do OmniScript não são vinculadas, portanto, o formulário em si não adere nativamente à validação no nível do sistema associada a um determinado objeto. No entanto, os valores que você usa para criar ou atualizar registros são processados na ordem de salvamento, o que significa que passam pela validação no nível do sistema do objeto.

**Nota:** Nem todos os componentes do Fluxo de tela oferecem suporte à validação de entrada.

Da mesma forma que os layouts de página, os Formulários dinâmicos permitem definir a **necessidade** e o estado **somente leitura** no nível da página. Lembre-se de que não é possível substituir configurações no nível do sistema.

O fluxo oferece flexibilidade para personalizar a validação de entrada de formulário. Várias verificações são realizadas no nível do cliente (por exemplo, a sinalização de campos obrigatórios ausentes e verificações de tipo de dados, bem como fórmulas compatíveis em regras de validação de entrada). Como um nível adicional de segurança, a validação de entrada também é avaliada no servidor. Quando um usuário clica em **Avançar**, o Fluxo envia as entradas ao servidor para validação novamente. Se alguma entrada inválida for retornada, a navegação será bloqueada e o erro adequado será exibido.

O servidor valida as entradas verificando:

- A configuração de **necessidade** da entrada ou se o valor inserido é compatível com o tipo de dados subjacente.

- A validação personalizada da entrada. Você precisa fornecer uma expressão de fórmula _booleana_ e uma mensagem de erro a ser exibida quando a expressão de fórmula não for atendida.

- A validação personalizada do componente subjacente. Se você estiver criando um LWC personalizado para um fluxo, precisará adicionar seu próprio código de validação ao método validate().

Você também pode fornecer alertas do usuário acessíveis por meio do componente **Mensagem** em Fluxos de tela, mas isso não impede o usuário de navegar para outras páginas ou avançar para a etapa seguinte em um fluxo guiado. O estado de _erro_ no componente **Mensagem** é melhor usado em telas de erro dedicadas que são acionadas por meio de um caminho de falha quando a navegação é desativada.

O OmniStudio oferece tratamento robusto de erros e validação por meio da ação [Definir erro](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5) em combinação com as Visualizações [condicionais](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5) e o componente [Mensagens](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5).

Para o LWC, a maioria dos componentes de base realiza suas próprias validações no lado do cliente (por exemplo, Lightning respeita a exigência no nível do sistema, mas não a exigência no nível da página). Para seus componentes personalizados, você pode Build Your Own mecanismos de validação.

Lembre-se de que os campos que exigem que os usuários insiram dados devem aparecer no início dos formulários. Valide as entradas do usuário no lado do cliente antes do envio dos formulários (quando possível).

### Design da interação

Formulários estáticos estão desatualizados. Hoje, o foco mudou para atualizar dinamicamente formulários com as propriedades e valores certos para um usuário _específico_, em um momento _específico_, em um lugar _específico_. Vamos analisar mais detalhadamente o que é viável usando as ferramentas de criação de formulário do Salesforce.

#### Perguntas a fazer

- Quais tipos de interações ou condições devem acionar respostas dinâmicas no seu formulário?

- Você precisa executar operações fora da tela (em segundo plano) enquanto seu formulário está sendo preenchido?

- Você precisa definir os campos como **visíveis**, **obrigatórios**, **somente leitura** ou **desabilitados** ou precisa alterar a formatação com base nas entradas do formulário?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Executar operações de dados fora da tela</th>
<th colspan="1" rowspan="1">Valores condicionais e cálculos</th>
<th colspan="1" rowspan="1">Visibilidade condicional</th>
<th colspan="1" rowspan="1">Requisito condicional</th>
<th colspan="1" rowspan="1">Formatação condicional</th>
<th colspan="1" rowspan="1">Estado somente leitura condicional</th>
<th colspan="1" rowspan="1">Estado condicional desabilitado</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="8" rowspan="1" style="border-right: 1px solid #d8dde6;">*Limitado a componentes que usam um seletor de recurso e não uma caixa de seleção estática</td></tr></table>

As **Telas reativas** habilitam a interatividade do Fluxo de tela. A reatividade permite que componentes individuais em uma tela de fluxo se comuniquem entre si, o que torna os Fluxos de tela mais eficientes.

**Executar operações de dados fora da tela**

Fluxos de tela fornecem uma abordagem declarativa para buscar dados na mesma tela por meio de **Ações de tela**. As Ações de tela permitem acionar fluxos iniciados automaticamente em qualquer alteração na tela ou quando um usuário clica em um componente de **Botão de ação**. Você pode mapear resultados de fluxo iniciados automaticamente para a mesma tela, o que elimina a necessidade de os usuários navegarem para outra tela.

O LWC fornece uma gama completa de adaptadores de conexão que fornecem acesso a dados do Salesforce para preencher dinamicamente dados em componentes de formulário, o que permite que os desenvolvedores **atualizem**, **excluam** e **criem** registros por meio de controladores do Apex.
<image src="https://architect.salesforce.com/ns-assets/legacy/buildingformsguidediagrams-offscreendataoperations-noheader.png" alt="Lightning Web Components Off-Screen Data Operations" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />

**Visibilidade**

A visibilidade pode ser controlada dinamicamente em todas as ferramentas de criação de formulário. Formulários dinâmicos, Flow Builder e OmniStudio lidam com isso usando recursos de visibilidade do componente. Você pode **mostrar** ou **ocultar** campos de modo declarativo com base em outros valores no formulário ou se o usuário está preenchendo o formulário em um dispositivo móvel.

- Formulários dinâmicos controlam a visibilidade com base em valores de campo de registro, campos de pesquisa e formato.

- Com o Fluxo, você pode basear uma regra de visibilidade em outras entradas de tela, bem como em outros recursos que são preenchidos anteriormente no fluxo (por exemplo, fórmulas ou valores de outros registros).

  - **Regras baseadas em dispositivo:** Pode não ser óbvio desde o início, mas você pode usar uma fórmula para **mostrar** ou **ocultar** um determinado campo quando o usuário estiver em um dispositivo móvel. Escreva uma fórmula de fluxo que verifique o valor da variável global **$User.UIThemeDisplayed**. Se o valor for **Theme4t**, o usuário está preenchendo o formulário usando o aplicativo Salesforce móvel.

  - **Avaliar outros recursos:** Referências de variável manual e de fórmula são avaliadas apenas no servidor. Isso significa que o valor que o recurso tem quando a tela é renderizada pela primeira vez é o valor que ele terá até você navegar para outra tela. Durante a navegação, o tempo de execução do fluxo envia uma solicitação ao mecanismo de fluxo (o servidor) e retorna os valores de fórmula e variável manual mais recentes. Se você espera que sua regra de visibilidade seja atualizada à medida que o usuário passa por uma única tela (por exemplo, onblur), precisará garantir que você faça referência apenas a valores dos outros componentes na tela.

- Com o OmniStudio, você pode **mostrar** ou **ocultar** componentes condicionalmente configurando uma propriedade de Visualização **condicional**. No entanto, não é possível adicionar mais de uma propriedade de Visualização condicional para uma entrada.

**Estados de entrada condicional**

Se você precisar controlar dinamicamente outras propriedades (por exemplo, se um campo é **obrigatório**, **desabilitado** ou **somente leitura**), há algumas opções. O LWC fornece controle reativo total sobre seu estado de entrada. Com os componentes de Fluxo de tela reativo, você pode controlar dinamicamente os atributos de componente (por exemplo, **somente leitura**, **desabilitado** e **necessário**) para componentes padrão que dão suporte a ele, enquanto o OmniStudio oferece suporte a todo o espectro de atributos específicos do componente. Se os seus requisitos ditarem que você precisa do Fluxo e o componente não oferecer suporte a um estado de atributo específico, você poderá criar um LWC integrável para obter um estado de entrada dinâmico.

Se você precisar controlar dinamicamente qualquer outra propriedade (por exemplo, se um campo é **obrigatório** ou **somente leitura**), use o LWC em curto prazo, pois você tem controle total. Isso é especialmente verdadeiro se você tiver requisitos personalizados para como lidar com onblur ou onclick.

**LWCs reativos em fluxos de tela**

Se você estiver criando LWCs que podem reagir e alterar outros componentes em um fluxo de tela, confira o guia [LWC Best Practices for Screen Flows](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows) para garantir que seus componentes se integram ao mecanismo de tempo de execução de fluxo e funcionem como desejado.

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Manipulação de evento padrão (onblur, onfocus)</th>
<th colspan="1" rowspan="1">Manipulação de evento personalizado</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*O Tempo de execução padrão do OmniStudio não oferece suporte a Pub/Sub, mas oferece suporte a Windows postMessage</td></tr></table>

Para eventos personalizados, se algumas de suas entradas (ou todo o formulário) precisarem se comunicar com outro elemento na página, o LWC será sua única opção.

- Para se comunicar dentro da mesma árvore DOM, use a [interface CustomEvent](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events).

- Para se comunicar no DOM, use o [Serviço de mensagens do Lightning](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel).

- Se o Serviço de mensagens do Lightning [não tiver suporte](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations) para seu contêiner de destino, use o módulo pub/sub.

#### Recursos adicionais para design de interações

- Para obter mais informações detalhadas, consulte [Comunicar com eventos](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events) e [Comunicar no DOM](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub) no Guia do desenvolvedor de _componentes da Web Lightning_.

- Para o OmniStudio, confira [Comunicar com OmniScript a partir de um Componente da Web Lightning.](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5)

### Estilização

Para proporcionar a melhor experiência do usuário, é importante garantir que o estilo do formulário seja consistente com o restante do aplicativo ou site em que ele está sendo integrado. Isso pode significar usar modelos padrão fornecidos pelo Salesforce ou criar um CSS personalizado que use cada pixel no design para proporcionar uma aparência mais nítida.

#### Substituições de estilo de fluxo de tela

Os administradores podem configurar um conjunto limitado de substituições de estilo de tela e componente (por exemplo, cores, bordas e exibições de botão), para o contêiner de tela ou para componentes individuais. Essas substituições são aplicadas após temas e identidade visual, o que permite que os criadores façam ajustes visuais direcionados sem afetar o restante do aplicativo.

As substituições de estilo são destinadas a exceções visuais localizadas (por exemplo, realçar uma tela de confirmação ou enfatizar uma chamada à ação (CTA) específica); elas não são um sistema de estilo completo. Eles não fornecem controle em nível de CSS e não são projetados para serem reutilizados entre telas ou fluxos.

De uma perspectiva arquitetônica, o estilo deve seguir esta ordem precedente:

1. **Temas e identidade visual:** Temas do Lightning, Conjuntos de identidade visual do Criador de experiências ou tema do site do LWR

2. **Substituições de estilo de fluxo:** Ajustes de tela ou componente direcionados

3. **Componentes personalizados (LWC):** quando o controle perfeito por pixel ou padrões de design reutilizáveis forem necessários

O uso de temas e sistemas de design ajuda a garantir que o estilo permaneça consistente, escalonável e fácil de manter ao longo do tempo.

#### Perguntas a fazer

- Quão sofisticado é o estilo e o CSS desejados?

- Você precisa de estilo personalizado perfeito para pixel ou temas padrão?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Estilização direta</th>
<th colspan="1" rowspan="1">Temas de organização e do Criador de experiências</th>
<th colspan="1" rowspan="1">Estilização perfeita para pixels</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível**</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="4" rowspan="1" style="border-right: 1px solid #d8dde6;">*Somente FlexCards<br><br>**Certos atributos de estilo podem ser configurados para componentes de tela, mas não substituições de CSS.</td></tr></table>

O FlexCards é o único produto neste guia que permite controlar declarativamente o estilo e o layout da interface do usuário que você está criando na ferramenta (por exemplo, margens e enchimento, tipografia, cores etc.).

Fluxos e formulários dinâmicos respeitam os recursos de tema declarativo. Se você precisar de controle adicional (além do suporte para [Temas do Salesforce](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1), [Conjuntos de identidade visual do Criador de experiências](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm) ou Sites do [LWR Experience Cloud](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm)), considere uma solução programática.

Equipes que se sentem à vontade ao trabalhar com CSS têm várias opções:

- Fluxos e LWCs herdam [tokens de design padrão](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm).

- OmniScripts e FlexCards incluem suporte de sistema de design personalizável via [Newport](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5).

- Com o LWC, você pode escrever seus próprios componentes e controlar totalmente o HTML e o CSS.

Quando possível, recomendamos usar temas e sistemas de design para garantir uma aparência consistente em todo o seu conteúdo.

**Nota:** Você pode integrar componentes do Lightning em Fluxos. Se você precisar de controle perfeito por pixel sobre a aparência do seu formulário, mas também quiser usar os outros benefícios de Fluxos (por exemplo, o modelo de navegação), poderá ter o melhor dos dois mundos! O mesmo princípio se aplica a OmniScripts e FlexCards.

### Layout

Escolher um bom layout é crucial para projetar formulários simplificados que permitem uma entrada de dados rápida e eficiente e aumentam a integridade dos dados.

#### Perguntas a fazer

- Como você pode estruturar layouts de formulário para otimizar as experiências do usuário?

- Como apresentar dados existentes aos usuários de maneira que facilite a inserção de novos dados nos formulários?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">2 colunas</th>
<th colspan="1" rowspan="1">4 colunas</th>
<th colspan="1" rowspan="1">Além de quatro colunas</th>
<th colspan="1" rowspan="1">Repetindo blocos de dados</th>
<th colspan="1" rowspan="1">Contêineres de guia</th>
<th colspan="1" rowspan="1">Contêineres de acordeão</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="7" rowspan="1" style="border-right: 1px solid #d8dde6;">*As guias podem ser usadas ao integrar dados em um FlexCard em um OmniScript</td></tr></table>

Os Formulários dinâmicos oferecem suporte a layouts de duas colunas que podem ser divididos em seções individuais dentro de campos. Essas seções podem ser colocadas dentro de componentes (por exemplo, guias e acordeões) para criar layouts organizados e fáceis de usar.

Fluxos também podem ser renderizados usando o componente **Seção**. Você pode adicionar até quatro colunas e um número ilimitado de seções na tela de fluxo. O componente Seções também é responsivo à largura da tela, assim, ele também funciona em telas menores. Isso permite que você aplique visibilidade condicional a toda a seção, o que facilita a aplicação em massa de visibilidade a vários campos dentro da seção. As **seções de fluxo** também suportam cabeçalhos de coluna e oferecem uma experiência de acordeão em que os usuários podem recolher toda a seção clicando no rótulo.

Os OmniScripts apresentam uma variedade de opções de layout para exibir campos e dados. Você pode criar seções de dados com até 12 colunas, incluindo acordeões condicionalmente recolhíveis.

Com o LWC, você pode usar Lightning\[edit\|view]-form e o campo Lightning-\[input\|output] com suporte para controlar o layout. As únicas restrições de layout vêm de HTML e CSS. O componente **Lightning-record-form** respeita a configuração de seção no layout de página associado (por exemplo, se uma seção for de duas colunas no layout de página, ela também será de duas colunas no componente).

### Tradução

Se o formulário precisar ser acessado por usuários em diferentes regiões ou que falam diferentes idiomas, você precisará garantir que a ferramenta que está usando para criá-lo atenda aos seus requisitos de localização.

**Nota:** Especificamente para formulários, os requisitos de localização geralmente envolvem a tradução de elementos de texto para outros idiomas.

#### Perguntas a fazer

- Seu formulário será usado em mais de um país ou região?

- O texto no formulário precisa ser localizado para outros idiomas?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Rótulos inseridos no Criador</th>
<th colspan="1" rowspan="1">Rótulos no código</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Não aplicável</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*Apenas cabeçalhos da seção de campo</td></tr></table>

Se você localizar campos personalizados, os Formulários dinâmicos respeitarão os rótulos traduzidos. Os Formulários dinâmicos também respeitam quaisquer [rótulos personalizados atribuídos a rótulos e atributos de componente](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5) no Criador de aplicativo Lightning.

O Fluxo dá suporte à tradução de rótulos voltados para o usuário para todos os componentes de tela padrão e personalizados por meio do Workbench de tradução.

Você pode localizar rótulos, texto de ajuda e mensagens de erro nestes componentes de tela:

- Texto
- Área de texto longo
- Número
- Moeda
- Caixa de seleção
- Botões de opção
- Lista de opções
- Lista de opções de seleção múltipla
- Senha do grupo de caixas de seleção
- Data
- Data/hora

Não há suporte de tradução integrado para ações prontas para uso (por exemplo, Enviar email ou Publicar no Chatter), mas há uma solução alternativa. Se você usar um [rótulo personalizado](https://help.salesforce.com/articleView?id=cl_about.htm) para definir os rótulos traduzidos, poderá fazer referência a esse rótulo personalizado na ação ou no componente ao configurá-lo no Flow Builder. Para fazer isso, você precisa criar uma fórmula de fluxo que faça referência ao rótulo personalizado e, em seguida, faça referência a essa fórmula nos locais apropriados em seu fluxo.

Os OmniScripts usam rótulos personalizados para traduções. Para obter mais informações, confira [este documento de ajuda](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm) para garantir que seus OmniScripts estejam prontos para vários idiomas.

Para o LWC, determinados componentes de base herdam automaticamente traduções dos campos do objeto associado, texto de ajuda e mensagens de validação se estiverem configurados no Workbench de tradução (por exemplo, Lightning).

Se você precisar introduzir novos rótulos traduzíveis no seu código, os rótulos personalizados são o caminho certo. Declare o rótulo personalizado de que você precisa e importe-o para seu componente do módulo com escopo de `@salesforce/label`.

## Considerações não funcionais

Use esta seção para avaliar restrições de segurança, qualidade e operacionais antes da implementação.

### Segurança

A segurança é um tópico complexo e, quando se trata de criar formulários, há várias considerações que podem não ser óbvias. No nível fundamental, você precisa garantir que o formulário esteja sendo executado no contexto correto e que os usuários tenham as permissões necessárias para trabalhar com os dados subjacentes. Além disso, você também pode tomar medidas adicionais para remover códigos ou URLs potencialmente mal-intencionados de campos de rich text, impedir que determinados usuários acessem o formulário ou impor limitações aos tipos de locais em que os administradores possam integrar o formulário no futuro.

Certifique-se de documentar cuidadosamente seus requisitos de segurança antes de escolher uma ferramenta. Para obter orientações adicionais sobre esse tipo de documentação, consulte o modelo de [política de segurança bem construída](/docs/architect/pt-br/resources/guide/security-policy-template) do Salesforce.

#### Perguntas a fazer

- O formulário deve verificar o acesso do usuário antes de realizar determinadas operações?

- Você deve limpar as entradas do usuário?

- Deseja controlar quem pode acessar o formulário?

- Deseja controlar onde o formulário pode ser integrado?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Elevar permissões de usuário</th>
<th colspan="1" rowspan="1">Controlar quem tem acesso</th>
<th colspan="1" rowspan="1">Restringir locais permitidos</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível**</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="4" rowspan="1" style="border-right: 1px solid #d8dde6;">*Requer Apex<br><br>**Enquanto os OmniScripts não podem ter um conjunto especificado de locais de destino, os FlexCards podem.</td></tr></table>

#### Elevar permissões de usuário

Quando um programa é executado no **contexto do usuário**, o Salesforce impõe uma série de verificações de acesso, que incluem verificar a segurança em nível de campo, as permissões CRUD e o acesso ao registro com base nas regras de compartilhamento da sua organização (por exemplo, os usuários só poderão executar um formulário de atualização de caso se tiverem a capacidade de atualizar casos, a segurança em nível de campo apropriada e o acesso ao registro em questão).

O que acontece se você quiser que os usuários possam realizar uma determinada operação quando estiverem usando seu formulário, mas não por meio de qualquer outro formulário ou interação? É aí que entra o **Contexto do Sistema**!

O **Contexto do sistema** permite elevar as permissões de um usuário durante a sessão (por exemplo, o usuário não precisa atualizar o acesso ao objeto Caso para preencher com sucesso o formulário de atualização de caso). Isso é especialmente útil para comunidades não autenticadas. Em vez de conceder a usuários convidados habilidades potencialmente perigosas, defina seu formulário para ser executado no contexto do sistema.

O Contexto do sistema deve ser usado apenas quando for absolutamente necessário. Quando um formulário é executado no Contexto do sistema, cada operação CRUD ignora os componentes de compartilhamento e segurança em nível de objeto e campo. Além disso, o Contexto do sistema não tem influência sobre quem o Salesforce considera como o _ator_ (o nome que você vê no campo **Última modificação feita por**). Para cada operação que seu formulário executa (por exemplo, uma atualização de caso), o _ator_ é o usuário atual (mesmo que o formulário seja executado em um contexto diferente).

**Nota:** Formulários dinâmicos, OmniScripts e LWCs sempre são executados no contexto do usuário e não há maneira de substituir esse comportamento.

Fluxos de tela são executados no contexto do usuário por padrão, mas você pode defini-los para serem executados no contexto do sistema. Você pode decidir se o fluxo deve conceder acesso a todos os dados ou se deve impor acesso em nível de registro.

- Se você integrar um componente do Lightning a um fluxo executado no contexto do sistema, o fluxo não substituirá o contexto do componente. Se precisar ignorar verificações de acesso do usuário, use o fluxo para realizar essas operações e passar os dados apropriados para dentro ou para fora do componente do Lightning. Alguns componentes prontos para uso (por exemplo, Pesquisa) não podem operar dentro do contexto do sistema.

- Se o seu fluxo chamar ações do Apex, outras nuances estarão envolvidas.

  - Se a classe do Apex estiver definida como _compartilhamento herdado_, ela será executada no contexto do sistema com compartilhamento, não importa como o fluxo seja definido.

  - Se a classe não tiver uma declaração de compartilhamento explícita, ela será executada no contexto do sistema sem compartilhamento, não importa como o fluxo seja definido.

  - Se a classe for definida como _com compartilhamento ou sem compartilhamento_, ela substituirá o contexto do fluxo.

** Consultar registros no contexto do sistema com sites do Experience Cloud**

Se você estiver executando um Fluxo no contexto do sistema em um site do Experience Cloud (especialmente se ele não for autenticado), armazene apenas campos específicos nos elementos **Obter registros**. Quando você está trabalhando com o Fluxo e passa os resultados de um elemento **Obter registros** para um Subfluxo, ação invocável ou componente do Lightning, todos os campos desse objeto podem ser inspecionados pelas ferramentas de desenvolvedor do navegador. Independentemente de suas intenções, isso pode disponibilizar campos a usuários do Experience Cloud. Para garantir que apenas os campos corretos sejam expostos quando Contexto do sistema estiver habilitado, especifique esses campos específicos nos elementos **Obter registros**.

**Nota:** A lógica do OmniScript é executada no lado do cliente, o que permite aos invasores modificar a execução esperada de um OmniScript e visualizar respostas a procedimentos de integração, mapeadores de dados e chamadas de método do Apex por meio das ferramentas de desenvolvedor do navegador. Quando estiver usando o OmniScript, é importante executar a lógica de negócios no lado do servidor (quando possível) e implementar regras de validação de entrada para todos os métodos do Apex expostos por meio de uma anotação [@InvocableMethod](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5).

**Sanear entradas**

Para proteger sua organização contra atores ruins, use a limpeza de entrada. Digamos que você tenha uma entrada em um formulário publicamente acessível que pode ser mapeada para um campo de **texto complexo** na sua organização. Talvez você queira considerar habilitar a automação que remova qualquer HTML que possa ocultar URLs mal-intencionados.

Não é ideal implementar a limpeza no nível do formulário porque você pode ter qualquer número de origens que escrevam nesses campos. Para ajudar a combater esse problema, crie um Fluxo de atualização de **campo rápido (antes de salvar)** ou use um **Apex Trader** existente para remover ou modificar qualquer HTML potencial que possa ser inserido no formulário.

#### Melhores práticas

- Permita que os fluxos sejam executados no contexto padrão (a menos que você precise elevar o acesso do usuário atual para uma operação específica).

- Evite executar Fluxos no contexto do sistema para usuários convidados. Crie conjuntos de permissões com acesso a campo limitado e atribua-os ao perfil do usuário convidado do Experience Cloud.

- Ao consultar registros em Fluxos de execução de contexto do sistema em sites do Experience Cloud, armazene apenas os campos necessários no elemento **Obter registros** ou **Ações invocáveis**.

- Se um fluxo realizar várias operações, todas elas sem exigir acesso elevado, use Subfluxos para isolar as operações que devem ser executadas no Contexto do sistema.

- Se estiver integrando um formulário em uma página da Web externa, talvez seja necessário mapeá-lo para campos de **texto complexo** para ajudar a prevenir possíveis ataques de phishing. Para fazer isso, limpe as entradas do usuário para remover HTML usando um **Fluxo de atualização rápida de campo** ou **Apex Trader**.

#### Notas adicionais

- OmniScripts, FlexCards e LWCs são executados no contexto do usuário por padrão.

- Os LWCs são executados no contexto do usuário por padrão.

- Os fluxos são executados no contexto do usuário, mas você pode substituí-los usando um controlador do Apex.

- As operações realizadas na API da IU são executadas no contexto do usuário.

- As operações realizadas com um controlador do Apex dependem da classe específica. Para realizar essas operações no modo de sistema, defina a **Classe do Apex** como with sharing ou without sharing.

#### Controle de acesso

Se precisar controlar quem pode acessar um formulário, revise o contêiner em que o formulário está integrado (por exemplo, você pode atribuir páginas do Lightning para que estejam disponíveis para aplicativos, tipos de registro ou perfis específicos). Se determinadas entradas forem confidenciais, use regras de visibilidade para controlar ainda mais o que é exibido para quem. Esse recurso se aplica a formulários dinâmicos e fluxos de tela.

Você pode [restringir um fluxo](https://help.salesforce.com/articleView?id=flow_distribute_security.htm) a determinados perfis ou conjuntos de permissões (semelhantes às páginas do Apex class ou Visualforce). Os fluxos não são restritos por padrão, o que significa que qualquer usuário com a permissão de usuário **Executar fluxos** pode acessá-los.

Se você estiver usando o OmniStudio, poderá configurar um verificador de permissões de classe do [Apex](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5) que exija que os usuários tenham acesso explícito à classe do Apex que administra ações remotas de APIs do OmniScript, FlexCard, Classic Card ou REST.

**Nota:** As verificações de permissão de classe do Apex se aplicam apenas a classes do Apex. Também é aconselhável definir permissões no nível do perfil para [Procedimentos de integração e Mapeadores de dados](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5).

#### Melhores práticas de controle de acesso

- Se você estiver expondo um fluxo a usuários convidados, conceda apenas ao perfil de usuário convidado acesso aos fluxos de que ele absolutamente precisa. É possível adicionar **Fluxos de execução** a perfis de usuário convidado; no entanto, essa prática pode ser arriscada.

- Tenha cuidado ao trabalhar com Fluxos que operam no Contexto do sistema. Você deve restringir esses Fluxos a um determinado conjunto de usuários, pois eles têm menos verificações e saldos em vigor para proteger seus dados.

- Certifique-se de que qualquer OmniScript que execute Apex em uma comunidade de usuários convidados tenha **compartilhamento** listado na definição de classe do Apex.

- Para perfis de usuário convidado, atribua apenas as classes do Apex que você deseja permitir que os usuários convidados chamem. Ao seguir essa prática, ele ajuda a evitar a exposição inadvertida de lógica de negócios adicional a usuários convidados.

Para LWCs, você pode verificar as atribuições de permissão do usuário atual para confirmar se eles têm uma permissão padrão ou personalizada específica. Você pode importar permissões do Salesforce dos módulos com escopo `@salesforce/userPermission` e `@salesforce/customPermission` diretamente no **JavaScript**. Você também pode usar o Apex para verificar permissões.

#### Integrar controles

Os LWCs só estão disponíveis em um determinado local depois de serem adicionados como um [alvo](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags) válido (por exemplo, você pode tornar um componente disponível em páginas de registro e indisponível como um item da barra de utilitários).

Depois que um fluxo de tela é ativado, ele fica disponível em todos os locais com suporte para fluxos de tela. O Flow Builder oferece suporte a vários tipos de Fluxos que têm telas. O tipo mais proeminente é o **Fluxo de tela**, mas há alguns outros tipos especializados que são restritos a locais específicos (por exemplo, o **Aplicativo Field Service Mobile** suporta apenas **Fluxos do Field Service Mobile)**. Isso é semelhante aos **Fluxos de solicitação de contato**, que são compatíveis apenas com o Experience Cloud.

Independentemente do tipo de Fluxo, a pessoa que está criando o Fluxo não tem controle sobre onde o Fluxo está integrado. Os fluxos estão disponíveis em todos os locais em que há suporte para esse tipo de fluxo específico.

Se você estiver usando o Salesforce Industries, haverá uma leve advertência quando se trata do OmniScript.Não é possível especificar um destino para um OmniScript; no entanto, você pode especificar um destino para os FlexCards que deseja integrar.

### Automação de teste de IU

No Salesforce, há várias ferramentas de automação de teste completas (por exemplo, consulte o [Salesforce UTAM](https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam)) que permitem simular como um usuário interage com seus formulários. Você pode escrever testes para qualquer interface do usuário padrão ou personalizada, incluindo páginas do Lightning e fluxos de tela.

**Nota:** Esses tipos de testes não podem verificar as saídas para os métodos que estão sendo realizados. Lembre-se disso ao configurar os requisitos de automação de teste da IU.

#### Perguntas a fazer

- Você precisa de testes automatizados para seus formulários?

- Quais tipos de testes você planeja realizar?

- Qual nível de granularidade é necessário para automações de teste?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Testes de unidade</th>
<th colspan="1" rowspan="1">Automação de ponta a ponta</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Disponível*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Disponível*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Disponível*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="3" rowspan="1" style="border-right: 1px solid #d8dde6;">*Requer código</td></tr></table>

**Considere os Requisitos de automação de teste da IU**

Os **testes de unidade** fornecem automação e validação granulares alinhadas aos sistemas e ferramentas CI/CD padrão do setor, que testam a lógica de negócios, os controles JavaScript e as saídas de componentes específicos. Se você escolher uma abordagem com pouco código, não poderá autenticar testes; no entanto, o Salesforce testa rigorosamente todas as ofertas de ponta a ponta.

Se os métodos do seu componente forem complexos, você poderá textá-los individualmente colocando os métodos em arquivos JavaScript dedicados. Isso permite importá-los para um LWC e, em seguida, para um **teste Jest (por exemplo,** importar { sort } de 'c/utils';).

Você pode usar uma solução sem código de um ISV, criar uma solução de automação de teste personalizada ou usar uma estrutura de teste de código aberto (por exemplo, Selenium WebDriver ou WebdriverIO) para automação completa. Essas soluções são válidas para todas as interações da IU do Salesforce (por exemplo, um Formulário dinâmico em uma página do Lightning, um Fluxo de tela em uma barra de utilitários ou um LWC em um Fluxo de ação rápida).

### Métricas

Depois de implementar seu formulário em um ambiente de produção, você precisa garantir que ele esteja sendo usado de modo eficaz. Dependendo do seu caso de uso, isso pode significar rastrear o número de vezes que seu formulário foi preenchido para a quantidade de tempo que o usuário médio passa preenchendo o formulário antes de enviar suas informações. É importante identificar seus KPIs rastreáveis antes de escolher uma ferramenta.

#### Perguntas a fazer

- Você precisa rastrear o uso do formulário?

- Quais KPIs podem determinar se o formulário está sendo usado de modo eficaz?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Exibições de página</th>
<th colspan="1" rowspan="1">Tempo gasto no formulário</th>
<th colspan="1" rowspan="1">Rastrear conclusão do formulário</th>
<th colspan="1" rowspan="1">Rastrear a taxa de sucesso</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Disponível**</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível**</td>
<td colspan="1" rowspan="1">Disponível*</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="5" rowspan="1" style="border-right: 1px solid #d8dde6;">*Disponível quando o Tempo de execução do OmniStudio baseado em pacote estiver habilitado** Disponível rastreando o uso de página pai do Lightning</td></tr></table>

Se precisar rastrear o uso e a adoção gerais do formulário, use ferramentas de baixa codificação. Formulários dinâmicos e fluxos de tela são rastreáveis por meio de relatórios personalizados prontos para uso. No entanto, os relatórios de rastreamento de fluxo de tela fornecem granularidade adicional. Se você precisar rastrear o uso do LWC, a disponibilidade pronta para uso dependerá de onde você está usando o LWC. Se estiver em uma página do Lightning, todos os elementos de rastreamento de uso de página do Lightning disponíveis também se aplicarão ao seu LWC. Isso também se aplica a LWCs integrados a Fluxos.

Os Formulários dinâmicos não podem ser rastreados prontos para uso; no entanto, você pode rastrear o uso da página pai do Lightning por meio de [objetos de uso do Lightning](https://help.salesforce.com/articleView?id=lex_usage_reports.htm). Para rastrear páginas padrão do Lightning, use o relatório personalizado **Usuários com uso do Lightning por métricas de página**. Para páginas personalizadas do Lightning, use o relatório personalizado **Usuários com uso do Lightning por métricas do FlexiPage**.

Os fluxos podem ajudá-lo a rastrear a adoção para formulários específicos. Use o Relatório de fluxo de **amostra: Fluxos de tela** para responder a estes tipos de perguntas:

- Qual é a taxa de conclusão para esse formulário? No momento, ele é bem adotado?

- Quanto tempo os usuários levam para preencher esse formulário?

- Que tela os usuários gastam mais tempo concluindo?

- Com que frequência os usuários navegam para telas anteriores?

- Com que frequência ocorrem erros?

Se o relatório padrão não atender às suas necessidades, você pode cloná-lo e fazer alterações ou Build Your Own relatório do zero usando o relatório **Fluxos de tela**.

Se você estiver usando o tempo de execução do OmniScript baseado em pacote, também poderá usar o [Omnistudio para serviço de rastreamento do Vlocity](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5). Esse serviço rastreia todos os tipos de eventos (por exemplo, você pode rastrear o tempo que leva para concluir as etapas em um OmniScript, o que ajuda a identificar melhorias no processo).

**Nota:** Não há uma opção pronta para uso para rastrear um LWC que não esteja integrado a um Fluxo de tela, OmniScript ou página do Lightning, mas você pode criar uma solução personalizada usando o Apex.

### Empacotamento e implantação

Você pode estar familiarizado com o uso de conjuntos de alterações ou o **DevOps Center** para implantar sua solução em ambientes de teste ou em produção. Essas opções de implantação oferecem suporte total a Formulários dinâmicos, Fluxos e LWCs. No entanto, o OmniStudio requer uma ferramenta separada, o [IDX Workbench](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5).

#### Perguntas a fazer

- Como você planeja implementar o formulário?

- O formulário precisa ser distribuído para mais de uma organização do Salesforce?

<table><tr><th colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"></th>
<th colspan="1" rowspan="1">Pacotes gerenciados de primeira geração (1GP)</th>
<th colspan="1" rowspan="1">Pacotes gerenciados de segunda geração (2GP)</th>
<th colspan="1" rowspan="1">Pacotes desbloqueados</th>
<th colspan="1" rowspan="1">Conjuntos de alterações</th>
<th colspan="1" rowspan="1">DevOps Center</th></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível</td>
<td colspan="1" rowspan="1">Não disponível*</td>
<td colspan="1" rowspan="1">Não disponível*</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela + LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td>
<td colspan="1" rowspan="1">Disponível</td></tr>
<tr><td colspan="6" rowspan="1" style="border-right: 1px solid #d8dde6;">*Use o Workbench do IDX para implementar soluções do OmniStudio em outras organizações.</td></tr></table>

Se você for um ISV ou um parceiro que planeja empacotar sua solução para distribuição no AppExchange, confira Formulários dinâmicos, Fluxos e LWCs. Lembre-se de que o OmniStudio não oferece suporte a empacotamento.

### Navegar de baixa codificação para continuum de código profissional

Este guia é destinado a mostrar quais níveis de funcionalidade e personalização estão disponíveis por meio de Formulários dinâmicos, fluxos de tela, OmniStudio e LWC.
<image src="https://architect.salesforce.com/ns-assets/guide-forms-lowcode-continuum.png" alt="Low-Code to Pro-Code Continuum" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem" />
Esta é uma visão geral de alto nível.

- Quando se trata de criar formulários, o LWC é a opção mais robusta e personalizável, mas tem menos proteções em vigor. É por isso que é crucial criar seus componentes com a [segurança](/docs/architect/pt-br/well-architected/guide/trust.html) e a [escalabilidade](/docs/architect/pt-br/well-architected/guide/reliability.html#scalability-and-capacity-planning) em mente.

- Formulários dinâmicos são a opção menos flexível, mas têm muito menos oportunidades para erros.

- Fluxo e OmniStudio ficam ligeiramente no meio. Eles são mais eficientes que Formulários dinâmicos, mas não estão no nível do LWC. No entanto, eles têm menos proteções do que Formulários dinâmicos e são mais difíceis de quebrar do que código personalizado.

Você pode encontrar várias ferramentas adequadas às suas necessidades. Em caso afirmativo, a decisão dependerá, por fim, da melhor ferramenta para sua equipe. Para obter mais informações sobre aspectos adicionais a serem considerados, confira estes [Guia de decisão do arquiteto](/docs/architect/pt-br/decision-guides).

#### Perguntas a fazer

- Ao comparar ferramentas, é importante avaliar quanto conhecimento sua equipe tem sobre cada ferramenta?
- Quantos de seus desenvolvedores conhecem bem o LWC ou JavaScript?
- Há desenvolvedores na sua equipe que sejam especialistas no Flow Builder ou que tenham manifestado interesse em aprender mais?

Embora não vamos entrar em detalhes específicos, aqui está um pouco mais de informações sobre como essas ferramentas específicas se relacionam às avaliações que abordamos até o momento.

**Delegação de entrega**

Lembre-se de que, mesmo que alguns de seus requisitos exijam o LWC, não é necessário criar toda a solução usando o LWC. É importante determinar como você pode criar sua solução modularmente. Para fazer isso, você precisa identificar quais partes exigem LWC codificado e quais não. As peças que não exigem o LWC devem ser criadas usando uma solução de baixa codificação.

Quando se trata de Fluxo e LWC, há vários componentes (por exemplo, Componentes de tela reativa e Fluxo de tela) que podem ser sincronizados entre si na mesma tela para desbloquear novas ferramentas para arquitetos, administradores e desenvolvedores. Os desenvolvedores agora podem criar componentes modulares que podem ser reutilizados em toda a organização, o que ajuda a aumentar a produtividade da equipe. Isso permite que os desenvolvedores economizem tempo usando uma combinação de componentes de Fluxo padrão e personalizados para alcançar o dinamismo do formulário, o que dá mais tempo para eles se concentrarem em resolver novos desafios. Com a introdução de Componentes reativos no Fluxo, nunca houve um momento mais adequado para combinar Fluxo e LWC ao criar formulários.

**Propriedade e manutenção a longo prazo**

Se você estiver criando um formulário de várias etapas, comece com Fluxo ou uma combinação de Fluxo e LWC. Se a equipe que está mantendo o formulário for uma equipe com pouco código, garanta que a solução seja o mais configurável e extensível possível para seu público-alvo. Para melhorar a estabilidade e a capacidade de manutenção, é importante organizar sua solução em unidades [compostables](/docs/architect/pt-br/well-architected/guide/resource-and-cost-optimization.html#packaging-and-modularity), independentemente da ferramenta escolhida.

### Desempenho

Considerações de desempenho relacionadas a Formulários dinâmicos, Fluxos de tela, OmniStudio ou LWC são baseadas na estrutura em que as tecnologias estão hospedadas. As tecnologias baseadas no LWC tendem a apresentar um desempenho superior àquelas baseadas no Aura. Devido a vários recursos principais implementados nativamente em mecanismos da Web (em vez de em JavaScript por meio de abstrações de estrutura), o LWC oferece benefícios de desempenho aprimorados.

Então, como aproveitamos esses benefícios de desempenho para nossas tecnologias de formulário no Salesforce? Vamos analisar mais detalhadamente.

- O recurso Formulários dinâmicos (integrado aos metadados da página do Lightning) é baseado em uma pilha do LWC, que nos permite implementar vários recursos muito esperados. Como um bônus de desempenho adicional, os Formulários dinâmicos usam renderização progressiva, o que melhora o tempo de carregamento para páginas com um grande número de campos.

- Os fluxos de tela são criados com base no LWC. A maioria dos componentes individuais prontos para uso agora foram convertidos para o LWC, com exceção dos componentes **Upload de arquivo** e **Imagem**. Embora a equipe do Fluxo tenha convertido o cliente de tempo de execução de fluxo para o LWC (e a maioria de seus componentes), os clientes ainda precisam converter seus componentes da tela do Aura para o LWC. Lembre-se de que o Salesforce oferece suporte apenas a componentes do LWC na estrutura de **Componente reativo** em Fluxos de tela. Para obter mais informações, consulte o módulo Trailhead [Lightning Web Components for Aura Developer](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers). Se você estiver pensando em criar um componente personalizado para um Fluxo de tela (ou qualquer outro contêiner), escolha LWC!

- Há várias versões do OmniStudio disponíveis. Se você é um cliente de longa data, pode estar usando o **Angular**. Incentivamos todos os novos clientes a usar OmniScripts e FlexCards baseados em LWC. Também incentivamos os clientes atuais a migrarem do Angular.

- O LWC é criado com base no LWC.

## Recursos

<table><tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Formulários dinâmicos</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_overview.htm&language=en_US&type=5">Dividir seus detalhes de registro com formulários dinâmicos</a><br>- <a href="https://help.salesforce.com/s/articleView?id=platform.lightning_app_builder_overview.htm&type=5">Obter ajuda para o Lightning App Builder</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Fluxo de tela</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=platform.create_forms_with_screen_flow_components.htm&type=5">Usar fluxos de tela para interagir com os usuários</a><br>- Automatizar <a href="https://help.salesforce.com/s/articleView?id=platform.flow.htm&type=5">tarefas com fluxos</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>Omnistudio</strong></td>
<td colspan="1" rowspan="1">- <a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_omnistudio.htm&release=236&type=5">Omnistudio</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_omniscripts_8355.htm&type=5">OmniScripts</a><br>- Aplicação de <a href="https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5">desktop do Workbench do IDX</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5">Newport Design System</a><br>- <a href="https://help.salesforce.com/s/articleView?id=xcloud.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5">Personalize OmniScripts e FlexCards com o Newport Design System</a></td></tr>
<tr><td colspan="1" rowspan="1" style="border-right: 1px solid #d8dde6;"><strong>LWC</strong></td>
<td colspan="1" rowspan="1">- <a href="https://developer.salesforce.com/developer-centers/lightning-web-components">Componentes da Web Lightning</a><br>- Guia do desenvolvedor de componentes do <a href="https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm">Lightning Aura</a><br>- <a href="https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers">Componentes da Web Lightning para desenvolvedores do Aura</a></td></tr></table>

<!-- document id=7065b2163f2c1bae1e15f84c06938b5e26ea525850abfeaf88877ef209b18cbe url=/architect/current/pt-br/decision-guides/guides/data-integration.md -->

# Integração de dados com o Salesforce

Há várias maneiras de acessar, sincronizar e compartilhar dados entre o Salesforce e sistemas externos. Porém, nem todas as ferramentas são adequadas para seu projeto específico. Este guia apresenta o panorama das ferramentas de integração de dados disponíveis no Salesforce. Ele também oferece recomendações para as ferramentas (ou combinações de ferramentas) mais adequadas para um determinado caso de uso, bem como orientações sobre ferramentas para evitar em cenários específicos.

## Visão geral do guia

Este guia de decisão foca integrações no nível de dados envolvendo o Salesforce. Especificamente, ele abrange os seguintes casos de uso de integração de dados:

- Salesforce para sistemas externos
- Sistemas externos para o Salesforce
- Organização do Salesforce para organização do Salesforce

Esses são apenas um subconjunto dos desafios de integração que os Arquitetos do Salesforce enfrentam, assim, planejamos adicionar mais guias de decisão focados na integração conduzida por evento, criar fluxos de trabalho eficazes voltados para o cliente ou para o funcionário usando a integração de processos e assim por diante. Por fim, é importante observar que muitas das ferramentas e abordagens descritas aqui podem ser usadas para resolver desafios de integração em toda a empresa, mas esses usos estão além do escopo deste guia.

## Capturas

- **Evite replicação desnecessária de dados.** A menos que os dados absolutamente precisem residir no Salesforce, considere a virtualização de dados com o Salesforce Connect. Mais dados em sua organização resultam em maiores volumes de dados, o que pode afetar negativamente o [desempenho](/docs/architect/pt-br/well-architected/guide/reliability.html#scalability-and-capacity-planning) e aumentar o débito técnico. Se seus dados já residem no Salesforce e você precisar deles em um sistema externo, evite copiá-los para um sistema externo, a menos que seja absolutamente necessário. Em vez disso, permita que o sistema externo acesse os dados por meio das APIs do Salesforce.
- **Use o MuleSoft ou outras soluções Enterprise Service Bus (ESB) ou Extract-Transform-Load (ETL), se disponíveis e parte de sua paisagem existente.** Como essas ferramentas são criadas para ajudar a dar suporte à migração e à transformação de dados, elas geralmente têm recursos poderosos que permitem reutilizar integrações em toda a empresa, manter uma governança mais forte e centralizar o gerenciamento de integrações. Neste guia, sempre que o MuleSoft Anypoint for recomendado, considere se sua solução ESB/ETL existente será suficiente.
- **Harmonize dados de diferentes origens com o Data 360 e o Data Cloud One.** Por meio do Modelo de Dados Customer 360, resolução de identidade, federação de dados e outros recursos, o Data 360 consolida dados do Salesforce e outros sistemas externos em uma visão unificada do seu cliente. Com o [Data Cloud One](/docs/architect/pt-br/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-data-cloud-one), os usuários em outras organizações do Salesforce podem acessar com segurança dados compartilhados virtualmente no Data 360 por meio de espaços de dados.
- Mova dados entre organizações usando **ações e ativações do Data 360.** Depois que os dados são ingeridos de diferentes organizações no Data 360, as [ações e ativações de](/docs/architect/pt-br/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound) dados podem sincronizar os dados com outra organização. Essa abordagem pode ser muito útil para integrações com organizações do Marketing Cloud.
- Extraia e mova dados usando o **MuleSoft Anypoint.** O MuleSoft Anypoint pode ser usado para extrair dados do Data 360 usando a API do Connect e a API do Data Graph e movê-los para outra organização do Salesforce. Sem o Data 360, o MuleSoft Anypoint também pode ser usado quando os dados precisam ser movidos entre organizações sem serem replicados no Data 360.
- **Tome cuidado se você optar por criar com Mensagens de saída.** A Salesforce continuará oferecendo suporte a Mensagens de saída dentro das capacidades funcionais atuais, mas não planeja fazer mais investimentos nessa tecnologia.
- **A licença de usuário de integração com o perfil "apenas API" é sempre recomendada para todas as integrações.** A Salesforce também recomenda usar Aplicativos cliente externos (em favor de aplicativos conectados ou login SOAP) como os padrões AuthN e AuthZ devidamente autorizados para todas as integrações.

## Considerações comuns sobre a escolha de ferramentas de integração de dados

Antes de se aprofundar nas ferramentas de integração de dados disponíveis, é importante ter em mente algumas considerações comuns ao escolher uma ferramenta. Como acontece com a arquitetura, não há uma resposta prescritiva para todos os desafios de negócios. Se você tiver pronunciado as palavras "depende" ao fazer escolhas de integração, está no lugar certo.

<table>
    <thead>
        <tr>
            <th>Área a considerar</th>
            <th>Perguntas comuns</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Ferramentas e paisagem existentes</td>
            <td>Existe uma solução de ETL ou ESB existente? Os dados envolvidos têm requisitos regulatórios ou de conformidade? Onde estão os sistemas que você está tentando integrar (na nuvem ou no local)?</td>
        </tr>
        <tr>
            <td>Fluxo de dados (tempo, experiência do usuário esperada, direcionalidade)</td>
            <td>Os dados precisam se mover de modo síncrono, assíncrono ou podem ser agendados/loteados? A replicação de dados é obrigatória? Qual sistema deve ser a fonte da verdade? Qual é a origem de dados? Qual é o destino? A interação do usuário é obrigatória? O usuário precisa ver o resultado da integração? Quais são as necessidades quanto ao gerenciamento de exceções (retomar, notificar, falhar)? Qual deve ser o nível de acoplamento dos sistemas?</td>
        </tr>
        <tr>
            <td>Implementação</td>
            <td>Qual é o nível de esforço para sistemas que não sejam do Salesforce? Quais equipes são responsáveis por fornecer integrações? Que ferramentas eles preferem usar?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/pt-br/well-architected/guide/resource-and-cost-optimization.html#code-organization">Manutenção</a></td>
            <td>Que equipes deverão manter a integração? Quais habilidades eles têm no momento? De quais habilidades eles precisarão no futuro? Qual é o custo total de propriedade ao longo do tempo? Qual é a importância da capacidade de testar, depurar e solucionar problemas com ferramentas de código baixo ou profissional?</td>
        </tr>
        <tr>
            <td><a href="/docs/architect/pt-br/well-architected/guide/reliability.html#scalability-and-capacity-planning">Volume de dados</a></td>
            <td>Quantos dados estão envolvidos na integração? Você estará trabalhando com <a href="https://trailhead.salesforce.com/content/learn/modules/large-data-volumes">grandes volumes de dados</a> (LDV)? Com que frequência as alterações ocorrerão em massa? Que tipo de impacto as atualizações do singleton terão? Com que frequência eles ocorrerão?</td>
        </tr>
        <tr>
            <td>Limites</td>
            <td>Os dados precisarão passar por uma transformação complexa? Os dados precisam ser combinados de vários sistemas de origem? Com que frequência uma integração ocorrerá por usuário? Quantos usuários no total? Você planejou com antecedência para carregamentos de dados em massa (exemplo: carregamento de dados inicial para uma nova instância)?</td>
        </tr>
    </tbody>
</table>

## Comparação de produto

Esta é uma visão geral de alto nível das ferramentas disponíveis para integração de dados e algumas considerações para começar a avaliar cada opção. As seções a seguir incluem casos de uso aprofundados e detalhes sobre os recursos dessas ferramentas.

<table>
    <thead>
        <tr>
            <th></th>
            <th>Do Salesforce para sistema externo</th>
            <th>Do sistema externo para o Salesforce</th>
            <th>Execução</th>
            <th>Licença adicional necessária</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Ações do Apex</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Não</td>
        </tr>
        <tr>
            <td><strong>Captura de dados de alteração</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-no">Não disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Não*</td>
        </tr>
        <tr>
            <td><strong>Apex personalizado (Serviços da Web REST e SOAP)</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Não</td>
        </tr>
        <tr>
            <td><strong>Serviços externos</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-no">Não disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Não</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Sim</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Sim</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Sim</td>
        </tr>
        <tr>
            <td><strong>APIs nativas do Salesforce</strong></td>
            <td class="guide-table-no">Não disponível</td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Não</td>
        </tr>
        <tr>
            <td><strong>OmniScript</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-no">Parte do cliente***</td>
            <td>Sim</td>
        </tr>
        <tr>
            <td><strong>Procedimento de integração do OmniStudio</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Sim</td>
        </tr>
        <tr>
            <td><strong>Mensagens de saída</strong></td>
            <td>Não ideal</td>
            <td class="guide-table-no">Não disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Não</td>
        </tr>
        <tr>
            <td><strong>Eventos de plataforma</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Não**</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Objetos externos</strong></td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Disponível</td>
            <td class="guide-table-ok">Lado do servidor</td>
            <td>Sim</td>
        </tr>
    </tbody>
</table>

[\*Adição necessária para casos de uso de evento de captura de dados de alteração de alto volume](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm)

[\*\*Adição necessária para casos de uso de evento de plataforma de alto volume](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)

\*\*\* Adequado em situações em que é normal que a lógica de negócios seja executada no navegador da Web.

Legenda da coluna:

- **Disponível**: funciona bem para a maioria dos casos de uso
- **Não ideal**: possível, mas considere uma ferramenta alternativa
- **Não disponível**: nenhum plano de suporte nos próximos doze meses

### Outras ferramentas para mover dados para dentro e para fora do Salesforce

Há outras ferramentas que podem dar suporte a alguns aspectos de uma integração de camada de dados, mas não devem ser consideradas um meio primário de resolver problemas de integração. Vamos dar uma olhada rápida nessas ferramentas agora.

Os **Componentes da Web Lightning** são normalmente usados para integrações de processos, mas podem fazer chamadas usando a funcionalidade JavaScript, portanto, os dados podem estar envolvidos nessas transações.

O **Fluxo do Salesforce** pode ser usado para orquestrar chamadas externas com Serviços externos ou Ações do Apex. O Salesforce Flow por si só não é considerado uma ferramenta de integração de dados independente.

O Assistente de **importação de dados e o Data Loader** podem ser usados para sincronizar, importar e migrar dados. Embora os comandos do Data Loader também possam ser scriptados para automatizar a importação e exportação de dados, a [interface de linha de comando](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm) é somente para Windows e nenhuma dessas ferramentas é uma base recomendada para uma estratégia de integração de dados. Em vez disso, use-os para complementar sua estratégia de manutenção e gerenciamento de dados.

Os comandos de dados [**Salesforce CLI**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm) podem ser usados para manipular registros em sua organização. Os comandos estão disponíveis para ajudá-lo a importar e exportar dados com a API em massa e a API de salvamento de árvore de SObject e realizar operações CRUD simples em registros individuais com a API REST. O Salesforce CLI por si só não é considerado uma ferramenta de integração de dados independente.

O **OmniStudio Data Mapper** pode ser usado como uma ferramenta ETL declarativa para mover dados entre objetos do Salesforce e estruturas de dados JSON. Embora uma interface REST seja criada automaticamente para cada interface do Data Mapper, fornecendo uma maneira declarativa de mover dados de sistemas externos para objetos do Salesforce, o Data Mapper independente não é uma base recomendada para uma estratégia de integração de dados. As ações do Mapeador de dados estão disponíveis em Procedimentos de integração do OmniStudio.

[**Dataloader.io**](http://dataloader.io/) é outra ferramenta de carregamento de dados para o Salesforce habilitada pela Anypoint Platform da MuleSoft que permite importar, exportar e excluir de forma rápida e segura quantidades ilimitadas de dados para a sua empresa. O Dataloader.io não é uma base recomendada para uma estratégia de integração de dados.

## Salesforce para sistemas externos (integração de saída)

Para integrações de saída do Salesforce, você pode considerar diferentes tipos de ferramentas: low-code, pro-code ou híbrido. As seções a seguir fornecem orientação para cada um desses tipos de ferramenta e oferecem soluções de amostra.

- [Ferramentas de baixo código para integrações de saída](#ferramentas-de-baixa-codificação-para-integrações-de-saída-do-salesforce)
- [Ferramentas híbridas para integrações de saída](#ferramentas-híbridas-para-integrações-de-saída-do-salesforce)
- [Ferramentas pro-código para integrações de saída](#ferramentas-de-código-profissional-para-integrações-de-saída-do-salesforce)

### Ferramentas de baixa codificação para integrações de saída do Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Diretrizes</th>
            <th>Licenciamento</th>
            <th>Tempo</th>
            <th>Volume e escala</th>
            <th></th>
            <th>Entrega e manutenção</th>
            <th></th>
            <th></th>
            <th>Privacidade e segurança</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quando usar</strong></th>
            <th><strong>Licença adicional</strong></th>
            <th><strong>Sincronizar (solicitação/resposta) ou assíncrono (ativar/esquecer)</strong></th>
            <th><strong>Suporte para vários objetos</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Teste e implantação**</strong></th>
            <th><strong>Depuração</strong></th>
            <th><strong>Comportamento de retry/tratamento de erro integrado</strong></th>
            <th><strong>Pode ser usado com dados criptografados em repouso</strong></th>
            <th><strong>Protocolo de autenticação</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Captura de dados de alteração</strong></td>
            <td>Quando você precisa publicar alterações no nível do registro feitas no Salesforce em um sistema externo e não precisa de uma carga útil personalizada.</td>
            <td>Obrigatório</td>
            <td>Assíncrono</td>
            <td>Não</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Serviços externos</strong></td>
            <td>Quando você está orquestrando um processo usando o Fluxo, o Apex, Bots do Einstein ou OmniStudio e as APIs do sistema externo são descritos usando especificações OpenAPI.</td>
            <td>Não necessário</td>
            <td>Sincronizar</td>
            <td class="guide-table-ok">Sim</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td>N/A</td>
            <td>Credenciais nomeadas</td>
        </tr>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>Quando você deseja estender seus dados com sincronização bidirecional para habilitar aplicativos móveis e outros no Heroku e deseja que os dados também sejam replicados ao Salesforce.</td>
            <td>Obrigatório</td>
            <td>Assíncrono</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Não</td>
            <td>Com ferramentas de código profissional</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim, por meio do Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Procedimento de integração do OmniStudio</strong></td>
            <td>Quando você precisa transformar dados sem interação com o usuário e melhorar o desempenho processando no servidor, em vez do navegador.</td>
            <td>Obrigatório</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Suporte declarativo</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Credenciais nomeadas</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Objetos externos</strong></td>
            <td>Quando você deseja que os dados apareçam na IU do Salesforce, mas que os dados sejam armazenados em um sistema externo. Os dados não são replicados para o Salesforce.</td>
            <td>Obrigatório</td>
            <td>Sincronizar</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim*</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional e um rastreador declarativo</td>
            <td>Não</td>
            <td>N/A</td>
            <td>Credenciais nomeadas</td>
        </tr>
        <tr>
            <td colspan="11">*Adaptadores OData mais antigos que a versão 4.01 estão sujeitos a limites de chamada. Consulte Considerações sobre o limite de taxa de chamada <a href="https://help.salesforce.com/s/articleView?id=platform.odata_general_limits.htm&type=5">OData</a> para obter mais detalhes. ** Teste e implantação refere-se à capacidade de criar em um ambiente inferior e implantar por meio da <a href="https://developer.salesforce.com/docs/metadata-coverage/">API de metadados</a>, pacotes ou conjuntos de alterações para produção.</td>
        </tr>
    </tbody>
</table>

### Caso de uso: Integração de saída usando ferramentas de baixa codificação

> Quando as oportunidades são ganhas, um pedido para os produtos associados precisa ser criado no sistema ERP ou no sistema de gerenciamento de pedidos da empresa.

**Captura de dados de alteração** À medida que os registros de Oportunidade são atualizados, a Captura de dados de alteração publica eventos de alteração que contêm as atualizações dos objetos. Os eventos de alteração são consumidos do lado do cliente por meio de uma conexão CometD (ou por meio de um conector do MuleSoft) e usados para atualizar o sistema de gerenciamento de pedido ou ERP do cliente. Os eventos de alteração podem ser aprimorados para sempre incluir IDs de registro externos ou outros dados do objeto (como região) necessários para a integração. Fluxos de evento de alteração para vários objetos podem ser combinados em _canales_ para simplificar o processamento de assinatura e fluxo (para que você possa assinar e processar um fluxo em vez de muitos).

**Serviços externos** Se você tiver um serviço da Web compatível com a especificação OpenAPI 2.0 ou 3.0, poderá expor as operações e serviços como um Serviço externo no Salesforce. As operações da API (por exemplo, criar pedido) podem ser chamadas como uma Ação invocável em um fluxo criado com o Flow Builder quando o estágio da oportunidade for alterado para "Ganho".

**Heroku Connect** O Heroku Connect geralmente é usado para manter um banco de dados Heroku Postgres e o Salesforce sincronizados. Se o cliente usar o Heroku Postgres como sua loja transacional de origem da verdade, você poderá sincronizar os registros e as alterações do Salesforce para o Heroku Postgres usando o Heroku Connect. De lá, você pode usar os Conectores de streaming do Heroku para publicar essas alterações no Apache Kafka e enviá-las como eventos para aplicativos downstream, incluindo o ERP ou o sistema de gerenciamento de pedidos.

**Procedimento de Integração do OmniStudio** Quando um pedido é enviado, o OmniScript que orquestra o processo pode publicar os detalhes do pedido em um conector ERP ou MuleSoft. A publicação pode ser executada diretamente pelo OmniScript (do lado do cliente) ou indiretamente por meio de um Procedimento de integração (do lado do servidor). Se o sistema ERP gerar um erro de validação, a IU do OmniScript deverá notificar o usuário e, se necessário, traduzir e contextualizar o erro para o usuário.

**Salesforce Connect/Objetos externos** Você pode criar um fluxo acionado por registro no Salesforce que insere um registro nos objetos externos relacionados quando o estágio da oportunidade for alterado para "Ganho". Uma vez que essa é uma [transação mista](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1), para evitar erros, adicione um elemento de pausa por zero segundos entre a atualização de Oportunidade e a inserção de objetos externos relacionados para que você feche um contexto de transação antes de iniciar uma nova.

### Ferramentas híbridas para integrações de saída do Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Diretrizes</th>
            <th>Licenciamento</th>
            <th>Tempo</th>
            <th>Volume e escala</th>
            <th></th>
            <th>Entrega e manutenção</th>
            <th></th>
            <th></th>
            <th>Privacidade e segurança</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quando usar</strong></th>
            <th><strong>Licença adicional</strong></th>
            <th><strong>Sincronizar (solicitação/resposta) ou assíncrono (ativar/esquecer)</strong></th>
            <th><strong>Suporte para vários objetos</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Teste e implantação**</strong></th>
            <th><strong>Depuração</strong></th>
            <th><strong>Comportamento de retry/tratamento de erro integrado</strong></th>
            <th><strong>Pode ser usado com dados criptografados em repouso</strong></th>
            <th><strong>Protocolo de autenticação</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Ações do Apex</strong></td>
            <td>Quando você deseja automatizar chamadas para outro sistema por meio do Salesforce Flow. Um desenvolvedor pode escrever uma classe do Apex que um fluxo pode invocar ou você pode baixar uma solução predefinida do AppExchange.</td>
            <td>Não necessário</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td>Vários</td>
        </tr>
        <tr>
            <td><strong>Retransmissões de evento</strong></td>
            <td>Quando você precisar enviar eventos de plataforma e alterar eventos de captura de dados para o Amazon EventBridge do Salesforce. As retransmissões de evento se conectam apenas ao AWS Eventbridge</td>
            <td>Não</td>
            <td>Assíncrono</td>
            <td class="guide-table-ok">Sim</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>HTTP/1.1 com TLS</td>
        </tr>
        <tr>
            <td><strong>Mensagens de saída</strong></td>
            <td>Quando você precisa enviar mensagens SOAP por HTTP(S) para um ponto de extremidade designado com recebimento garantido quando acionado por uma regra de fluxo de trabalho.</td>
            <td>Não necessário</td>
            <td>Assíncrono</td>
            <td>Não</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td>Suporte declarativo</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>TLS bidirecional</td>
        </tr>
        <tr>
            <td><strong>Eventos de plataforma</strong></td>
            <td>Quando você precisa de uma carga útil personalizada e estruturada para alterações quase em tempo real no Salesforce ou em um sistema externo.</td>
            <td>Não necessário*</td>
            <td>Assíncrono</td>
            <td class="guide-table-ok">Sim</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Objetos externos do Salesforce Connect (com adaptadores personalizados do Apex)</strong></td>
            <td>Quando você deseja que os dados apareçam na interface do usuário do Salesforce, mas que os dados sejam armazenados em um sistema externo que não possa usar protocolos padrão como OData ou GraphQL.</td>
            <td>Obrigatório</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td>N/A</td>
            <td>Vários</td>
        </tr>
         <tr>
            <td><strong>Data 360</strong></td>
            <td>Quando você deseja harmonizar dados de diferentes origens em um repositório de dados ou replicar seus dados para outras organizações do Salesforce ou para outros sistemas externos.</td>
            <td>Obrigatório</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Vários</td>
        </tr>
    </tbody>
</table>

[\*Adição](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) necessária para casos de uso de grande volume.

\*\*Teste e implantação refere-se à capacidade de criar em um ambiente inferior e implantar por meio da [API de metadados](https://developer.salesforce.com/docs/metadata-coverage/), pacotes ou conjuntos de alterações para produção.

### Caso de uso: Integração de saída usando ferramentas híbridas

> Quando as oportunidades são ganhas, um pedido para os produtos associados precisa ser criado no ERP ou no sistema de gerenciamento de pedidos da empresa.

**Ações do Apex** Um fluxo acionado por registro com base no estado da oportunidade pode ser acionado automaticamente quando uma oportunidade é ganha. O fluxo executa uma ação invocável que usa uma chamada externa para enviar o pedido ao sistema de gerenciamento de pedidos ou à solução ERP. Envios de alto volume e pedidos de vários sites são processados por mecanismos de lote e fila do Apex.

**Mensagens de saída** Depois de [configurar as mensagens de saída](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm), você pode definir uma regra de fluxo de trabalho acionada pela atualização de oportunidade para enviar uma mensagem SOAP por HTTP(S) para um URL de ponto final especificado que hospeda o ouvinte. A mensagem conterá os campos especificados quando a mensagem de saída foi criada. Se as informações no objeto mudarem depois que a notificação for colocada na fila, mas antes de ela ser enviada, somente as informações atualizadas serão entregues e as mensagens permanecerão na fila até o envio ser bem-sucedido ou até que tenham 24 horas. Após 24 horas, as mensagens são eliminadas da fila. Se o sistema ERP precisar de dados adicionais, você poderá passar o sessionId em mensagens de saída para que o sistema externo possa fazer uma solicitação de retorno.

**Eventos de plataforma** Você pode definir um evento de plataforma que inclua a carga útil personalizada com os dados necessários para criar os registros no sistema externo. Como os Eventos de plataforma não são publicados automaticamente na mudança de registro, você deve publicar o evento por meio do Apex, do Salesforce Flow ou do Criador de processos quando o estágio da oportunidade for alterado para "Ganho". Um serviço externo escuta o canal de evento da plataforma usando CometD (ou um conector do MuleSoft) e cria os registros apropriados no sistema externo.

**Objetos externos do Salesforce Connect (com adaptadores do Apex personalizados)** Uma solução baseada em objetos externos do Salesforce Connect não é perfeitamente adequada para um caso de uso que exija sincronização de dados. No entanto, essa solução pode se aplicar a casos em que os usuários no Salesforce precisam ver e possivelmente interagem com dados do sistema externo e os dados não podem ser replicados no Salesforce. Se o ERP ou o sistema de gerenciamento de pedidos não suportam protocolos OData ou GraphQL, a equipe de desenvolvimento pode usar o [Apex Connector Framework](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm) para escrever classes do Apex que lidam com a comunicação com o sistema externo por meio de um protocolo compatível.

**Data 360** Uma solução baseada no Data 360 é perfeitamente adequada para casos de uso em que precisamos de dados harmonizados de diferentes fontes em um único repositório de dados. Ele também pode ser usado quando precisamos replicar dados de uma organização do Salesforce para várias organizações do Salesforce ou para outros sistemas externos usando o Data 360 como um data hub. Quando uma oportunidade é ganha e atualizada na organização de origem, os dados da oportunidade são sincronizados com o Data 360, onde podem ser replicados em outros sistemas, incluindo organizações do Salesforce, usando diferentes mecanismos, como ações, ativações e APIs. Da mesma forma, uma oportunidade pode ser referenciada sem replicar os dados em outras organizações do Salesforce usando o Data Cloud One. No entanto, o Data Cloud One não oferece suporte a plataformas que não sejam do Salesforce.

### Ferramentas de código profissional para integrações de saída do Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Diretrizes</th>
            <th>Licenciamento</th>
            <th>Tempo</th>
            <th>Volume e escala</th>
            <th></th>
            <th>Entrega e manutenção</th>
            <th></th>
            <th></th>
            <th>Privacidade e segurança</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quando usar</strong></th>
            <th><strong>Licença adicional</strong></th>
            <th><strong>Sincronizar (solicitação/resposta) ou assíncrono (ativar/esquecer)</strong></th>
            <th><strong>Suporte para vários objetos</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Teste e implantação**</strong></th>
            <th><strong>Depuração</strong></th>
            <th><strong>Comportamento de retry/tratamento de erro integrado</strong></th>
            <th><strong>Pode ser usado com dados criptografados em repouso</strong></th>
            <th><strong>Protocolo de autenticação</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Apex personalizado</strong></td>
            <td>Quando você precisa de mais funcionalidade do que está disponível em ferramentas com pouco código.</td>
            <td>Não necessário</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim*</td>
            <td>Vários</td>
        </tr>
        <tr>
            <td><strong>Serviços externos</strong></td>
            <td>A integração do código a APIs do sistema externo é descrita usando especificações OpenAPI.</td>
            <td>Não necessário</td>
            <td>Sincronizar</td>
            <td class="guide-table-ok">Sim</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td>N/A</td>
            <td>Vários</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>Quando você precisa de uma única solução unificada de nível corporativo para criar, orquestrar e gerenciar suas integrações; quando precisa substituir uma arquitetura de ponto a ponto legada; ou quando precisa de suporte de gerenciamento de API.</td>
            <td>Obrigatório</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim*</td>
            <td>Vários</td>
        </tr>
    </tbody>
</table>

\* A ativação da Shield Platform Encryption altera determinados comportamentos, consulte [Considerações gerais sobre a Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) para obter mais detalhes.

\*\*Teste e implantação refere-se à capacidade de criar em um ambiente inferior e implantar por meio da [API de metadados](https://developer.salesforce.com/docs/metadata-coverage/), pacotes ou conjuntos de alterações para produção.

### Caso de uso: Integração de saída usando ferramentas de código profissional

> Quando as oportunidades são ganhas, um pedido para os produtos associados precisa ser criado no ERP ou no sistema de gerenciamento de pedidos da empresa.

**Apex personalizado** Você pode criar um acionador do Apex e manipuladores de acionador na Oportunidade que fazem uma chamada para o sistema de gerenciamento de ERP ou pedido quando o estágio da oportunidade é alterado para "Ganho". Observe que, se você fizer chamadas de um acionador ou depois de realizar uma operação DML, deverá usar um método anotado como futuro ou enfileirável. Uma chamada em um acionador mantém a conexão do banco de dados aberta pela vida útil da chamada. Todo o Apex code é vinculado aos limites [de API e controlador do Apex](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm), que são revisados continuamente.

**Serviços externos** Se o ERP externo ou sistema de gerenciamento de pedidos da empresa for definido por meio de uma especificação OpenAPI, as chamadas a esses serviços que são realizadas no futuro método ou trabalho enfileirável poderão ser simplificadas. Os serviços externos registrados podem ser chamados diretamente do Apex sem precisar escrever código de caldeira. No exemplo, a chamada para criar o pedido pode ser processada pelo serviço externo.

**MuleSoft Anypoint** O MuleSoft Anypoint fornece gerenciamento de API de nível corporativo. O MuleSoft Anypoint pode criar APIs para habilitar o acesso de leitura (e/ou gravação) a dados para o Salesforce e muitos outros sistemas corporativos. Há [muitos conectores pré-construídos disponíveis](https://www.mulesoft.com/platform/cloud-connectors) para simplificar a implementação, e as empresas também podem criar e publicar seus próprios conectores. Essas APIs podem ser implementadas no Anypoint com políticas de segurança flexíveis, com suporte para gerenciamento centralizado e governança. Não há restrições ao volume de transações, desde que a API tenha sido dimensionada adequadamente para sua utilização máxima (como medida em vCores).

## Dados de sistemas externos para o Salesforce (integração de entrada)

Para integrações de entrada ao Salesforce, você pode considerar diferentes tipos de ferramentas: low-code, pro-code ou híbrido. As seções a seguir fornecem orientação para cada um desses tipos de ferramenta e oferecem soluções de amostra.

- [Ferramentas de baixo código para integrações de entrada](#ferramentas-de-baixa-codificação-para-integrações-de-entrada-ao-salesforce)
- [Ferramentas híbridas para integrações de entrada](#ferramentas-híbridas-para-integrações-de-entrada-ao-salesforce)
- [Ferramentas pro-código para integrações de entrada](#ferramentas-de-código-profissional-para-integrações-de-entrada-ao-salesforce)

### Ferramentas de baixa codificação para integrações de entrada ao Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Diretrizes</th>
            <th>Licenciamento</th>
            <th>Tempo</th>
            <th>Volume e escala</th>
            <th></th>
            <th>Entrega e manutenção</th>
            <th></th>
            <th></th>
            <th>Privacidade e segurança</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Quando usar</th>
            <th>Licença adicional</th>
            <th>Sincronizar (solicitar/responder) ou assíncrono ( disparar/esquecer)</th>
            <th>Suporte a vários objetos</th>
            <th>LDV/Bulk</th>
            <th>Teste e implantação*</th>
            <th>Depuração</th>
            <th>Comportamento de retry/tratamento de erro integrado</th>
            <th>Pode ser usado com dados criptografados em repouso</th>
            <th>Protocolo de autenticação</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>Quando você deseja estender seus dados com sincronização bidirecional para habilitar aplicativos móveis e outros no Heroku e deseja que os dados também sejam replicados ao Salesforce.</td>
            <td>Obrigatório</td>
            <td>Assíncrono</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Não</td>
            <td>Com ferramentas de código profissional</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim, por meio do Shield Connect</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Procedimento de integração do OmniStudio</strong></td>
            <td>Quando você precisa importar e transformar dados de fontes de terceiros sem interação com o usuário.</td>
            <td>Obrigatório</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Suporte declarativo</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td>Credenciais nomeadas</td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect/Objetos externos</strong></td>
            <td>Quando você deseja que os dados apareçam na interface do usuário do Salesforce, mas que os dados sejam armazenados em um sistema externo que possa usar protocolos padrão como OData ou GraphQL.</td>
            <td>Obrigatório</td>
            <td>Sincronizar</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td>N/A</td>
            <td>Vários</td>
        </tr>
    </tbody>
</table>

\*Teste e implantação refere-se à capacidade de criar em um ambiente inferior e implantar por meio da [API de metadados](https://developer.salesforce.com/docs/metadata-coverage/), pacotes ou conjuntos de alterações para produção.

### Caso de uso: Integração de entrada usando ferramentas de baixa codificação

> Um contato é atualizado no sistema ERP da organização. Essas informações de contato precisam ser atualizadas no Salesforce.

**Heroku Connect** O Heroku Connect geralmente é usado para manter um banco de dados Heroku Postgres e o Salesforce sincronizados. A menos que o sistema ERP use o Heroku Postgres como loja de transações, esse caso de uso não será possível. Se ele usa o Heroku Postgres, as alterações feitas nas tabelas do Postgres podem ser sincronizadas com objetos no Salesforce usando o Heroku Connect.

**Procedimento de integração do OmniStudio** Depois que o sistema ERP atualiza o registro de contato, um Procedimento de integração do OmniStudio com uma Ação de carregamento do Data Mapper e uma Ação de resposta pode ser chamado por meio da API REST gerada pelo Data Mapper. Primeiro, uma ação Carregar do Data Mapper envia uma carga útil JSON ou XML, que é usada para inserir e atualizar os registros de contato com base em um campo de ID externo ou por meio de uma [chave de inserção e atualização](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio). Se uma resposta simples no JSON for tudo o esperado, uma Ação de resposta poderá enviar de volta qualquer informação relevante das ações anteriores para indicar sucesso ou falha. Se o sistema ERP espera uma resposta específica, uma Ação de extração ou Transformação do mapeador de dados pode ser usada para gerar uma resposta JSON ou XML com recursos adicionais para incluir de modo declarativo dados que foram gerados em acionadores pela atualização de registro de contato. O principal desafio com esse cenário é a simultaneidade: Várias chamadas para atualizar o mesmo registro de contato ao mesmo tempo causarão problemas, pois a API existe diretamente no Salesforce.

**Salesforce Connect / Objetos externos** Salesforce Connect e objetos externos não são recomendados para este caso de uso, pois o cenário exige especificamente a replicação de dados no Salesforce. Se você tiver uma integração preexistente do Salesforce Connect integrada ao ERP, poderá configurar o conector OData 4.0 para dar suporte à captura de dados de alteração externa se o ERP puder dar suporte à captura de dados de alteração. Além disso, você deve configurar no Salesforce para assinar o fluxo de alteração no ERP usando a API Pub/Sub.

### Ferramentas híbridas para integrações de entrada ao Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Diretrizes</th>
            <th>Licenciamento</th>
            <th>Tempo</th>
            <th>Volume e escala</th>
            <th></th>
            <th>Entrega e manutenção</th>
            <th></th>
            <th></th>
            <th>Privacidade e segurança</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Quando usar</th>
            <th>Licença adicional</th>
            <th>Sincronizar (solicitar/responder) ou assíncrono ( disparar/esquecer)</th>
            <th>Suporte a vários objetos</th>
            <th>LDV/Bulk</th>
            <th>Teste e implantação**</th>
            <th>Depuração</th>
            <th>Comportamento de retry/tratamento de erro integrado</th>
            <th>Pode ser usado com dados criptografados em repouso</th>
            <th>Protocolo de autenticação</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Eventos de plataforma</strong></td>
            <td>Quando você precisa de uma carga útil personalizada e estruturada para alterações quase em tempo real no Salesforce ou em um sistema externo.</td>
            <td>Não necessário*</td>
            <td>Assíncrono</td>
            <td class="guide-table-ok">Sim</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>OAuth</td>
        </tr>
        <tr>
            <td><strong>Objetos externos do Salesforce Connect (com adaptadores personalizados do Apex)</strong></td>
            <td>Quando você precisa que os dados apareçam na interface do usuário do Salesforce, mas deseja que os dados sejam armazenados em um sistema externo que não possa usar os protocolos OData 2.0/4.0.</td>
            <td>Obrigatório</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td>N/A</td>
            <td>Vários</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>Quando você deseja harmonizar dados de diferentes origens em um repositório de dados ou replicar seus dados de outras organizações do Salesforce ou para outros sistemas externos. O Data 360 também oferece suporte à virtualização para algumas plataformas.</td>
            <td>Obrigatório</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Vários</td>
        </tr>
    </tbody>
</table>

\* [Adição](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) necessária para casos de uso de grande volume.

\*\*Teste e implantação refere-se à capacidade de criar em um ambiente inferior e implantar por meio da [API de metadados](https://developer.salesforce.com/docs/metadata-coverage/), pacotes ou conjuntos de alterações para produção.

### Caso de uso: Integração de entrada usando ferramentas híbridas

> Um contato é atualizado no sistema ERP da organização. Essas informações de contato precisam ser atualizadas no Salesforce.

**O código personalizado de Eventos de plataforma** em um sistema externo publica um Evento de plataforma quando o registro de contato é atualizado no ERP. Um acionador, processo ou fluxo no Salesforce pode assinar o evento de plataforma e atualizar os objetos do Salesforce correspondentes quando um evento é processado. O Evento de plataforma pode funcionar simplesmente como um sinal de que uma alteração ocorreu no sistema ERP do cliente sem conter nenhum dado ou pode conter os dados reais necessários para atualizar o objeto do Salesforce.

**Objetos externos do Salesforce Connect (com adaptadores do Apex personalizados)** Esta solução não é aplicável a um caso de uso que exija replicação de dados. Essa solução é aplicável se você precisar que os usuários no Salesforce vejam informações de um sistema externo que não deve ou não pode ser replicado no Salesforce e o sistema externo não pode dar suporte a protocolos padrão como OData ou GraphQL. Consulte Caso de [uso: Integração de saída usando ferramentas híbridas](#caso-de-uso-integração-de-saída-usando-ferramentas-híbridas) para um exemplo de caso de uso para um adaptador personalizado do Apex.

Quando um contato é atualizado em sistemas externos, como ERP, as atualizações de contato podem ser sincronizadas com o Data 360 usando conectores prontos para uso ou usando APIs e ferramentas de código profissional, como MuleSoft.**** O contato também pode ser referenciado no Data 360 usando o mecanismo de cópia zero (disponível com algumas plataformas). Depois que os dados estiverem disponíveis no Data 360, diferentes mecanismos de integração prontos para uso poderão ser usados para sincronizar os dados com outras organizações do Salesforce. Os dados podem ser acessados por referência usando o Data Cloud One. Os dados também podem ser replicados usando ativações e outras APIs usando conectores prontos para uso ou com a ajuda de ferramentas de código profissional, como a MuleSoft Anypoint Platform.

### Ferramentas de código profissional para integrações de entrada ao Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Diretrizes</th>
            <th>Licenciamento</th>
            <th>Tempo</th>
            <th>Volume e escala</th>
            <th></th>
            <th>Entrega e manutenção</th>
            <th></th>
            <th></th>
            <th>Privacidade e segurança</th>
            <th></th>
        </tr>
        <tr>
            <th></th>
            <th>Quando usar</th>
            <th>Licença adicional</th>
            <th>Sincronizar (solicitar/responder) ou assíncrono ( disparar/esquecer)</th>
            <th>Suporte a vários objetos</th>
            <th>LDV/Bulk</th>
            <th>Testar e implementar****</th>
            <th>Depuração</th>
            <th>Comportamento de retry/tratamento de erro integrado</th>
            <th>Pode ser usado com dados criptografados em repouso</th>
            <th>Protocolo de autenticação</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Serviços da Web REST e SOAP do Apex personalizados</strong></td>
            <td>Quando você precisa de mais funcionalidades do que as fornecidas pelos pontos de extremidade de API nativos, como processamento de objetos cruzados ou outra lógica complexa.</td>
            <td>Não necessário</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim***</td>
            <td>Vários</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>Quando você precisa de uma única solução unificada de nível corporativo para criar, orquestrar e gerenciar suas integrações; quando precisa substituir uma arquitetura de ponto a ponto legada; ou quando precisa de suporte de gerenciamento de API.</td>
            <td>Obrigatório</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim***</td>
            <td>Vários</td>
        </tr>
        <tr>
            <td><strong>APIs nativas do Salesforce</strong></td>
            <td>Quando você precisa de mais controle ou tem um conjunto de habilidades de código profissional para criar integrações por meio da API REST, da API SOAP, da API em massa ou de APIs GraphQL ou gRPC.</td>
            <td>Não necessário*</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim*****</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td class="guide-table-ok">Sim**</td>
            <td class="guide-table-ok">Sim***</td>
            <td>Vários</td>
        </tr>
    </tbody>
</table>

\*Limites e alocações de [solicitação de API](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm) se aplicam.

\*\*As APIs em massa têm aspectos de comportamento de nova tentativa e várias APIs oferecem proteção _de reversão_ por meio da configuração allOrNone (por exemplo, consulte [parâmetros allOrNone em Solicitações compostas e de coleta](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm))

\*\*\* A ativação da Shield Platform Encryption altera determinados comportamentos, consulte [Considerações gerais sobre a Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) para obter mais detalhes.

\*\*\*\*Teste e implantação refere-se à capacidade de criar em um ambiente inferior e implantar por meio da [API de metadados](https://developer.salesforce.com/docs/metadata-coverage/), pacotes ou conjuntos de alterações para produção.

\*\*\*\*\*As APIs compostas têm suporte para vários objetos.

### Caso de uso: Integração de entrada usando ferramentas de código profissional

> Um contato é atualizado no sistema ERP da organização. Essas informações de contato precisam ser atualizadas no Salesforce.

**Serviços personalizados do Apex REST e SOAP Web Services** Você pode criar um serviço da Web usando o Apex code que poderia executar operações CRUD (criar, ler, atualizar, excluir) no objeto Contato. Esse serviço será chamado por SOAP ou REST do sistema externo (o ERP).

**MuleSoft Anypoint** A intenção do MuleSoft Anypoint é fornecer gerenciamento de API de nível empresarial. O MuleSoft Anypoint oferece um [grande conjunto de conectores predefinidos](https://www.mulesoft.com/platform/cloud-connectors) que você pode usar para integrar com muitos sistemas ERP, incluindo SAP, Oracle EBS, Oracle ERP e NetSuite. Você pode criar um fluxo para ouvir eventos nesses sistemas ERP (neste caso, quando um novo contato é criado). Quando o fluxo é iniciado, ele usa o conector do Salesforce para criar um novo registro de Contato (ou atualizar um caso o contato já exista). Além disso, é possível integrar-se a outros sistemas se a transação de replicação envolver a sindicação do contato em outros sistemas. Se necessário, você pode usar a linguagem de mapeamento e transformação (DataWeave) para realizar lógica e cálculos complexos à medida que as informações fluem entre vários sistemas diferentes. A autenticação com esses sistemas pode ser feita por meio de vários mecanismos de autenticação diferentes, como Autenticação básica e OAuth, entre outros. Não há restrições ao volume de transações, desde que o fluxo tenha sido dimensionado adequadamente para sua utilização máxima (medido em vCores).

**APIs nativas do Salesforce** À medida que (ou imediatamente após) a transação de atualização no sistema ERP é concluída, você pode realizar uma operação de inserção e atualização no objeto Contato por meio da API SOAP ou realizar um [PATCH](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) na API REST de sObjects de contato na organização do Salesforce.

## Integrações do Salesforce para Salesforce

O produto Salesforce para Salesforce chegou ao fim da sua vida útil. O Salesforce para Salesforce facilitou para parceiros que trabalham juntos venderem e oferecerem suporte a clientes conjuntos, mas a Salesforce vai investir em trazer mais inovação para outras ferramentas. Avançando, as seguintes abordagens são recomendadas para compartilhar dados entre organizações do Salesforce.

### Ferramentas para integração de dados em organizações do Salesforce

<table>
    <thead>
        <tr>
            <th></th>
            <th>Diretrizes</th>
            <th>Custo</th>
            <th>Tempo</th>
            <th>Volume e escala</th>
            <th></th>
            <th></th>
            <th>Entrega e manutenção</th>
            <th></th>
            <th>Privacidade e segurança</th>
            <th></th>
            <th>Ferramentas a implementar</th>
        </tr>
        <tr>
            <th></th>
            <th><strong>Quando usar</strong></th>
            <th><strong>Licença adicional</strong></th>
            <th><strong>Sincronizar (solicitação/resposta) ou assíncrono (ativar/esquecer)</strong></th>
            <th><strong>Suporte para vários objetos</strong></th>
            <th><strong>LDV/Bulk</strong></th>
            <th><strong>Teste e implantação*</strong></th>
            <th><strong>Depuração</strong></th>
            <th><strong>Comportamento de retry/tratamento de erro integrado</strong></th>
            <th><strong>Pode ser usado com dados criptografados em repouso</strong></th>
            <th><strong>Protocolo de autenticação</strong></th>
            <th><strong>Código baixo → Código profissional</strong></th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Heroku Connect</strong></td>
            <td>Quando você deseja estender seus dados com sincronização bidirecional entre organizações do Salesforce e também habilitar o acesso aos dados de dispositivos móveis e outros aplicativos em execução no Heroku</td>
            <td>Obrigatório</td>
            <td>Assíncrono</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Não</td>
            <td>Com ferramentas de código profissional</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim, por meio do Shield Connect</td>
            <td>OAuth</td>
            <td>Código inferior</td>
        </tr>
        <tr>
            <td><strong>MuleSoft Anypoint</strong></td>
            <td>Quando você precisa de uma única solução unificada de nível corporativo para criar, orquestrar e gerenciar suas integrações; quando precisa substituir uma arquitetura de ponto a ponto legada; ou quando precisa de suporte para gerenciamento de API</td>
            <td>Obrigatório</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim**</td>
            <td>Vários</td>
            <td>Código profissional</td>
        </tr>
        <tr>
            <td><strong>APIs nativas do Salesforce</strong></td>
            <td>Quando o Salesforce ou o Heroku Connect não são uma opção ou você precisa de processamento mais complexo</td>
            <td>Não necessário</td>
            <td>Ambos</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim**</td>
            <td>Vários</td>
            <td>Código profissional</td>
        </tr>
        <tr>
            <td><strong>Captura de dados de alteração</strong></td>
            <td>Quando você precisa publicar alterações no nível do registro feitas no Salesforce em um sistema externo e não precisa de uma carga útil personalizada.</td>
            <td>Obrigatório</td>
            <td>Assíncrono</td>
            <td>Não</td>
            <td>Não</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>OAuth</td>
            <td></td>
        </tr>
        <tr>
            <td><strong>Salesforce Connect com adaptador entre organizações</strong></td>
            <td>Quando você deseja que os usuários em uma organização visualizem ou editem registros em uma organização diferente sem replicação de dados</td>
            <td>Obrigatório</td>
            <td>Assíncrono</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td>N/A</td>
            <td>N/A</td>
            <td>Vários</td>
            <td>Código inferior</td>
        </tr>
        <tr>
            <td><strong>Data 360</strong></td>
            <td>Quando você deseja que os usuários em uma organização visualizem ou editem registros em uma organização diferente com dados replicados no Data 360.</td>
            <td>Obrigatório</td>
            <td>Ambos</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Com ferramentas de código profissional</td>
            <td class="guide-table-ok">Sim</td>
            <td class="guide-table-ok">Sim</td>
            <td>Vários</td>
            <td>híbrido</td>
        </tr>
    </tbody>
</table>

\*Teste e implantação refere-se à capacidade de criar em um ambiente inferior e implantar por meio da [API de metadados](https://developer.salesforce.com/docs/metadata-coverage/), pacotes ou conjuntos de alterações para produção

\*\* A ativação da Shield Platform Encryption altera determinados comportamentos, consulte [Considerações gerais sobre a Shield Platform Encryption](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5) para obter mais detalhes.

Os eventos de _plataforma não são ideais para integrar dados de uma organização do Salesforce a outra, pois não podem "escutar" entre organizações para o mesmo evento. O Apex personalizado também não é uma abordagem recomendada para esse tipo de integração._

### Caso de uso: Conectar várias organizações do Salesforce

> Uma grande empresa opera em várias unidades de negócios (BUs). Cada BU tem sua própria organização do Salesforce. Um único cliente lida com várias unidades de negócios da empresa e, portanto, tem dados de conta e oportunidade em várias organizações. A empresa precisa acessar uma visualização agregada de todos os dados de Conta e Oportunidade em todas as BUs em uma só organização.

_Nota: Todas as soluções abaixo são projetadas para a menor quantidade de replicação de dados, de acordo com a [Takeaway #1](#capturas)._

Dados de conta e oportunidade do **Data 360** de diferentes organizações do Salesforce podem ser ingeridos no Data 360 usando conectores prontos para uso do Salesforce. Eles também podem ser agregados e harmonizados (se necessário). Depois que os dados são agregados no Data 360, eles podem ser acessados em outras organizações do Salesforce usando o Data Cloud One sem replicação de dados.

**Heroku Connect** Para cada organização individual da BU, você pode usar o Heroku Connect para sincronizar alterações do Salesforce em um único banco de dados Heroku Postgres. Nesse cenário, a sincronização bidirecional não está habilitada, apenas a sincronização do Salesforce para o Postgres. Então, no Heroku Connect, você pode habilitar o provedor OData e selecionar as tabelas que deseja expor como objetos externos na organização do Salesforce em que deseja uma visualização agregada. No Salesforce, você define uma origem de dados externa apontando para o provedor OData no Heroku.

**MuleSoft Anypoint** O MuleSoft Anypoint fornece gerenciamento de API de nível corporativo. Uma API do MuleSoft Anypoint pode ser configurada para ler informações de várias organizações relacionadas do Salesforce usando o conector do Salesforce com várias conexões às organizações. O fluxo do MuleSoft pode consultar as diferentes organizações do Salesforce e retornar uma estrutura específica aprimorada ou aprimorada com outras informações de terceiros, se necessário. Quando a API é invocada, ela fará todas as chamadas adequadas da organização do Salesforce (neste exemplo, consultando informações de Conta e Oportunidade) para que os dados possam ser processados pelo consumidor (provavelmente uma UI). A autenticação com esses sistemas pode ser feita por meio de vários mecanismos de autenticação, incluindo autenticação básica e OAuth. Não há restrições ao volume de transações, desde que o fluxo tenha sido dimensionado adequadamente para sua utilização máxima (medido em vCores ou Cores).

As operações de consulta **nativas das APIs do Salesforce** podem ser emitidas a cada uma das organizações de interesse, principalmente por meio da API em massa 2.0 do Salesforce, que é adequada para extrair de forma eficiente milhares de registros. Você pode recuperar os resultados da consulta de cada organização individualmente e agregá-los com um aplicativo personalizado ou middleware conforme os requisitos do cliente.

**Salesforce Connect com adaptador entre organizações** O adaptador entre organizações do Salesforce Connect não é adequado nesse cenário, pois as contas ou oportunidades de organizações remotas aparecerão na organização central como objetos _diferentes_. Por exemplo, não há maneira de somar um total geral para os valores de todas as oportunidades em todas as organizações.

**Scenário de atualizações seletivas entre organizações:** Um vendedor, usando a organização do Salesforce A, precisa visualizar e atualizar dados de caso da organização do Salesforce B e adicionar comentários de caso ao caso pai na organização do Salesforce B enquanto trabalha na organização A. Os dados não devem ser replicados à organização A.

**Heroku Connect** Você pode usar a mesma abordagem descrita no _scenário de agregação de dados_ acima. No entanto, você deve habilitar o CRUD no objeto externo por meio do conector OData e gravar as alterações de volta no Heroku Postgres.

**MuleSoft Anypoint** O MuleSoft Anypoint fornece gerenciamento de API de nível corporativo. Você pode usar a mesma abordagem descrita no _Scenário de agregação de dados_ acima.

As APIs **nativas do Salesforce** usam credenciais nomeadas e invocam as APIs nativas do Salesforce para ler e atualizar dados na organização do Salesforce relacionada. Um componente deve ser projetado para exibir os dados.

**Salesforce Connect com adaptador entre organizações** A capacidade de visualizar dados em um objeto externo (e editar os dados se você tiver o CRUD habilitado no objeto externo) é suportada por meio do [adaptador entre organizações do Salesforce](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5). Há suporte para relacionamentos entre objetos externos para que você possa vincular ao caso pai no objeto externo. No entanto, criar relacionamentos hoje é um processo manual em que você converte um tipo de dados existente em um tipo de dados de relacionamento. Além disso, as otimizações feitas no Service Cloud para trabalhar com Casos com mais eficiência não passam em cascata para a organização remota. A Salesforce recomenda enfaticamente testar o adaptador entre organizações e avaliar as vantagens de trabalhar com objetos externos vs. objetos padrão para seu caso de uso.

**Sincronização de dados entre organizações**: Quando uma conta de um cliente é atualizada em uma das organizações do Salesforce da unidade de negócios da organização, os outros objetos da Conta da organização do Salesforce precisam ser atualizados para manter informações de conta consistentes.

O Data 360 **do Data 360** pode ser usado para replicação de dados de uma organização para outra organização do Salesforce. Os dados da conta de uma organização do Salesforce podem ser ingeridos no Data 360 usando conectores prontos para uso do Salesforce. Podemos usar mecanismos de ativação de dados, como ativação em lote, ações de dados quase em tempo real ou ativações baseadas em API, bem como mover os dados do Data 360 para a organização do Salesforce.

**Heroku Connect** Você pode usar a mesma abordagem descrita no _scenário de agregação de dados_ acima. No entanto, você deve habilitar a sincronização bidirecional e não precisa mais habilitar o Salesforce Connect, pois a sincronização bidirecional manterá todas as organizações atualizadas quando forem feitas alterações na tabela do Postgres.

**MuleSoft Anypoint** O MuleSoft Anypoint fornece gerenciamento de API de nível corporativo. Você pode [configurar um aplicativo do Mule](https://docs.mulesoft.com/design-center/about-designing-a-mule-application) com o Designer de fluxo no MuleSoft Anypoint para ouvir eventos de objeto padrão e personalizados para iniciar um fluxo iniciado automaticamente no Salesforce. Quando o aplicativo Mule é acionado, ele pode invocar o Conector do Anypoint para Salesforce para se comunicar com qualquer número de organizações do Salesforce. Nesse caso de uso, quando um registro de Conta é atualizado em uma organização do Salesforce, o aplicativo Mule pode atualizar registros de Conta nas organizações relacionadas do Salesforce. Cada organização do Salesforce relacionada teria uma etapa de atualização exclusiva integrada ao fluxo de aplicativo geral no MuleSoft. A autenticação com esses sistemas pode ser feita por meio de vários mecanismos de autenticação, incluindo autenticação básica e OAuth. Não há restrições ao volume de transações, desde que o fluxo tenha sido dimensionado adequadamente para sua utilização máxima (medido em vCores ou Cores).

**APIs nativas do Salesforce** A [API de replicação](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm) (operações getUpdated, getDeleted) pode ser usada para sincronizar dados entre organizações, mas essa abordagem não é recomendada.

**Salesforce Connect com adaptador entre organizações** Você pode usar fluxos acionados por registro e objetos externos para manter alguns dados sincronizados entre as organizações do Salesforce. Por exemplo, atualizar um registro de conta na Organização A aciona um fluxo que então atualiza o registro correspondente no objeto externo Conta, que grava essas atualizações no registro da conta na Organização B. Isso exige o uso adequado da semântica do fluxo para evitar [transações DML mistas](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1). Além disso, lembre-se de que as regras de validação e os fluxos na organização B serão acionados da mesma maneira que quando as alterações forem feitas por nossas APIs REST/SOAP.

## Observações de fechamento

Lembre-se deste guia e consulte-o quando estiver planejando uma nova integração de dados envolvendo o Salesforce. Sempre é uma boa ideia entender todo o escopo de opções disponíveis para você e como elas podem se ajustar ao seu caso de uso específico.

### Diga-nos o que você pensa

Ajude-nos a garantir que estejamos publicando o que é mais relevante para você. [Pegue nossa pesquisa](https://sfdc.co/J0cWb) para fornecer feedback sobre esse conteúdo e nos diga o que você gostaria de ver em seguida.

<!-- document id=f3c4d20365fbe05b72b94d45470e307f599aaa30666bf69c9090b79f66ac742d url=/architect/current/pt-br/decision-guides/guides/data-360-interoperability.md -->

# Interoperabilidade do Data 360

As empresas muitas vezes armazenam dados no Salesforce e outros data lakes externos (por exemplo, _Snowflake_, _Google BigQuery_, _Databricks_, _Redshift_ ou armazenamento de objetos como o _Amazon S3_). Siloar dados entre vários sistemas cria um desafio para empresas que querem aproveitar todo o valor de seus dados para impulsionar experiências conduzidas por IA. O Salesforce _Data 360_ é a camada de inteligência básica que cada Agente de IA do Agentforce usa para acessar o contexto correto no momento certo.

Os arquitetos que trabalham para unir dados entre vários data lakes enfrentam decisões arquitetônicas importantes sobre como integrar melhor esses dados. O _Data 360_ oferece várias opções para integração de dados, cada uma oferecendo vários prós e contras.

## Visão geral do guia

Este guia fornece uma estrutura para avaliar qual padrão atende melhor aos seus requisitos de latência, custo, escalabilidade, governança e complexidade ao integrar dados, ajudando você a escolher quando usar ingestão de dados, federação de dados de Cópia zero ou uma abordagem híbrida. O guia também o ajudará a selecionar entre diferentes métodos de ingestão de dados e federação de dados, cada um dos quais preenche uma necessidade diferente.

Integrar casas de data lake externas ao _Data 360_ exige que você considere cuidadosamente as compensações entre a atualização dos dados, a governança e a eficiência do pipeline. Por exemplo, usar consultas ativas de federação de dados do Zero Copy maximiza a atualidade dos dados, mas pode reduzir a eficiência do pipeline à medida que mais dados são movidos pela rede. Para a maioria das implementações do mundo real, combinar ingestão e federação em um ecossistema de casa de lago de várias nuvens é o caminho ideal. Essa abordagem híbrida garante uma arquitetura escalonável, governada e interoperável que dá suporte a cargas de trabalho operacionais de baixa latência (por exemplo, personalização em tempo real e detecção de fraudes) e cargas de trabalho analíticas (por exemplo, relatórios regulatórios e análise de tendências históricas). Este guia ajuda a determinar como navegar por essas compensações usando uma estratégia adequada.

## Principais transferências

- A **Ingestão de dados** copia dados para o Salesforce _Data 360_ e cria Modelos de dados canônicos governados. Isso é ideal para quando você precisa:
  - **Construa um Customer 360 abrangente.** Isso permite unificar e transformar origens diferentes em um único perfil confiável.
  - **Cumpra a rigorosa conformidade regulatória.** Isso permite que você crie uma cópia auditável centralizada para que o acesso aos dados e a linhagem possam ser controlados de perto.
- A **Federação de cópia zero** consulta fontes externas em tempo real sem duplicação, permitindo personalização em tempo real, painéis ativos e integração rápida de origem. Essa abordagem oferece duas opções principais, mas há compensações que precisam ser balanceadas:
  - **Consulta ao vivo:** Use isso para análise interativa e painéis de dados em tempo real que estão em plataformas de dados externas (por exemplo, _Snowflake_, _BigQuery_, _Redshift_ ou _Databricks_). Isso ajuda a evitar duplicação de dados lenta e dispendiosa enviando o processamento de consulta para o sistema de origem e retornando apenas os resultados necessários. Essa abordagem é otimizada para consultas raras ou ad-hoc em que a frescura é crítica. É adequado para cargas de trabalho de baixa _consulta por segundo (QPS)_ (custos de consulta podem aumentar significativamente em QPS alto).
  - **Cache (consulta acelerada):** Use isso para consultas de dados frequentes que não mudam com frequência. Consultas aceleradas mantêm um cache local que é atualizado a intervalos configuráveis (15 minutos a 7 dias), o que reduz os encontros de origem repetidos. Essa abordagem equilibra o desempenho do painel e o custo, a segmentação e as cargas de trabalho de BI em que resultados levemente obsoletos são aceitáveis. Isso não é adequado para tomada de decisão em menos de um segundo.
  - **Federação de arquivos:** Use isso para processamento em lote em grande escala e treinamento de modelo de IA para dados no data lake da sua nuvem (por exemplo, _S3_ ou _ADLS_). Essa abordagem evita a ingestão lenta e dispendiosa consultando diretamente arquivos em formatos de tabela abertos, o que desbloqueia conjuntos de dados ETL e cargas de trabalho de ciência de dados em massa.
- Os **Modelos híbridos** combinam ingestão para _Perfis unificados_ com federação para frescura, que suporta engajamento do Omni-Channel, ações conduzidas pelo Agentforce e treinamento de IA/ML.

### Considerações importantes

- **Usar uma arquitetura híbrida.** Misturar ingestão de dados e federação costuma ser necessário.
  - Use a _ingestão de dados_ em dados críticos para modelos de dados canônicos e governança principal.
  - Use _Cópia zero_ para todas as outras federações de dados para manter a atualidade e minimizar a sobrecarga operacional de criar e manter pipelines de ingestão de dados.
- **A frequência de ingestão de dados importa.** Escolha a frequência com base no valor dos negócios, nas necessidades de latência e na complexidade operacional.
  - Use o recurso _em tempo real_ para fluxos de trabalho urgentes (por exemplo, personalização, painéis ativos e ações do Agentforce).
  - Use _quase em tempo real_ para processos moderadamente urgentes (por exemplo, campanhas e relatórios operacionais).
  - Use lote para conjuntos de dados históricos ou de baixa velocidade.
- **Combine padrões de federação com latência e desempenho.** Escolha a opção que melhor corresponde aos seus padrões de acesso e requisitos de frescura, desempenho e custo.
  - Use a _consulta ativa_ para painéis operacionais e personalização em tempo real quando a baixa latência for crítica.
  - Use o _cache (consulta acelerada)_ quando as consultas forem frequentes e os resultados ligeiramente obsoletos forem aceitáveis, o que ajuda a equilibrar o desempenho e o custo.
  - Use a _Federação de arquivos_ para análises em grande escala e de alto rendimento ou cargas de trabalho em lote, que são ideais para conjuntos de dados históricos ou menos sensíveis ao tempo.
- **Alinhar a governança aos requisitos de residência de dados.**
  - Use a _ingestão_ quando a governança centralizada for crítica.
  - Use a _federação_ quando a governança descentralizada for aceitável, ao mesmo tempo que também imponha uma governança rígida na fonte externa.
  - Use _Cópia zero_ em relação a políticas em nível de origem (por exemplo, segurança em nível de _linha (RLS)_ e mascaramento de dados).
- **Priorize a ingestão para fluxos de trabalho de alto valor.** Aplique a ingestão de modo seletivo a processos críticos (por exemplo, resolução de identidade, relatórios regulatórios e ativação operacional).
- **Decisões de custo e complexidade.** A ingestão em tempo real pode ser cara e complexa. É por isso que é importante que os arquitetos ponderem o custo de integração, armazenamento e transformação de dados com o custo de consultá-los diretamente por meio da _Cópia zero_.

Escolher o padrão de integração correto (_Ingestão de dados_, _Cópia zero_ ou uma abordagem _híbrida_) afeta diretamente a latência, a governança, a eficiência operacional e o custo em várias plataformas de nuvem. Essa decisão determina como percepções em tempo real, ativação conduzida por IA e engajamento personalizado são entregues de forma confiável e em escala.

## Comparação de produto

Esta tabela compara os padrões de _ingestão de dados_ e _cópia zero_ no Salesforce _Data 360_, com foco em recursos, compensações e benefícios, bem como casos de uso e resultados corporativos. Use isso como referência para projetar plataformas de dados de várias nuvens híbridas que equilibram desempenho, custo e conformidade.

<table>
  <thead>
    <tr>
      <th align="left" valign="top"><strong>Tipo de padrão</strong></th>
      <th align="left" valign="top"><strong>Modo/ferramenta</strong></th>
      <th align="left" valign="top"><strong>Benefícios</strong></th>
      <th align="left" valign="top"><strong>Considerações</strong></th>
      <th align="left" valign="top"><strong>Resultados</strong></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td align="left" valign="top"><strong>Ingestão de dados</strong></td>
      <td align="left" valign="top">
        <strong>Em tempo real:</strong>
        <ul>
          <li>Ingestão de latência de subsegundo por meio de APIs de ingestão com suporte para CDC.</li>
          <li>Pipelines de streaming contínuo.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Fornece percepções imediatas</li>
          <li>Aborda casos de uso operacionais e de personalização de baixa latência</li>
          <li>Dá suporte a fluxos de trabalho conduzidos por evento</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Custo alto</li>
          <li>Arquitetura complexa</li>
          <li>Requisitos do sistema de origem de baixa latência</li>
          <li>Origens de alto volume podem causar streaming excessivo, o que leva a pipelines saturados</li>
          <li>Intensivo de I/O</li>
          <li>Campos seletivos e filtragem podem ajudar a reduzir a sobrecarga</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Alertas de fraude em tempo real, personalização do varejo e alertas operacionais</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Painéis de subsegundo e monitoramento de KPI</li>
        </ul>
        <strong>Conformidade:</strong>
        <ul>
          <li>Atualizações contínuas de registro do cliente para fluxos de trabalho regulados</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Streaming:</strong>
        <ul>
          <li>Ingestão de microlote a cada 1 a 3 minutos por meio de conectores nativos</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Salda o custo vs. a frescura</li>
          <li>Recebe uma arquitetura mais simples do que em tempo real</li>
          <li>Dá suporte a atualizações incrementais</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Baixa latência</li>
          <li>Pode não ser adequado para decisões críticas de subsegundo</li>
          <li>O tamanho do lote afeta a memória/compute</li>
          <li>Moderar I/O</li>
          <li>Adequado para padrões de atualização repetitivos e previsíveis</li>
          <li>Agregação com janelas pode ajudar a reduzir a carga de processamento</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Acionadores de campanha oportunos e engajamento quase ativo</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Mecanismos de recomendação e painéis quase ativos</li>
        </ul>
        <strong>Conformidade:</strong>
        <ul>
          <li>Atualizações frequentes com capacidade de auditoria</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Lote:</strong>
        <ul>
          <li>Fornece cargas de grande volume agendadas por meio de conectores ou APIs.</li>
          <li>Suporta o armazenamento de objetos e pipelines ETL/ELT.</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Dá suporte a custo-benefício para conjuntos de dados massivos</li>
          <li>Recursos de fácil implementação</li>
          <li>Fornece confiabilidade para análise histórica</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Latência de dados</li>
          <li>Inadequado para operações que exigem tempo</li>
          <li>Intensidade de I/O durante janelas de carregamento</li>
          <li>A taxa de transferência de rede pode se tornar um gargalos para arquivos grandes</li>
          <li>Adequado para agregação de histórico ou fluxos de trabalho de relatórios regulados</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Pedidos de suporte de TI (Jira/ServiceNow) e fluxos de trabalho agregados</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Análise histórica e avaliação de tendências</li>
        </ul>
        <strong>Conformidade:</strong>
        <ul>
          <li>Relatórios regulatórios e agregação de dados de paciente/reivindicações</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"><strong>Zero Copy</strong></td>
      <td align="left" valign="top">
        <strong>Consulta ao vivo:</strong>
        <ul>
          <li>Fornece consultas diretas em sistemas externos e esquema de leitura sem duplicação de dados</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Fornece frescura máxima</li>
          <li>Recebe sobrecarga mínima de armazenamento</li>
          <li>Dá suporte a percepções operacionais em tempo real</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Dependendo do desempenho de origem</li>
          <li>O alto volume de consultas pode afetar a latência</li>
          <li>Adequado para consultas com push-down de predicado e agregação para minimizar I/O</li>
          <li>Evite usar consultas não filtradas em conjuntos de dados massivos</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Fluxos de trabalho dinâmicos que se adaptam à atividade ativa</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Painéis operacionais e relatórios ativos</li>
        </ul>
        <strong>Conformidade:</strong>
        <ul>
          <li>Respeita a segurança em nível de linha e o mascaramento na origem</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Consulta acelerada (cache):</strong>
        <ul>
          <li>Fornece cópias locais em cache para consultas federadas configuráveis de 15 minutos a sete dias.</li>
          <li>Fornece execução de consulta otimizada</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Reduz a latência</li>
          <li>Recorre a custos menores do que consultas ativas repetitivas</li>
          <li>Melhora o desempenho para padrões de acesso frequente</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Gerenciamento de cache necessário</li>
          <li>A permanência depende dos intervalos de cache</li>
          <li>Adequado para consultas de alta frequência</li>
          <li>Não é adequado para tomada de decisão em menos de um segundo</li>
          <li>A atualização incremental oferece suporte apenas a inserções e atualizações; os registros excluídos não são removidos do cache.</li>
          <li>Periodicamente exige uma atualização manual completa para manter o cache sincronizado com a origem</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Métricas de engajamento pré-agregadas para uma rápida tomada de decisão</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Painéis de BI, segmentação e relatórios analíticos</li>
        </ul>
        <strong>Conformidade:</strong>
        <ul>
          <li>Painéis regulados de modo consistente com registros de auditoria</li>
        </ul>
      </td>
    </tr>
    <tr>
      <td align="left" valign="top"></td>
      <td align="left" valign="top">
        <strong>Federação de arquivos:</strong>
        <ul>
          <li>Fornece acesso direto a conjuntos de dados históricos grandes em lojas de objetos ou lagos (por exemplo, <em>S3</em>, <em>Iceberg</em>, <em>Google BigQuery</em> e <em>Redshift</em>).</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Processa conjuntos de dados em escala enorme</li>
          <li>Requer armazenamento mínimo no <em>Data 360</em></li>
          <li>Dá suporte a cargas de trabalho de IA/ML</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <ul>
          <li>Somente leitura</li>
          <li>O desempenho da consulta depende da taxa de transferência do sistema externo</li>
          <li>Adequado para trabalhos pesados em lote com alta taxa de transferência</li>
          <li>Não é adequado para painéis em tempo real</li>
        </ul>
      </td>
      <td align="left" valign="top">
        <strong>Agentforce:</strong>
        <ul>
          <li>Não típico (pesado em lote)</li>
        </ul>
        <strong>Analytics:</strong>
        <ul>
          <li>Treinamento em ML/IA, análise histórica e relatórios em escala de petabyte</li>
        </ul>
        <strong>Conformidade:</strong>
        <ul>
          <li>Controla o acesso a conjuntos de dados externos sem duplicação</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

## Padrões de integração do Data 360

Há três padrões de integração principais para o Data 360: ingestão de dados, federação de dados de cópia zero e abordagem híbrida.

### Ingestão de dados

Com a _Ingestão de dados_, os dados são copiados fisicamente para o _Data 360_ e totalmente controlados, ao contrário da _Cópia zero_, em que os dados permanecem na fonte. Em outras palavras, a computação para transformações ocorre no _Data 360_, que fornece governança e auditoria centralizadas.

#### Casos de uso de ingestão de dados

Use a _Ingestão de dados_ para armazenar conjuntos de dados canônicos e controlados no Salesforce _Data 360_ para conformidade e controle operacional. Use a ingestão quando controle total, auditoria e rastreabilidade forem necessários. A Ingestão de dados é ideal para fluxos de trabalho regulados ou de alto valor em que computação centralizada e governança são essenciais.

A ingestão é adequada para criar uma base confiável para resolução de identidade, relatórios regulatórios e fluxos de trabalho conduzidos por IA críticos para a missão e engajamento do cliente.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360  Ingestion.png" alt="Visão geral da ingestão de dados" />

#### Métodos de ingestão de dados

Os métodos de _ingestão de dados_ podem variar, dependendo do conector que você usa para ingerir seus dados. Alguns conectores oferecem uma variedade de métodos de ingestão, enquanto outros operam apenas no modo de lote ou streaming. Para obter uma lista completa de conectores e métodos disponíveis do _Data 360_, consulte [Data 360: Integrações e conectores](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5).

- **Em tempo real:**
  - Fornece ingestão de subsegundo usando a _captura de dados de alteração (CDC)_
  - Adequado para fluxos de trabalho urgentes (por exemplo, detecção de fraudes, personalização e painéis operacionais)
  - Possui transformações e agregações por push no _Data 360_, o que ajuda a reduzir as I/O a jusante e otimizar o uso de computação
  - Suporta o uso de CDC incremental para minimizar o desvio de dados
- **Streaming:**
  - Fornece ingestão a cada 1 a 3 minutos em pequenos incrementos
  - Balança a frescura e o custo
  - Adequado para orquestração de campanha, engajamento quase ativo e relatórios operacionais
  - Suporta o uso de microlotes para controlar picos de entrada/saída
  - Agrega dados na origem (se possível) para reduzir volumes de transferência e otimizar o armazenamento
- **Lote (cargas agendadas):**
  - Fornece ingestão periódica de conjuntos de dados grandes (por exemplo, por hora, diariamente e semanalmente)
  - Fornece custo-benefício e confiabilidade para conjuntos de dados históricos, relatórios regulatórios e casos de uso de conformidade
  - Garante que a localidade de computação esteja na mesma região que o armazenamento de origem para aprimorar o desempenho e otimizar os custos

#### Manual do arquiteto

- **Casos de uso de ingestão de dados:**
  - **Gerar perfis unificados do Customer 360.** Crie uma única fonte da verdade para identidades e atributos do cliente.
  - **Manter conjuntos de dados de conformidade regulatória.** Impor governança, lineagem e capacidade de auditoria para dados confidenciais.
  - **Centralize a orquestração da campanha.** Garanta que marketing, vendas e serviço operem com base em conjuntos de dados consistentes e confiáveis.
- **Práticas de design:**
  - Acomode a ingestão em lote para necessidades históricas ou com baixa tolerância a latência (por exemplo, relatórios de arquivo ou instantâneos periódicos).
  - Use as APIs de streaming ou CDC para manter a atualidade dos fluxos de trabalho operacionais e de personalização para garantir atualizações quase em tempo real.
  - Controle o armazenamento e o crescimento de computação aplicando cargas incrementais para otimizar o custo e a eficiência (em vez de recarregar conjuntos de dados inteiros).
  - Alinhe os pipelines de ingestão com localidade de computação e processamento incremental para reduzir as I/O de rede.
  - Aplique transformações dentro do _Data 360_ para evitar mover dados brutos desnecessariamente.
- **Considerações de custo:**
  - A **Ingestão em tempo real** tem os custos de computação e pipeline mais altos, o que pode ser justificado para fluxos de trabalho de alto valor e sensíveis ao tempo (por exemplo, personalização, painéis operacionais ou ações conduzidas pelo Agentforce).
  - A **Ingestão de streaming** tem custos moderados de computação e armazenamento, o que pode ser adequado para atualizações frequentes que podem tolerar pequenos atrasos (por exemplo, orquestração de campanha ou relatórios operacionais).
  - A **Ingestão em lote** tem custos de computação mais baixos e armazenamento previsível, o que é adequado para conjuntos de dados históricos ou atualizações de baixa frequência. A ingestão de dados em lote de organizações do Salesforce usando determinados conectores é gratuita.
  - **Modo de atualização** Permite que você selecione o modo _Atualização incremental_, o que reduz os custos totais de ingestão e computação. Na Salesforce, recomendamos usar a atualização _incremental_ sempre que possível para otimizar a eficiência em todos os tipos de ingestão.
  - O **custo** também é afetado pelo volume de I/O da fonte para o _Data 360_. Otimizar tamanhos de lote, partições e alinhamento regional reduz os custos de transferência e melhora o desempenho.
- **Cenários da indústria:**
  - **Finanças:** Os conjuntos de dados de ingestão são necessários para _conhecer seu cliente (KYC)_, _Anti Money Laundering (AML)_ e detecção de fraudes quando a capacidade de auditoria e a conformidade não são negociáveis.
  - **Saúde:** Use a ingestão para resolução de identidade do paciente e registros em conformidade com HIPAA, o que habilita visualizações seguras e unificadas.
  - **Retail:** Consolide dados de _ponto de venda (POS)_, comércio eletrônico e programa de fidelidade em perfis unificados para segmentação e personalização.
  - **Telecom:** Dê suporte à prevenção de rotatividade e à análise de uso com dados canônicos de assinante regulamentados.

#### Critérios de decisão do método de ingestão de dados

| Recurso                              | Ingestão em tempo real                                                                                                                                                                         | Ingestão de streaming                                                                                                                                           | Ingestão em lote                                                                                                                                                                            |
| :----------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Latency e frescura**            | Possui ingestão de latência subsegunda por meio de APIs de ingestão com suporte para _captura de dados de alteração (CDC)_. Fornece pipelines de streaming contínuos. Adequado para casos de uso operacionais de baixa latência. | Apresenta ingestão de microlote a cada 1 a 3 minutos por meio de conectores nativos. Dá suporte a atualizações incrementais. É esperada uma pequena latência.                             | A latência de dados é esperada. Permite carregamentos de grande volume agendados. Apresenta ingestão periódica (horária, diária e semanal). Não é adequado para operações que exigem tempo.                        |
| **Casos de uso primários**                | Ideal para casos de uso operacionais e de personalização de baixa latência. Use para fluxos de trabalho urgentes. Dá suporte a fluxos de trabalho conduzidos por evento. Use para alertas de fraude em tempo real e alertas operacionais.  | Adequado para processos moderadamente urgentes. Use para orquestração de campanha, engajamento quase ativo e relatórios operacionais. Use para acionadores de campanha oportunos.  | Eficiente para conjuntos de dados massivos. Confiável para análise histórica. Use para agregação de histórico ou fluxos de trabalho de relatórios regulados. Adequado para conjuntos de dados históricos ou de baixa velocidade. |
| **Complexidade arquitetônica e I/O** | Inclui um alto custo e uma arquitetura complexa. Requer sistemas de origem de baixa latência. Intensivo de I/O. Origens de alto volume podem causar pipelines saturados.                                         | Recebe uma arquitetura mais simples do que em tempo real. O I/O é moderado. Adequado para padrões de atualização repetidos e previsíveis. O tamanho do lote afeta a memória e os cálculos. | Fácil de implementar. Intensivo de I/O durante janelas de carregamento. A taxa de transferência de rede pode se tornar um gargalos para lotes grandes.                                                                        |
| **Considerações de custo**              | Inclui os custos de computação e pipeline mais altos. Justificável apenas para fluxos de trabalho de alto valor e urgentes.                                                                                 | Inclui moderar os custos de computação e armazenamento. Fornece uma abordagem de custo equilibrado versus frescura. Adequado para atualizações frequentes que podem tolerar pequenos atrasos.   | Recorre a menores custos de computação e armazenamento previsível. Recomendado para conjuntos de dados históricos ou atualizações de baixa frequência. A ingestão por meio de pipelines internos do Salesforce é gratuita.                   |
| **Práticas de design**                 | Use a CDC incremental para minimizar o desvio de dados. Filtre e use campos seletivos para reduzir a sobrecarga.                                                                                         | Use microlotes para controlar picos de I/O. Considere a agregação com janelas para reduzir a carga de processamento.                                                             | Use para relatórios de arquivamento ou instantâneos periódicos. Certifique-se de que a localidade de computação esteja na mesma região que o armazenamento de origem para otimização de custo.                                              |

### Federação de dados de cópia zero

#### Casos de uso de cópia zero

Use a _Cópia zero_ para consulta em tempo real de sistemas externos sem duplicação de dados para permitir a agilidade, a frescura e o acesso escalonável a conjuntos de dados grandes ou temporários. É adequado para painéis ativos, análise exploratória, treinamento de modelo de IA/ML e engajamento do cliente em tempo real diretamente no Salesforce _Data 360_.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Data 360 Zero Copy.png" alt="Visão geral da Federação de dados de cópia zero" />

#### Métodos de cópia zero

Ao usar o _Zero Copy_, os arquitetos devem escolher entre três métodos de federação de dados disponíveis, cada um dos quais oferece seus próprios prós e contras entre frescura, desempenho e custo.

- **Consulta ativa**
  - Executa consultas diretamente em sistemas externos (por exemplo, _Snowflake_, _Google BigQuery_, _Redshift_, _Databricks_, etc.) sem duplicação de dados.
  - Minimize a movimentação de dados pela rede e reduza as entradas/saídas no cálculo do Salesforce _Data 360_, o que é ideal quando os predicados e agregações podem ser reduzidos.
  - Adequado para percepções em tempo real e painéis operacionais de baixa latência.
  - Dependendo do desempenho do sistema externo.
- **Cache (consulta acelerada)**
  - Armazena temporariamente cópias em cache de dados federados no Salesforce _Data 360_.
  - Reduz os custos de consulta repetida e a latência para conjuntos de dados acessados com frequência com duração configurável (minutos a dias).
  - Os dados não são copiados permanentemente nem totalmente controlados, assim, a atualidade é gerenciada por meio de atualizações agendadas da origem.
  - A _atualização incremental_ oferece suporte apenas a upserts. Registros excluídos não são removidos do cache.
  - Realize uma atualização completa periodicamente para garantir que o cache permaneça sincronizado com a origem.
  - **Nota:** O conector _Snowflake_ suporta a função _Descarregar_, que aumenta as taxas de aceleração usando um balde de preparação iniciado pelo Snowflake. Isso é ativado por padrão, mas pode ser desativado editando a conexão.
- **Federação de arquivos**
  - Fornece acesso direto e somente leitura a conjuntos de dados em grande escala em repositórios de objetos (por exemplo, _S3_ e _GCS_ com _Iceberg_).
  - Adequado para cargas de trabalho de IA/ML, análise histórica e relatórios em escala de petabytes sem mover dados.
  - O desempenho da consulta depende muito do formato do objeto, do particionamento e das I/O de rede. As verificações grandes podem gerar I/O substanciais se não forem otimizadas.

#### Manual do arquiteto

- **Casos de uso**
  - A **personalização em tempo real e os fluxos de trabalho adaptáveis** oferecem ofertas dinâmicas, recomendações e as melhores ações conforme o comportamento do cliente muda.
  - **Painéis ativos e análise operacional** alimentam painéis e KPIs críticos para os negócios diretamente de armazéns externos.
  - O **treinamento de modelo de IA/ML com grandes conjuntos de dados externos** aproveita dados em escala de petabytes de data lakes e armazéns sem movê-los via federação de arquivos.
- **Cenários da indústria**
  - **Retail/Media:** Habilite recomendações personalizadas e engajamento do cliente em tempo real federando dados de interação de conteúdo ou fluxo de cliques.
  - **Finanças:** Execute a detecção de fraudes e a pontuação de risco quase em tempo real consultando armazéns externos sem duplicar dados confidenciais.
  - **Tech/Enterprise:** Dê suporte a relatórios entre nuvens, painéis de serviço de TI e análise operacional quando os conjuntos de dados residem em vários sistemas.
- **Práticas de design**
  - **Consulta ativa**
    - Use para consultas de alta QPS e baixa latência quando a frescura for crítica.
    - Envie por push predicados e agregações para o sistema externo para reduzir o desvio de dados na rede.
    - Evite consultas que verificam volumes de dados enormes desnecessariamente.
    - Considere cortar a partição e filtros em vez disso.
  - **Federação de arquivos**
    - Acesse conjuntos de dados em escala de petabytes em lojas de objetos sem ingestão.
    - Minimize os custos de latência e saída mantendo o armazenamento de objetos na mesma região de nuvem que o cálculo do Salesforce.
    - Use formatos particionados em coluna (Parquet/ORC) e filtros de menu suspenso para reduzir a transferência de I/O e rede.
    - Aproveite a consulta e o menu suspenso de predicado para filtrar e agregar dados na origem, o que reduz a movimentação dos dados.
    - Evite o acesso a dados entre regiões, a menos que seja absolutamente necessário, pois isso aumenta a entrada/saída, a latência e os custos.
  - **Cache (consulta acelerada)**
    - Armazene em cache conjuntos de dados acessados com frequência para equilibrar custo e desempenho.
    - Configure intervalos de atualização para equilibrar a frescura versus o custo da consulta.
  - **Conformidade:** Imponha a governança na fonte aproveitando a _segurança em nível de linha (RLS)_ e mascarando políticas diretamente dentro de sistemas federados.
    - Aqui estão algumas práticas recomendadas para RLS uniforme e mascaramento entre plataformas:
      - **Usar um ID corporativo centralizado.** Mapeie usuários e entidades no Salesforce _Data 360_ para um identificador corporativo único e centralizado que corresponde a identidades em sistemas externos.
      - **Align Políticas de segurança.** Garanta que o RLS e as políticas de mascaramento em sistemas federados sejam aplicados com base na identidade mapeada. Isso preserva a conformidade ao consultar dados externos.
      - **Padronizar esquemas de identidade.** Mantenha atributos de identidade consistentes (email, ID do usuário, ID do cliente etc.) em todas as fontes de dados para evitar incompatibilidades e violações de acesso.
- **Considerações de custo**
  - **Consulta ao vivo:** No modelo de pagamento por consulta, os custos se acumulam no cálculo externo da residência do lake, o que pode causar picos com QPS alto. Isso é adequado para casos de uso críticos de frescura em que o valor é maior que a variabilidade de custo.
  - **Consulta acelerada (cache):** Esse método reduz o custo de consulta (em comparação com a _Questão ativa)_ reduzindo os encontros no sistema de origem; no entanto, aumenta os custos de ingestão de dados em lote para preenchimento e atualização do cache. Isso é adequado para conjuntos de dados acessados com frequência.
  - **Federação de arquivos:** Essa é a opção de armazenamento mais econômica como dados na Loja de objetos; no entanto, os custos de consulta dependem do tamanho do arquivo, do particionamento e da redução. Isso é adequado para dados históricos ou em massa em escala de petabytes.

#### Critérios de decisão do método de cópia zero

| Ponto de decisão           | Consulta ativa                                                                                                                                                                                                                    | Armazenamento em cache (consulta acelerada)                                                                                                                                | Federação de arquivos                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
| :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Local da fonte de dados** | Casas de data lake externas (por exemplo, _Snowflake_, _Google BigQuery_, _Redshift_ e _Databricks_)                                                                                                                         | Casas de data lake externas (por exemplo, _Snowflake_, _Google BigQuery_, _Redshift_ e _Databricks_)                                                      | Armazéns de objetos ou data lakes de nuvem (por exemplo, _S3_, _ADLS_ e _GCS_), que muitas vezes usam formatos de tabela aberta, como _Iceberg_.                                                                                                                                                                                                                                                                                                                                                     |
| **Objetivo/Caso de uso**     | Adequado para análise interativa e painéis em tempo real. Adequado para personalização em tempo real e fluxos de trabalho dinâmicos.                                                                                                     | Adequado para quando as consultas são frequentes, mas os resultados levemente obsoletos são aceitáveis. Adequado para painéis de BI e segmentação.                            | Adequado para processamento em lote em grande escala e treinamento de modelo de IA/ML. Adequado para análise histórica e relatórios em escala de petabytes.                                                                                                                                                                                                                                                                                                                                              |
| **Fresqueza/Latency**    | Fornece máxima atualidade Executa consultas diretamente em tempo real. Dá suporte à tomada de decisão em menos de um segundo quando o sistema de origem é otimizado para consultas de baixa latência com um menu suspenso de predicado eficaz.                                 | Use quando resultados levemente obsoletos forem aceitáveis. A atualidade depende do intervalo de cache, que pode ser configurado de 15 minutos a 7 dias.                  | Adequado para trabalhos pesados em lote com alta taxa de transferência. Não é adequado para painel em tempo real.                                                                                                                                                                                                                                                                                                                                                                                    |
| **Padrão de acesso**       | Adequado para consultas raras ou ad-hoc em que a atualidade é crítica e o volume de consultas é baixo. Os custos aumentam significativamente em QPS alto, portanto, é importante avaliar o armazenamento em cache (consulta acelerada) quando a frequência de consulta é alta. | Adequado para cenários de leitura de alta frequência. Melhora o desempenho para padrões de acesso frequente.                                                             | Fornece acesso somente r*ead*. Adequado para conjuntos de dados em escala de petabytes sem ingestão.                                                                                                                                                                                                                                                                                                                                                                                             |
| **Drivers de desempenho**  | Altamente dependente do desempenho do sistema de origem externo. Adequado para quando predicados e agregações podem ser enviados para baixo para a origem.                                                                                     | Reduz a latência em comparação a consultas ativas repetidas. O desempenho depende do gerenciamento de cache e dos intervalos.                                             | O desempenho depende muito do formato do objeto, do particionamento e da taxa de transferência do sistema externo. Use formatos particionados em colunas (Parquet/ORC).                                                                                                                                                                                                                                                                                                                                     |
| **Implicações dos custos**    | Esse é um modelo de pagamento por consulta, portanto, os custos se acumulam nos cálculos externos do Lake House. É econômico para consultas infrequentes, mas as despesas podem aumentar com alto volume de QPS.                                                  | O custo é menor que consultas ativas repetidas. Ele reduz a necessidade de consultar repetidamente a origem externa, mas adiciona armazenamento em cache e sobrecarga de atualização. | Esta é a opção de armazenamento mais barata. Para configurações da AWS na mesma região (por exemplo, _S3_ nos EUA-Leste-1 com um locatário do _Data Cloud_ que também está nos EUA-Leste-1), os créditos não são consumidos para as linhas acessadas. Configurações entre regiões ou entre nuvens (por exemplo, _Azure_, _GCS_ ou diferentes regiões da _AWS_) geram consumo de crédito para as linhas acessadas. Os custos de consulta também dependem do tamanho do arquivo, do particionamento e da otimização de menu suspenso de predicado. |
| **Consideração principal**    | Evite consultas não filtradas que verificam volumes de dados enormes desnecessariamente.                                                                                                                                                        | Essa abordagem requer gerenciamento de cache. Não é adequado para tomada de decisão em menos de um segundo.                                                                          | O desempenho da consulta depende fortemente da otimização por meio de particionamento e menu suspenso de predicado.                                                                                                                                                                                                                                                                                                                                                                                        |

### Abordagem híbrida

As arquiteturas híbridas permitem aos arquitetos ancorar conjuntos de dados críticos no _Data 360_ para governação centralizada, ao mesmo tempo que aproveitam consultas federadas para atualização, redução de duplicação e acesso escalonável a conjuntos de dados externos grandes. Essa abordagem balanceia os requisitos de I/O, localidade de computação, custo e conformidade.

#### Casos de uso híbridos

Use uma abordagem híbrida para uma governança equilibrada, frescura e eficiência operacional combinando ingestão de dados e cópia zero para fornecer percepções acionáveis em tempo real. Use a ingestão para conjuntos de dados regulados de alto valor em que rastreabilidade, RLS e mascaramento são necessários e federação para conjuntos de dados efetivos ou de alto volume em que a atualização e o desempenho são essenciais.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Data Ingestion and Zero Copy - Copy of Hybrid.png" alt="Visão geral da abordagem híbrida" />

#### Manual do arquiteto

- **Casos de uso**
  - **Engajamento do Omni-Channel:** Combine dados históricos do cliente com comportamento em tempo real para proporcionar experiências consistentes sensíveis ao contexto.
  - **Pipelines de IA/ML:** Treine modelos em conjuntos de dados canônicos selecionados enquanto os aprimora com sinais brutos ou em tempo real de fontes externas.
  - **Necessidades de conformidade e agilidade mistas:** Aplique governança rígida para dados confidenciais e federação para agilidade operacional.
- **Cenários da indústria**
  - **Retail:** Use a _ingestão_ para resolução de identidade e unificação de perfil, e a _federação_ para ofertas e personalização em tempo real.
  - **Saúde:** Mantenha registros de pacientes dourados por meio da _ingestão_ enquanto usa a _federação em_ fluxos de dispositivos de IoT e dados de sensor para contexto imediato.
  - **Serviços financeiros:** Ingira dados regulamentados em um lago de conformidade enquanto usa a _federação_ para consultas externas de detecção de fraudes e monitoramento de risco.
- **Práticas de design**
  - **Ancora governança com ingestão:** Ingira dados de alto valor ou regulados em modelos canônicos para garantir Trust e conformidade.
  - **Use Federação para frescura:** Permite que as casas de lago externas forneçam acesso a dados em tempo real ou em grande escala sem duplicação.
  - **Custo do saldo vs. desempenho:** Analise as cargas de trabalho para determinar quando usar a _ingestão_ vs. a _federação_, o que minimiza os custos desnecessários de armazenamento e consulta.
  - **Aplicar governança em camadas:** Imponha a governança centralizada para dados ingeridos enquanto aproveita os controles de segurança de sistemas federados (por exemplo, RLS e mascaramento).
  - **Nota:** Ao projetar pipelines híbridos, é importante garantir a ingestão incremental para conjuntos de dados históricos e enviar agregações ou filtros por push a fontes federadas para otimizar o uso de I/O e computação.
- **Considerações de custo**
  - Pesquise o custo total versus o desempenho combinando a _ingestão_ para conformidade ou dados críticos com a _federação_ quando a frescura for necessária.
  - Considere a distribuição de I/O e computação ao misturar _a ingestão_ e a _federação_. Para reduzir o custo de computação de consultas repetidas em sistemas de origem, use o armazenamento em cache (consulta acelerada) para conjuntos de dados federados de alta leitura acessados com frequência.
  - Use esta regra para orientar a decisão de ingestão vs. federação: Quando os dados são acessados com frequência, mas mudam com pouca frequência, a _consulta acelerada_ geralmente é mais econômica. No entanto, quando os dados mudam com frequência (em relação à frequência de acesso), a _consulta ao vivo_ ou a _ingestão_ é mais adequada. Aqui estão alguns exemplos de custo:
    - **Aceleração ganha:** Um painel criado com base em 1 milhão de registros e atualizado diariamente com ~10 mil alterações é visualizado 20 vezes por dia. Os custos de _aceleração_ são equivalentes a aproximadamente ~600 créditos/mês vs. ~4.200 créditos/mês para _consultas ao vivo_.
    - **Question ao vivo ganha:** Segmentos publicados 20 vezes por dia usando dados que mudam a cada 30 minutos. _As consultas ao vivo_ custam aproximadamente ~4.200 créditos/mês vs. ~28.800 créditos/mês para a _aceleração_ nessa frequência de atualização.

## Usar o Guia de decisão de caso

Vamos analisar em mais detalhes alguns arquetípicos comuns que ilustram como aplicar essa lógica.

- **O Arquétipo da "Fonte Única da Verdade": Centralizar e governar**
  - **Cenário:** Você precisa criar perfis compatíveis e unificados do _Customer 360_ para toda a sua empresa global. Os dados vêm de uma dúzia de sistemas diferentes, devem cumprir os rigorosos regulamentos _GDPR_ e _CCPA_, e servirão como fonte de verdade para todas as interações de marketing e serviço.
  - **Padrão recomendado:** **Ingestão de dados.** A prioridade aqui é governança, Trust e controle. Ingerir os dados no _Data 360_ é a única maneira de criar um perfil canônico totalmente auditável, isolado dos sistemas de origem.
- **O Arquiteto de Insights em tempo real: Analisar sem se mover**
  - **Cenário:** Sua equipe de ciência de dados precisa executar consultas exploratórias em uma tabela de transações maciça e constantemente atualizada no _Snowflake_. Ao mesmo tempo, sua equipe executiva quer um painel _BI_ ativo que seja alimentado pelos mesmos dados. Mover petabytes de dados por dia é lento e caro.
  - **Padrão recomendado:** **Federação de cópia zero.** A prioridade aqui é velocidade, agilidade e custo-benefício em escala. O _Zero Copy_ permite que você aproveite o poder do seu armazém de dados existente para consultas em tempo real sem sobrecarga e latência de duplicação de dados.
- **O Arquétipo de Inteligência Híbrida: Governar o núcleo, Federar a borda**
  - **Cenário:** Você deseja aprimorar seus perfis de cliente administrados e ingeridos com sinais comportamentais em tempo real (por exemplo, cliques no site) de um data lake. Você precisa da estabilidade do perfil principal, mas da imediatez dos dados ativos para habilitar a personalização no momento.
  - **Padrão recomendado:** **Uma abordagem híbrida.** Use a _Ingestão de dados_ para criar um núcleo estável e regulado para seus dados do cliente. Use a _Cópia zero_ para federar os dados de "frente" em tempo real e voláteis e, em seguida, uní-los no momento da consulta para obter uma visualização completa até o segundo.

## O caminho para frente

A estratégia de dados corporativos não é mais focada na escolha de um único padrão de integração, é sobre arquitetar flexibilidade controlada em um ecossistema de dados interoperável. A abordagem correta mapeia cada sistema de origem para o padrão mais adequado aos requisitos de atualidade, governança, custo e acesso:

- Ingira conjuntos de dados regulados essenciais para a missão no Salesforce _Data Cloud_ para conformidade, resolução de identidade e fluxos de trabalho operacionais.
- Federar dados por meio da _Cópia zero_ para análise ativa, exploratória e orientada por IA sem armazenamento duplicado.
- Aplicar _cache (consulta acelerada)_ para reduzir a carga do sistema de origem e o consumo de crédito quando a frequência de consulta é alta e a frequência de alteração de dados é baixa

O Salesforce _Data 360_ no _Hyperforce_ oferece resiliência e escalabilidade multi-região. Sua casa de lago aberto com mesas _Iceberg_ permite a separação de computação e a interoperabilidade com plataformas como _Snowflake_, _Databricks_ e _S3 Iceberg, que_ constitui a espinha dorsal de um ecossistema de dados multi-nuvem verdadeiramente interoperável.

Conforme os ecossistemas de dados evoluem, precisamos equilibrar continuamente a atualidade, o custo, o desempenho e a conformidade para manter a agilidade arquitetônica. É por isso que é importante preparar sua plataforma para o futuro unificando dados ingeridos e controlados com acesso federado. Isso habilita a inteligência em tempo real, a ativação de IA e a personalização em escala corporativa em nuvens, regiões e domínios de negócios.

Lembre-se de que soluções unidimensionais para todos não são adequadas à maioria das empresas. A estratégia ideal mapeia o padrão correto para o motor de negócios correto.

## Sobre os autores

**Yugandhar Bora** é um arquiteto de engenharia de software na Salesforce que é especialista em arquitetura de dados na plataforma de aplicativos de dados e inteligência. Ele lidera iniciativas do _Corpo de Revisão de Arquitetura Empresarial (EARB)_ que se concentram na governança de dados e modelos de dados unificados, além de contribuir para soluções de provisionamento de plataforma automatizadas.

**Jan Fernando** é um arquiteto principal no _Office of Chief Architect (OCA)_ da Salesforce que entrou para a Salesforce em 2012\. Ele traz uma rica experiência de sua época no ecossistema de startups. Antes de ingressar na OCA, ele passou mais de uma década na organização da _Plataforma_, onde liderou várias transformações tecnológicas importantes.

<!-- document id=a12562baf988b2b56447fcd8a3e7815abdb14fe34b0c8fb5e32a44a08f2bd2fe url=/architect/current/pt-br/decision-guides/guides/get-started-platform-decision-guides.md -->

# Introdução aos guias de decisão da plataforma

Esta seção fornece orientação prática para tomar decisões arquitetônicas essenciais sobre os recursos da Salesforce Platform. Ele abrange processamento assíncrono, eventos acionados por registro, criação de formulário, automação de fluxo de trabalho agente e tradicional, arquitetura conduzida por evento e estruturas assíncronas baseadas em etapa para ajudar os arquitetos a projetar soluções de plataforma escalonáveis, manejáveis e de alto desempenho.

---

## Processamento assíncrono

O [Processamento assíncrono](/docs/architect/pt-br/decision-guides/guide/async-processing) fornece orientação sobre ferramentas e abordagens para operações assíncronas no Salesforce:

- **Ferramentas de processamento assíncrono**: Comparação de Apex enfileirável, Apex agendado, acionadores de evento de plataforma, captura de dados de alteração, caminho agendado (depois de fluxos de confirmação) e caminho assíncrono (fluxos acionados por registro), com orientação sobre casos de uso apropriados.
- **Processamento assíncrono no lado do servidor**: Padrões para operações de banco de dados de execução longa, chamadas externas e processamento de registro de grande volume.
- **Processamento assíncrono do lado do cliente**: Técnicas como Chamadas de continuação do Apex e processamento assíncrono no lado do cliente que podem ser executadas em navegadores ou aplicativos móveis.
- **Quadro de Decisão**: Considere a validação de caso de uso, a escalabilidade, a compreensão de quando as transações são verdadeiramente assíncronas, o monitoramento e o tratamento de eventos de carga extrema.
- **Práticas recomendadas e antipadrões**: Orientação para o uso adequado, incluindo integrações de saída, monitoramento e evitar armadilhas comuns.

Permite que os arquitetos implementem padrões assíncronos escalonáveis, confiáveis e mantidos, evitando armadilhas que comprometem o desempenho.

---

## Formulários de construção

O [Building Forms](/docs/architect/pt-br/decision-guides/guide/build-forms) orienta os arquitetos sobre as opções de criação de formulário do Salesforce:

- **Fórmulas de construção**: Comparação de Formulários dinâmicos, Fluxo de tela, OmniStudio, Fluxo de tela com Componentes da Web Lightning (LWC) e LWC, incluindo habilidades e considerações de licenciamento.
- **Quadro de Decisão**: Considere o impacto do objeto, o escopo do formulário, a navegação, o local (aplicativo, dispositivo móvel, Web), a UX e a automação de teste.
- **Orientação de seleção de ferramentas**: Recomendações de layouts de registro simples a assistentes de várias páginas e formulários voltados para o cliente com marca.
- **Padrões de combinação**: Orientação para combinar ferramentas, por exemplo, navegação de Fluxo de tela com estilo do LWC.
- **Recursos avançados**: Aprofunde-se em recursos e limitações para informar a escolha de ferramentas.

Ajuda os arquitetos a selecionar a abordagem de criação de formulário certa para seus requisitos de UX, funcional e de integração específicos.

---

## Determinação da automação de fluxo de trabalho agente e tradicional

[Determining Agentic and Traditional Workflow Automation](/docs/architect/pt-br/decision-guides/guide/determining-agentic-vs-traditional-workflow-automation.html) fornece uma estrutura para escolher entre automação tradicional e Agentforce usando a estrutura Densidade de orquestração:

- **Orquestração Densidade Estrutura**: Avalia a complexidade da automação com base no caminho de execução (totalmente especificável vs. não especificável), na complexidade da meta (tarefa única vs. metas concorrentes) e na combinação de modalidades (entrada estruturada vs. multimodal).
- **Paisagem do produto**: Comparação de fluxos, Apex, Agentforce, Agent Script, Agentforce Grid, Agentforce Operations e MuleSoft para diferentes cenários de automação.
- **Matriz de seleção de densidade**: Mapeie os níveis de densidade da orquestração (baixo, médio e alto) para padrões arquitetônicos, da automação acionada por registro à orquestração híbrida ao determinismo guiado com o script do agente.
- **Quadro de Decisão**: Processo de avaliação sequencial – inspecione primeiro o caminho de execução, depois a complexidade da meta e depois a combinação de modalidades – para determinar a ferramenta certa.
- **Usar orientação de caso**: Recomendações específicas para automação tradicional (baseada em regras, determinística), Agentforce Grid (tarefas de IA em massa), orquestração híbrida (processos complexos de ponta a ponta) e Agent Script (pontos de entrada não estruturados com necessidades de raciocínio).

Permite que os arquitetos tomem decisões bem informadas em todo o espectro de automação, equilibrando os recursos de raciocínio com controle determinístico para soluções escalonáveis, auditáveis e manejáveis.

---

## Arquitetura conduzida por evento

A [Arquitetura conduzida por evento](/docs/architect/pt-br/decision-guides/guide/event-driven) fornece um guia abrangente para ferramentas e padrões do Salesforce Eventing:

- **Ferramentas para Eventos**: Visão geral de Eventos de plataforma, Captura de dados de alteração, API Pub/Sub, MuleSoft Anypoint, API de streaming e considerações de integração.
- **Padrões conduzidos por evento**: Inclui padrões de publicação/assinatura, efetuação, mensagens passadas, streaming e enfileiramento para vários casos de uso conduzidos por evento.
- **Integração com MuleSoft**: Usar conectores do Anypoint (Pub/Sub, JMS, Kafka, Solace, MQ, MQTT, AMQP) para arquiteturas empresariais.
- **Eventos de plataforma e captura de dados de alteração**: Orientação sobre mecanismos preferenciais para publicar alterações de registro e campo, com migração de Eventos PushTopic/Generic.
- **Padrões de implementação**: Práticas recomendadas para escalabilidade, consistência, tratamento de erros e monitoramento.

Permite que os arquitetos projetem sistemas escalonáveis conduzidos por evento quase em tempo real que conectam vários sistemas de modo eficiente.

---

## Estrutura assíncrona baseada em etapas

O [Step-Based Async Framework](/docs/architect/pt-br/decision-guides/guide/step-based-async-framework) fornece uma estrutura para processamento de trabalho assíncrono modular e escalável:

- **Arquitetura de estrutura**: Os componentes incluem Apex enfileirável, finalizadores, fluxo agendado, cursores do Apex, ações invocáveis e integrações do Slack.
- **Processamento baseado em etapas**: Divide o trabalho em etapas independentes que podem ser executadas, tentadas novamente e reiniciadas com governança compartilhada e visibilidade operacional.
- **Orientação de Aplicação**: Padrões para interface de etapa, Processador de etapa, Camada invocável do Apex, tratamento de atraso e notificações.
- **Práticas recomendadas**: Recomendado quando a maioria das informações existe no CRM, para cargas de trabalho de alto volume e processamento de registro hierárquico ou baseado em árvore; orientação sobre quando não usar.
- **Recursos empresariais**: Governança, conformidade, estado distribuído, rastreamento de progresso, monitoramento de SLA, diagnóstico de falha e registro em nível de auditoria.

Fornece aos arquitetos uma alternativa escalonável a trabalhos em lote monolíticos e chamadas assíncronas encadeadas, oferecendo suporte a cargas de trabalho do Salesforce de alto volume com transparência operacional total.

---

## Automação acionada por registro

A [Automação acionada por registro](/docs/architect/pt-br/decision-guides/guide/record-triggered) fornece a estrutura para projetar a automação acionada por registro na Salesforce Platform:

- **Seleção de ferramentas**: Quando usar o Fluxo acionado por registro versus acionadores do Apex, guiado pela densidade de automação (baixo, médio, alto) e pela matriz de seleção de densidade.
- **Densidade de automação**: Como avaliar a quantidade de automação, o volume de registros e a disseminação de dependência para escolher Fluxo, fluxo híbrido (Fluxo com Apex invocável) ou acionadores do Apex.
- **Ponto de entrada e governança**: Um ponto de entrada por objeto do Salesforce; orientação sobre condições de entrada, controle de recursão e execução ordenada.
- **Invocação assíncrona**: Quando e como invocar processos assíncronos de fluxos acionados por registro ou Apex, com cuidado em relação ao tratamento de erros e limites do regulador.
- **Práticas recomendadas**: Padrões para massificação, design de Fluxo híbrido – Apex e evitar armadilhas comuns na automação do acionador.

Permite que os arquitetos projetem automação acionada por registro dimensionável, manejável e de desempenho alinhada aos padrões de plataforma.

<!-- document id=7cbc98eb4e00e24d27cd7f0b9f79aa64a861baec23dda573e6ec0e03a8621594 url=/architect/current/pt-br/decision-guides/guides/get-started-integration-decision-guides.md -->

# Introdução aos guias de decisão de integração

Esta seção fornece orientação prática para escolher as ferramentas e abordagens de integração de dados certas para o Salesforce. Ele abrange integrações de saída, integrações de entrada e cenários organizacionais cruzados, ajudando os arquitetos a projetar e implementar integrações de camada de dados que balanceiam desempenho, capacidade de manutenção e custo.

---

## Integração de dados com o Salesforce

A [Integração de dados com o Salesforce](/docs/architect/pt-br/decision-guides/guide/data-integration) apresenta uma visão geral abrangente das melhores práticas e ferramentas de integração de dados do Salesforce:

- **Paisagem de ferramentas de integração**: Visão geral das ferramentas de integração de dados do Salesforce, incluindo opções de código baixo, híbridas e de código profissional, com orientação sobre a seleção da ferramenta certa para casos de uso específicos.
- **Integrações de saída**: Métodos para enviar dados do Salesforce para sistemas externos, incluindo captura de dados, Serviços externos, Heroku Connect, Procedimentos de integração do OmniStudio, Salesforce Connect, MuleSoft Anypoint e soluções personalizadas do Apex.
- **Integrações de entrada**: Abordagens para trazer dados externos para o Salesforce, com orientação sobre replicação de dados versus virtualização e quando usar cada ferramenta.
- **Integrações entre organizações**: Métodos recomendados para compartilhar dados entre organizações do Salesforce, incluindo MuleSoft Anypoint, Heroku Connect, APIs nativas do Salesforce, Captura de dados de alteração e Salesforce Connect com adaptador entre organizações, incluindo orientação para substituir implementações legadas do Salesforce para Salesforce.
- **Quadro de Decisão**: Considerações importantes para selecionar ferramentas de integração, como ferramentas e paisagem existentes, requisitos de fluxo de dados (tempo, direcionalidade, experiência do usuário esperada), complexidade da implementação, capacidade de manutenção, volume de dados e limites da plataforma.

Permite que os arquitetos escolham as ferramentas e os padrões de integração certos para cada cenário, minimizando a replicação de dados desnecessária, aproveitando soluções ESB/ETL existentes e garantindo integrações dimensionáveis e manejáveis alinhadas aos princípios da arquitetura corporativa.

<!-- document id=1c5812bd23a5a6a25d987db00575b30f0114d13324234158a5753bd17b5d666a url=/architect/current/pt-br/decision-guides/guides/get-started-data-360-decision-guides.md -->

# Introdução aos guias de decisão do Data 360

Esta seção fornece orientação prática para tomar decisões arquitetônicas essenciais sobre o Salesforce Data 360, incluindo estratégias de provisionamento, conectividade de várias organizações e padrões de integração. Use esses guias para projetar e implementar arquiteturas de dados eficientes que unificam dados do cliente e habilitam recursos desenvolvidos com IA.

---

## Provisionamento do Data 360

O [Data 360 Provisioning](/docs/architect/pt-br/decision-guides/guide/data-360-provisioning) abrange decisões fundamentais ao provisionar o Salesforce Data 360:

- **Home Organização Seleção**: Decida se deseja provisionar o Data 360 em uma organização de produção existente ou criar uma organização dedicada, considerando a governança, a conformidade e o tempo de valorização.
- **Estratégia de várias organizações**: Escolha entre várias instâncias independentes do Data 360 ou use o Data Cloud One para unificar várias organizações do Salesforce, equilibrando a autonomia, a conformidade e o custo.
- **Arquitetura Data Cloud One**: Habilite várias organizações parceiras para compartilhar uma única instância do Data 360 com governança centralizada, compartilhamento de metadados e paridade de recursos entre organizações.
- **Compartilhamento de dados entre organizações do Data 360**: Use o compartilhamento de dados de cópia zero entre instâncias independentes para conformidade regional, colaboração da unidade de negócios ou painéis executivos federados.
- **Considerações sobre provisionamento**: Fatores na residência de dados, modelos de governança, latência, complexidade da integração, custo e prontidão de IA para implantações corporativas.

Ajuda os arquitetos a projetar estratégias de provisionamento que garantem simplicidade, consistência corporativa, conformidade e escalabilidade para Customer 360, IA e inovação entre plataformas.

---

## Interoperabilidade do Data 360

A [Interoperabilidade do Data 360](/docs/architect/pt-br/decision-guides/guide/data-360-interoperability) fornece uma estrutura para integrar o Data 360 a plataformas externas e data lakes:

- **Padrões de ingestão de dados**: Tempo real, streaming e ingestão em lote para criar conjuntos de dados canônicos gerenciados ideais para Customer 360, conformidade e governança centralizada.
- **Federação de dados de cópia zero**: Consultas ao vivo, consultas aceleradas (cache) e métodos de federação de arquivos para acessar sistemas externos em tempo real sem duplicação, habilitando personalização, painéis e cargas de trabalho de IA/ML.
- **Abordagem híbrida**: Combine ingestão governada para conjuntos de dados principais com federação de cópia zero para atualização e escalabilidade, com suporte para engajamento do Omni-Channel, ações conduzidas pelo Agentforce e análise corporativa.
- **Quadro de Decisão**: Avalie compensações em latência, custo, escalabilidade, governança e complexidade para selecionar o padrão de integração certo por fonte de dados.
- **Architect Playbooks**: Diretrizes específicas do setor, práticas de design e considerações de custo para cenários financeiros, de saúde, de varejo e de telecomunicações.

Orienta os arquitetos no equilíbrio entre a atualidade dos dados, a governança e a eficiência do pipeline para criar arquiteturas de dados escalonáveis, interoperáveis e prontas para IA que dão suporte a cargas de trabalho operacionais e analíticas.

<!-- document id=5b270e7348bc8b79f024a36331f6fc5bf4e988a43ef081bdab3f40451fb279da url=/architect/current/pt-br/decision-guides/guides/async-processing.md -->

# Processamento assíncrono

Use este guia para escolher a abordagem de processamento assíncrono do Salesforce certa para cada caso de uso.

## Visão geral do guia

Este guia vai ajudá-lo a avaliar a abordagem certa para seus requisitos de processamento assíncronos na Salesforce Platform. Ele explica cada abordagem, detalhando os pontos fortes e as limitações de cada uma. A maioria das abordagens está alinhada a um recurso de produto, mas algumas abordagens usam vários recursos em coordenação. O guia inclui casos de uso para destacar quando usar cada abordagem.

O processamento assíncrono oferece dois benefícios importantes para sua arquitetura. Primeiro, ele aumenta a escalabilidade porque os processos assíncronos têm limites de controlador maiores. Segundo, as solicitações assíncronas são executadas em seus próprios threads para que os usuários possam fazer outro trabalho enquanto as tarefas assíncronas são executadas em segundo plano.

Observe que este guia se concentra exclusivamente na escolha de uma tecnologia de processamento assíncrona na Salesforce Platform. Outros recursos para ajudar seu processo de decisão são listados na [seção Recursos](#recursos).

## Produtos no escopo deste guia

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://a.sfdcstatic.com/developer-website/prod/images/architect/salesforce.svg" alt="Plataforma Salesforce"></td>
      <td>A <a href="https://www.salesforce.com/platform/agentforce-platform">Salesforce Lightning Platform</a> é uma plataforma abrangente baseada em IA que une funcionários, agentes de IA autônomos, dados da empresa e aplicativos em um único sistema confiável para aumentar a produtividade e a experiência do cliente. Ele permite a criação de uma "empresa ativa" conectando os aplicativos Customer 360, o Data Cloud e o Slack para automação completa.</td>
    </tr>
  </tbody>
</table>

Este documento não abrange tecnologias em outros ecossistemas, como MuleSoft, Informatica, Commerce Cloud, Tableau e Marketing Cloud.

## Capturas

- **Antes de usar o processamento assíncrono, certifique-se de que seus casos de uso se encaixam no padrão.** Os padrões assíncronos não têm SLA, estão sujeitos a vários mecanismos de controlador, podem ter limites de capacidade definidos com base no licenciamento e podem causar atrasos de processamento devido à natureza finita dos recursos alocados à infraestrutura assíncrona na Salesforce Platform. Considere essas limitações ao usar processamento assíncrono em cenários em que um usuário precisa de uma resposta do sistema antes de continuar o trabalho.
- **O processamento assíncrono com o Salesforce não é uma solução para necessidades de escala ilimitadas.** A Salesforce Platform não é dimensionada de modo infinito e os padrões assíncronos estão sujeitos a limitações. O processamento assíncrono usa threads, que contêm as informações contextuais de que uma CPU precisa para executar um fluxo de instruções. Os threads podem ser executados em paralelo. O número de threads disponíveis em qualquer CPU é limitado, portanto, a plataforma tem mecanismos em vigor para usar seus threads disponíveis da maneira mais eficiente possível. O [mecanismo de controle de fluxo](/docs/architect/pt-br/fundamentals/guide/async-fundamentals#controle-de-fluxo) da plataforma impede que as organizações consumam fitas demais e afetem negativamente outras organizações. O [algoritmo de uso justo](/docs/architect/pt-br/fundamentals/guide/async-fundamentals#uso-justo) da plataforma também controla o número de threads que uma organização tem disponíveis para cada tipo de mensagem específico.
- **Tome em conta os eventos que podem causar cargas extremas.** Ao projetar processos assíncronos, certifique-se de que eles possam gerenciar de modo previsível picos e lacunas da carga de trabalho. Considere como sua implementação lida com eventos inesperados, como falhas de energia, e projete proteções que mitiguem a perda de dados ou a perda de funcionalidade.

## Comparação de produto

Esta tabela descreve as ferramentas disponíveis para processamento assíncrono com o Salesforce. Consulte esta tabela para revisar as principais características de cada ferramenta durante o processo de tomada de decisão. Consulte [Usar casos](#casos-de-uso) e [pontos de decisão](#pontos-de-decisão) para obter ajuda na escolha das ferramentas certas para sua arquitetura.

<table style="border-color:white;overflow-x:scroll;">
  <thead>
    <tr>
      <th>Abordagem</th>
      <th>Descrição</th>
      <th>Habilidades necessárias</th>
      <th>Licenças e limites</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Apex enfileirável</b></td>
      <td>Use para processos que envolvem operações de banco de dados de execução longa ou chamadas de serviço da Web externo. O Apex enfileirável oferece recursos como IDs de trabalho, suporte para tipos não primitivos e encadeamento de trabalho.</td>
      <td>Código profissional</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">O número de licenças pode aumentar os limites.</a></td>
    </tr>
    <tr>
      <td><b>Apex de lote</b></td>
      <td>Crie processos complexos de longa duração que envolvem milhões de registros dividindo seu conjunto de registros e processando-o em partes gerenciáveis.</td>
      <td>Código profissional</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">O número de licenças pode aumentar os limites.</a></td>
    </tr>
    <tr>
      <td><b>Apex agendado</b></td>
      <td>Execute o Apex em um horário agendado definido por uma expressão cron. Embora o ato de agendar o Apex por meio da expressão cron seja um processo assíncrono, o código subjacente é executado de forma síncrona quando o trabalho é iniciado.</td>
      <td>Código profissional</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm">O número de licenças pode aumentar os limites.</a></td>
    </tr>
    <tr>
      <td><b>Chamadas de continuação do Apex</b></td>
      <td>Execute chamadas de métodos do Apex em execução em um contexto de transação síncrona.</td>
      <td>Código profissional</td>
      <td>Não</td>
    </tr>
    <tr>
      <td><b>Caminho assíncrono (fluxos acionados por registro)</b></td>
      <td>Execute uma operação que você deseja executar em seu próprio horário. Evite erros DML mistos que ocorram quando você atualiza um valor em um registro relacionado que não faz parte do registro que acionou um fluxo.</td>
      <td>Código baixo</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">O número e o tipo de licenças podem aumentar os limites.</a></td>
    </tr>
    <tr>
      <td><b>Caminho agendado (depois de fluxos de confirmação)</b></td>
      <td>Execute em um horário dinamicamente agendado após um evento acionador, como quando um registro é criado, atualizado ou excluído.</td>
      <td>Código baixo</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">O número e o tipo de licenças podem aumentar os limites.</a></td>
    </tr>
    <tr>
      <td><b>Fluxos agendados</b></td>
      <td>Execute um fluxo em segundo plano em um horário especificado e com uma frequência repetida (diária, semanal ou uma vez) para realizar ações em um lote de registros.</td>
      <td>Código baixo</td>
      <td><a href="https://help.salesforce.com/s/articleView?id=platform.flow_considerations_limit.htm&type=5">O número e o tipo de licenças podem aumentar os limites.</a></td>
    </tr>
    <tr>
      <td><b>Acionadores de evento de plataforma</b></td>
      <td>Combine o Salesforce com sistemas externos e se comunique entre componentes assíncronos dentro da Salesforce Platform.</td>
      <td>Código inferior + Código profissional</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm">Uma licença complementar é necessária para casos de uso de evento de plataforma de alto volume</a></td>
    </tr>
    <tr>
      <td><b>Captura de dados de alteração</b></td>
      <td>Capture e processe eventos de alteração de modo assíncrono após a transação do banco de dados ser confirmada.</td>
      <td>Código profissional</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm">Uma licença complementar é necessária para escalar acima da alocação de linha de base.</a></td>
    </tr>
    <tr>
      <td><b>API em massa</b></td>
      <td>Insira, atualize, insira e atualize, consulte ou exclua muitos registros de modo assíncrono e processe os resultados mais tarde.</td>
      <td>Código profissional</td>
      <td><a href="https://developer.salesforce.com/docs/atlas.en-us.260.0.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_bulkapi.htm">Há limites.</a></td>
    </tr>
    <tr>
      <td><b>Ações do Lightning</b></td>
      <td>Permita que as páginas do Lightning interajam com o servidor sem forçar os usuários a atualizar completamente a página.</td>
      <td>Código baixo</td>
      <td>Não</td>
    </tr>
  </tbody>
</table>

## Pontos de decisão

Esta tabela contém uma visão geral dos pontos a serem considerados ao decidir qual ferramenta assíncrona usar.

<table>
  <tbody>
    <tr>
      <td><b>Habilidades necessárias</b></td>
      <td>Algumas das ferramentas descritas neste guia exigem código, enquanto outras podem ser configuradas declarativamente. Ao considerar suas opções, pense nos conjuntos de habilidades que os membros da sua equipe têm. Lembre-se de que, mesmo que os desenvolvedores estejam disponíveis para sua implementação inicial (por meio de um parceiro de implementação, por exemplo), talvez você precise modificar suas soluções no futuro. Se a sua equipe de manutenção não tiver desenvolvedores, uma opção com pouco código poderá ser mais adequada.</td>
    </tr>
    <tr>
      <td><b>Tipo de limites de plataforma aplicados</b></td>
      <td>Determine o tipo de <a href="https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm">limite</a> que se aplica à execução. Conforme você projeta suas soluções, pense cuidadosamente em como o volume e a frequência das transações contam para os limites do regulador para a abordagem escolhida a cada dia. Calcule o número de execuções que ocorrerão a cada dia. Certifique-se de que os valores calculados estejam dentro dos limites associados às ferramentas selecionadas.</td>
    </tr>
    <tr>
      <td><b>Latency</b></td>
      <td>Determine a rapidez com que os resultados do processamento estarão disponíveis na plataforma. Para algumas abordagens, as alterações serão quase imediatas, enquanto para outras podem ser minutos ou horas.</td>
    </tr>
  </tbody>
</table>

## Casos de uso

Ao selecionar uma ferramenta para processamento assíncrono, primeiro avalie os requisitos e os recursos disponíveis da sua organização. Sua meta é selecionar a ferramenta ou ferramentas que minimizam os custos de implementação e manutenção, mas ainda garantem a escalabilidade e minimizam a probabilidade de violações de limite. Essa meta depende das considerações técnicas descritas anteriormente, bem como da composição da sua equipe.

Considere um processo de pedido assíncrono no Salesforce. Quando um pedido é salvo, ele aciona uma mensagem para um sistema de gerenciamento de armazém externo com instruções especiais sobre como empacotar e enviar um item. O usuário que faz o pedido não precisa de uma resposta imediata do sistema de gerenciamento de armazém, portanto, a solicitação pode ser enviada de modo assíncrono. O processamento assíncrono permite que o usuário continue seu trabalho sem esperar uma resposta.

Para esse caso de uso, você pode considerar implementar com Apex. Essa abordagem funcionará apenas se você tiver desenvolvedores do Apex em sua equipe que possam manter sua solução de código profissional. Caso contrário, uma abordagem declarativa faz mais sentido. Lembre-se também de que diferentes conjuntos de [limites](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) se aplicam a diferentes ferramentas.

Esta tabela lista casos de uso comuns na coluna mais à esquerda, seguidos por uma descrição. A coluna _Primeira escolha_ fornece a abordagem mais típica usada para satisfazer esse caso de uso, junto com a justificação para a abordagem Primeira escolha. Use isso como ponto de partida em sua análise. A abordagem Primeira opção pode ter limitações que não funcionarão para seu caso de uso.

<table>
  <thead>
    <tr>
      <th>Caso de uso</th>
      <th>Descrição</th>
      <th>Abordagem de primeira escolha</th>
      <th>Racionalidade</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><b>Processamento em lote de alto desempenho</b></td>
      <td>Qualquer automação que precise processar milhares ou milhões de registros de maneira eficiente</td>
      <td>Lote <b>Apex</b></td>
      <td>O Apex em lote fornece APIs avançadas para interface com a plataforma e velocidade bruta.</td>
    </tr>
    <tr>
      <td><b>Trabalho de limpeza de dados</b></td>
      <td>Um trabalho que é executado de rotina ou sob demanda que limpa dados. Exemplos incluem desduplicação, verificação de endereço ou consolidação de dados.</td>
      <td>Lote <b>Apex</b></td>
      <td>O Apex em lote fornece APIs avançadas para interface com a plataforma e velocidade bruta.</td>
    </tr>
    <tr>
      <td><b>Trabalho de totalização noturna</b></td>
      <td>Trabalho que calcula os dados de totalização no fim de um dia útil.</td>
      <td>Lote <b>Apex</b></td>
      <td>O Apex em lote fornece APIs avançadas para interface com a plataforma e velocidade bruta.</td>
    </tr>
    <tr>
      <td><b>Lógica acionada por registro</b></td>
      <td>Execute a lógica em resposta a uma atualização de registro.</td>
      <td><i>Varia</i></td>
      <td>Consulte nosso guia de decisão de companheiro, <a href="/docs/architect/pt-br/decision-guides/guide/record-triggered">Automação de eventos acionados por registro</a>. Inclui uma árvore de decisão para casos de uso assíncronos, incluindo Apex enfileirável, Apex em lote, Apex agendado, Fluxo agendado, Fluxos de caminho assíncrono e Captura de dados de alteração.</td>
    </tr>
    <tr>
      <td><b>Atualizações em cascata por meio de um gráfico de objeto</b></td>
      <td>Permite que a ação de salvar de um usuário seja concluída rapidamente, adiando atualizações em cascata a outros objetos para execução assíncrona.</td>
      <td><b>Apex</b> enfileirável</td>
      <td>O Apex enfileirável tem recursos poderosos de encadeamento que permitem que a lógica divida uma cadeia de atualizações em uma série de transações assíncronas.</td>
    </tr>
    <tr>
      <td><b>Processamento agendado específico do registro</b></td>
      <td>Automação em uma data dinâmica futura específica do registro (por exemplo, três dias antes de uma data de fechamento).</td>
      <td><b>Fluxo</b> com um caminho agendado</td>
      <td>Os caminhos agendados fornecem um poder exclusivo ao Fluxo, pois a plataforma gerencia automaticamente o agendamento, o cancelamento e o reagendamento desses caminhos se os dados do registro mudarem.</td>
    </tr>
    <tr>
      <td><b>Invocando vários serviços externos lentos em paralelo</b></td>
      <td>Durante uma execução síncrona, vários serviços externos são chamados em paralelo para otimizar o tempo de execução geral.</td>
      <td>Chamadas de continuação do <b>Apex</b></td>
      <td>Permitir que várias chamadas de execução lenta sejam executadas em paralelo minimiza o tempo geral para concluir o trabalho.</td>
    </tr>
    <tr>
      <td><b>Migração de dados de registros de um sistema externo</b></td>
      <td>Mova grandes quantidades de registros para a Salesforce Platform de um sistema externo. Um processo único ou agendado regularmente.</td>
      <td><b>Bulk</b> <b>API</b></td>
      <td>Essa é a abordagem mais eficiente e amigável para a migração de dados.</td>
    </tr>
    <tr>
      <td><b>Executar lógica adicional em um sistema externo</b></td>
      <td>Padrão de foco e esquecimento de notificar um sistema externo de um evento na plataforma, então permitindo que esse sistema processe o evento de modo assíncrono.</td>
      <td><b>Eventos de plataforma</b> ou <b>captura de dados de alteração</b></td>
      <td>Um modelo pub-sub funciona melhor aqui e permite que o sistema externo processe o evento quando ele estiver pronto. Consulte Arquitetura conduzida por <a href="/docs/architect/pt-br/decision-guides/guide/event-driven">evento</a> para obter mais detalhes sobre esse padrão.</td>
    </tr>
  </tbody>
</table>

A tabela Casos de uso é um guia para a abordagem mais adequada para cada caso de uso. No entanto, você precisará validar o quão bem a tecnologia Primeira escolha atende às necessidades específicas do seu caso de uso. Em particular, determine se a abordagem escolhida pode cumprir os limites do controlador para sua organização.

Depois de identificar uma abordagem candidata para seu caso de uso, o [Guia de Fundamentos de Processamento Assíncrono](/docs/architect/pt-br/fundamentals/guide/async-fundamentals) pode ajudar a verificar totalmente a solução.

## Recursos

Estes recursos adicionais podem ajudar no processo de decisão:

- Aprofunde-se em cada uma das tecnologias assíncronas da plataforma: [Fundamentos do processamento assíncrono](/docs/architect/pt-br/fundamentals/guide/async-fundamentals)
- Escolher entre Apex e Fluxo para acionadores de registro: [Automação de eventos acionados por registro](/docs/architect/pt-br/decision-guides/guide/record-triggered)
- Informações sobre padrões de integração assíncronos: [Arquitetura orientada por evento](/docs/architect/pt-br/decision-guides/guide/event-driven)

<!-- document id=d79e83987f1c14ae7ec12028cfe202d74e057551d97be56faae9734cf4dcf6ab url=/architect/current/pt-br/decision-guides/guides/data-360-provisioning.md -->

# Provisionamento do Data 360

O Salesforce Data 360 é uma plataforma de dados baseada no [Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/) que unifica dados do Salesforce e externos em uma visão clara, completa e confiável de 360 graus de cada cliente ou conta.

As empresas costumam operar várias organizações do Salesforce devido a fusões e aquisições, operações regionais, separação funcional ou por motivos históricos. Os arquitetos têm várias decisões sobre o Data 360 a tomar, todas afetando a governança, a conformidade, o custo, a latência e a capacidade da organização de dimensionar recursos de plataforma de IA e organizações cruzadas.

## Visão geral do guia

Este guia fornece uma estrutura para tomar decisões de provisionamento com o Data 360\. Essas decisões incluem:

- Selecionar uma única organização de origem versus uma configuração de várias organizações

- Provisionamento de várias instâncias independentes do Data 360

  - Usar o Data Cloud One para unificar organizações em uma única instância

  - Colabore entre instâncias independentes do Data 360 que usam compartilhamento de dados entre organizações do Data 360

O Data 360 é provisionado automaticamente em qualquer organização de produção que receba uma licença do Data 360. O Data Cloud One é a arquitetura de conectividade de várias organizações do Salesforce que permite que uma única organização inicial hospede a instância do Data 360, enquanto outras organizações do Salesforce se conectam como organizações companheiras. A escolha de qual organização possui a licença do Data 360 e, portanto, se torna uma organização inicial do Data 360 é uma decisão arquitetônica crítica com consequências de longo prazo.

Como você provisionar o Salesforce Data 360 é uma decisão arquitetônica fundamental. Ele determina como a empresa unifica dados do cliente, impõe governança e habilita recursos essenciais da plataforma, especialmente IA, Agentforce e análise em toda a organização. Ancorar um grupo de organizações em um único Data 360 fornece um modelo de dados unificado, uma governança centralizada e ativa a prontidão de IA corporativa. Organizações parceiras podem acessar metadados e recursos compartilhados como se os dados fossem locais. Por outro lado, várias instâncias independentes do Data 360 são adequadas quando requisitos regulatórios, de conformidade ou de autonomia impedem a centralização. O compartilhamento de dados entre organizações do Data 360 habilita a colaboração seletiva de cópia zero entre essas instâncias.

Essa decisão influencia quem controla a governança de dados, onde os dados estão, como os recursos da plataforma são habilitados e como futuras integrações e iniciativas de IA podem ser dimensionadas. Mesmo para organizações que não têm o Data 360 no momento, pode ser importante preparar suas arquiteturas para o futuro desenvolvendo uma estratégia para adicionar acesso ao Data 360 no futuro. Cada vez mais, os recursos do Salesforce em Vendas, Serviços, Marketing, Comércio, Indústrias e Agentforce são criados no Data 360\. As organizações que desejam usar esses recursos de plataforma devem provisionar o próprio Data 360 ou se conectar a um Data 360 compartilhado como organizações parceiras.

Este guia ajuda os arquitetos a projetar uma estratégia de provisionamento que equilibra simplicidade, consistência em toda a empresa, conformidade e escalabilidade, garantindo que a organização possa aproveitar com confiança o Data 360 para Customer 360, a IA e a inovação entre plataformas. Use este guia para determinar quais organizações exigem o Data 360 e se o Data Cloud One ou o compartilhamento de dados entre organizações do Data 360 devem ser usados. Essa estratégia estabelece uma base sólida para um futuro centrado no Data 360.

## Produtos no escopo

<table>
  <tbody>
    <tr>
      <td style="text-align:center;vertical-align:middle;border:none;padding:0.25rem 0"><!-- Image: Salesforce Platform logo --><img style="border:none;margin:2rem 0rem;width:52px;height:52px;object-fit:contain" src="https://architect.salesforce.com/ns-assets/logos/data360-logo.png" alt="Logo da Salesforce Platform"></td>
      <td>O Salesforce Data 360 é a plataforma de dados em larga escala em tempo real do Salesforce que harmoniza e unifica dados de qualquer origem (CRM, Web, móvel ou data lakes externos) em um único perfil de cliente acionável. Como um componente essencial da plataforma <a href="https://www.salesforce.com/products/what-is-customer-360/">Customer 360</a>, ele potencia a IA, a análise e as experiências personalizadas em vendas, serviços e marketing.</td>
    </tr>
  </tbody>
</table>

## Capturas

- **Todas as organizações devem planejar o acesso a uma instância do Data 360.** Cada organização deve hospedar uma organização inicial do Data 360 ou ser uma organização companheira conectada por meio do Data Cloud One.

- **Pense em toda a empresa, não organização por organização.** Evite decisões unilaterais de linha de negócios tomadas isoladamente. O ideal é que uma arquitetura corporativa ou um conselho de governança de dados decidam coletivamente sobre a estratégia de provisionamento. Sempre antecipe as necessidades futuras de IA e análise, que dependem de conjuntos de dados amplos e unificados.

- **Planeje a governança e a propriedade antecipadamente.** Decida se o Data 360 deve ser gerenciado centralmente (modelo do Centro de excelência) ou delegado às linhas de negócios. Defina papéis para administradores, equipes de segurança e leads de conformidade. Evite ambiguidade, pois a propriedade pouco clara pode ser problemática.

- **Lembre-se, o provisionamento está ligado à licença.** A organização em que a licença do Data 360 é adquirida determina onde o Data 360 é provisionado e o local dessa organização determina a região.

- **Entenda as considerações de suporte de fonte de dados.** Fique atento às regiões com suporte para várias nuvens públicas e fontes de dados de cópia zero. Além disso, determine se a conexão privada é necessária para sua condição de segurança se conectar a essas fontes de dados e se há suporte para conexões na região ou entre regiões.

- **Provisionamento baseado em se você tem uma organização única ou uma organização múltipla.** Para clientes de organização única, provisione o Data 360 em sua organização de produção existente para o tempo de valor mais rápido. Para clientes de várias organizações, minimize a complexidade criando o menor número possível de instâncias do Data 360, idealmente usando a configuração do Data Cloud One.

- **Use** **várias instâncias do Data 360 apenas quando necessário.** Várias instâncias devem ser usadas apenas quando exigidas por conformidade, residência ou autonomia organizacional. Nesses casos, use o [compartilhamento de dados](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5) entre organizações do Data 360 para habilitar a colaboração segura.

- **Configure o compartilhamento de dados entre organizações do Data 360 para colaboração, não para pipelines ETL personalizados.** Compartilhe objetos específicos (DMOs, percepções calculadas, segmentos) por meio de compartilhamentos de dados. Lembre-se de que as marcas não são compartilhadas e o consumo é faturado para a organização de origem.

- **Evite atalhos de curto prazo.** Não ative várias organizações do Data 360 para comprovação de conceitos (POCs) sem um plano de longo prazo. Alinhe pilotos e implantações iniciais à sua estratégia de provisionamento corporativo.

## Pontos de decisão

Avalie cada opção de provisionamento (escolhendo entre o Data Cloud One, o compartilhamento de dados entre organizações do Data 360 ou a designação da organização de origem) com base nessas considerações intersetoriais.

<table>
  <tr>
    <th>Consideração</th>
    <th>Por que é importante</th>
    <th>Cenários de exemplo</th>
  </tr>
  <tr>
    <td>Residência e conformidade de dados</td>
    <td>Determina onde os dados são armazenados e processados. Regras regulatórias podem exigir regiões específicas ou várias instâncias.</td>
    <td>Um banco global provisiona um locatário do Data 360 em uma organização do Salesforce geograficamente localizada em Frankfurt para conformidade com o GDPR. Eles provisionam outro locatário em uma organização na Virgínia para a divisão dos EUA.</td>
  </tr>
  <tr>
    <td>Governança e segurança</td>
    <td>Identifique um administrador e a propriedade do Data 360, incluindo gerenciamento de políticas e estratégias de delegação.</td>
    <td>Uma multinacional com TI central forte cria uma organização residencial dedicada gerenciada por um Centro de excelência.</td>
  </tr>
  <tr>
    <td>Autonomia vs. centralização</td>
    <td>Diferentes líderes podem querer uma propriedade separada dos dados. A autonomia favorece várias organizações do Data 360. A centralização favorece o Data Cloud One.</td>
    <td>Uma empresa de holding com subsidiárias independentes permite que cada BU execute seu próprio Data 360.</td>
  </tr>
  <tr>
    <td>Latência e desempenho</td>
    <td>Impacta a velocidade e a experiência da consulta, especialmente para organizações companheiras conectadas a um locatário do Data 360 entre regiões.</td>
    <td>Uma equipe de vendas em Londres que consulta dados de um locatário do Data 360 nos EUA pode ver uma latência maior.</td>
  </tr>
  <tr>
    <td>Complexidade da integração</td>
    <td>Mais locatários do Data 360 = mais pipelines, APIs e middleware. A consolidação simplifica a integração.</td>
    <td>Um varejista evita criar 10 pipelines ETL consolidando-os em uma configuração do Data Cloud One.</td>
  </tr>
  <tr>
    <td>Região da fonte de dados de cópia zero</td>
    <td>Os requisitos de acesso entre regiões para alguns conectores podem limitar a região ou o local da sua organização do Data 360.</td>
    <td>Uma empresa tem uma instância do Snowflake na região eu-west-1 da AWS. Eles podem usar o Zero Copy para federar dados em um Data 360 em sua região, mas não podem usar o Zero Copy para federar em um Data 360 na região dos EUA.</td>
  </tr>
  <tr>
    <td>Compatibilidade entre regiões da Conexão privada</td>
    <td>Às vezes, o suporte para Conexão privada depende de se a fonte de dados está na mesma região que o locatário do Data 360.</td>
    <td>Uma empresa tem uma instância do Snowflake na região aws-east-1 que deseja conectar ao Data 360 por meio de cópia zero. Eles só poderão estabelecer uma conexão de rede de Conexão privada se a organização inicial do Data 360 estiver na mesma região.</td>
  </tr>
  <tr>
    <td>Custo e licenciamento</td>
    <td>Cada locatário do Data 360 aumenta o custo. Consolidar em menos instâncias otimiza o gasto.</td>
    <td>Um provedor de saúde reduz os custos de licenciamento adotando o Data Cloud One em vez de várias instâncias independentes do Data 360.</td>
  </tr>
  <tr>
    <td>Escalabilidade futura</td>
    <td>As opções de provisionamento hoje estabelecem a base para o crescimento.</td>
    <td>Uma empresa de SaaS começa com uma única instância do Data 360, mas planeja expandir-se para o Data Cloud One à medida que adquire subsidiárias com organizações do Salesforce.</td>
  </tr>
  <tr>
    <td>Prontidão de IA corporativa</td>
    <td>Os recursos de IA e Agentforce exigem um locatário do Data 360 conectado em cada organização. As decisões de provisionamento afetam como os modelos de IA são treinados e ativados em toda a empresa.</td>
    <td>Uma empresa de serviços financeiros unifica dados no Data Cloud One para que seus modelos de IA do Einstein tenham acesso a dados de clientes em toda a empresa.</td>
  </tr>
</table>

## Casos de uso

Há três casos de uso principais que exigem decisões para o provisionamento do Data 360:

- Escolher a organização residencial
- Aplicar uma estratégia de várias organizações
- Compartilhamento de dados entre organizações do Data 360

### Escolher a organização residencial

Quando você compra uma licença do Data 360, a instância do Data 360 é provisionada na organização do Salesforce associada a essa licença. Essa organização é chamada de organização inicial do Data 360. A organização de origem é a âncora para sua instância do Data 360. Isso inclui:

- Gerenciamento de armazenamento e computação do Data 360 (na região selecionada no provisionamento).

- Aplicação de políticas de administração, governança e segurança

- Desempenho de ingestão de dados, harmonização, resolução de identidade, segmentação e ativação

Em cenários de várias organizações, a organização de origem gerencia a instância central do Data 360 para outras organizações "companheiras" do Salesforce.

**The Home Organisation:**

- Determina a localização geográfica da sua instância do Data 360.

- Determina quem é proprietário e administra sua instância do Data 360. Os administradores na sua organização inicial do Data 360 podem acessar todos os dados ingeridos no Data 360.

- Controla as conexões da organização companheira em uma configuração do Data Cloud One.

- Define a base para sua estratégia de dados corporativa. Alterá-la posteriormente é difícil e disruptiva.

Para obter mais informações sobre organizações iniciais do Data 360, consulte [Padrões e práticas de integração do Data 360](/docs/architect/pt-br/fundamentals/guide/data360_integration_patterns_and_practices).

#### Decisão: Organização existente ou nova organização como a organização inicial?

A primeira decisão importante é provisionar o Data 360 em uma organização de produção existente ou criar uma nova organização dedicada para atuar como a organização de origem.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data 360 Existing_Org_vs_New_Dedicated_Org.png" alt="Diagrama de decisão mostrando a organização existente vs. nova organização como organização inicial" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

**Opção A: Provisionar o Data 360 em uma organização** existente

**Funciona melhor para:** Clientes com uma única organização do Salesforce ou clientes de várias organizações que já têm uma organização centralizada importante em que a maioria dos processos de negócios é executada.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_an_existing.png" alt="Diagrama mostrando o provisionamento do Data 360 em organização existente" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

- **Prós:**

  - Caminho mais simples: O Data 360 é provisionado onde seus dados do CRM estão.

  - Acesso imediato aos dados locais de Vendas, Serviço e Marketing.

  - Nenhuma integração adicional é necessária.

  - Menos licenças e ambientes para gerenciar.

  - Acelera a adoção antecipada, pilotos e casos de uso de produção.

- **Contras:**

  - Pode herdar a governança ou o débito técnico de uma organização existente.

  - Se não existir uma única "organização principal", a seleção de uma poderá criar debates de propriedade.

  - Desempenho vinculado ao local da organização; pode não estar alinhado às necessidades de residência corporativas.

  - Se várias unidades de negócios usarem organizações diferentes, o provisionamento local poderá levar à fragmentação se não for combinado ao Data Cloud One.

**Exemplo:**

Uma empresa de SaaS com uma organização do Salesforce provisiona o Data 360 nessa organização para unificar dados de assinatura e suporte do cliente.

**Opção B: Provisionar o Data 360 em uma nova organização dedicada**

**Funciona melhor para:** Clientes com várias organizações do Salesforce que não conseguem se alinhar em uma única organização principal ou empresas com um forte modelo de Centro de excelência (CoE).

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies - Data360 DC_Home_as_new_dedicated_org.png" alt="Diagrama mostrando o provisionamento do Data 360 em uma nova organização dedicada" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

- **Prós:**

  - Limpe o quadro para governança, sem complexidades da organização herdadas.

  - Controle centralizado em várias linhas de negócios.

  - Flexibilidade para escolher uma região com base nas necessidades de conformidade.

  - Atua como uma organização de "atendimento compartilhado" neutra, não vinculada a uma unidade de negócios.

  - Configure para a arquitetura futura do Data Cloud One (organização inicial com várias organizações parceiras).

- **Contras:**

  - Os clientes devem licenciar uma nova organização do Salesforce na qual provisionar o Data 360.

  - Integração adicional necessária para conectar a organização a um Data 360 por meio de uma conexão de companheiro do Data Cloud One.

  - Pode adicionar sobrecarga administrativa (gerenciamento de usuários, segurança, identidade).

  - Tempo para obter valor mais lento em comparação ao provisionamento em uma organização de produção existente.

**Exemplo:**

Uma empresa multinacional de serviços financeiros cria uma organização de origem dedicada para provisionar o Data 360\. Todas as organizações de unidade de negócios (Retail, Wealth, Commercial Banking) se conectam como organizações companheiras por meio do Data Cloud One.

**Critérios de decisão**

<table>
  <tr>
    <th>Consideração</th>
    <th>Organização existente como organização inicial (padrão preferencial)</th>
    <th>Nova organização como organização residencial (alternativa)</th>
  </tr>
  <tr>
    <td>Simplicidade</td>
    <td>Cria na estrutura de dados e usuário existente para uma configuração mais rápida.<br> O Data 360 é integrado por padrão à organização inicial .</td>
    <td>Requer licenciamento e configuração de uma nova organização do Salesforce e sobrecarga administrativa adicional para gerenciá-la</td>
  </tr>
  <tr>
    <td>Tempo para valor</td>
    <td>Uso imediato de dados locais do CRM</td>
    <td>Rampas e integração mais lentas são necessárias.</td>
  </tr>
  <tr>
    <td>Governança</td>
    <td>Herda o modelo de governança básico da organização existente – usuários e conjuntos de permissões existentes (pode ser aceitável se a organização já é central ).</td>
    <td>Limpe o quadro para governança. Ideal para modelos conduzidos por COE.</td>
  </tr>
  <tr>
    <td>Conformidade</td>
    <td>Residência vinculada à região da organização existente</td>
    <td>Flexibilidade para selecionar uma região independente de organizações existentes</td>
  </tr>
  <tr>
    <td>Desempenho</td>
    <td>Melhor desempenho para consultas de CRM locais</td>
    <td>Dependendo da conectividade da organização companheira, esteja ela na mesma região ou entre regiões para as outras organizações</td>
  </tr>
  <tr>
    <td>Escalabilidade futura</td>
    <td>Funciona bem se combinado ao Data Cloud One. É mais difícil mudar mais tarde se a organização errada for escolhida</td>
    <td>Escala facilmente com o Data Cloud One. Projetado para neutralidade.</td>
  </tr>
  <tr>
    <td>Custo</td>
    <td>Custo incremental menor</td>
    <td>Sobrecarga maior de ambientes adicionais</td>
  </tr>
</table>

#### Recomendações

Como um princípio geral, use uma organização principal existente como sua organização de origem para minimizar o esforço inicial e acelerar a adoção. Crie uma nova organização inicial dedicada apenas se sua estratégia de governança ou conformidade de longo prazo precisar. Criar uma nova organização residencial dedicada é uma escolha comum para empresas maiores com um Centro de excelência (COE).

**Entorno da organização única**

Provisione o Data 360 em sua organização de produção existente. Isso maximiza a simplicidade e o valor imediato. Evita sobrecargas de integração desnecessárias.

**Entorno de várias organizações**

Prefira selecionar uma das suas principais organizações, geralmente aquela em que a maioria dos seus negócios é executada, ou a organização que atua como seu CRM centralizado, para atuar como a organização de origem. Isso reduz a complexidade, minimiza o trabalho de configuração e permite que você perceba o valor do Data 360 rapidamente. Usar uma organização principal existente também evita o custo e o esforço de integração de gerenciar um novo ambiente.

**Quando considerar uma nova organização residencial dedicada**

Criar uma organização de origem oferece flexibilidade e neutralidade, mas com um tempo de valor mais lento nestes casos.

- Se sua organização tiver um forte Centro de excelência (CoE) e quiser uma governança separada das organizações da unidade de negócios.
- Se nenhuma organização existente for adequada devido a conformidade ou restrições organizacionais.

### Aplicar uma estratégia de várias organizações

#### O desafio de várias organizações

As empresas costumam operar várias organizações do Salesforce, e isso não é um caso de ponta, mas a norma. Desde fevereiro de 2024, aproximadamente 19 mil clientes do Salesforce já executam mais de uma organização do Salesforce.

Por que isso acontece?

- **Adquisições e fusões:** As empresas recém-adquiridas trazem suas próprias instâncias do Salesforce.
- **Operações regionais:** Organizações separadas para a UE, América do Norte, Ásia-Pacífico e assim por diante, geralmente para cumprir as leis de residência de dados.
- **Separação funcional:** Diferentes unidades de negócios (por exemplo, Retail Banking, Wealth Management, Insurance) mantêm suas próprias organizações para autonomia.
- **Isolamento regulamentar ou de segurança:** Determinados setores exigem organizações lógicamente distintas por motivos de conformidade.
- **Motivos históricos ou técnicos:** Ao longo do tempo, os clientes acumulam organicamente várias organizações.

Cada motivo faz sentido individualmente, mas juntos eles criam fragmentação de dados. Sem uma camada unificadora, cada organização tem apenas uma visualização parcial do cliente.

O desafio arquitetônico: Como unificar dados entre organizações em uma única fonte da verdade enquanto respeita os requisitos de conformidade, governança e autonomia?

---

#### Data Cloud One

O Data Cloud One é a arquitetura de conectividade de várias organizações do Salesforce que permite que várias organizações do Salesforce compartilhem uma única instância do Data 360. É o padrão recomendado para empresas com várias organizações do Salesforce.

Em qualquer cluster do Data Cloud One, uma organização do Salesforce é designada como a organização de origem, que hospeda a instância do Data 360. Outras organizações do Salesforce se conectam como organizações companheiras, consumindo os dados unificados e metadados do Data 360 da organização de origem.

<img src="https://a.sfdcstatic.com/developer-website/prod/images/architect/df25_dc_images/Salesforce Org Strategies Data 360 DC One.png" alt="Diagrama mostrando a arquitetura do Data Cloud One" style="width:100%;border:1px solid #e5e5e5;margin-top:1rem;margin-bottom:1rem." />

**Como o Data Cloud One funciona**

- **Ingestão e unificação de dados (organização inicial)**

  - Todas as configurações de ingestão de dados (Salesforce CRM, origens externas, streaming, lote) ocorrem apenas na organização de origem.

  - O locatário do Data 360 vinculado à organização de origem realiza resolução de identidade, harmonização, modelagem e unificação em perfis de clientes confiáveis.

  - Administração, políticas de governança, marcação e mascaramento do Data 360 são aplicados centralmente na organização de origem.

- **Arquitetura de espaço de dados**

  - Na organização de origem, os dados são organizados em espaços de dados, que atuam como contêineres lógicos para dados, metadados e processos.

  - As empresas podem criar espaços de dados para marcas, regiões ou linhas de negócios.

  - Compartilhamento de espaço de dados: Na organização de origem, espaços de dados específicos são compartilhados seletivamente com organizações companheiras. Isso garante que apenas os dados relevantes (e metadados associados) fluam para as organizações certas.

- **Compartilhamento de metadados**

  Organizações parceiras recebem definições de metadados da organização de origem, incluindo objetos de modelo de dados (DMOs), esquema de perfil unificado, insights calculados, segmentos [e muito mais](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5). Eles aparecem nativamente dentro da organização companheira como se fossem ativos locais, mas estão vinculados à organização de origem.

- **Capacidades em organizações iniciais vs. organizações companheiras**
  O acesso ao recurso difere entre organizações iniciais e companheiras. Organizações parceiras não podem ingerir nem unificar dados e dependem da organização inicial para ingestão, modelagem e unificação. Organizações parceiras podem acessar dados do Data 360 para aprimorar recursos de plataforma desenvolvidos com o Data 360 e podem criar percepções, segmentos e fluxos locais com base nos dados compartilhados e confiáveis. Na visão futura, eles também podem acessar recursos de ativação.

<table>
  <tr>
    <th>Capacidade</th>
    <th>Organização residencial</th>
    <th>Organização de companheiro</th>
  </tr>
  <tr>
    <td>Conectar Configurar conectores, criar fluxos de dados, ingerir ou federar dados</td>
    <td>✅</td>
    <td>❌</td>
  </tr>
  <tr>
    <td>Harmonizar e unificar Criar e executar transformações de dados e resolução de identidade</td>
    <td>✅</td>
    <td>❌</td>
  </tr>
  <tr>
    <td>Governar Dados seguros com permissões e espaço de dados</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Crie segmentos, percepções e crie modelos do Einstein Studio</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Ativar ativações Everywhere, ações de dados</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Recursos da plataforma: Criador de prompts, fluxos, relatórios, aprimoramento [e muito mais] (https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&amp;type=5)</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
  <tr>
    <td>Recursos habilitados pelo Data 360: Centro de prospecção, recursos de Vendas e Service Cloud, Agentforce e muito mais</td>
    <td>✅</td>
    <td>✅</td>
  </tr>
</table>

- Paridade de recursos da **plataforma**
  Da perspectiva de usuários e criadores, depois que os metadados são compartilhados, há algumas diferenças funcionais entre organizações iniciais e companheiras em termos de uso de recursos da Salesforce Platform. A lista de recursos com suporte pode ser encontrada em [Recursos do Data 360 em organizações Companion](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5).

  - Os recursos de plataforma do Salesforce, como Fluxos, Relatórios, Criador de prompts, painéis e outras ferramentas nativas da plataforma, funcionam em organizações iniciais e companheiras assim que os metadados estiverem disponíveis.

  - Os recursos habilitados para o Data 360, como Agentforce, o Prospecting Center, os recursos Sales Cloud Einstein e os recursos de IA do Service Cloud, também funcionam perfeitamente em organizações de origem e companhias. Alguns recursos podem estar no caminho certo para alcançar a compatibilidade completa, mas a meta geral é ter a paridade de recursos entre organizações iniciais e companheiras para todos os recursos entre nuvens que dependem do Data 360.

- **Modelo de consumo**
  Todas as atividades da organização companheira (consultas, execuções de segmento, fluxos acionados pelo Data 360, uso de IA, registro da Camada de Trust do Einstein e assim por diante) consomem créditos do Data 360 da organização inicial. O consumo flui de uma só maneira: os créditos são centralizados, faturados e rastreados em relação à alocação de crédito da organização de origem. No entanto, você pode detalhar para ver quantos créditos cada organização individual usou na Digital Wallet.
- **Princípio de design: Estrutura horizontal**
  A construção horizontal no Data 360 é um princípio de design fundamental, implementado principalmente por meio do Data Cloud One, que permite que uma única instância do Data Cloud abranja várias organizações distintas do Salesforce CRM. A meta é que cada novo recurso liberado funcione em organizações iniciais e de companheiros sem configuração adicional. Essa funcionalidade garante que o Data Cloud One não seja apenas uma escolha de arquitetura de dados, mas um elemento fundamental da Salesforce Platform no futuro.

---

#### Decisão: Várias organizações de dados versus o Data 360 compartilhado (Data Cloud One)

Empresas com várias organizações devem escolher como e onde localizar o Data 360 em seu ecossistema. Eles querem provisionar organizações independentes do Data 360 em cada organização ou usar o Data Cloud One para unificar organizações em uma única organização de origem?

**Opção A: Várias organizações independentes do Data 360**

Cada organização do Salesforce provisiona sua própria instância do Data 360.

**Prós:**

- **Autonomia:** Cada unidade de negócios ou região controla o próprio Data 360.

- **Simplicidade dentro de cada organização:** Governança, segurança e personalizações são localizadas.

- **Conformidade regulatória:** Útil quando a separação regulatória rígida é necessária (por exemplo, os dados não devem cruzar fronteiras).

**Contras:**

- **Silos de dados:** Perfis unificados não podem ser alcançados entre organizações.

- **Custo maior:** Cada instância requer licenciamento, administração e integração. Os clientes acabam ingerindo os mesmos dados de origem várias vezes em várias organizações diferentes.

- **Trabalho duplicado:** A resolução, a segmentação e o aprimoramento de identidade devem ser repetidos em cada instância do Data 360.

**Opção B: Um cluster compartilhado do Data 360 (Data Cloud One Cluster)**

Um único Data 360 é provisionado em uma organização inicial, com outras organizações do Salesforce conectadas como organizações companheiras.

**Prós:**

- **Fonte Única da Verdade (SSOT):** Todas as organizações compartilham um modelo de dados unificado.

- **Eficiência de custo:** Gerencie apenas uma licença e uma infraestrutura do Data 360.

- **Governação unificada:** Políticas aplicadas centralmente, segurança e controles de conformidade.

- **Enriquecimento entre organizações:** Acesse perfis, percepções e segmentos harmonizados em organizações parceiras.

- **Prontidão de IA:** Um conjunto de dados corporativo permite um treinamento e ativação melhores de modelos de IA.

- **Prova futura:** Adicionar novas organizações de companheiro é simples, pois não há necessidade de novas organizações do Data 360.

**Contras:**

- **Preparação adicional:** Um Data 360 requer planejamento para conectividade organizacional organizacional.

- **Considerações de latência:** Organizações parceiras em diferentes regiões podem ver consultas mais lentas.

- **Governação complexa:** Se cada organização tiver diferentes necessidades de personalização, a governança detalhada poderá ser complexa.

**Opção C: Vários clusters do Data Cloud One**

**Às vezes**, governança, conformidade ou outros requisitos de negócios podem tornar imprático agrupar todas as organizações. Isso pode levar à necessidade de implementar uma solução híbrida na qual a empresa opera várias organizações do Data 360, cada uma das quais é a organização de origem para um cluster diferente de organizações companheiras.

**Exemplo:**

Uma corporação multinacional tem organizações do Salesforce em várias regiões, incluindo Europa, EUA e Ásia. Para cumprir as normas de residência de dados regionais, eles fornecem um Data 360 para cada região separada.

**Critérios de decisão**

<table>
  <tr>
    <th>Consideração</th>
    <th>Várias organizações independentes do Data 360</th>
    <th>Um Data 360 compartilhado (Data Cloud One)</th>
  </tr>
  <tr>
    <td>Autonomia</td>
    <td>Alta autonomia para cada organização ou unidade de negócios</td>
    <td>Governança centralizada, menos autonomia por organização</td>
  </tr>
  <tr>
    <td>Conformidade</td>
    <td>Útil quando a separação rígida é necessária (por exemplo, leis regionais)</td>
    <td>Funciona melhor quando a residência permite a centralização</td>
  </tr>
  <tr>
    <td>Custo</td>
    <td>Custos de licenciamento e administrador maiores</td>
    <td>Mais econômico; uma licença para muitas organizações</td>
  </tr>
  <tr>
    <td>Governança</td>
    <td>Fragmentado; as políticas diferem por organização</td>
    <td>Políticas centralizadas e consistentes entre organizações</td>
  </tr>
  <tr>
    <td>Silos de dados</td>
    <td>Cada organização com sua própria visualização Sem o Enterprise 360</td>
    <td>Conjunto de dados unificado, sem duplicação</td>
  </tr>
  <tr>
    <td>IA/Analytics</td>
    <td>Limitado aos dados de cada organização</td>
    <td>Modelos corporativos com maior precisão</td>
  </tr>
  <tr>
    <td>Complexidade</td>
    <td>Mais instâncias para gerenciar, mais integrações</td>
    <td>Arquitetura mais simples, menos peças móveis</td>
  </tr>
  <tr>
    <td>Desempenho</td>
    <td>Melhor para casos de uso organizacionais</td>
    <td>Potencial aumento na latência com acesso à organização companheira</td>
  </tr>
</table>

---

#### Recomendações

Padrão **preferido: Data Cloud One**

Para simplificar a governança e otimizar o custo em empresas com diversas organizações, use uma única organização de origem com organizações companheiras conectadas.

**Quando usar várias organizações do Data 360:** Use várias organizações do Data 360 apenas se a conformidade, a residência ou a autonomia organizacional o exigirem estritamente (por exemplo, se as operações europeias precisarem permanecer totalmente separadas das operações dos EUA devido a regulamentações).

**Como escolher a organização inicial no Data Cloud One:** Comece considerando uma das suas principais organizações, geralmente onde a maioria dos negócios é executada. O provisionamento do Data 360 lá pode minimizar a complexidade e maximizar o valor antecipado.

Considere criar uma organização inicial dedicada gerenciada por uma equipe de COE apenas se nenhuma organização existente for adequada.

**Princípio geral:**

Em ambientes de várias organizações, minimize o número de organizações do Data 360. Favorecer o Data Cloud One como padrão para reduzir a duplicação, habilitar a prontidão de IA e simplificar a governança.

### Compartilhamento de dados entre organizações do Data 360

#### A necessidade de compartilhamento de dados

Embora o Data Cloud One seja a abordagem recomendada para a maioria das empresas, há cenários em que os clientes devem provisionar várias instâncias do Data 360, incluindo:

- **Conformidade regional.** Um varejista multinacional fornece um Data 360 na UE e outro nos EUA. O compartilhamento de dados do Data 360-to-Data 360 permite que a empresa crie percepções com base em dados locais e ainda compartilhe a percepção com a sede dos EUA.
- **Colaboração de unidade de negócios.** Um conglomerado executa organizações separadas do Data 360 para varejo e seguro. O compartilhamento de dados entre organizações do Data 360 permite que os usuários acessem uma única fonte de dados autônoma sem mover nem copiar. Com o compartilhamento de dados entre organizações do Data 360, a organização de Seguro recebe o segmento "Cliente de alto valor" do varejo para campanhas de venda cruzada direcionadas.
- **Fusões e aquisições.** Uma matriz adquire uma subsidiária com seu próprio Data 360\. Com duas instâncias para gerenciar, reter silos de dados de curto prazo preserva a segurança de dados e a integridade de SSOT. Ao mesmo tempo, o compartilhamento de dados entre duas instâncias do Data 360 permite a colaboração necessária durante a transição.
- **Painéis executivos federais.** Uma distribuição multinacional entre continentes provisiona organizações individuais do Data 360 por região. Os executivos querem uma visualização de desempenho trimestral federada. Cada Data 360 regional compartilha percepções calculadas agregadas com uma "Organização executiva", habilitando relatórios corporativos.

#### Como o compartilhamento de dados funciona

Quando existem várias organizações do Data 360, a unificação entre elas não é automática. O compartilhamento de dados do Data 360 para Data 360 permite que os clientes compartilhem objetos específicos entre instâncias do Data 360 sem duplicação ou pipelines personalizados. É um mecanismo de compartilhamento de metadados de cópia zero projetado para colaboração entre organizações do Data 360.

- Cada Data 360 é provisionado em sua própria organização de origem.

- Os administradores podem criar um compartilhamento de dados, um agrupamento de objetos específicos que desejam compartilhar.

- O acesso aos dados selecionados é compartilhado com o Data 360 de uma organização de destino, em que os objetos aparecem como se fossem definidos localmente. Apenas o acesso é compartilhado, os dados subjacentes permanecem no Data 360 de origem.

- As marcas não são compartilhadas. Somente os objetos brutos são disponibilizados; a organização de destino deve reaplicar quaisquer marcas de governança, operacionais ou de IA conforme necessário.

#### Principais diferenças do Data Cloud One

- No Data Cloud One, várias organizações companheiras compartilham uma única instância do Data 360. Para garantir a consistência, recursos de plataforma, como Agentforce, Prospecting Center e Tableau Next, são executados nos mesmos dados subjacentes.

- Ao usar o compartilhamento de dados entre organizações do Data 360, cada organização tem seu próprio Data 360\. Recursos como Agentforce na organização A e na organização B funcionam separadamente em sua instância local. Nenhum compartilhamento ocorre automaticamente – compartilhamentos de dados deliberados devem ser criados para colaborar apenas em objetos específicos.

#### Prós e contras do compartilhamento de dados entre organizações do Data 360

<table>
  <tr>
    <th>Fator</th>
    <th>Prós</th>
    <th>Contras</th>
  </tr>
  <tr>
    <td>Residência de dados</td>
    <td>Dá suporte à separação regional enquanto ativa a colaboração.</td>
    <td>Não elimina a necessidade de gerenciar várias organizações do Data 360.</td>
  </tr>
  <tr>
    <td>Duplicação de dados</td>
    <td>Cópia zero; nenhuma duplicação de objetos.</td>
    <td>Requer seleção deliberada de objetos para inclusão em cada compartilhamento de dados.</td>
  </tr>
  <tr>
    <td>Governança</td>
    <td>O compartilhamento é explícito e deliberado (no nível do objeto).</td>
    <td>Sem marcas ou fluxo de políticas; a organização de destino deve reaplicar a governança.</td>
  </tr>
  <tr>
    <td>Complexidade</td>
    <td>Ativa a colaboração seletiva sem centralização.</td>
    <td>Requer o gerenciamento de várias organizações do Data 360 e compartilhamentos de dados.</td>
  </tr>
  <tr>
    <td>**IA/Analytics**</td>
    <td>IA/análise regional possível; as percepções podem ser compartilhadas entre organizações.</td>
    <td>Nenhuma IA corporativa, a menos que os dados sejam compartilhados intencionalmente.</td>
  </tr>
  <tr>
    <td>**Recursos da plataforma**</td>
    <td>Os recursos desenvolvidos com o Data 360 de cada organização são executados de modo independente.</td>
    <td>Sem compartilhamento automático. Risco de duplicação se não tiver sido projetado com cuidado.</td>
  </tr>
  <tr>
    <td>Custo</td>
    <td>Pode reduzir a necessidade de pipelines de ETL.</td>
    <td>Ainda incorre o custo de várias organizações do Data 360. Consome créditos para consultas de dados e compartilhamento de dados.</td>
  </tr>
</table>

#### Critérios de decisão

<table>
  <tr>
    <th>Consideração</th>
    <th>Data Cloud One (preferencial para várias organizações)</th>
    <th>Compartilhamento de dados entre organizações do Data 360</th>
  </tr>
  <tr>
    <td>Fonte única da verdade</td>
    <td>Sim – todas as organizações compartilham um modelo de dados.</td>
    <td>Não – cada Data 360 tem seu próprio modelo de dados.</td>
  </tr>
  <tr>
    <td>Conformidade</td>
    <td>Funciona apenas quando a residência permite a centralização.</td>
    <td>Necessário quando as leis de residência impedem a centralização.</td>
  </tr>
  <tr>
    <td>Governança</td>
    <td>Centralizado, consistente.</td>
    <td>Federado; compartilhamentos deliberados no nível do objeto.</td>
  </tr>
  <tr>
    <td>Complexidade</td>
    <td>Menos peças móveis, mais simples.</td>
    <td>Mais complexo – requer compartilhamentos de dados de configuração e várias organizações de dados.</td>
  </tr>
  <tr>
    <td>IA/Analytics</td>
    <td>Modelos de IA corporativa.</td>
    <td>IA regional. Compartilhe percepções seletivamente.</td>
  </tr>
  <tr>
    <td>Recursos de plataforma</td>
    <td>O Data 360 compartilhado significa que todos os recursos funcionam de modo consistente entre o Início + os Companheiros.</td>
    <td>Os recursos são executados de forma independente em cada Data 360; o compartilhamento deve ser explícito.</td>
  </tr>
</table>

#### Recomendações

**Se sua empresa tiver várias organizações do Data 360**

- Use o compartilhamento de dados entre organizações do Data 360 para colaborar entre elas, em vez de criar pipelines personalizados ou duplicar dados.

- Compartilhe objetos específicos (DMOs, percepções calculadas, segmentos) criando compartilhamentos de dados e concedendo-os a organizações de destino.

- As marcas não são compartilhadas – a organização receptora deve reaplicar as marcas para governança, classificação ou aprimoramento de IA.

**Usar compartilhamento de dados entre organizações do Data 360**

- Para cumprir requisitos regulatórios que impedem a centralização.

- Para manter a autonomia da unidade de negócios enquanto habilita a colaboração seletiva.

- Para fornecer painéis executivos federados em várias regiões.

- Para fazer a ponte entre cenários de M&A em que a consolidação não é possível imediatamente.

**Designe cuidadosamente**

Trate o compartilhamento de dados do Data 360-to-Data 360 como uma estratégia de federação, não como uma substituição do Data Cloud One.

- Use o compartilhamento específico do objeto.
- Evite o excesso de compartilhamento.
- Alinhe compartilhamentos de dados às necessidades de negócios e conformidade.

#### Lembrar

Planejar sua estratégia de dados para provisionamento do Data 360 é uma decisão arquitetônica de longo prazo crítica que deve ser abordada em toda a empresa, não organização por organização. Essa escolha estratégica inicial determina como os dados do cliente são unificados, como a governança é imposta e como os recursos essenciais da plataforma, especialmente IA e análise, são dimensionados em toda a organização. Planeje modelos de governança e propriedade com antecedência e evite atalhos de curto prazo que levem à fragmentação e maior complexidade mais tarde.

## Recursos

[O que é Customer 360?](https://www.salesforce.com/products/what-is-customer-360/)

[Padrões e práticas de integração do Data 360](/docs/architect/pt-br/fundamentals/guide/data360_integration_patterns_and_practices)

[Arquitetura do Data 360](/docs/architect/pt-br/fundamentals/guide/data-360-architecture)

[Arquitetura de segurança do Data 360](/docs/architect/pt-br/fundamentals/guide/data360_security_architecture)

**Sobre os autores**

Kunal Goyal é diretor de Gerenciamento de produto na Salesforce, focado no avanço da arquitetura e escalabilidade de várias organizações no Data 360\. Desde 2017, ele liderou várias iniciativas e produtos centrados na colaboração entre organizações e no design de sistemas de vários locatários. Kunal é um dos leads de Arquitetura de melhores práticas do Data 360 e o proprietário do produto para experiências de configuração, provisionamento e administrador do Data Cloud One.

Erin Wagner Tidwell é redatora técnica principal e designer de conteúdo para o Data 360\. Ela está no Salesforce desde 2013\. Ela está dedicada a tornar o Data 360 mais fácil de entender e usar por meio de documentação técnica clara, consistente e precisa e comunicação no aplicativo.

Yugandhar Bora é um arquiteto de engenharia de software na Salesforce, especializado em arquitetura de dados na plataforma de Aplicativos de dados e inteligência. Ele lidera iniciativas do Conselho de revisão de arquitetura corporativa (EARB) focadas na governança de dados e modelos de dados unificados, ao mesmo tempo que contribui para soluções de provisionamento de plataforma automatizadas.

Samarpan Jain é um arquiteto principal na Salesforce especializado em Commerce Cloud, integração de plataforma e arquitetura entre organizações. Um dos funcionários mais antigos da Salesforce, ele lidera iniciativas importantes, incluindo conformidade de residência de dados para clientes do governo e sistemas de atribuição de uso do Data 360.