Esse texto foi traduzido usando o sistema de tradução automatizado do Salesforce. Pegue nossa enquisa para fornecer feedback sobre esse conteúdo e diga-nos o que você gostaria de ver em seguida.
Leia sobre nossas agendas de atualização aqui.
Os sistemas demonstram o comportamento automatizado permitindo que os negócios atendam às principais metas e objetivos de forma mais rápida e em escala. Automação saudável permite que os usuários se concentrem em trabalho de alto valor e reduz o tempo gasto em tarefas manuais repetitivas ou entrada de dados complexos.
Na maioria das vezes, a automação significa traduzir processos de negócios de um formulário para outro: de formulário baseado em papel para formulário digital, de um sistema antigo para um novo. A cada tradução de processo de negócios vem uma oportunidade para transformação.
A transformação não é sobre usar novas tecnologias para introduzir alterações disruptivas e confusas para os usuários. A transformação é criar maneiras mais simples de realizar o trabalho, permitir que os negócios cresçam sem atrito e capacitar os usuários de negócios a se concentrarem mais profundamente no que realmente importa para as partes interessadas. Do ponto de vista arquitetônico, isso envolve identificar tarefas que podem ser eliminadas por completo ou processadas automaticamente. Ele exige uma conexão clara entre como a tecnologia é usada e seu impacto mensurável sobre os negócios.
Algo importante a observar sobre a automação com o Salesforce: isso pode ser feito com uma variedade de ferramentas, usando conjuntos de habilidades programáticas e declarativas. Projetar automações bem arquitetas não é escolher criar com apenas uma ferramenta de automação. Trata-se de usar abordagens consistentes e previsíveis e permitir que as equipes desenvolvam, testem, implementem e mantenham as automações que você projeta. Suas automações devem assumir a forma mais manutencionável e legível possível.
Esta seção abrange como projetar e refator automações para permitir que as empresas atendam aos principais objetivos mais rapidamente e em escala. Você pode melhorar a arquitetura de suas automações no Salesforce focando a eficiência e a integridade dos dados.
Criar eficiência em suas automações não é apenas recriar os negócios como sempre com tecnologias do Salesforce. Trata-se de compreender profundamente as principais métricas e os resultados de negócios que as equipes serão responsáveis por reunir ou rastrear, e voltar atrás para ver as unidades funcionais dentro e entre o trabalho que você está automatizando. Trata-se de identificar como você pode criar padrões com suas automações que permitem que a empresa opere de forma mais eficiente e rápida em escala.
Uma lógica de automação eficiente fará com que seus sistemas:
- Mais escalonável e valioso para os negócios
- Mais útil para usuários
- Mais adaptável e capaz de atender às necessidades de negócios em evolução
Você pode melhorar a eficiência em suas automações por meio do design de processos e da lógica operacional.
O design de processos envolve definir as maneiras como o trabalho é feito. Criar processos realmente eficientes e eficientes significa que seus designs não apenas replicam as maneiras atuais de trabalhar. É essencial identificar e remover etapas ineficazes ou pouco claras. Processos otimizados devem criar valor comercial mensurável (consulte KPIs) sem etapas desnecessárias. Etapas imprecisas ou desnecessárias provavelmente criarão débito técnico e resultarão em automações insustentáveis.
Geralmente, a responsabilidade de descobrir e documentar processos de negócios fica sob a responsabilidade de um analista de negócios ou até mesmo de um administrador do sistema. Os arquitetos são responsáveis por fazer parcerias com esses membros da sua equipe para garantir que seus designs de processo sejam tecnicamente sólidos e bem estruturados. Aplicar o Knowledge da Salesforce Platform o mais cedo possível ajudará sua equipe a identificar processos para simplificar por meio da automação ou processos que precisam ser alterados para evitar personalizações caras.
Para criar processos otimizados para o Salesforce, considere:
-
Definir processos cuidadosamente. Processos com finalidades imprecisas ou definições ambíguas têm maior probabilidade de serem interpretados incorretamente no momento do design. Isso levará a designs com defeito baseados em pressuposições, o que resultará em automações incorretas ou ineficientes. Garanta que os processos de negócios que você deseja automatizar atendam aos seguintes padrões:
- Escopo para uma única função específica (consulte Unidades funcionais)
- Tem resultados claramente definidos e mensuráveis (ver Valor comercial)
- Tem entradas e saídas definidas claramente
-
Deixe os passos do processo claros.* Embora às vezes possa ser tentador adicionar passos adicionais que “pode ser útil no futuro”, essa nunca é uma boa abordagem. Cada etapa em uma automação deve ser relevante ao resultado geral do processo. Certifique-se de que cada etapa do processo tenha as seguintes características:
- Realiza uma tarefa específica e granular (Consulte composível)
- Obrigatório para o processo gerar sua saída definida (remover todas as etapas não essenciais)
- Pode ser concluído usando um número mínimo de recursos
- Usa dados do sistema existentes em vez de pedir entradas do usuário quando possível (consulte engajamento)
- Fornece opções de entrada que os usuários podem entender sem precisar saber como os sistemas subjacentes funcionam (consulte o útil)
A lista de padrões e antipadrões abaixo mostra como é uma otimização adequada (e ruim) em uma organização do Salesforce. Você pode usá-los para validar seus designs de automação antes de criar ou identificar automações que precisam ser otimizadas ainda mais.
Para saber mais sobre as ferramentas de automação de processos disponíveis no Salesforce, consulte Ferramentas relevantes para automatizado.
A lógica operacional lida com a eficácia com que um processo é traduzido de seu design para uma implementação real. Automações com lógica operacional forte continuam a apresentar um bom desempenho, independentemente de picos nos volumes de transações ou do número de instâncias simultâneas em execução. Automações lógicas facilitam a escala das empresas para operar em níveis mais altos de demanda. A criação de uma lógica operacional forte em suas automações está diretamente relacionada com a confiabilidade geral do seu sistema.
Automações que não funcionam de forma eficaz proporcionam experiências de usuário e cliente ruins, levando a potencial perda de receita e perda de Customer Trust. Eles também têm custos de manutenção mais altos e podem se tornar gargalos que atrasam processos relacionados, contribuindo para problemas gerais de desempenho do sistema.
Para criar uma lógica operacional eficaz em automações, considere:
- Assegure que todos os criadores de automações saibam como fazer isso. Escolhas de design ruins podem ser feitas com qualquer tipo de ferramenta de automação. O código não é menos propenso a erros ou escolhas de implementação ruins do que ferramentas baseadas em cliques. O uso de IDs de referência embutidos em código, por exemplo, é um antipadrão que aparece tanto no Fluxo quanto no código. Ferramentas baseadas em cliques não devem ser vistas como uma licença para permitir que qualquer pessoa libere uma automação para produção. Todo membro da equipe que cria uma automação precisa saber como criá-la da maneira correta. Consulte Legibilidade e padrões de design para obter mais informações sobre como definir e aplicar padrões eficazes em seus sistemas.
- Documente claramente todos os caminhos de execução. O aumento do uso de automações não só aumenta os volumes de dados em potencial, como também aumenta os contextos de invocação não planejados. Você precisa entender como diferentes automações podem ser invocadas e garantir que os controles de transação adequados (consulte a manipulação de dados) apareçam em todas as automações que têm vários pontos de entrada. Por exemplo, fluxos de tela não serão executados com cargas de dados em massa, mas acionadores do Apex e fluxos acionados (e iniciados automaticamente) provavelmente serão. A documentação clara de caminhos de execução planejados e potenciais para automações é um aspecto crucial para entender quais condições lógicas você precisará acomodar durante a implementação.
- “Bulkify” todas as operações de dados (incluindo SOQL). Todas as operações de dados (inserir, atualizar e assim por diante) devem ser realizadas em relação às coleções. Sempre. Sem exceções. Isso é o que significa operações de " massificação". Embora a plataforma possa dar suporte a operações de dados singleton, você nunca deve permitir que padrões singleton sejam implementados.
- Use SOSL para operações de busca. Há um equívoco de que as operações de dados não podem ser realizadas com relação a registros retornados por meio de SOSL. É verdade que DML não pode ser invocado diretamente em relação aos resultados de SOSL, mas o código pode analisar os resultados de SOSL e criar uma coleção que pode ser referenciada em métodos de classe de DML ou Banco de dados. As principais diferenças entre SOSL e SOQL são os tipos de retorno para cada um e como eles respondem a pesquisas generalizadas ou curingas. O SOSL pode funcionar com diversos tipos de sObject (o que faz com que o tipo de retorno seja diferente) e pode lidar com pesquisas de string generalizada e curinga com um desempenho melhor que SOQL.
- Trate SOQL como uma operação de dados. Não use SOQL para localizar registros, use-o para refinar suas operações de dados. O SOQL e as operações de dados podem ter um impacto muito semelhante no desempenho do base de dados relacional subjacente. O SOQL pode até mesmo passar um indicador DML explícito que bloqueará linhas de banco de dados em antecipação de operações de dados. Para criar automações escalonáveis, certifique-se de tratar o SOQL com a mesma devida diligência: não o use sem critérios de seleção muito específicos e bem formados, não permita referências a campos externos e exige uma correspondência cuidadosa de tipos de dados entre campos e entradas de filtro na lógica de instruções de
WHERE. Seu código também deve ter controles adequados para garantir que uma consulta nunca seja executada em contextos não massificados ou em critérios de filtro nulos ou em branco. - Mantenha operações síncronas estritamente focadas no trabalho que ajuda um usuário em tempo real. Durante sua otimização de processo, identifique a lógica relevante para o que os usuários precisam fazer em tempo real ou quase em tempo real e o que pode ser adiado em uma transação assíncrona. Consulte Manuseio de dados para mais considerações sobre a criação de operações de sincronização/assíncrono.
A lista de padrões e antipadrões abaixo mostra como é a lógica operacional correta (e ruim) na automação do Salesforce. Você pode usá-los para validar seus designs de automação antes de criar ou identificar automações que precisam ser otimizadas ainda mais.
Para saber mais sobre as ferramentas disponíveis do Salesforce que podem ajudá-lo a planejar a escala, consulte Ferramentas relevantes para automatizado.
Os KPIs de automação medem o impacto de uma automação ao longo do tempo. Sem eles, você não terá como determinar se uma automação está realmente adicionando valor comercial ou criando complexidade indesejada para seus usuários. Todas as automações criadas devem estar vinculadas a um conjunto claro e mensurável de KPIs.
Os bons KPIs são definidos por um valor mensurável junto com um período associado. Os exemplos incluem:
- [Número X] Horas de trabalho salvas por mês
- Falhas de processamento de entrada de dados manual reduzidas em [Y%] por semana
Depois de ter KPIs claros e mensuráveis, você também precisa entender se e como uma automação no Salesforce gerará dados relevantes para relatórios com base nesses KPIs.
A lista de padrões e antipadrões abaixo mostra a aparência dos KPIs adequados (e ruins) quando se trata de automações do Salesforce. Você pode usá-los para validar seus KPIs existentes ou identificar onde é necessário identificar melhor os KPIs antes de criar.
Para saber mais sobre as ferramentas disponíveis no Salesforce para obter ajuda com KPIs, consulte Ferramentas relevantes para automatizado.
A tabela a seguir mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.
✨ Descubra mais padrões para eficiência no Padrão & Anti-Padrão Explorador.
| Padrões | Antipadrões | |
|---|---|---|
| Projeto de processo | Em sua organização:
- Cada fluxo atende a uma única finalidade específica - Cada etapa realiza uma tarefa granular específica - Os fluxos são organizados em uma estrutura hierárquica que consiste em um fluxo principal e subfluxos de suporte - Todas as entradas do usuário têm um propósito claro no fluxo - Os usuários são solicitados a fornecer dados apenas quando os dados do sistema existentes não puderem ser usados |
Em sua organização:
- Os fluxos atendem a vários fins e exigem entradas adicionais para fornecer contexto - Os fluxos exigem entradas cujos dados não são usados - Grupos de etapas relacionadas contêm funcionalidades que se sobrepõem a grupos de etapas em outros fluxos - Os fluxos solicitam entradas do usuário quando os dados armazenados podem ser usados |
| No Apex:
- Cada classe atende a um único propósito específico - Cada método realiza uma tarefa granular específica - Todas as variáveis de entrada têm um propósito claro dentro da classe - A execução de código requer um número mínimo de recursos |
No Apex:
- As classes têm várias finalidades - Os métodos realizam várias tarefas ou realizam tarefas que não estão alinhadas à finalidade declarada da classe da qual fazem parte - As variáveis de entrada não são, na verdade, usadas em métodos - Métodos que recuperam dados desnecessariamente do banco de dados ou de sistemas externos |
|
| Lógica operacional | Em fluxo:
- Nenhuma variável se refere a valores embutidos em código (para tipos de registro, usuários etc.) - Todos os fluxos e processos iniciados automaticamente usam elementos de decisão e/ou pausa para avaliar critérios de entrada e evitar loops ou execuções infinitas em grandes volumes de dados - Fluxos (incluindo processos) lógica de mão para Apex em contextos de grande volume de dados - Os subfluxos são usados para as seções de um processo que precisam ser reutilizados em todo o negócio |
Em fluxo:
- As variáveis têm valores embutidos em código - Os fluxos (incluindo processos) devem ser desativados manualmente antes do carregamento de dados em massa - Fluxos (incluindo processos) acionam avisos de "exceção não tratada" - Mesmo fluxos simples geralmente causam erros relacionados a limites do regulador - Partes de um fluxo são repetidas entre fluxos em vez de usar subfluxos |
| No Apex:
- Nenhuma variável se refere a valores embutidos em código (para tipos de registro, usuários etc.) - Todos os critérios curingas aparecem em SOSL - SOQL é envolvido em try-catch
- Nenhum SOQL aparece em um loop - As instruções SOQL são seletivas, incluindo: -- sem uso de comparações LIKE ou comparações parciais de texto
-- operadores de comparação usam lógica positiva (ou seja, INCLUDES, IN) como lógica primária ou única
-- uso de = NULL, != NULL é raro e/ou sempre segue um operador de comparação positivo
-- nenhuma instrução LIMIT 1 é exibida
-- nenhum uso da palavra-chave ALL ROWS
| No Apex:
- As variáveis têm valores embutidos em código - SOSL raramente é usado ou não é usado de modo consistente para critérios de seleção de curinga - SOQL não está envolvido em try-catch
- SOQL aparece dentro de loops - As instruções SOQL não são seletivas, incluindo: -- Aparecem os critérios de filtro LIKE e curinga
-- comparações usando critérios NÃO, NÃO IN são usados como o operador de comparação principal ou único
-- = NULL, != NULL critérios são usados como o principal ou único operador de comparação
As instruções -- LIMIT 1 são exibidas
-- A palavra-chave ALL ROWS é usada
| |
| Em suas normas de design e documentação:
- Os caminhos de execução planejados e potenciais para automações são descritos claramente - Os casos de uso para operações síncronas e assíncronas em automações são descritos claramente como parte dos padrões de design |
Em suas normas de design e documentação:
- A invocação de automação não está documentada - Casos de uso para operações síncronas e assíncronas não são tratados |
|
| KPIs | Na sua documentação:
- As saídas para cada automação são mensuráveis e temporizadas - As partes interessadas responsáveis são listadas para cada KPI |
Na sua documentação:
- Os KPIs não existem para automações ou têm períodos de tempo imprecisos para medidas - Existem KPIs sem partes interessadas responsáveis |
| Dentro dos relatórios e painéis:
- Todas as métricas relacionadas a KPIs são incluídas em pelo menos um relatório ou painel |
Dentro dos relatórios e painéis:
- Não existe relatório de KPI ou os relatórios estão sem métricas relacionadas a alguns KPIs |
A integridade dos dados é sobre como um sistema mantém dados precisos e completos. A Salesforce Platform mantém uma robusta lógica de processamento integrada projetada para proteger a integridade dos dados armazenados no banco de dados relacional de uma organização individual. Um dos fundamentos da criação de automações saudáveis é entender os comportamentos integrados de integridade de dados do Salesforce e garantir que todos os seus designs de automação se alinhem (e reconheçam) a esses comportamentos.
Os maiores desvios no design de automação resultam de não reconhecer os poderosos serviços de integridade de dados já fornecidos pelo Salesforce e de não usar a funcionalidade padrão que aproveita esses serviços. Para projetar automações que protegem e mantenham a integridade dos dados, você deve estar familiarizado com a ordem fundamental dos comportamentos de operação do Salesforce.
Estender adequadamente a integridade dos dados para suas automações personalizadas significa que seu sistema pode:
- operar em massa e grandes volumes de dados sem intervenção manual,
- aplicar políticas de segurança do usuário quando necessário e mudar para o contexto do sistema quando necessário,
- encontrar erros no tempo de execução e seguir caminhos de recuperação ou falha previsíveis.
Você pode criar uma maior integridade de dados em suas automações do Salesforce por meio do tratamento adequado de dados e do tratamento de erros.
O primeiro passo para projetar para o tratamento adequado de dados no Salesforce é entender como a plataforma multitenant lida com transações. Isso inclui a compreensão da ordem de execução integrada que a Salesforce Platform usa para garantir a integridade dos dados durante operações de dados em nível de registro. Para obter mais informações sobre os impactos desse comportamento, consulte Manipulação de banco de dados em Noções básicas da Arquitetura do Salesforce.
O mau tratamento de dados em suas automações pode ser alguns dos antipadrões mais difíceis de identificar e remediar totalmente. A natureza recursiva e sobreposta da ordem de execução da plataforma pode tornar difícil ver onde os problemas se originam. A seção específica de código ou fluxo que gera um erro fatal ou excede os limites do controlador pode não ser a causa-raiz de um problema de processamento de dados subjacente.
A consciência da transação é fundamental para criar automações que tenham um desempenho confiável e em escala com o Salesforce. Isso significa garantir que cada etapa em uma automação seja projetada com o Knowledge de onde ela está em relação à ordem de execução controlada pela plataforma, possa realizar sua função corretamente e passe a informação para a próxima etapa corretamente.
Independentemente da ferramenta de automação que você está usando, a conscientização adequada da transação segue padrões semelhantes e requer considerações comuns:
- Suponha que cada automação seja solicitada para ser executada em grandes volumes de dados sem aviso, a qualquer momento. As automações devem ter caminhos para permitir a execução em lote ou em massa (consulte Escalabilidade).
- Não misture operações de dados de contexto do usuário e do sistema na mesma transação.
- Reserve operações de sincronização de dados para contextos antes e use operações assíncronas para todas as ações de contexto depois.
- Use mensagens e notificações para evitar criar experiências no aplicativo que exigiriam que o usuário esperasse os dados com base nos resultados de uma operação assíncrona.
Além da consciência da transação, há uma segunda dimensão para o tratamento de dados: saber quando executar lógica em diferentes contextos de execução. Os motivos comuns para dividir automações em diferentes contextos de execução incluem:
- Grandes volumes e/ou operações de dados complexas
- As operações de massificação não garantem que uma automação trate grandes volumes de dados corretamente. Se o volume de operações de dados em uma automação exceder os limites por transação, você precisará realizar operações de dados usando funcionalidades específicas para grandes volumes de dados (como por meio do Apex em lote ou da API Bulk 2.0). Eles têm limites de transação distintos, adequados a grandes volumes de dados.
- Operações de dados que precisam cruzar hierarquias de relacionamento complexas ou realizar recálculos complexos (não incluindo campos de fórmula) entre registros podem facilmente exceder os limites por transação quando realizadas em massa. Considere o quão "ruim" é uma atualização de um registro em termos das operações de dados relacionadas ou SOQL necessárias para concluir ações subsequentes no sistema.
- Os tipos de sObjects envolvidos em toda a cadeia de uma automação podem exigir que você divida operações de dados em transações separadas para evitar erros de "DML misto".
- Lógica que precisa ser executada no contexto do usuário ou do sistema
- A Salesforce Platform impõe o compartilhamento e a visibilidade no contexto do usuário. Se você precisar realizar operações que vão além dos níveis de permissão dos usuários de sua automação, terá que garantir que essas operações sejam executadas no contexto do sistema.
- Diferentes ferramentas serão ou não executadas em diferentes contextos:
- O Apex será executado no contexto do sistema por padrão. Você pode controlar se e como os comportamentos do Apex aplicam regras de compartilhamento no nível do usuário usando palavras-chave de compartilhamento em uma definição de classe do Apex.
- O fluxo não tem um único comportamento padrão. Um fluxo será executado no contexto do usuário ou do sistema com base em como o fluxo é iniciado. Você tem a opção de impor o compartilhamento no contexto do sistema.
- Processos (ou seja, automações criadas com o Criador de processos) são executados no contexto do sistema sem considerações de compartilhamento. (Nota: Recomendamos criar automações com pouco código com o Fluxo.
- Lógica que precisa ser executada de forma assíncrona
- Operações do sistema externo – Chamadas síncronas ou ações que acessam dados externos não são incluídas em nenhum comportamento de reversão de plataforma. Para aproveitar esses comportamentos, você deve colocar ações envolvendo sistemas externos em transações separadas (usando métodos assíncronos Apex, caminhos assíncronos ou ações invocáveis).
- Evento e mensagens - Para controlar o fluxo de eventos ou mensagens relacionadas a operações de dados (e aproveitar os comportamentos de reversão de plataforma), coloque todas as ações relacionadas a mensagens ou eventos em contextos depois, usando métodos assíncronos do Apex.
A lista de padrões e antipadrões abaixo mostra como é o tratamento de dados correto (e ruim) em automações do Salesforce. Você pode usá-los para validar seus designs de automação antes de criar ou identificar automações que precisam ser refatoradas para melhorar o tratamento de dados.
Para saber mais sobre as ferramentas disponíveis do Salesforce para processamento de dados em automação, consulte Ferramentas relevantes para automatizado.
O tratamento de erros é essencial para a integridade dos dados. O gerenciamento de erros forte também ajuda a dimensionar e envelhecer seu sistema com mais resiliência.
Manipulação inadequada de erros em automações pode levar a:
- Registre inconsistências e outros problemas de integridade de dados
- Enviar notificações imprecisas a usuários e outros sistemas
- Gastar tempo e recursos com processamento manual ou repetido
- Falta geral de Trust em um sistema
O gerenciamento de erros em automações requer dar a qualquer processo em execução a capacidade de analisar um erro para obter informações, acessar a lógica sobre quais as próximas etapas devem ser baseadas nas informações de erro e, em seguida, seguir o caminho correto. Esses recursos não precisam ser criados repetidamente em cada automação (isso é um antipadrão de otimização). Em vez disso, cada automação no sistema deve ser capaz de se conectar aos componentes relevantes de tratamento de erros.
Para criar controles adequados de tratamento de erros em suas automações, faça estas perguntas:
- O que é um erro "fatal"?
- O que é um erro "recuperável"?
- Para automações acionadas por ações do usuário, como a automação pode capturar e notificar o usuário sobre erros antes de tentar confirmar alterações?
Depois de decidir como lidar com esses erros, você pode começar a criar um tratamento eficaz de erros em suas automações. A lista de padrões e antipadrões abaixo mostra como é o tratamento de erros correto (e ruim) em uma automação do Salesforce. Você pode usá-los para validar seus designs de automação antes de criar ou identificar automações que precisam ser refatoradas para melhorar o tratamento de erros.
Para saber mais sobre ferramentas disponíveis no Salesforce para tratamento de erros, consulte Ferramentas relevantes para automatizado.
A tabela a seguir mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.
✨ Descubra mais padrões para integridade de dados no Pattern & Anti-Pattern Explorer.
| Padrões | Antipadrões | |
|---|---|---|
| Manuseio de dados | No seu dicionário de dados:
- Há dados em nível de campo e lógica de priorização para todas as fontes de dados e objetos de data lake - O mapeamento de campo do objeto de data lake para o objeto de modelo de dados existe |
No seu dicionário de dados:
- Dados em nível de campo e lógica de priorização para origens de dados e objetos de data lake não são incluídos - O mapeamento de campo de objetos de data lake para objetos de modelo de dados não está incluído |
| No Apex:
- Todas as instruções DML síncronas ou métodos de classe de banco de dados são executados em contextos antes da execução do acionador - As invocações assíncronas do Apex usam enfileiráveis para DML complexo 'chain' entre transações - O Apex em lote é usado exclusivamente para grandes volumes de dados - O Apex @future não é usado ou usado com moderação, para chamadas ou DML de objeto do sistema |
No Apex:
- As instruções DML aparecem regularmente em código que será invocado em contextos de acionador depois - O Apex assíncrono é raramente usado - Recursos assíncronos do Apex são usados arbitrariamente, incluindo: -- Métodos futuros e Apex enfileirável são usados de forma inconsistente ou intercambiável -- As operações de banco de dados não têm lógica clara e consistente para passar a execução para o Apex em lote quando necessário |
|
| Em fluxo:
- Todos os fluxos iniciados no contexto do usuário resumem todas as transações de contexto do sistema para subfluxos, que são colocados consistentemente após um elemento Pausar, para criar uma nova transação - Sequências complexas de operações de dados relacionadas são criadas com o Orquestrador (em vez de invocar vários subfluxos em um fluxo monolítico) - Todos os fluxos acionados por registro têm valores de ordem de acionador preenchidos - Fluxos que envolvem chamadas do sistema externo ou processos de execução longa usam caminhos assíncronos |
Em fluxo:
- Fluxos grandes e monolíticos tentam coordenar sequências complexas de operações de dados relacionadas (com ou sem subfluxos) - Fluxos acionados por registro não usam atributos de ordem do acionador nem usam valores de ordem do acionador de modo consistente - Os caminhos assíncronos não são usados de modo consistente ou não são usados de modo algum |
|
| Em sua organização:
- As regras de reconciliação de resolução de identidade seguem a lógica de priorização em seu dicionário de dados |
Em sua organização:
- As regras de reconciliação de resolução de identidade não seguem a lógica de priorização no dicionário de dados |
|
| Tratamento de erros | No Apex:
- O código engloba todos os DML, SOQL, chamadas e outras etapas críticas do processo em blocos de try-catch
- Exceções personalizadas são usadas para criar mensagens de erro avançadas e lógica - Em contextos assíncronos e em massa, os métodos de classe de banco de dados são usados em vez de DML - Os métodos de classe do banco de dados podem ser usados exclusivamente para todas as operações de dados (em vez de DML) |
No Apex:
- DML, SOQL, chamadas ou outras etapas críticas do processo não são consistentemente agrupadas em blocos de try-catch
- As instruções System.debug aparecem no código de produção (e não são comentadas)
- Nenhum método de classe de banco de dados é usado - As operações de dados são feitas exclusivamente com DML |
| Em Componentes da Web Lightning (LWC):
- JavaScript engloba todas as operações de dados e etapas críticas do processo em se () / outro se () bloqueia
- Todas as funções @wire usam propriedades de dados e erros fornecidas pela API
- Todas as instruções se (erro) / else se (erro) contêm lógica para processar erros e fornecer mensagens informativas |
In LWC:
- O JavaScript não é usado consistentemente se ()/outro se () bloqueia com operações de dados ou etapas críticas do processo
- As funções @wire não usam propriedades de dados e erros fornecidas pela API (ou não as usam de maneira consistente)
- Se usado, se (erro) / outro se (erro) as instruções não realmente contêm lógica para processar erros e fornecer mensagens úteis de erro |
|
| Em Aura:
- JavaScript engloba todas as operações de dados e etapas críticas do processo em blocos de try-catch
- Dentro de blocos de try-catch, erro JavaScript nativo é usado em instruções de lançamento (sem uso de $A.error())
- Todas as lógicas de erro recuperáveis aparecem nas instruções de captura e fornecem mensagens claras do usuário |
Em Aura:
- O JavaScript não engloba consistentemente operações de dados e etapas críticas do processo em blocos de try-catch
- Os componentes usam $A.error()
- Lógica de erro recuperável não aparece consistentemente nas instruções de captura, e as mensagens de erro aos usuários não são claras |
|
| Em fluxo:
- Fluxos de tela usam consistentemente conectores de falha para mostrar erros aos usuários - Mensagens de erro personalizadas são configuradas para erros que aparecerão na tela - Fluxos com operações de dados, chamadas e outra lógica de processamento crítica têm caminhos de falha para todas as ações-chave |
Em fluxo:
- Os fluxos não usam caminhos de falha de modo consistente ou de modo algum - As mensagens de erro personalizadas não são usadas, portanto, os usuários veem a mensagem padrão "Uma falha não tratada ocorreu nesse fluxo" |
O conceito de valor comercial, no contexto da automação, é sobre como os processos criam um impacto positivo mensurável para as partes interessadas do negócio. O ideal é que a automação de processos permita que os usuários dediquem menos tempo em tarefas repetitivas de baixo valor. Também ajuda a aumentar a integridade dos dados eliminando atividades de processamento manual que podem gerar erros. Assim como o Process Design, identificar e entregar automações que gerem valor real para os negócios exige trabalho além da descoberta básica e análise de negócios.
Às vezes, pode parecer que a melhor maneira de entregar valor ao negócio é simplesmente automatizar cada processo solicitado por um usuário de negócios, seja na ordem em que eles aparecem em sua pendência (ou fila de pedidos) ou com base em fatores políticos na sua organização. Isso pode levar a dois problemas relacionados: criar automações em uma ordem subótima e criar as automações incorretas. O primeiro problema, uma priorização ruim, impede que os processos de alto valor sejam implementados quando deveriam, possivelmente desacelerando o crescimento. O segundo problema, criar as automações erradas, não apenas atrasa a entrega de automações de alto valor, como também leva a tempo perdido, custos desnecessários e maior frustração entre as equipes de entrega.
Você pode oferecer maior valor comercial focando KPIs e priorização.
| Ferramenta | Descrição | Eficiência | Integridade de dados | Valor de negócios |
|---|---|---|---|---|
| Apex Lote | Reúna registros em lote e processe-os em partes manipuláveis | X | X | |
| Métodos futuros do Apex | Executar métodos do Apex de modo assíncrono em segundo plano | X | X | |
| Enfileiramento Apex | Adicionar trabalhos do Apex a uma fila e monitorá-los | X | X | |
| Apex Scheduler | Executar classes do Apex de modo assíncrono em horários especificados | X | X | |
| Homologações | Especifique as etapas necessárias para aprovar registros | X | X | |
| Apex assíncrono | Executar Apex code de maneira assíncrona | X | X | |
| Ações automatizadas | Realizar atualizações de campo, envios de email e outras ações em segundo plano | X | X | |
| Einstein Next Best Action | Exiba as recomendações certas para as pessoas certas na hora certa | X | X | |
| Alerta por email | Criar e enviar emails automatizados | X | X | |
| Ações de escalação | Especificar ações automatizadas para escalonamentos de caso | X | X | |
| Atualização de campo | Atualizar valores de campo com base em automação | X | X | |
| Flow Builder | Crie automações com uma interface do tipo apontar e clicar | X | X | |
| Extensões de fluxo | Acessar variáveis armazenadas como entradas de componente em fluxos | X | ||
| Biblioteca de modelos de fluxo | Usar modelos para projetar fluxos específicos do setor | X | X | |
| Acionador de fluxo | Automatizar processos comerciais complexos | X | ||
| Ações invocáveis | Adicionar funcionalidade do Apex a fluxos | X | X | |
| Orquestrador | Criar e gerenciar automações de várias etapas | X | X | |
| Mensagem de saída | Enviar informações de um processo automatizado com recibos e novas tentativas | X | ||
| Publicar eventos de plataforma com fluxo | Publicar eventos por meio de interações e automações do usuário | X | ||
| Otimizador de consulta | Usar seletividade e índices para melhorar o desempenho de consulta, relatório e modo de exibição de lista | X | X | |
| Fluxo do Salesforce | Criar automações de processo declarativas com o Flow Builder | X | X | |
| Enviar notificações com fluxos | Enviar mensagens por SMS, WhatsApp ou Facebook Messenger | X | X | |
| Enviar notificações com processos | Enviar mensagens por SMS, WhatsApp ou Facebook Messenger | X | X | |
| SOQL para modificador de atualização | Bloqueie registros para evitar condições de corrida e problemas de segurança de thread | X | ||
| Strategy Builder | Identifique recomendações para exibir em páginas de registro | X | X | |
| Subfluxos | Reduza a complexidade do fluxo por meio da reutilização | X | ||
| Assinar eventos de plataforma com fluxo | Receber mensagens publicadas por meio de automações | X | ||
| Ações de tarefa | Determine os detalhes de atribuição fornecidos a um usuário por uma automação | X |
| Recurso | Descrição | Eficiência | Integridade de dados | Valor de negócios |
|---|---|---|---|---|
| Controladores e limites de execução do Apex | Saiba como o mecanismo de tempo de execução do Apex aplica limites | X | X | |
| Recursos de gerenciamento em lote | Criar, gerenciar, agendar e monitorar trabalhos em lote | X | X | |
| Práticas recomendadas para SOQL e SOSL | Melhore o desempenho da consulta de aplicativos com grandes volumes de dados | X | ||
| Modelo de padrões de design | Criar padrões de design para sua organização | X | X | X |
| Multiplicação de fluxo em transações | Projetar fluxos para operar em relação a coleções | X | X | |
| Considerações sobre fluxos de dados | Aprenda sobre fluxos acionados por agenda para dados em lote | X | X | |
| Depuração de fluxo | Testar e solucionar problemas de fluxos | X | ||
| Como as solicitações são processadas | Saiba como o Salesforce processa trabalhos rapidamente e minimiza falhas | X | X | |
| Modelo de planilha de KPI | Determinar o valor comercial de uma determinada métrica | X | X | |
| Fazendo chamadas a sistemas externos de ações invocáveis | Chamar sistemas externos de um fluxo usando o Apex | X | ||
| Operações de DML mistas | Saiba quais sObjects podem ser usados juntos para DML na mesma transação | X | X | |
| Ordem de Execução | Entenda a ordem dos eventos para inserções, atualizações e inserções e atualizações | X | X | |
| Páginas frequentes do plano de consulta | Otimizar consultas envolvendo grandes volumes de dados | X | X | |
| Considerações sobre fluxo acionado por agenda | Entenda os comportamentos especiais de fluxos acionados por agenda | X | ||
| Controle de transação | Gere um ponto de salvamento que especifique o estado atual do banco de dados | X | X | |
| O que acontece quando um fluxo falha? | Entender o tratamento de erros em fluxos | X | X | |
| Guia de melhores práticas de Automação de fluxo de trabalho | Introdução à automação do Salesforce | X | X | X |
| Trabalhando com consultas SOQL muito grandes | Escreva consultas SOQL mais eficientes | X |
Ajude-nos a manter o Salesforce Well-Architected relevante para você; faça nossa pesquisa para fornecer feedback sobre esse conteúdo e diga-nos o que você gostaria de ver em seguida.