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.

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.

• 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).

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

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.

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.

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.

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

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.

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

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.

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.

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.

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

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.

Os componentes do LWC também podem iniciar Fluxos com o componente Lightning-Flow.

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.

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.

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

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. O LWC também pode interagir com vários registros usando o cabo para getListInfoByName.

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

As transações e os limites de governador 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 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) 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. 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:

• 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. 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. 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 e Multiplicação de fluxo em transações.

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.

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

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

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.

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

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.

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 do Apex.

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

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 em combinação com as Visualizações condicionais e o componente Mensagens.

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

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.

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

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.

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 para garantir que seus componentes se integram ao mecanismo de tempo de execução de fluxo e funcionem como desejado.

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.

• Para se comunicar no DOM, use o Serviço de mensagens do Lightning.

• Se o Serviço de mensagens do Lightning não tiver suporte para seu contêiner de destino, use o módulo pub/sub.

• Para obter mais informações detalhadas, consulte Comunicar com eventos e Comunicar no DOM no Guia do desenvolvedor de componentes da Web Lightning.

• Para o OmniStudio, confira Comunicar com OmniScript a partir de um Componente da Web Lightning.

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.

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.

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

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

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, Conjuntos de identidade visual do Criador de experiências ou Sites do LWR Experience Cloud), 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.

• OmniScripts e FlexCards incluem suporte de sistema de design personalizável via Newport.

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

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.

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

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

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.

• 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ê 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 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 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 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.

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

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 do Salesforce.

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

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.

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

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

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

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

Os LWCs só estão disponíveis em um determinado local depois de serem adicionados como um alvo 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.

No Salesforce, há várias ferramentas de automação de teste completas (por exemplo, consulte o Salesforce 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.

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

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

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.

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

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

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

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.

• Como você planeja implementar o formulário?

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

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.

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. 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 e a escalabilidade 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.

• 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, independentemente da ferramenta escolhida.

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