Está procurando criar formulários no Salesforce Platform? Você tem várias opções, abrangendo todo o continuum de código baixo para código profissional. Representam formulários dinâmicos no Criador de aplicativo Lightning e fluxos de tela no Flow Builder. A vantagem no meio do continuum é a capacidade de estender fluxos de tela com LWCs e criar formulários voltados para o cliente com o OmniStudio. E representando o código profissional é a estrutura do LWC e sua biblioteca crescente de componentes básicos.

As opções são ótimas, mas como determinar qual (ou qual combinação) é a opção certa? É aí que esse guia entra.

• Takeaway #1: Ao criar layouts de criação/editação/visualização para páginas do Lightning, use Formulários dinâmicos. Talvez você observe que os layouts de página estão ausentes nas tabelas de comparação neste guia. Para avançar, a maneira recomendada de configurar páginas de detalhes de registro é usar Formulários dinâmicos no Criador de aplicativo Lightning. Consulte a seção Layouts de página para obter mais informações sobre por que não esperamos aprimorá-los ainda mais.
• Takeaway #2: Se você precisar criar um formulário de criação ou edição para exatamente um objeto, comece com páginas do Lightning e Formulários dinâmicos. Esta é a maneira mais simples de criar formulários na plataforma Salesforce. Ele também fornece algumas funcionalidades adicionais, como a capacidade de controlar a visibilidade do campo. Se seus requisitos forem mais avançados, continue lendo. Fluxo de tela, OmniStudio ou Componentes da Web Lightning (LWC) podem ser mais adequados.
• Takeaway #3: 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, comece com um Fluxo de tela. Os Fluxos de tela fornecem uma estrutura de navegação linear para orquestrar vários formulários juntos. Você poderia usar o LWC para criar sua própria estrutura para navegar entre formulários, mas recomendamos deixar o Fluxo fazer o trabalho duro para você, para que você possa se concentrar nos formulários em si, em vez de se preocupar com o estado do formulário.
• Takeaway #4: Se precisar de lógica ou ações adicionais por trás do formulário, use um Fluxo de tela, OmniStudio ou LWC. Todas as três ferramentas oferecem maneiras de sua solução fazer mais do que criar ou editar um único registro. Essa "mais" pode ser uma lógica mais avançada, como ramificação ou iteração, ou pode ser mais ações, como integração a sistemas externos, envio de emails ou envio de notificações por push ao aplicativo móvel de um usuário.
• Takeaway # 5: Você tem requisitos de UX sofisticados? Precisa lidar dinamicamente com mais do que visibilidade? Use o LWC ou o OmniScript. Se seus requisitos puderem ser atendidos com temas simples e layouts baseados em coluna, você poderá criar seus formulários diretamente em um criador de código baixo. Para ter um controle mais detalhado sobre o estilo do formulário, você precisará da flexibilidade máxima 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 permitirá criar formulários de classificação de consumidor que podem lidar com lógica de negócios e transformações de dados complexas.
• Takeaway #6: Se você precisar de automação de teste, comece com Componentes da Web Lightning. Você pode escrever testes de unidade para qualquer LWC, não importa onde você planeja integrá-lo. Isso lhe permite criar uma estratégia de teste mais robusta, que pode incluir testes em massa com vários registros e testes negativos. Consulte Salesforce Well-Architected – Testing Strategy para obter mais informações sobre a criação de testes que o ajudarão a ver o quão bem seus formulários estarão alinhados aos seus requisitos funcionais e não funcionais.

Lembre-se de que sua escolha não precisa ser um ou dois. Você pode combinar o poder de várias opções. Por exemplo, se você precisar do sistema de navegação integrado do Fluxo e da flexibilidade de estilo total que o LWC oferece, use-os juntos.

A tabela abaixo descreve as ferramentas disponíveis para criar formulários com o Salesforce, junto com suas habilidades necessárias e considerações de licença. Posteriormente, analisaremos mais detalhadamente os recursos específicos com suporte para cada ferramenta, bem como como escolher entre ferramentas baseadas em clique e ferramentas baseadas em código (e quando combiná-las):

A tabela abaixo contém uma visão geral dos pontos de decisão a serem considerados ao fazer suas seleções de produto, junto com perguntas que você deve se fazer sobre cada uma. Vamos aprofundar-nos em cada um desses tópicos ao longo do restante deste guia.

Estes são os termos que usamos nas tabelas de comparação junto com suas definições:

• Disponível: Funciona bem com considerações básicas.
• Não ideal: Pode funcionar, mas não é a ferramenta ideal.
• Roadmap: Suporte estimado nos próximos doze meses (june de 2025).
• Futuro: Estimado para suporte além dos próximos doze meses.
• Não disponível: Não há planos de dar suporte a esse recurso nos próximos doze meses.

Conforme prometido, vamos começar um aprofundamento em uma variedade de pontos de comparação e diferenças funcionais entre Formulários dinâmicos, Fluxos de tela, OmniStudio, Fluxos de tela com LWCs integrados e a estrutura do LWC em si.

Se seu formulário opera em um único objeto do Salesforce, qualquer uma das ferramentas que estamos comparando funcionará. As coisas ficam um pouco mais complicadas com formulários entre objetos ou agnósticos a objetos. Por objeto agnóstico, entendemos entradas que não são mapeadas para nenhum objeto do Salesforce. Talvez seu formulário represente uma estrutura de dados que você enviará a um serviço externo, como Stripe ou DocuSign. Ou talvez você esteja usando várias entradas no formulário para calcular um valor e, em seguida, confirmar esse valor no banco de dados.

• Em relação a quais objetos o formulário operará?
• É apenas um objeto ou há vários objetos?
• Você está trabalhando com objetos específicos (por exemplo, Conta, Contato, Oportunidade, Lead e Caso) ou seu formulário precisará funcionar com outros objetos também?

Para formulários entre objetos e agnósticos a objetos, o Fluxo e o OmniStudio são opções sólidas. Os componentes disponíveis nas telas de fluxo são agnósticos por natureza, assim, você pode escolher o que fazer com esses dados nos bastidores. Por exemplo, use os dados inseridos em um formulário para criar vários registros nos bastidores ou use os dados para realizar outras ações, como gerar publicações do Chatter, enviar mensagens do Slack, enviar emails ou conectar-se a serviços externos.

Para casos simples, usar componentes do LWC existentes, como Lightning, pode ser uma maneira simples de reduzir o código necessário para fornecer uma solução robusta. No entanto, para cenários em que vários objetos estão envolvidos, o Fluxo fornece um controle abrangente para todos os objetos e elimina a necessidade de os desenvolvedores atravessarem relacionamentos e dependências complexos.

O OmniStudio avança um passo e é completamente agnóstico ao objeto, separando a forma que um usuário vê do modelo de dados subjacente. Em vez disso, o OmniStudio manipula o JSON subjacente que é mapeado para objetos do Salesforce (ou dados externos) usando ferramentas como o Mapeador de dados e Procedimentos de integração. O Mapeador de dados e os Procedimentos de integração são dois componentes importantes na conexão de seus formulários do OmniStudio com dados internos e externos ao Salesforce. Usando elementos de arrastar e soltar, você pode trabalhar com dados hierárquicos complexos em um sistema externo e então transformar os dados conforme suas necessidades, dependendo de onde os dados precisam ir. Eles também permitem que você use fórmulas para realizar matemática e lógica em matrizes ou listas de dados, assim como no Apex.

Integrações do OmniStudio

Se você puder obter todas as suas entradas de usuário de um formulário de tela única, comece com Formulários dinâmicos. No entanto, embora Formulários dinâmicos em páginas de registro possam usar o recurso Caminho para representar os vários estágios em seu processo de negócios, talvez não se adapte à maioria dos casos de uso.

• 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 de 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, a escolha entre Fluxo, OmniStudio e LWC também dependerá de algumas outras perguntas:

• Quais habilidades sua equipe tem? Para uma organização mais pesada em administração, recomendamos começar com o Fluxo. Se você tiver soluções de Indústrias, sua equipe já estiver familiarizada com o OmniStudio e seu projeto tiver requisitos de UX rígidos, comece com o OmniStudio.
• 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 forem UX indesejável, aponte para o LWC.
• O que precisa acontecer por trás do formulário? Se você precisar que o comportamento seja configurável por um administrador, crie um fluxo ou, para alterações básicas, como alterar rótulos de campo, um OmniScript. Caso contrário, para relacionamentos complexos de vários objetos, crie um OmniScript ou LWC.
• Se você escolher o Fluxo ou o OmniStudio, poderá precisar criar um LWC de qualquer forma para obter a UX certa. Se você já estiver criando um LWC para estilizar seu formulário corretamente, considere se a integração desse componente em um fluxo é excessiva.

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 vêm com 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. Para obter um ótimo exemplo do uso de fluxos de tela, confira o pacote de auditoria da loja digital da Salesforce Labs.

O OmniStudio oferece uma vantagem de navegação principal fornecendo indicadores de progresso da navegação padrão que detecta "etapas" no formulário. Esse modo de exibição de etapa exibe automaticamente onde um usuário está em um determinado formulário de várias etapas. Diferentemente do Fluxo, ele permite que os usuários "saltem" entre as telas clicando em várias etapas do formulário.

Não importa se você está criando formulários de tela única ou de várias telas, certifique-se de que seus formulários estejam simplificados para que sejam fáceis de navegar para seus usuários.

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

• 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 usar 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?

Como eles exigem contexto de registro, os Formulários dinâmicos têm suporte apenas em páginas de registro do Lightning. No entanto, não há suporte para Formulários dinâmicos em páginas do Experience Cloud. Essa limitação está em vigor porque o Experience Cloud não usa a estrutura subjacente à qual os Formulários dinâmicos dependem: Páginas do Lightning. Estamos avaliando isso com base nas solicitações de Formulários dinâmicos no Experience Cloud.

Você pode criar fluxos que exigem um contexto de registro ou fluxos que funcionam globalmente. Assim, você pode integrar fluxos em vários locais. Para fluxos contextuais de registro, isso pode ser uma página de registro do Lightning, uma página de registro do Experience Cloud, uma ação específica de objeto ou uma implantação de Ações e recomendações. Para o fluxo global, isso pode ser a barra de utilitários, outras páginas do Lightning ou do Criador de experiências, um Snap ou um aplicativo externo. Atualmente, não há suporte para fluxos como ações globais, mas como uma solução alternativa, você pode quebrar o fluxo em um componente do Aura.

O OmniStudio permite criar FlexCards e OmniScripts composíveis que você pode colocar em praticamente qualquer lugar em que possa colocar um fluxo. No entanto, embora sejam compostos, eles não são empacotáveis.

O LWC oferece suporte a um alto grau de reutilizabilidade, pois você está criando componentes que podem ser associados a metas por meio de metadados no Salesforce, em Comunidades e até mesmo em projetos de código aberto. Os componentes do LWC também podem ser integrados dentro do seu próprio site por meio do Lightning Out.

_ Lightning Out em sites externos_

Atualmente, não há suporte para componentes da Web Lightning como ações rápidas (objeto específico ou global), mas como solução alternativa, você pode colocar um LWC em um componente do Aura (como pode fazer com fluxos). Os componentes do LWC também podem iniciar fluxos com o componente Lightning-Flow.

O OmniStudio se destaca em expor conteúdo a seus 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 executá-los fora da plataforma em sites ou aplicativos de terceiros.

Nenhuma das tecnologias de formulário abordadas neste guia tem suporte oficial em modelos do Mobile SDK hoje. Se o Mobile SDK for essencial para seu caso de uso, é melhor criar seu formulário nativamente em seu aplicativo móvel ou criar uma página do Visualforce, mantendo a orientação do Salesforce Well-Archived form factor em mente.

Nota do roteiro: A equipe do Mobile SDK está trabalhando ativamente em dar suporte a LWCs em páginas do Visualforce.

Os Formulários dinâmicos são perfeitos se você precisar usar os valores em seu formulário para criar ou atualizar um registro. Para quaisquer recursos além disso, você precisará aproveitar o Fluxo, o OmniStudio ou o LWC. Esses recursos podem incluir uma camada de decisão ou iteração, ou a geração de publicações ou emails do Slack usando as entradas do formulário.

• Que ações ou lógica você deseja que sejam realizadas nos bastidores?
• Seu modelo de dados contém dados hierárquicos?
• 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?

O Fluxo oferece ações padrão para publicar no Slack, enviar emails e interagir com documentos do Quip, para que você não precise escrever código para essas operações. O LWC oferece interações avançadas com registros únicos e objetos relacionados através do uso de adaptadores de conexão que interagem com a API Interface do usuário. O LWC também pode interagir com vários registros ao usar o cabo para getListInfoByName.

_ Componentes da Web Lightning Interação via adaptadores de conexão_

Como mencionado acima, o OmniStudio usa Procedimentos de integração e o Mapeador de dados para capturar e transformar facilmente dados externos e internos no Salesforce. Ele brilha em nivelar e expandir conjuntos de dados com vários níveis de relacionamentos graças a várias funções sem código que você pode usar.

Nota do roteiro: O fluxo logo dará suporte à capacidade de inserir e atualizar coleções de registros, bem como gerenciar dados hierárquicos.

O Fluxo, o OmniStudio e o LWC integram-se ao Apex para que você possa fechar facilmente qualquer lacuna na solução escolhida. Por exemplo, se você precisar filtrar registros de um LWC, sempre poderá usar o adaptador de conexão para Apex para criar consultas SOQL complexas. Se você estiver preocupado com a história baseada em cliques, considere o Fluxo ou o OmniStudio como alternativas viáveis a um controlador do Apex para suas necessidades no lado do servidor.

Uma pergunta secundária aqui é se você deseja confirmar ações imediatamente ou adiá-las para uma parte específica do formulário. Isso é especialmente relevante se você estiver em um formulário de várias páginas. O fluxo torna fácil combinar entradas de vários formulários (tela de fluxo) e usá-las muito mais tarde no assistente (fluxo) para realizar algumas operações. Na verdade, recomendamos projetar fluxos dessa maneira (realizar ações no fim) caso o usuário volte e avance entre as telas, alterando suas respostas.

Transações e limites de governador são um modo de vida na Salesforce Platform. Se o seu caso de uso for bastante simples, talvez não seja tão importante controlar em qual transação 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 em vez de realizá-las entre várias transações. Alguns exemplos:

• Para reverter ou não reverter: Essa é a pergunta. Digamos que seu formulário crie vários registros nos bastidores. Se a criação do terceiro registro falhar, os dois primeiros registros deverão ser revertidos? Se cada uma de suas ações for independente uma da outra, sinta-se à vontade para executá-las em transações separadas. No entanto, se forem dependentes e você quiser que a falha de um também reverta os outros, implemente-os em uma única transação. Se o formulário estiver em Fluxo, você poderá usar o elemento Reverter em um caminho de falha para reverter sua transação e garantir a integridade dos dados.
• Impacto a jusante nos limites do regulador: Especialmente quando seu formulário cria ou atualiza um registro, considere 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 na ordem de salvamento serão acionados com base nessa alteração de registro? Como essas alterações coletivas afetam os limites do controlador que são consumidos nessa transação? Se uma alteração de registro em particular resultar em muitas alterações a jusante que afetam seus limites, considere isolar essa alteração de registro em sua própria transação.
• Processamento em lote: Mesmo em um contexto de UI, talvez seja necessário colocar várias atualizações em lote juntas. 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, aguarde 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 acontece 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 à API com as entradas.
3. A API recebe a solicitação e uma conexão de banco de dados e transação é aberta. A API então 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 um nó de Tela ou Ação local. O mecanismo então 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 (cue a execução do pedido de salvar) e a conexão de banco de dados e a transação 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. Repita a etapa 1.

Em outras palavras, as telas "quebram" transações. Quando isso acontece, qualquer ação pendente ou DML é confirmado, a transação anterior é fechada e uma nova transação é iniciada.

O design certo – que operações você agrupa em uma determinada transação – é sua chamada. Vamos analisar alguns exemplos.

À esquerda, você pode ver um fluxo que coleta entradas em várias telas e, em seguida, executa várias ações em uma transação.

O fluxo à direita realiza cada operação em uma transação separada.

Suponha que você tenha um fluxo que crie registros, atualize registros e crie mais registros, conforme ilustrado no próximo fluxo à direita.

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 esses registros, enquanto o terceiro não.

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 em conjunto, conforme visto no fluxo final à esquerda.

Para obter mais detalhes, consulte Fluxos em transações e Multiplicação de fluxo em transações. A seção Automatizado do Salesforce Well-Architected também aprofunde-se sobre isso em Manuseio de dados.

Sua capacidade de controlar a transação de um LWC se resume aos 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) acontecerá em uma transação independente assim que o formulário for enviado.

Em geral, estas regras se aplicam:

• Cada chamada à API da IU é isolada em 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, como um controlador do Apex ou um fluxo. As regras de transação normais para essa tecnologia se aplicam.

O Fluxo, o OmniStudio e o LWC oferecem suporte a eventos de plataforma (para a arquitetura orientada por evento) e integrações de API. Além do Apex code personalizado, o Fluxo e o OmniStudio oferecem suporte a mecanismos declarativos para integrar uma API.

Se precisar se conectar a uma API ou bot de RPA do Mulesoft, use os Serviços do Mulesoft. Isso gera um Serviço externo.

_ Integrações externas por meio de APIs da Mulesoft e Bots de RPA_

Se a API tiver um esquema OpenAPI, crie um Serviço externo.

Integrações externas a APIs com esquemas OpenAPI

Caso contrário, use o recurso Chamada HTTP no Fluxo ou Ação HTTP no OmniStudio. A chamada HTTP do fluxo é habilitada por Serviços externos.

Integrações externas via HTTP

O OmniStudio oferece um conjunto avançado de recursos de integração que podem chamar sistemas externos com Procedimentos de integração e transformar os dados com o Data Mapper. (Consulte impacto de objeto para obter mais informações)

Independentemente de você implementá-lo com Apex personalizado ou um serviço externo, uma chamada é uma chamada. Isto é o que você precisa saber.

1. Uma chamada pode levar muito tempo.
2. Quando uma chamada é executada de modo síncrono, ela é realizada enquanto uma transação de banco de dados está aberta.
3. O Salesforce não permitirá que você mantenha uma transação de banco de dados aberta se tiver operações de banco de dados pendentes.

A principal limitação a ter em mente é o perigo das chamadas transações sujas, onde você executa uma operação de criação, atualização ou exclusão e, em seguida, na mesma transação, executa uma chamada. Esse padrão não é permitido devido à consideração no 3 acima, que, claro, existe devido às considerações no 1 e no 2.

No Fluxo, você pode contornar essa limitação interrompendo a transação. Lembre-se de que as telas e as ações locais reintroduzem o contexto do navegador, o que interrompe a transação. Embora você possa usar telas e ações locais ao trabalhar com chamadas externas, recomendamos habilitar o Controle de transação em configurações avançadas invocáveis. O Controle de transação é um recurso de ações invocáveis que permite encerrar automaticamente a transação antes de uma chamada ser feita. Você pode habilitar o Controle de transação selecionando Sempre iniciar uma nova transação na seção Avançado de uma ação invocada.

Para obter orientações mais detalhadas sobre chamadas do Apex, serviços externos e recursos de integração de dados em geral, consulte o Guia do arquiteto para integração de dados com o Salesforce.

Formulários dinâmicos não oferecem suporte à reutilização. Cada Formulário dinâmico é vinculado a uma página de registro do Lightning específica para um objeto específico (embora você possa atribuir essa página de registro do Lightning a vários aplicativos, perfis etc.).

Assim como você pode escrever bibliotecas, utilitários e componentes destinados a serem usados em vários outros componentes, você pode aplicar padrões de design semelhantes ao criar fluxos com o poder de subfluxos. Salve seus fluxos em grupos menores e mais modulares 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 independente e seja útil como um subfluxo de outro.

O OmniStudio foi criado inerentemente para modularidade. Mapeadores de dados, OmniScripts, FlexCards e Procedimentos de integração são criados de modo independente e podem funcionar de modo intercambiável. Além disso, FlexCards 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. Quando você projeta suas soluções para serem composíveis, obtém vantagens adicionais como adaptabilidade e estabilidade.

Todas as tecnologias usadas para criar ou atualizar um registro seguem a validação no nível do sistema, sejam elas regras de validação clássicas ou validação personalizada integrada em um acionador do Apex. Independentemente da tecnologia usada para realizar uma alteração de registro, todas as alterações passam pelo pedido de salvamento. Isso significa que, além das regras de validação, a alteração de registro é processada por qualquer número de fluxos antes ou depois de salvar, acionadores antes ou depois, regras de escalação, regras de atribuição e muito mais. Se ainda não tiver feito isso, certifique-se de marcar como favorito e familiarizar-se com a ordem de execução do Apex.

• Seu formulário tem requisitos adicionais além da validação no nível do sistema?
• Você precisará definir campos como obrigatórios ou somente leitura dinamicamente no formulário?

As entradas em uma tela de fluxo ou etapa do OmniScript são por natureza não vinculadas, portanto, o formulário em si não adere nativamente à validação no nível do sistema associada a um objeto específico. No entanto, quaisquer valores que você use para criar ou atualizar registros serão processados pelo pedido de salvamento, o que significa que passam pela validação no nível do sistema do objeto. Observe, porém, que nem todos os componentes de fluxo de tela oferecem suporte à validação de entrada. A partir da versão Summer '24, os componentes da tela restantes que não oferecem suporte à validação de entrada são Botões seletores, Lista de opções, Lista de opções de seleção múltipla, Grupo de caixas de seleção e Pesquisa de opção.

Assim como os layouts de página, os Formulários dinâmicos permitem definir a obrigatoriedade e o estado somente leitura no nível da página. No entanto, não é possível substituir as configurações no nível do sistema.

O fluxo oferece flexibilidade para personalizar a validação nas entradas de um formulário. Embora algumas verificações sejam realizadas no cliente (como sinalizar campos obrigatórios ausentes ou valores incompatíveis), nenhuma validação no lado do cliente impede que o usuário tente navegar. A validação real acontece no servidor. Quando um usuário clica em Avançar, o Fluxo envia as entradas para o servidor para validação. Se alguma entrada for retornada como inválida, a navegação será bloqueada e o erro adequado será exibido. O servidor valida as entradas verificando:

1. A configuração de obrigatoriedade da entrada ou se o valor inserido é compatível com o tipo de dados subjacente.
2. Validação personalizada nessa entrada: Vários componentes padrão (Caixa de seleção, Moeda, Data, Data/hora, Área de texto longo, Número, Senha e Texto) oferecem suporte à validação personalizada por tela. Forneça uma expressão de fórmula booleana e uma mensagem de erro para ser exibida quando a expressão da fórmula não for atendida.
3. Validação personalizada no componente subjacente: Se você estiver criando um LWC personalizado para um fluxo, adicione seu próprio código de validação ao método validate().

O OmniStudio oferece processamento de erros avançados e validação por meio da ação Definir erro em combinação com as Visualizações condicionais e o componente Mensagens.

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

Os campos que exigem que os usuários insiram dados devem aparecer mais cedo nos formulários. Sempre que possível, valide as entradas do usuário no lado do cliente antes do envio dos formulários. Para obter mais práticas recomendadas para simplificar seus formulários, consulte a orientação de formulários no Salesforce Well-Architected – Engaging.

A segurança é um tópico complexo em geral e, quando se trata de criar formulários, há uma série de considerações sobre as quais você pode nem ter pensado. No nível fundamental, você quer 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. Porém, além disso, você também pode tomar medidas extras para remover códigos ou URLs potencialmente mal-intencionados de campos de rich text, impedir que determinados usuários possam acessar o formulário ou colocar limitações nos tipos de locais em que os administradores possam integrar o formulário no futuro. Documente cuidadosamente seus requisitos de segurança antes de escolher uma ferramenta. O modelo de política de segurança bem criado do Salesforce contém diretrizes para esse tipo de documentação.

• 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?

Quando algo é executado no contexto do usuário, o Salesforce impõe uma série de verificações de acesso, incluindo a verificação da segurança em nível de campo, permissões CRUD e 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 adequada e o acesso ao registro em questão. Mas e se você quiser que os usuários possam realizar uma operação específica quando estiverem usando o 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 é uma maneira de elevar as permissões do usuário em execução para a duração da sessão, de modo que o usuário não precise, por exemplo, de Acesso de atualização ao objeto Caso para concluir com sucesso o formulário de atualização de caso. Isso é especialmente útil para comunidades não autenticadas. Em vez de conceder aos usuários convidados habilidades potencialmente perigosas, defina seu formulário para ser executado no contexto do sistema.

É claro que o contexto do sistema é uma espada dupla e você deve usá-la apenas quando necessário. Quando um formulário é executado no contexto do sistema, cada única operação CRUD ignora a segurança e o compartilhamento em nível de objeto e de campo, não apenas a operação específica que importa. Observe também que o contexto do sistema não tem relação com 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, como a atualização de caso, o ator é o usuário em execução mesmo que o formulário seja executado em um contexto diferente.

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.

Os 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. É sua escolha se o fluxo deve conceder acesso a todos os dados ou se ele ainda deve impor acesso em nível de registro, como compartilhamento.

• 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 você precisar ignorar verificações de acesso do usuário, recomendamos usar 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 (como Pesquisa) não podem funcionar no contexto do sistema.
• Se o seu fluxo chamar ações do Apex, haverá mais algumas nuances a entender. Se a classe do Apex estiver definida como herdado compartilhamento, ela será executada no contexto do sistema com compartilhamento, independentemente do fluxo ser 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 para que o fluxo esteja definido. Se a classe estiver definida como com compartilhamento ou sem compartilhamento, ela fará isso e substituirá o contexto do fluxo.

Pesquisar 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 não autenticado, recomendamos armazenar 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 por meio das ferramentas de desenvolvedor do navegador. Isso pode tornar os campos disponíveis aos usuários do site do Experience Cloud que você não deseja. Ao especificar campos específicos nos elementos Obter registros, você pode garantir que apenas os campos certos sejam expostos mesmo com o contexto do sistema ativado.

Observe que a lógica 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 usando as ferramentas de desenvolvedor do navegador. Quando você estiver usando o OmniScript, recomendamos executar a lógica de negócios no lado do servidor sempre que possível e implementar regras de validação de entrada em qualquer método do Apex exposto por meio de uma anotação @InvocableMethod.

Entradas de saneamento:

Para proteger sua organização contra atores ruins, considere também a limpeza de entrada. Suponha que você tenha uma entrada em um formulário acessível ao público que possa ser mapeada para um campo de rich text na sua organização. Talvez você queira considerar a automação que remova qualquer HTML que possa ocultar URLs mal-intencionados. Em geral, não é ideal implementar essa limpeza no nível do formulário, pois você pode ter qualquer quantidade de origens gravando nesses campos. Recomendamos criar um Fluxo de atualização de campo rápido (antes de salvar) ou usar um Acionador do Apex existente no objeto para remover ou modificar qualquer HTML potencial que possa ser inserido no formulário.

Práticas recomendadas:

• Deixe os fluxos em execução no contexto padrão, a menos que você precise elevar o acesso do usuário em execução para uma operação específica.
• Evite executar fluxos no contexto do sistema para usuários convidados por motivos de segurança. Crie conjuntos de permissões com acesso a campo limitado atribuído ao perfil de usuário convidado do site 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 executar várias operações e nem todas elas exigirem acesso elevado, use subfluxos para isolar as operações que devem ser executadas no contexto do sistema.
• Se você planeja integrar um formulário a uma página da Web externa, considere limpar as entradas do usuário para remover HTML usando um Fluxo de atualização rápida de campo ou Apex Trigger se elas forem eventualmente mapeadas para campos de rich text para evitar possíveis ataques de phishing de atores ruins.

• 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 e os fluxos são executados no contexto do usuário, mas você pode substituir isso em um controlador do Apex.
• As operações realizadas por meio da API da IU são executadas no contexto do usuário.
• As operações realizadas por meio de um controlador do Apex dependem dessa classe. Para realizar essas operações no modo de sistema, defina a classe do Apex como with sharing ou without sharing.

Se você precisar de controle sobre quem pode acessar seu formulário, costuma procurar o contêiner no qual o formulário está integrado. Por exemplo, você pode atribuir páginas do Lightning para que estejam disponíveis para determinados aplicativos, tipos de registro ou perfis. Se determinadas entradas em seu formulário forem confidenciais, use regras de visibilidade para controlar ainda mais o que é exibido a quem; esse recurso se aplica tanto a Formulários dinâmicos quanto a fluxos de tela.

Você pode restringir um fluxo a determinados perfis ou conjuntos de permissões, assim como uma classe do Apex ou uma página do Visualforce. Por padrão, os fluxos não são restritos, o que significa que qualquer usuário com a permissão de usuário Executar fluxos pode executá-los.

Se você estiver usando o OmniStudio, poderá configurar um verificador de permissões de classe do Apex para garantir que os usuários precisem de acesso explícito à classe do Apex que administra a ação remota chamada de um OmniScript, FlexCard, Classic Card ou API REST.

• Observação As verificações de permissão da classe do Apex estão habilitadas por padrão para scripts recém-criados. No entanto, eles precisam ser habilitados manualmente para quaisquer scripts existentes
• Observe também que as verificações de permissão de classe do Apex se aplicam apenas a classes do Apex. Recomendamos configurar permissões no nível do perfil para Procedimentos de integração e Mapeadores de dados também.

Para obter mais detalhes e práticas recomendadas sobre permissões de usuário convidado, consulte:

• Práticas recomendadas de acesso ao registro do usuário convidado
• Desenvolver sites seguros: Usuários autenticados e convidados

Práticas recomendadas:

• Se você estiver expondo um fluxo a usuários convidados, conceda ao perfil de usuário convidado acesso apenas aos fluxos de que ele precisa. Embora seja possível adicionar Fluxos de execução ao perfil de usuário convidado, consideramos que isso é uma prática arriscada.
• Seja especialmente cuidadoso com fluxos que operam no contexto do sistema. Recomendamos enfaticamente que você restrinja esses fluxos a um conjunto específico de usuários, pois eles têm menos verificações e saldos em vigor para proteger seus dados.
• Qualquer OmniScript que execute Apex em uma comunidade de usuários convidados deve ter "com compartilhamento" na definição da classe do Apex.
• No perfil de Usuário convidado, atribua apenas as classes do Apex que você deseja que os usuários convidados possam chamar ou corra o risco de expor inadvertidamente lógica de negócios adicional aos usuários convidados.

Para LWCs, você pode verificar as atribuições de permissão do usuário em execução para confirmar se ele tem uma permissão padrão ou personalizada específica. Diretamente de JavaScript, você pode importar permissões do Salesforce dos módulos com escopo @salesforce/userPermission e @salesforce/customPermission. Ou você pode usar o Apex para verificar o mesmo.

Os componentes da Web Lightning só estão disponíveis em um determinado local quando foram adicionados como um alvo válido. Por exemplo, você pode tornar um componente disponível em páginas de registro e não disponível como um item da barra de utilitários.

Depois que um fluxo de tela é ativado, ele fica disponível em todos os locais em que os fluxos de tela têm suporte, independentemente de você querer que ele esteja disponível em todos os lugares ou não. Dito isto, o Flow Builder oferece suporte a vários tipos de fluxos que têm telas. O tipo de pizza é Fluxo de tela, mas há alguns outros tipos especializados restritos a locais específicos. Por exemplo, o aplicativo Field Service Mobile oferece suporte apenas a fluxos do Field Service Mobile, você adivinhou. O mesmo se aplica a Fluxos de solicitação de contato, que têm suporte apenas no Experience Cloud.

Independentemente do tipo de fluxo, o indivíduo que está fazendo o fluxo não tem controle sobre onde o fluxo pode ser integrado. O fluxo estará disponível em todos os locais com suporte para esse tipo de fluxo.

Se você estiver usando o Salesforce Industries, há um pequeno aviso quando se trata do OmniScript: Embora não seja possível especificar um destino para um OmniScript em si, você pode especificar um para os FlexCards que talvez queira integrar a ele.

Formulários estáticos são algo do passado. Hoje, é tudo sobre atualizar dinamicamente o formulário com as propriedades e valores certos para esse usuário, dessa vez, neste local. Vamos falar sobre o que é possível nessa veia para as ferramentas de criação de formulário do Salesforce.

• Quais tipos de interações ou condições devem acionar respostas dinâmicas no seu formulário?
• Você precisará executar operações fora da tela em segundo plano conforme seu formulário está sendo preenchido?
• Você precisará definir campos como visíveis, obrigatórios, somente leitura ou desabilitados ou alterar a formatação com base em entradas de formulário?

A interatividade do Fluxo de tela agora é uma realidade graças às telas reativas. A reatividade permite que componentes individuais em uma tela de fluxo se comuniquem entre si, tornando os fluxos de tela infinitamente mais poderosos.

Executar operações de dados fora da tela: Fluxos de tela oferecem uma abordagem declarativa para buscar dados na mesma tela por meio de Ações de tela. Ações de tela podem permitir que você acione fluxos iniciados automaticamente em qualquer alteração na tela ou quando um usuário clica em um componente Botão de ação. Você então pode mapear os resultados desses fluxos iniciados automaticamente para a mesma tela, eliminando a necessidade de os usuários navegarem para outra tela.

O LWC oferece uma gama completa de adaptadores de conexão que permitem acessar dados do Salesforce para preencher dados nos componentes do formulário dinamicamente e permite que os desenvolvedores atualizem, excluam e criem registros por meio de controladores do Apex.

Componentes da Web Lightning Operações de dados off-screen

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 com recursos de visibilidade do componente. Com isso, você pode mostrar ou ocultar campos declarativamente com base em outros valores no formulário ou se o usuário está em um dispositivo móvel ou não.

• Com Formulários dinâmicos, a visibilidade pode ser controlada com base em valores de campo de registro, registros relacionados por meio de campos de pesquisa e formato.
• Com o Fluxo, você pode basear uma regra de visibilidade em outras entradas na tela, bem como em outros recursos preenchidos anteriormente no fluxo, como fórmulas ou valores de outros registros.
  • Regras baseadas em dispositivo: Não é ó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 estará no aplicativo Salesforce móvel.
  • Avaliação de outros recursos: Referências de variável manual e de fórmula são avaliadas apenas no servidor. Assim, qualquer valor que o recurso tenha quando a tela for renderizada pela primeira vez será o valor que ele terá até você navegar para outra tela. Na navegação, o tempo de execução do fluxo envia uma solicitação ao mecanismo de fluxo (o servidor) e retorna os valores mais recentes das fórmulas e variáveis manuais. Se você espera que sua regra de visibilidade seja atualizada à medida que o usuário passa por uma única tela (por exemplo, onblur), 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 qualquer outra propriedade, como se um campo é obrigatório, desabilitado ou somente leitura, você tem algumas opções. Conforme esperado, o LWC oferece controle reativo total sobre seu estado de entrada. Com componentes reativos do Fluxo de tela, você pode controlar dinamicamente atributos de componente como Somente leitura, Desabilitado e Obrigató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, como se um campo é obrigatório ou somente leitura, sua melhor aposta no curto prazo é o LWC, em que você tem controle total. Isso é especialmente verdadeiro se você tiver requisitos personalizados para lidar com onblur ou onclick.

LWCs reativos em fluxos de tela: Ao criar LWCs que podem reagir e alterar outros componentes em um fluxo de tela, consulte este guia LWC Best Practices for Screen Flows para garantir que seus componentes se integram bem no mecanismo de tempo de execução de fluxo e funcionem como esperado no futuro.

Agora para eventos personalizados. Se algumas das suas entradas ou todo o formulário precisarem se comunicar com outra coisa na página, o LWC será sua única opção.

• Para se comunicar dentro da mesma árvore DOM, use a interface CustomEvent.
• Para se comunicar no DOM, use o Lightning Messaging Service.
• Se o Lightning Messaging Service não tiver suporte para seu contêiner de destino, use o módulo pub/sub.

• Para obter mais detalhes, consulte Comunicar com eventos e Comunicar no DOM no Guia do desenvolvedor de componentes da Web Lightning.
• Para o OmniStudio, consulte Comunicar com OmniScript a partir de um Componente da Web Lightning.

Para proporcionar a melhor experiência do usuário, você precisará garantir que o estilo do formulário seja consistente com o restante do aplicativo ou site em que ele está integrado. Realizar isso pode significar qualquer coisa, desde a utilização de modelos padrão fornecidos pelo Salesforce até a criação de CSS personalizado que utiliza totalmente cada pixel no design para proporcionar uma aparência mais nítida.

• Quão sofisticado é o estilo e o CSS desejados?
• Você precisa de um estilo personalizado perfeito para pixels ou está bem com temas padrão?

O FlexCards é o único produto coberto neste guia que permite controlar declarativamente o estilo e o layout da interface do usuário que você está criando na ferramenta diretamente, sejam elas as margens e o preenchimento, a tipografia, as cores etc.

Tanto Formulários dinâmicos quanto fluxos respeitam os recursos de tema declarativo. Se você precisar de controle além do suporte para Temas do Salesforce, Conjuntos de identidade visual do Criador de experiências ou Sites do Experience Cloud do LWR, considere uma solução programática.

Para equipes que se sentem à vontade ao trabalhar com CSS, você tem algumas opções:

• Fluxos e LWCs herdam tokens de design padrão.
• OmniScripts e FlexCards incluem suporte para um sistema de design personalizável: Newport.
• Com o LWC, você pode escrever seus próprios componentes e controlar totalmente o HTML e o CSS para eles.

Sempre que possível, recomendamos usar temas e sistemas de design para que sua aparência seja aplicada de modo consistente em todo o conteúdo.

Lembrete: Você pode integrar componentes do Lightning em fluxos. Portanto, se você precisar de controle perfeito por pixel sobre a aparência do seu formulário, mas quiser usar os outros benefícios de fluxos, como o modelo de navegação, poderá ter o melhor dos dois mundos. O mesmo princípio se aplica a OmniScripts e FlexCards.

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. Consulte Salesforce Well-Architected - Formulários para obter mais informações sobre este tópico.

• Como você pode utilizar o layout do formulário para otimizar as experiências do usuário?
• Como apresentar dados existentes a seus usuários de uma maneira que facilite a inserção de novos dados nos formulários?

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

Os fluxos também podem ser renderizados usando o componente Seção. Com seções, você pode adicionar até quatro colunas e quantas seções quiser na tela de fluxo. O componente também é responsivo à largura da tela, assim, ele pode funcionar em telas menores. Por fim, ele permite aplicar a visibilidade condicional a toda a seção, facilitando a aplicação em massa de visibilidade a vários campos dentro da seção. Seções de fluxo também dão suporte a cabeçalhos de coluna e oferecem uma experiência semelhante a 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 são as do HTML/CSS. Lightning respeita a configuração da seção no layout de página associado; por exemplo, se uma seção for de duas colunas no layout de página, ela será de duas colunas nesse componente.

Se o formulário for acessível por usuários em diferentes regiões ou que falam diferentes idiomas, você precisará garantir que a ferramenta que estiver usando para criá-lo cumpra os requisitos de localização. Consulte Salesforce Well-Architected – Localização para obter orientações e recomendações adicionais. No caso de formulários especificamente, os requisitos de localização geralmente envolvem a tradução de elementos de texto para outros idiomas.

• 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?

Se você tiver localizado seus campos personalizados, esses rótulos traduzidos serão respeitados em Formulários dinâmicos. O recurso Formulários dinâmicos também respeita os rótulos personalizados que você atribuiu aos rótulos e atributos de componente no Criador de aplicativo Lightning.

Com o poder do Workbench de tradução, o Fluxo oferece suporte à tradução de rótulos voltados para o usuário para todos os componentes de tela padrão e personalizados. Você pode localizar o rótulo, o texto de ajuda e a mensagem de erro destes componentes da tela: Texto, Área de texto longo, Número, Moeda, Caixa de seleção, Botões seletores, Lista de opções, Lista de opções de seleção múltipla, Grupo de caixas de seleção, Senha, Data e Data/hora.

Não há suporte integrado para tradução para ações prontas para uso, como Enviar email ou Publicar no Chatter. No entanto, há uma solução alternativa! Se você definir os rótulos traduzidos com um rótulo personalizado, poderá fazer referência a esse rótulo personalizado na ação ou no componente ao configurá-lo no Flow Builder. Crie uma fórmula de fluxo que faça referência ao rótulo personalizado e faça referência a essa fórmula nos locais apropriados em seu fluxo.

Os OmniScripts usam rótulos personalizados para traduções. Consulte este documento de ajuda para preparar seus OmniScripts em vários idiomas.

Agora 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 tiverem sido 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 ainda serão o herói não escrito. Declare o rótulo personalizado necessário e importe-o para seu componente do módulo no escopo @salesforce/label.

Há várias ferramentas de automação de teste completas disponíveis (por exemplo, Selenium), que permitem simular como o usuário interage com seu formulário. Você pode escrever esses testes para qualquer interface de usuário padrão ou personalizada, incluindo páginas do Lightning e fluxos de tela. No entanto, é importante observar que esses tipos de testes não podem verificar as saídas de cada método que está sendo realizado. Certifique-se de levar isso em conta ao pensar nos seus requisitos para automação de teste de interface do usuário.

• Você precisa de testes automatizados para seu formulário?
• Quais tipos de testes você precisa realizar?
• De que nível de granularidade você precisa em suas automações de teste?

Considere seus requisitos para automação de teste da IU.

Os testes de unidade permitem uma automação e validação mais granulares que funcionam com os sistemas e ferramentas CI/CD padrão do setor, que podem testar a lógica de negócios dos componentes, seu controlador JavaScript e suas saídas. Ao usar exclusivamente com baixa codificação, você não poderá realizar testes de autoautoria, mas o Salesforce testa rigorosamente nossas ofertas completas.

Se os métodos do seu componente forem complexos o suficiente para que sejam testados individualmente, coloque-os em arquivos JavaScript dedicados. Dessa forma, você pode importá-los para um LWC e para um teste Jest com algo como import { sort } from 'c/utils';.

Consulte Automação de teste de UI no Salesforce para obter uma comparação das várias opções disponíveis para criar automação completa no Salesforce. Incluem considerações sobre quando usar uma solução sem código de um ISV, Build Your Own solução de automação de teste personalizada ou usar uma estrutura de teste de código aberto como Selenium WebDriver ou WebdriverIO. Essas soluções são válidas para qualquer interação da IU no Salesforce, seja 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 em ação rápida.

Depois de implementar seu formulário em um ambiente de produção, você vai querer garantir que ele esteja sendo usado de modo eficaz. Dependendo do seu caso de uso, isso pode significar qualquer coisa, desde simplesmente rastrear o número de vezes que ele foi preenchido até a quantidade de tempo que os usuários passam preenchendo-o antes de enviar suas informações. Identifique os KPIs que deseja rastrear antes de escolher uma ferramenta.

• Você precisa rastrear o uso do seu formulário?
• Quais KPIs determinam se seu formulário está sendo usado de modo eficaz?

Se precisar rastrear o uso geral e a adoção do formulário, comece com as ferramentas de baixa codificação. Tanto Formulários dinâmicos quanto Fluxos de tela podem ser rastreados usando tipos de relatório personalizados prontos para uso, embora você obtenha mais granularidade dos relatórios de rastreamento de Fluxo de tela. Se você precisar rastrear o uso de um LWC, a disponibilidade pronta para uso dependerá de onde você está usando esse LWC. Se estiver em uma página do Lightning, tudo o que estiver disponível para rastrear o uso da página do Lightning será aplicado ao seu LWC. A mesma história se aplica a LWCs integrados a fluxos.

Os formulários dinâmicos não podem ser rastreados prontos para uso, embora você possa rastrear o uso da página pai do Lightning por meio de objetos de uso do Lightning. Para rastrear as páginas padrão do Lightning, use o tipo de relatório personalizado Usuários com uso do Lightning por métricas de página. Para o mesmo em páginas personalizadas do Lightning, use o tipo de relatório personalizado Usuários com uso do Lightning por métricas FlexiPage.

Para rastrear a adoção do seu formulário específico (não apenas a página em que ele está), o Fluxo tem você coberto. Use o "Relatório de fluxo de amostra: Fluxos de tela" para responder a perguntas como:

• Qual é a taxa de conclusão para esse formulário? Está sendo bem adotado?
• Quanto tempo os usuários levam para preencher esse formulário?
• Em qual tela os usuários passam mais tempo?
• Com que frequência os usuários navegam para trás?
• Com que frequência ocorrem erros?

Se o relatório padrão não atender às suas necessidades, clone-o para fazer suas próprias alterações ou Build Your Own do zero usando o tipo de relatório Fluxos de tela.

Se você estiver usando o tempo de execução do OmniScript baseado em pacote, poderá utilizar o Serviço de rastreamento do OmniStudio para Vlocity. Esse serviço rastreia qualquer tipo de evento. Por exemplo, você pode rastrear o tempo que leva para concluir as etapas em um OmniScript para identificar melhorias no processo. Está no roteiro da equipe do OmniStudio para dar suporte a esse serviço no OmniStudio padrão.

Para rastrear o mesmo para um LWC que não esteja integrado a um fluxo de tela, OmniScript ou página do Lightning, não há opção pronta para uso. Você pode criar uma solução personalizada usando o Apex.

Quando você precisa implantar sua solução em ambientes mais altos para testes ou implantação em produção, pode ser usado para usar conjuntos de alterações ou DevOps Center para fazer isso. Formulários dinâmicos, fluxos e LWCs têm suporte total nessas opções de implantação. O OmniStudio requer uma ferramenta separada: IDX Workbench.

• Como você planeja implementar seu formulário?
• Seu formulário será distribuído para mais de uma organização do Salesforce?

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

Este guia foi focado em ajudá-lo a entender qual funcionalidade e nível de personalização é possível com Formulários dinâmicos, fluxos de tela, OmniStudio e LWC. Em um nível alto:

• O LWC é a opção mais personalizável e robusta para criar um formulário, mas tem o menor número de proteções em vigor. Cabe a você criar um componente de uma maneira que garanta a segurança e a escalabilidade.
• Formulários dinâmicos são os menos flexíveis, mas há muito menos oportunidades para erros.
• O Fluxo e o OmniStudio estão em algum ponto no meio, mais poderosos que Formulários dinâmicos, mas não no nível do LWC. No mesmo token, eles têm menos proteções do que Formulários dinâmicos, mas são mais difíceis de quebrar do que o código personalizado.

Se várias ferramentas caberem à conta, a decisão será sobre qual ferramenta é a certa para sua equipe. Outros Guia de Decisão de Arquiteto apresentam aspectos adicionais a serem considerados ao tomar essa decisão.

Não vamos entrar nos detalhes de cada um desses aspectos aqui, mas vamos interpretá-los para as ferramentas específicas que este documento está avaliando.

Habilidades especiais: Quanto conhecimento sua equipe tem nas ferramentas que você está comparando? Quantos criadores conhecem bem o LWC ou JavaScript? Que tal criadores que são especialistas no Flow Builder ou que manifestaram interesse em detalhar? Geralmente, as habilidades de fluxo e formulários dinâmicos são mais alcançáveis para uma população mais ampla de pessoas que criam formulários. Formulários dinâmicos são a ferramenta de criação de formulário mais declarativa e sempre serão mais fáceis de aprender do que o Fluxo. Dito isto, a equipe do Fluxo está comprometida em manter essa barra o mais baixa possível. Em termos de complexidade, o OmniStudio fica em algum ponto entre o Fluxo e o LWC e oferece superpoderes significativos de criação de formulário.

Delegation of Delivery: Apenas porque alguns de seus requisitos exigem o LWC não significa que toda a sua solução precisa ser criada com o LWC. Considere como você pode criar sua solução de modo modular, de modo que as peças que exigem LWC sejam codificadas e as peças que não são criadas em uma solução de baixa codificação. Fazer isso maximiza a eficiência de uma equipe diversificada e garante que cada indivíduo esteja resolvendo problemas apropriados para sua especialização.

Agora vamos falar sobre Fluxo e LWC. Com Componentes de tela reativos, os componentes de fluxo de tela agora podem conversar entre si na mesma tela, desbloqueando uma nova cesta de ferramentas para arquitetos, administradores e desenvolvedores. Os desenvolvedores agora podem criar componentes modulares que podem ser reutilizados em toda a organização, aumentando a produtividade para todos na equipe. Os desenvolvedores podem se concentrar em resolver novos desafios e economizar tempo usando uma combinação de componentes de Fluxo padrão e personalizados para alcançar o dinamismo da forma. Com componentes reativos no Fluxo, nunca houve um momento mais adequado para combinar Fluxo e LWC ao criar seus formulários.

Manutenção e propriedade de longo prazo: Se você tiver um formulário de várias etapas, é uma boa ideia começar com Fluxo ou uma combinação de Fluxo e LWC. Se você tiver uma equipe com pouco código mantendo a solução, pense em como tornar a solução o mais configurável e extensível possível para esse público. Seja qual for a ferramenta que você escolher, organize sua solução em unidades compostables para melhorar a manutenção e a estabilidade.

Avançando, a maneira recomendada de configurar páginas de detalhes de registro é Formulários dinâmicos no Criador de aplicativo Lightning usando páginas do Lightning. Há muito tempo que não temos layouts de página aprimorados e essa tendência continuará. Este é o motivo:

• Os Formulários dinâmicos são mais flexíveis: você pode colocar campos e seções onde quiser diretamente no Criador de aplicativo Lightning, onde você pode aproveitar seções, guias e acordeões. Assim como você pode fazer com componentes na página do Lightning, você pode controlar a visibilidade de seus campos e seções sem definir vários layouts de página ou tipos de registro.
• Com os componentes Acordeão e Guia, você pode restringir a quantidade de campos exibidos inicialmente. Adivinha o que isso significa? Tempos de carregamento de página mais rápidos.
• O gerenciamento de layout é mais simples com páginas do Lightning, pois você pode gerenciar tudo sobre suas páginas no Criador de aplicativo Lightning – seja o conteúdo da página ou quais usuários têm acesso à página. Não é mais necessário fazer atualizações no layout de página para fazer uma alteração na página do Lightning. Sem mencionar que, com o poder das regras de visibilidade, você não precisa mais criar várias páginas (ou layouts de página) para controlar quem vê quais campos quando. Isso também significa que você só precisa atribuir aos usuários uma página do Lightning em vez de atribuir uma página do Lightning e um layout de página.

Recomendamos usar Formulários dinâmicos sempre que possível e voltar aos layouts de página apenas quando necessário. Como sempre, recebemos feedback no Idea Exchange sobre as melhorias que teriam maior impacto na sua organização.

Qualquer consideração de desempenho relacionada a Formulários dinâmicos, fluxos de tela, OmniStudio e LWC se concentra na estrutura em que essas próprias tecnologias se sentem. As baseadas no LWC (além, claro, de um LWC) terão um desempenho superior às baseadas no Aura. A estrutura do LWC oferece um desempenho melhor porque os principais recursos são implementados nativamente em mecanismos da Web em vez de em JavaScript por meio de abstrações de estrutura. Se você não está familiarizado, dê uma leitura a este post.

Em 2019, realizamos um case study comparando o desempenho da mesma funcionalidade no Aura versus no LWC. Como resultado da conversão do DreamHouse do Aura para o LWC, não apenas a experiência de desenvolvimento estava muito mais alinhada aos padrões e padrões de desenvolvimento de front-end da Web atuais, mas os ganhos de desempenho eram significativos. As medições de laboratório mostraram ganhos na faixa de 2,4% a 24,7% para cache frio e ganhos na faixa de 31,83% a 63,32% para cache quente nas mesmas duas páginas.

Agora, qual estrutura nossas tecnologias de formulário estão usando? Em outras palavras, quais tecnologias de forma se beneficiam desse desempenho superior?

• O recurso Formulários dinâmicos, que está integrado aos metadados das páginas do Lightning, é construído sobre uma base que usa a pilha do LWC, que nos permitirá implementar alguns recursos muito solicitados. Como um bônus de desempenho, os Formulários dinâmicos usam renderização progressiva, o que resulta em um tempo de carregamento de página aprimorado para páginas com um grande número de campos.
• Os Fluxos de tela são criados no LWC com a maioria dos componentes individuais prontos para uso agora convertidos no LWC, com a exceção de dois componentes prontos para uso: Upload de arquivo e imagem. Embora a equipe do Fluxo tenha convertido o cliente de tempo de execução de fluxo para o LWC, bem como a maioria de seus componentes, os clientes ainda precisam converter seus componentes da tela do Aura para o LWC. Além disso, o Salesforce oferece suporte apenas a componentes do LWC na nova estrutura de componente reativo em fluxos de tela. Existe um excelente módulo do Trailhead que explica como fazer isso: Componentes da Web do Lightning para desenvolvedores do Aura. É evidente que: Se você estiver pensando em criar um componente personalizado para um fluxo de tela ou qualquer outro contêiner, sempre vá para o LWC.
• Há algumas versões do OmniStudio disponíveis. Se você for um cliente de longa data, poderá estar usando Angular. Incentivamos todos os novos clientes a começar com OmniScripts e FlexCards baseados em LWC e para que os clientes atuais migrem do Angular.
• O LWC é baseado em... LWC, claro. Este é um prêmio gratuito.

Como um arquiteto, é importante ter uma compreensão sólida de todas as opções disponíveis para você e como aplicá-las em seu caso de uso específico. Para criar formulários no Salesforce, as opções variam de baixo código (usando Formulários dinâmicos no Criador de aplicativo Lightning, Fluxos de tela no Flow Builder e OmniScripts no OmniStudio) a pro-código (usando a estrutura LWC), com uma combinação de fluxos de tela ou OmniScripts e LWC no meio. Lembre-se deste guia e use-o como referência ao planejar criar ou reprojetar formulários no Salesforce. Se você está procurando orientação sobre como criar formulários simplificados e úteis, consulte Salesforce Well-Architected: Engraçado.

Ajude-nos a garantir que estejamos publicando o que é mais relevante para você: pegue nossa pesquisa para fornecer feedback sobre esse conteúdo e diga-nos o que você gostaria de ver em seguida.