# architect Bem arquitetado (well-architected) - Full Documentation > Leia sobre nossas agendas de atualização [aqui](/docs/architect/pt-br/well-architected/guide/contributors). ## Introdução Uma solução do Salesforce que é **adaptável** evolui com os negócios. Uma solução bem projetada para ser **adaptável** é resiliente e composta. Soluções **resilientes** lidam bem com as mudanças.
As soluções **compostables** ajustam-se rapidamente e com maior estabilidade. A necessidade de mudança de negócio pode vir de muitas fontes: solicitações do cliente, interrupção de mercado ou setor ou oportunidades de transformação digital. Às vezes, as alterações são pequenas. Às vezes, as alterações são profundas. Nos níveis mais profundos, uma mudança pode exigir que as empresas repensem e mudem os principais motivos para operar e reavaliem o que, como e onde oferecer aos clientes. Arquiteturas que são **adaptáveis** não apenas ajudam as empresas a sobreviver e recuperar da interrupção, elas criam o potencial para as empresas inovarem e prosperarem em tempos de profunda mudança. Criar sistemas que sejam **Adaptáveis** requer pensamento arquitetônico profundamente criativo e preciso. Você precisa começar com uma compreensão precisa da trajetória de curto e longo prazo dos negócios. Conforme você avalia os detalhes individuais da implementação, é preciso considerar os impactos em várias dimensões e níveis de detalhes. Você precisa pensar em termos de pessoas, processos e tecnologia. Você precisa prever simultaneamente os impactos nos níveis de macro e micro, para o estado atual e para qualquer estado futuro. As seções a seguir fornecem orientação mais aprofundada para cada um dos comportamentos centrais de uma arquitetura de soluções **adaptável**. ## Visão geral adaptável

Resistente
Soluções resilientes lidam bem com as mudanças. Arquiteturas resilientes podem retornar ao comportamento e operações esperados de maneira rápida e previsível.
Gerenciamento de ciclo de vida do aplicativo	Resposta de incidente	Planejamento de continuidade
Gerenciamento de versão Estratégia ambiental Estratégia de teste	Tempo para recuperar Capacidade de triagem Monitoramento e alerta	Continuidade dos negócios Continuidade da tecnologia
Composto
As soluções compostables são ajustadas rapidamente e com maior estabilidade. As arquiteturas compostables são criadas em unidades que funcionam perfeitamente entre si e podem ser trocadas entre entrar e sair do serviço.
Separação de preocupações	Interoperabilidade	Capacidade de empacotamento
Unidades funcionais Gerenciamento de estado	Mensagens e eventos Gerenciamento de API	Acoplamento solto Gerenciamento de dependência

> Leia sobre nossas agendas de atualização [aqui](/docs/architect/pt-br/well-architected/guide/contributors). ## Introdução 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](/docs/architect/pt-br/well-architected/guide/intentional) 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. ## Eficiência 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](/docs/architect/pt-br/well-architected/guide/composable#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](/docs/architect/pt-br/well-architected/guide/adaptable-overview) 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. ### Design de processos 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](/docs/architect/pt-br/well-architected/guide/automated#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](/docs/architect/pt-br/well-architected/guide/composable#unidades-funcionais)) - Tem resultados claramente definidos e mensuráveis (ver [Valor comercial](/docs/architect/pt-br/well-architected/guide/automated#valor-de-negócios)) - 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](/docs/architect/pt-br/well-architected/guide/composable)) - 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](/docs/architect/pt-br/well-architected/guide/engaging)) - Fornece opções de entrada que os usuários podem entender sem precisar saber como os sistemas subjacentes funcionam (consulte [o útil](/docs/architect/pt-br/well-architected/guide/engaging#útil)) A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/automated#padrões-de-eficiência-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](/docs/architect/pt-br/well-architected/guide/automated#ferramentas-relevantes-para-automatizado). ### Lógica operacional 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](/docs/architect/pt-br/well-architected/guide/reliable) 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](/docs/architect/pt-br/well-architected/guide/intentional#legibilidade) e [padrões de design](/docs/architect/pt-br/well-architected/guide/intentional#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](/docs/architect/pt-br/fundamentals/guide/platform-multitenant-architecture#a-camada-de-dados-da-plataforma). O SOQL pode até mesmo passar [um indicador DML explícito](https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for%20update) 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](/docs/architect/pt-br/well-architected/guide/automated#design-de-processos), 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](/docs/architect/pt-br/well-architected/guide/automated#tratamento-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](/docs/architect/pt-br/well-architected/guide/automated#padrões-de-eficiência-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](/docs/architect/pt-br/well-architected/guide/automated#ferramentas-relevantes-para-automatizado). ### KPIs 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](/docs/architect/pt-br/well-architected/guide/automated#padrões-de-eficiência-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](/docs/architect/pt-br/well-architected/guide/automated#ferramentas-relevantes-para-automatizado). ### Padrões de eficiência e antipadrões 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](/docs/architect/pt-br/well-architected-tools/guide/easy-efficiency).

	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
Projeto de processo	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
KPIs	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

## Integridade de dados 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](/docs/architect/pt-br/fundamentals/guide/architecture-basics#manipulação-de-banco-de-dados) 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](/docs/architect/pt-br/fundamentals/guide/architecture-basics#manipulação-de-banco-de-dados) e de não usar a [funcionalidade padrão](/docs/architect/pt-br/well-architected/guide/intentional#funcionalidade-padrão-versus-personalizada) 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. ### Tratamento de dados O primeiro passo para projetar para o tratamento adequado de dados no Salesforce é entender como a plataforma multitenant lida com [transações](/docs/architect/pt-br/fundamentals/guide/architecture-basics#transações). Isso inclui a compreensão da [ordem de execução](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) 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](/docs/architect/pt-br/fundamentals/guide/architecture-basics#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](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) 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](/docs/architect/pt-br/well-architected/guide/reliable#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_](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm) e use operações assíncronas para todas as ações de contexto _depois_. - Use [mensagens e notificações](/docs/architect/pt-br/well-architected/guide/engaging#notificações-e-mensagens) 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](/docs/architect/pt-br/fundamentals/guide/architecture-basics#contexto-da-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](/docs/architect/pt-br/well-architected/guide/automated#tratamento-de-dados) 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](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm)). 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](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm)". - **Lógica que precisa ser executada no contexto do usuário ou do sistema** - A Salesforce Platform impõe o [compartilhamento e a visibilidade](/docs/architect/pt-br/well-architected/guide/secure#compartilhamento-e-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](https://developer.salesforce.com/docs/atlas.en-us.238.0.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm?q=run%20as%20user) 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](https://help.salesforce.com/s/articleView?id=sf.flow_distribute_context.htm&type=5). 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](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm), [caminhos assíncronos](https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_asynchronous_path.htm&type=5&release=234) ou [ações invocáveis](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm)). - 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_](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm), usando métodos assíncronos do Apex. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/automated#padrões-de-integridade-de-dados-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](/docs/architect/pt-br/well-architected/guide/automated#ferramentas-relevantes-para-automatizado). ### Manipulação de erros 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](/docs/architect/pt-br/well-architected/guide/resilient). 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](/docs/architect/pt-br/well-architected/guide/trusted-overview) 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](/docs/architect/pt-br/well-architected/guide/automated#design-de-processos)). Em vez disso, cada automação no sistema deve ser capaz de se conectar aos [componentes](/docs/architect/pt-br/well-architected/guide/composable#acoplamento-solto) 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](/docs/architect/pt-br/well-architected/guide/automated#padrões-de-integridade-de-dados-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](/docs/architect/pt-br/well-architected/guide/automated#ferramentas-relevantes-para-automatizado). ### Padrões de integridade de dados e antipadrões 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](/docs/architect/pt-br/well-architected-tools/guide/easy-data-integrity).

	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"

## Valor de negócios 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](/docs/architect/pt-br/well-architected/guide/automated#design-de-processos), 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. ## Ferramentas relevantes para Automatizado

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

## Recursos relevantes para automatizados

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

Este é um diagrama que mostra como os tópicos em compostable se relacionam por meio de três cartões aninhados: o cartão mais interno é uma unidade funcional, a camada seguinte é interoperabilidade e a camada externa é empacotabilidade.

Um sistema composto:

## Separação de preocupações Um conceito fundamental na engenharia de software e arquitetura de sistemas, a _separação de preocupações_ implica identificar várias preocupações dentro de um sistema maior que pode ser separado em unidades modulares. Para realizar uma forte separação de preocupações em um sistema, é necessário criar unidades significativas para lógica de aplicativos e funções em todo o sistema. As unidades menores tornam mais fácil para as equipes de entrega e manutenção de aplicativos entenderem como e onde fazer alterações, com interrupções mínimas no sistema maior. As unidades menores também tornam mais claro como e onde focar o trabalho ao lidar com a [débeda técnica](/docs/architect/pt-br/well-architected/guide/intentional#dívido-técnico) e contribuem para a [leitura](/docs/architect/pt-br/well-architected/guide/intentional#legibilidade) geral do seu sistema. Você pode criar uma melhor separação de preocupações em sua organização do Salesforce orientando-a para a funcionalidade de negócios e o estado de gerenciamento. ### Unidades funcionais Para sistemas do Salesforce, a melhor abordagem para a separação de preocupações aplica uma perspectiva orientada para os negócios para identificar e organizar unidades modulares (ou recursos) no sistema. Isso é diferente de uma visualização focada em engenharia, que identifica unidades com base em sua função técnica. Uma perspectiva orientada para os negócios em separação de preocupações exige organizar o código e as personalizações em seu sistema com base no serviço que eles fornecem aos usuários comerciais e comerciais. Adotar essa abordagem não significa ignorar o potencial de funções técnicas redundantes ou duplicadas em um sistema. Em vez disso, isso significa que os serviços técnicos são mapeados claramente para um princípio de organização que seja, por fim, transparente para os negócios. Orientar-se para as funcionalidades de negócios ajuda a garantir que as transferências entre a análise de negócios e as equipes de descoberta para as equipes de entrega sejam o mais simples possível. Se os criadores de aplicativo não tiverem ideia de onde suas unidades de trabalho serão mapeadas para sua arquitetura composível, você terá uma bagunça, não uma paisagem de aplicativo composível. Mapeamentos pouco claros entre o estado final exigido pela empresa e as unidades modulares em uma organização também aumentam as chances de equipes de desenvolvimento ou fornecedores criarem funções redundantes no sistema. Considere o seguinte para orientar as unidades funcionais para a funcionalidade dos negócios: - **Comece com trabalhos a serem feitos**. Concentre-se nos trabalhos a serem feitos (JTBD) dos usuários e na empresa em si. Iniciada por Tony Ulwick, a abordagem do JTBD se concentra na compreensão do "trabalho", ou verdadeiro propósito, que as pessoas estão tentando alcançar usando um produto ou serviço. É um nível mais alto de abstração do que as tarefas relacionadas ao papel dos usuários ou as etapas individuais em um processo de negócios. Por exemplo, tarefas como verificações de duplicados e validações de endereço podem se enquadrar em uma função de ordem superior de "estabelecer uma única visualização do cliente". Depois de ter uma ideia clara desses recursos de negócios de ordem superior, você pode começar a mapear partes do seu sistema para eles. - **Oriente-se às capacidades, não às estruturas de relatórios**. A hierarquia interna de suas unidades de negócios não é um proxy para funcionalidades ou trabalhos significativos a serem feitos. A hierarquia interna de seus negócios tem impacto material em processos e estruturas de equipe (para não mencionar orçamentos). Essas são considerações logísticas importantes. Porém, as necessidades funcionais dos negócios operam em um nível mais alto de abstração do que a logística. Se você estiver criando um módulo para apresentar uma estrutura de relatórios em vez de uma função de ordem superior, esteja ciente de que talvez seja necessário realizar etapas adicionais para identificar como esse módulo se relaciona às funcionalidades de negócios. - **Seja iterativo**. Comece fazendo parceria com a empresa para identificar qual funcionalidade poderia funcionar para um produto mínimo viável (MVP). Ao identificar uma funcionalidade, comece a criar esse MVP. Conforme você cria, identifique os processos, metadados e [eventos ou mensagens](/docs/architect/pt-br/well-architected/guide/composable#mensagens-e-eventos) que são centrais para a unidade funcional que você está criando. Identifique quaisquer processos, metadados e eventos ou mensagens que sejam dependências externas. À medida que unidades mais funcionais são projetadas, implemente o [Gerenciamento de API](/docs/architect/pt-br/well-architected/guide/composable#gerenciamento-de-api) e o [Gerenciamento de dependência](/docs/architect/pt-br/well-architected/guide/composable#gerenciamento-de-dependência) para criar unidades que funcionem bem umas com as outras (em vez de criar unidades isoladas). A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/composable#separação-de-padrões-de-preocupações-e-antipadrões) abaixo mostra qual é a orientação correta (e ruim) para funções de negócios em uma solução do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas. Para saber mais sobre as ferramentas disponíveis do Salesforce para ajudá-lo a se orientar melhor para as funcionalidades de negócios, consulte [Ferramentas relevantes para composáveis](/docs/architect/pt-br/well-architected/guide/composable#ferramentas-relevantes-para-composáveis). ### Gerenciamento de estado O gerenciamento de estado se concentra na movimentação de informações em um sistema em vários pontos no tempo. O gerenciamento de estado eficaz permite que os aplicativos lidem com fluxos complexos de dados ou interações com um mínimo de resultados não planejados ou indeterminados. Gerenciar o estado em uma organização do Salesforce modular significa criar caminhos claros para fluxos de lógica dentro e entre unidades, bem como caminhos elegantes para comportamentos de execução não planejados. O gerenciamento de estado permite formar fluxos de lógica coerentes de unidades de aplicativo do Salesforce modulares. Na maioria dos casos, isso exige [interoperabilidade](/docs/architect/pt-br/well-architected/guide/composable#interoperabilidade) para estruturar o fluxo de informações entre unidades. Dificuldades no gerenciamento de estado entre unidades soltas geralmente levam ao desenvolvimento de aplicativos monolítico no Salesforce. Você pode ver isso em grandes "monofluxos", que são criados em uma tentativa de orquestrar um processo complexo em um fluxo singular. Outro exemplo são classes Apex maciças, que orquestram processos complexos por meio de _código espaguete_, ou uma longa série de métodos de uso único. Esses tipos de arquiteturas de aplicativo dificultam o refator e a depuração e aumentam os tempos de integração para novos membros da equipe ou fornecedores. Eles também reduzem o valor dos aplicativos entregues à empresa, pois a funcionalidade não é reutilizável. Considere o seguinte para gerenciar o estado em uma organização do Salesforce modular: - **Decida quando usar padrões stateful versus stateless**. Os padrões com estado retêm informações em todo o caminho de execução, os padrões sem estado não. Em um sistema solto, padrões sem estado permitem que os componentes sejam refatorados mais rapidamente e com menos efeitos colaterais. No entanto, padrões sem estado não são adequados para todos os casos de uso. Se você estiver criando componentes para operações de dados, os padrões de estado poderão ajudar na integridade e consistência dos dados em todos os seus sistemas. Use um padrão de estado se seu componente atender a qualquer um dos seguintes critérios: - Conhecer o posicionamento em um caminho de execução maior é essencial para o comportamento do componente - O comportamento do componente precisa mudar com base nos resultados de uma ação downstream (por exemplo, ele precisa alterar a execução com base em mensagens de reversão/erro/sucesso de componentes downstream) - O componente precisa aguardar respostas de um sistema externo ou downstream para concluir seu trabalho - **Criar categorias significativas para informações de estado**. _Estado_ é um termo ambíguo que pode ser aplicado a um conjunto tão profundo e amplo de informações dentro (e além) de uma organização do Salesforce que por si só o termo é quase sem significado. Uma primeira etapa necessária para criar padrões de estado, portanto, é criar categorias _significativas_ para os caminhos de execução de estado mais importantes (ou tipos de comportamentos de estado) em seu sistema. Algumas categorias a considerar: - Navegação e formulários - Operações de banco de dados - Operações em lote e em massa - Erros - **Definir estados relacionados a dados em termos de [transações de banco de dados](/docs/architect/pt-br/fundamentals/guide/architecture-basics#manipulação-de-banco-de-dados)**. Os comportamentos integrados da plataforma limitarão a maioria das considerações de estado para dados no Salesforce. Não tente lidar com ou contra esse comportamento. Projetar para e com isso. Projete soluções que minimizam ou eliminam a lógica de transação distribuída. (Consulte [tratamento de dados](/docs/architect/pt-br/well-architected/guide/automated#tratamento-de-dados) para obter mais detalhes). - **Identifique estados que ocorrem dentro (e entre) unidades funcionais**. Conforme você monta unidades funcionais em sistemas maiores, esteja ciente de quando estiver misturando o comportamento do componente sem estado e com estado e evite combinações que possam criar loops ou lacunas infinitas no processamento. - **Definir transferências**. Considere que padrões de [mensagens ou de envio](/docs/architect/pt-br/well-architected/guide/composable#mensagens-e-eventos) os componentes usarão para transmitir dados relacionados a estado para outra parte do sistema. Certifique-se de que você está criando consciência sobre transações e [tratamento](/docs/architect/pt-br/well-architected/guide/automated#tratamento-de-dados) em seus componentes. Não inclua nenhuma lógica de transação distribuída em suas transferências. - **Criar mapeamentos entre seus diagramas de processo e estados**. Os diagramas de processo detalham as etapas que movem as informações pelo seu sistema em vários pontos no tempo. Um diagrama de estado mostra as alterações reais nas informações (o estado). Use a parte do rodapé de metadados dos [Diagramas do Salesforce](/docs/architect/pt-br/reference-diagrams/guide/kit-of-parts) para capturar o estado de alteração das informações em cada etapa do processo. Se você separar diagramas de processo e diagramas de estado, lembre-se de vinculá-los. Esse conceito não deve ser confundido com capturar o estado atual e futuro dos processos ou paisagens do sistema durante o design e a implementação, pois isso não se refere às informações que passam pelo sistema. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/composable#separação-de-padrões-de-preocupações-e-antipadrões) abaixo mostra como é o gerenciamento de estado adequado (e ruim) em uma solução do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar locais em seu sistema que precisam ser refatorados. Para aprender mais sobre ferramentas do Salesforce para gerenciar o estado, consulte [Ferramentas relevantes para composível](/docs/architect/pt-br/well-architected/guide/composable#ferramentas-relevantes-para-composáveis). ### Separação de padrões de preocupações e antipadrões 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 separação de preocupações no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/adaptable-separation-of-concerns).

	Padrões	Antipadrões
Unidades funcionais	Em seus padrões de design: - Convenções de nomenclatura identificam como denotar uma unidade funcional - Existe uma lista de todas as unidades funcionais definidas no momento (e convenções de nomenclatura relacionadas) - Existem padrões para propor alterações ou adições de unidades funcionais	Em seus padrões de design: - Os padrões de design não existem ou não lidam com unidades funcionais e casos de uso
	Na sua documentação: - Os diagramas de paisagem do sistema mostram claramente as unidades funcionais em uma organização - Todos os diagramas de implementação e documentação mostram claramente as unidades funcionais para componentes - A documentação para componentes individuais inclui mapeamento de unidade funcional para o componente - Todos os componentes em uma unidade funcional são pesquisáveis e fáceis de localizar	Na sua documentação: - A documentação do componente não existe - A documentação do componente descreve a unidade funcional à qual um componente pertence, mas esse é o único lugar em que a definição dessa unidade funcional aparece - Você não pode pesquisar uma unidade funcional específica e/ou as pesquisas não ajudam a identificar todos os componentes em uma unidade funcional
	Em sua organização: - É possível identificar rapidamente o alinhamento da unidade funcional para um determinado pedaço de metadados (por exemplo, um fluxo, classe do Apex ou página do Lightning) - As unidades funcionais são rotuladas em termos adequados aos negócios	Em sua organização: - Não é possível identificar o alinhamento da unidade funcional para nenhum metadado - As informações da unidade funcional são inconsistentes ou imprecisas - As informações da unidade funcional são rotuladas em termos focados em engenharia que são sem significado para usuários de negócios
Gestão do Estado	Em seus padrões de design: - Os casos de uso para designs stateful vs. stateless estão claros - Existem padrões aprovados para comunicação sem estado - Existem padrões aprovados para comunicação de estado - Limpe as categorias de estado existentes	Em seus padrões de design: - Os padrões de design não existem ou não lidam com padrões e casos de uso de estado/sem estado
	Na sua documentação: - Cada componente que lida com comunicação de estado e/ou sem estado indica qual padrão foi implementado - É possível pesquisar e localizar todos os componentes que implementaram um padrão stateful/sem estado específico - Os diagramas de processo e interação fornecem detalhes sobre categorias de estado e transferências	Na sua documentação: - A documentação do componente não existe - A documentação do componente descreve o padrão stateful/sem estado implementado, mas esse é o único lugar em que a definição aparece - Não é possível pesquisar um padrão específico e/ou as pesquisas não ajudam a identificar todos os componentes usando esse padrão
	No Apex: - Os pontos de salvamento e os comportamentos de reversão são usados em todas as operações de dados	No Apex: - Os pontos de salvamento e os comportamentos de reversão não são usados
	Em fluxo: - Caminhos de falha e o elemento Reverter registros é usado	Em fluxo: - O elemento Reverter registros não é usado

## Interoperabilidade Em um sistema arquitetado para interoperabilidade, os componentes podem trocar informações e operar juntos de modo eficaz. A interoperabilidade é uma chave para tornar um sistema modular composível em vez de ser isolado. A interoperabilidade pode ser difícil de ser alcançada em um sistema [coplado livremente](/docs/architect/pt-br/well-architected/guide/composable#acoplamento-solto). É necessário estabelecer padrões para métodos consistentes de integração que não minem a independência entre unidades e a [separação de preocupações](/docs/architect/pt-br/well-architected/guide/composable#separação-de-preocupações) em geral em todo o sistema. A interoperabilidade também afeta a qualidade das experiências do usuário. Seus usuários esperam que os dados criados em uma área (como informações do pedido) sejam utilizáveis em outra (como campanhas de marketing), e seus criadores esperam que, se aprenderem a fazer algo (como criar um fluxo ou autenticar-se em uma API), encontrem técnicas familiares que funcionem quando avançarem para o próximo problema. Não projetar para interoperabilidade resultará em arquiteturas redundantes, dados replicados, ineficiências de processo e maiores custos de desenvolvimento e suporte. Você pode criar interoperabilidade em sistemas modulares com mensagens e compromissos, bem como com o gerenciamento de API. ### Mensagens e eventos Mensagens e eventos são duas maneiras de habilitar componentes em um sistema para enviar e receber informações. Em termos do conteúdo que eles podem conter, os eventos e as mensagens são semelhantes. Uma diferença crucial é o comportamento do remetente. Um componente que envia uma _mensagem_ geralmente envia dados para um destino específico e espera algum tipo de resposta do destinatário. Por outro lado, um componente emite um _evento_ quando algo aconteceu. Não há um destino específico nem uma expectativa de uma resposta. Essas diferenças de comportamento dão suporte a diferentes padrões de comunicação. As mensagens oferecem suporte a padrões de comunicação de estado e os eventos oferecem suporte a padrões de comunicação sem estado. (Consulte [Gestão do Estado](/docs/architect/pt-br/well-architected/guide/composable#gerenciamento-de-estado) para saber mais sobre essa distinção.) É importante alinhar as equipes em protocolos e usar casos para mensagens e compromissos. Padrões pouco claros podem resultar em uma combinação de padrões em todo o seu sistema, levando a: - Problemas de desempenho e escalabilidade em que os padrões errados são aplicados a um caso de uso específico - Processamento inconsistente que faz o sistema parecer instável para os usuários finais - Tempos de solução de problemas mais longos e processos de manutenção mais complexos Considere o seguinte ao projetar mensagens e eventos para criar estruturas mais soltas na sua organização do Salesforce: - **Identifique casos de uso assíncronos e sincronizados**. O uso de eventos permite comunicações sem estado e assíncronas em um sistema. O Messaging permite padrões mais controlados, de estado e síncronos de comunicação. Ao decidir quando usar mensagens ou eventos, você precisa decidir se sua comunicação precisa ser síncrona (e potencialmente bloqueadora) em vez de assíncrona e não bloqueadora. - **Defina estruturas de dados cuidadosamente**. A estrutura das informações que os componentes passam entre eles é uma parte importante de manter um sistema de fácil gerenciamento e coerência. (Consulte Gerenciamento de [API](/docs/architect/pt-br/well-architected/guide/composable#gerenciamento-de-api) para saber mais sobre isso.) Uma consideração importante ao projetar uma mensagem ou evento é a frequência com que a estrutura das informações pode precisar mudar. Depois que uma estrutura de mensagem ou evento é definida e implementada em seu sistema, pode ser difícil lidar com atualizações, especialmente se o evento ou a mensagem já estiver sendo usada para enviar informações a um sistema externo. - **Mensagens do tamanho certo**. Em geral, é uma prática recomendada manter os tamanhos de mensagem pequenos. No entanto, também há um equilíbrio entre o _tamanho_ da mensagem e o _volume_ da mensagem. Os sistemas podem processar quantidades menores de dados mais rapidamente. O ato de processamento vem com uma quantidade adicional de sobrecarga, pois os destinatários precisam desempacotar, interpretar e determinar o que fazer com as informações que receberam. Essas etapas podem levar um tempo insignificante para serem concluídas, mas podem acumular e criar um fardo nos sistemas em escala. Evite projetos que exigem que os componentes do sistema processem muitas mensagens pequenas em sequência para concluir um trabalho. Para ajustar o tamanho certo das suas mensagens, pense em projetar para os componentes de dados downstream que precisarão processar e agir com sucesso com base nas informações que foram enviadas, sem também presumir que cada componente downstream possa solicitar ou processar várias mensagens de acompanhamento. - **Design para escalabilidade**. Componentes soltos podem facilitar a escala da sua arquitetura. A eliminação de dependências entre componentes permite que as equipes trabalhem para melhorar o desempenho ou a escalabilidade de qualquer componente individual com efeitos mínimos sobre os outros. No entanto, componentes soltos também introduzem uma complexidade significativa em sua arquitetura em escala (especialmente quando se trata de [gerenciar estado](/docs/architect/pt-br/well-architected/guide/composable#gerenciamento-de-estado)). Identifique processos que precisam ter lógica ou dependências mais acopladas por motivos válidos de experiência do usuário ou integridade de dados e não tente introduzir padrões assíncronos/compromissados nesses processos. Use padrões baseados em sincronização/mensagem e tratamento de erro adequado. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/composable#padrões-de-interoperabilidade-e-antipadrões) abaixo mostra a aparência de mensagens e eventos adequados (e ruins) em uma solução do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar locais em seu sistema que precisam ser refatorados. Para saber mais sobre as ferramentas de mensagens e agendamento do Salesforce, consulte [Ferramentas relevantes para composáveis](/docs/architect/pt-br/well-architected/guide/composable#ferramentas-relevantes-para-composáveis). Para obter mais informações sobre a escolha de um padrão ou ferramenta de evento para um determinado caso de uso, consulte o Guia do [arquiteto para arquitetura orientada por evento com o Salesforce](/docs/architect/pt-br/decision-guides/guide/event-driven#key-takeaways). ### Gerenciamento de API A criação do gerenciamento adequado da interface de programação de aplicativo (API) em uma solução do Salesforce permite que componentes individuais do seu sistema sigam padrões de comunicação previsíveis. O Salesforce fornece APIs integradas e seguras para usar para comunicação com sistemas fora do Salesforce. (Para obter mais informações sobre as APIs da Salesforce Platform, consulte [As noções básicas de arquitetura](/docs/architect/pt-br/fundamentals/guide/architecture-basics#apis-da-plataforma).) O gerenciamento de API eficaz nas soluções do Salesforce é fundamental para criar arquiteturas verdadeiramente composíveis. Ele permite que componentes dentro de uma organização do Salesforce enviem e recebam informações com eficiência. Também permite que os criadores de soluções sigam protocolos claros para como os componentes que eles criam se comunicam com outros componentes no sistema e os ajuda a identificar implementações ruins mais cedo. Além disso, ele permite que os criadores de soluções se concentrem mais estreitamente no componente em particular que estão criando ou refatorando, o que aumenta a produtividade e a qualidade. O Gerenciamento de API no nível corporativo é um tópico separado e é melhor feito com uma ferramenta abrangente de Gerenciamento de API. (Para obter mais informações sobre a perspectiva da MuleSoft sobre este tópico, consulte [O que é Gerenciamento de API?](https://www.mulesoft.com/resources/api/what-is-api-management#:~:text=API%20management%20is%20the%20process,create%20are%20consumable%20and%20secure.).) Considere o seguinte para criar funcionalidades de gerenciamento de API em suas soluções do Salesforce: - **Pense nas APIs como padrões ou contratos de comunicação _previsíveis_**. O tipo de dados de variáveis de entrada ou saída, os nomes de variáveis, as informações que devem (ou não devem) aparecer em um determinado padrão são as chaves para um gerenciamento de API eficaz. Essas definições devem aparecer em seus padrões de design e as equipes devem poder descobrir como essas definições foram implementadas em partes específicas do seu sistema por meio de sua documentação. Uma maneira de visualizar as dificuldades de mesclar alterações de um novo desenvolvimento em um ambiente de integração é olhar para elas como evidência de onde as comunicações da API foram mal implementadas (ou talvez nenhuma definição de API). - **Não limite seu pensamento sobre APIs a código exclusivo**. O que define uma API nesse contexto é a consistência das estruturas e variáveis de mensagens nessa mensagem. Desde que essa consistência seja mantida, uma API pode ser implementada em código, bem como em personalizações declarativas, como fluxos modulares iniciados automaticamente (ou acionados por evento de plataforma) ou mesmo modelos de fluxo. Baseie suas decisões sobre o que definir em código versus em fluxos não na implementação da API, mas na [capacidade do pacote](/docs/architect/pt-br/well-architected/guide/composable#capacidade-de-empacotamento) e na [testabilidade](/docs/architect/pt-br/well-architected/guide/resilient#gerenciamento-de-ciclo-de-vida-do-aplicativo). - **Mantenha seu ciclo de vida e controle de versão simples**. Como todas as partes do desenvolvimento de aplicativo, as APIs têm um ciclo de vida: definir, criar, testar, implementar e manter (incluindo descontinuação). As APIs da Salesforce Platform lançam várias versões em um ano calendário, devido ao rápido ciclo de lançamento da plataforma. (Você pode ler mais sobre esse comportamento em Noções básicas de [arquitetura do](/docs/architect/pt-br/fundamentals/guide/architecture-basics#apis-da-plataforma) Salesforce.) Isso significa que as APIs da plataforma têm um ciclo de vida bastante complexo, pois várias versões de uma determinada API precisam ser mantidas e disponibilizadas para clientes do Salesforce. Esse nível de complexidade é adequado para casos de uso de PaaS, mas provavelmente é uma complexidade desnecessária para suas arquiteturas de soluções na plataforma (consulte: [Anti-patterns de legibilidade](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-legibilidade-e-antipadrões)). Concentre-se em definir um propósito claro para uma API (por exemplo, tratamento de erros) e definições de linha de base claras. Tente ter apenas uma versão de cada API. - **Faça suas APIs descobríveis, acessíveis e gerenciáveis**. [Documente suas APIs](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-design) para que os clientes em potencial possam encontrar APIs disponíveis conectando-se facilmente a eles. As APIs precisam funcionar sem problemas como parte de uma paisagem de [capacidades](/docs/architect/pt-br/well-architected/guide/composable#unidades-funcionais). - **Seja iterativo**. Concentre-se em definir e implementar apenas uma API interna por vez. Dessa forma, você pode se concentrar em iterar a definição de API rapidamente, encontrar o formulário certo para sua versão com suporte _uma_ e estabelecer práticas recomendadas com base na experiência de implementação. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/composable#padrões-de-interoperabilidade-e-antipadrões) abaixo mostra como é o gerenciamento de API adequado (e ruim) em uma solução do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas. Para saber mais sobre as ferramentas disponíveis do Salesforce para ajudá-lo a criar mais interoperabilidade, consulte [Ferramentas relevantes para composáveis](/docs/architect/pt-br/well-architected/guide/composable#ferramentas-relevantes-para-composáveis). ### Padrões de interoperabilidade e antipadrões 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 interoperabilidade no [Pattern & Anti-Pattern Explorer](/docs/architect/pt-br/well-architected-tools/guide/adaptable-interoperability).

	Padrões	Antipadrões
Mensagens e Eventos	Em seus padrões de design: - Existem padrões claros para quando usar padrões síncronos (messaging) e padrões assíncronos (eventing) - Existem padrões claros para estruturas de eventos e mensagens	Em seus padrões de design: - Não existem padrões de design ou eles não têm padrões claros para padrões de sincronização vs. assíncronos e padrões claros para estruturas de mensagem ou evento
	Em sua organização: - Eventos de plataforma usados para mensagens internas do sistema são rotulados claramente - Ferramentas do Salesforce Flow fazem referência a serviços de mensagens ou compromissos de todo o sistema - Padrões consistentes de mensagens e compromissos aparecem em fluxos e códigos	Em sua organização: - Eventos de plataforma usados para mensagens internas do sistema não são rotulados claramente ou não existem - Diferentes estratégias para padrões de mensagens e compromissos aparecem em fluxo e código
	No Apex ou LWC: - Definições de evento personalizadas têm escopo limitado (nenhum evento ou mensagem de todo o sistema é definido em código) - Serviços de mensagens ou eventos em todo o sistema no Apex são anotados de maneiras que os tornam disponíveis nas ferramentas do Salesforce Flow	No Apex ou LWC: - Estruturas de mensagens e/ou eventos de todo o sistema são definidas no Apex ou JavaScript - As estruturas de eventos ou mensagens definidas no Apex não estão disponíveis em ferramentas como o fluxo
Gerenciamento de API	Em seus padrões de design: - Existem protocolos claros para comunicação entre componentes (ou seja, APIs) - Os protocolos/APIs são descritos em grupos lógicos que os criadores podem pesquisar e localizar - Os protocolos/APIs definem tipos de dados variáveis, nomes de variáveis, o que é obrigatório ou opcional e fornecem uma descrição clara de quando usar	Em seus padrões de design: - Os padrões de design não existem ou não definem APIs e casos de uso
	Na sua documentação: - A documentação de cada componente lista claramente qual protocolo de API/comunicação foi implementado - É possível pesquisar uma API ou protocolo específico e identificar componentes em que ele é implementado	Na sua documentação: - A documentação do componente não existe - A documentação do componente descreve a API implementada em um componente, mas esse é o único lugar em que a definição da API aparece - Não é possível pesquisar uma API ou protocolo específico e/ou as pesquisas não ajudam a identificar componentes em que uma API ou protocolo foi implementado
	Em sua organização: - Formatos de mensagem de API e variáveis para comunicação interna são definidos com tipos de metadados personalizados - Formatos de mensagem de API e variáveis para comunicação interna são definidos com eventos de plataforma - Personalizações declarativas e de código fazem referência ao tipo de metadados personalizados apropriado (ou evento de plataforma) para enviar ou receber informações	Em sua organização: - A comunicação entre componentes do sistema (código e personalizações declarativas) é ad hoc - As APIs são definidas exclusivamente para comunicação entre o Salesforce e sistemas externos

## Capacidade de empacotamento Criar capacidade de empacotamento em uma organização do Salesforce significa que a funcionalidade na organização vem de unidades que podem ser desenvolvidas e implementadas de modo independente e confiável, como pacotes. Idealmente, essas unidades são definidas como um tipo de pacote de [segunda geração](https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_pkg_types.htm) (um pacote desbloqueado ou pacote gerenciado para ISVs). Nota: Como soluções bem projetadas usam esses tipos de pacote exclusivamente, os pacotes gerenciados de primeira geração não são abordados aqui. É uma coisa definir [separações de preocupações](/docs/architect/pt-br/well-architected/guide/composable#separação-de-preocupações) e criar unidades funcionais em uma organização do Salesforce. Outra coisa é limpar e gerenciar as dependências com clareza suficiente para fazer a versão dessas unidades com sucesso como artefatos de pacote. Para atingir esse nível de estabilidade e isolamento de metadados, é necessário um nível significativo de maturidade de DevOps (e arquitetônica). Também acelera o tempo de desenvolvimento, melhora as experiências do criador de aplicativos e proporciona previsibilidade e controle a versões e gerenciamento de versão. Nem todas as organizações poderão dar suporte à infraestrutura necessária para definir, manter e desenvolver pacotes eficazes. Porém, alcançar a capacidade de empacotamento deve ser a meta final para quase todas as organizações do Salesforce. Você pode criar capacidade de empacotamento em suas soluções do Salesforce focando acoplamento flexível e gerenciamento de dependência. ### Acoplamento solto Em um sistema com acoplamento solto, as partes individuais não estão fortemente vinculadas umas às outras. Muitas das vantagens de um sistema composível derivam do acoplamento solto. Em sistemas empacotáveis, conseguir acoplamento flexível entre pacotes (e instalação de organizações) permitirá que você tenha pacotes bem definidos e ciclos de desenvolvimento mais produtivos para equipes que trabalham com pacotes. Na Salesforce Platform, você pode criar pacotes que estão [acoplados a uma organização específica](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_org_dependent.htm). Essa funcionalidade é útil para definir unidades funcionais e experimentar com a [separação adequada de preocupações](/docs/architect/pt-br/well-architected/guide/composable#separação-de-preocupações) em sua organização conforme você avança na maturidade do empacotamento. No entanto, se você escolher essa abordagem, perceberá poucos dos benefícios de metadados verdadeiramente empacotáveis, incluindo desenvolvimento conduzido por origem, capacidade de usar controle de versões e estabilidade de artefatos. Em vez disso, você provavelmente continuará experimentando as desvantagens de um sistema fortemente acoplado, incluindo: - Pontos únicos de falha causando falhas e problemas de desempenho - Implantações lentas e imprevisíveis - Ciclos de depuração e resolução de problemas difíceis e complexos - Problemas de [escala](/docs/architect/pt-br/well-architected/guide/reliable#escalabilidade) e [desempenho](/docs/architect/pt-br/well-architected/guide/reliable#desempenho) A meta final para qualquer sistema do Salesforce empacotável são pacotes soltos. Considere o seguinte ao analisar a separação de metadados do Salesforce em pacotes eficazes: - **Quais personalizações são dados versus metadados**. Quando se trata de capacidade de empacotamento, a Salesforce Platform trata dados e metadados de maneira muito diferente. É importante entender quais recursos em sua organização são [metadados ou dados](/docs/architect/pt-br/fundamentals/guide/architecture-basics#metadados-versus-dados). Você não pode incluir dados em nenhuma unidade empacotada. Conforme você decide onde começar a abstrair a funcionalidade em uma unidade empacotada, suas equipes precisarão decidir se as personalizações armazenadas como dados devem ser excluídas do pacote totalmente ou refatoradas em uma implementação baseada em metadados. - **Como a embalagem afetará as equipes**. Uma realidade logística do empacotamento do Salesforce é que grande parte do trabalho de produzir e lançar uma versão de pacote requer conhecimento das tecnologias Salesforce CLI e/ou CI/CD. Isso significa que personalizações programáticas e de baixa codificação exigirão tempo e atenção de alguém capaz de trabalhar com a tecnologia DevOps relacionada ao pacote. Dependendo de como sua equipe gerencia a entrega de recursos, a adoção do pacote pode apresentar atrasos ou bloqueadores significativos para diferentes equipes em uma organização. Você precisará identificar se as equipes conseguirão gerenciar a entrega de recursos por meio de empacotamento e criar um plano para lidar com qualquer lacuna de habilidades ou equipe. As soluções podem incluir adotar a programação combinada ou implementar trabalhos de CI/CD para ambientes de desenvolvimento. - **Como as embalagens mudarão as estratégias ambientais**. Em um ciclo de vida de desenvolvimento orientado por pacote, o trabalho inicial deve ser feito em [organizações teste](https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_setup.meta/sfdx_setup/sfdx_setup_next_steps.htm?q=scratch%20org). Esses ambientes de desenvolvimento temporários orientados por origem permitem ciclos mais rápidos e iterativos. Eles também oferecem suporte a controles de acesso de ambiente mais granulares para suas equipes de desenvolvimento e maior isolamento da produção. Quanto mais dependências seus pacotes tiverem sobre metadados desempacotados ou dados que existam apenas em um ambiente de sandbox ou produção, menor será a probabilidade de que as equipes possam, na verdade, usar organizações teste. Você pode [habilitar o rastreamento de origem em sandboxes](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm), para permitir padrões de desenvolvimento orientados por origem em ambientes de organização não teste, mas suas equipes de desenvolvimento não se beneficiarão da velocidade e da velocidade iterativa de organizações teste. - **Como as versões do pacote se relacionam às versões**. Planeje com que frequência e em que estágio do controle de versão do pacote de desenvolvimento deve ocorrer. As solicitações de versão do pacote são limitadas (por organização) em 24 horas seguidas. Como prática recomendada geral, faça a versão de um pacote apenas quando estiver confiante de que nenhum conteúdo do pacote precisa ser alterado. O ideal é provisionar versões do pacote após a conclusão dos processos de garantia de qualidade. Não permita que as equipes de desenvolvimento usem o sucesso ou a falha de solicitações de criação de pacote como "testes" de quão bem elas definiram os limites do pacote. Há maneiras de fazer isso sem tentar fazer a versão de um artefato de pacote. - **O que o estado final ideal deve apoiar**. A estratégia de empacotamento ideal permite versões controladas e estáveis do Salesforce que podem ser desenvolvidas e entregues rapidamente. Definir um número excessivo de pacotes em toda a sua organização pode gerar novos tipos de complexidade e gargalos para as equipes de desenvolvimento. Uma organização excessivamente modularizada também pode fazer com que as versões sejam lentas e difíceis. Comece criando e lançando algumas versões de um único pacote significativo. Derive pacotes de acompanhamento incrementalmente. Pare de apresentar pacotes quando tiver um ritmo de versão que atenda bem ao seu negócio. Pacotes de reator ao longo do tempo, se as necessidades de negócios mudarem ou se a qualidade da versão diminuir. O estado de extremidade ideal do pacote é subjetivo. Independentemente de como você decidir definir seus pacotes, você só terá sucesso na versão de um pacote solto por meio de um [gerenciamento de dependências](/docs/architect/pt-br/well-architected/guide/composable#gerenciamento-de-dependência) eficaz. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/composable#padrões-de-capacidade-de-empacotamento-e-antipadrões) abaixo mostra a aparência correta (e ruim) do acoplamento solto para empacotamento do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas. Para saber mais sobre ferramentas do Salesforce para ajudá-lo a criar mais capacidade de empacotamento, consulte [Ferramentas relevantes para componíveis](/docs/architect/pt-br/well-architected/guide/composable#ferramentas-relevantes-para-composáveis). ### Gerenciamento de dependência No contexto de uma solução do Salesforce, o gerenciamento de dependência significa identificar e estruturar os relacionamentos entre os metadados em seus pacotes e os metadados nas organizações em que esses pacotes serão instalados. O gerenciamento de dependência é uma parte importante do desenvolvimento de artefatos de pacote estáveis. Dependências podem estar em conflito com esforços para criar unidades funcionais perfeitamente separadas, [copladas livremente](/docs/architect/pt-br/well-architected/guide/composable#acoplamento-solto). Em um estado de engenharia ideal, um sistema solto não tem dependências entre unidades. No mundo real, porém, eliminar todas as dependências não é prático. Muitas vezes, o equilíbrio entre tornar os sistemas [legíveis](/docs/architect/pt-br/well-architected/guide/intentional#legibilidade) e usar [unidades funcionais](/docs/architect/pt-br/well-architected/guide/composable#unidades-funcionais) fáceis de usar requer uma compensação em termos de isolamento perfeito entre as unidades em um sistema. Mais pragmatisticamente, os serviços centrais fornecidos pela [funcionalidade padrão](/docs/architect/pt-br/well-architected/guide/intentional#funcionalidade-padrão-versus-personalizada) da Salesforce Platform criam dependências chave e líquidas positivas para qualquer solução do Salesforce. Muitas vantagens de escalabilidade, desempenho e segurança integrados vêm da profundidade em que são integrados à plataforma. Ao projetar soluções do Salesforce empacotáveis, é importante lembrar que as dependências de pacote não são inerentemente ruins. Uma má gestão de dependência _é_ ruim. O gerenciamento de dependência eficaz com o empacotamento do Salesforce significa que as equipes de desenvolvimento e manutenção podem: - Integre a novos projetos mais rapidamente e com acesso limitado ao ambiente - Desenvolva e teste alterações rapidamente - Entenda como a funcionalidade complexa deve ser fornecida em compromissos menores e específicos - Controlar ritmos de versão e reduzir janelas de falha de manutenção/lançamento do sistema - Alterações adversas de reversão previsíveis em qualquer ambiente As técnicas para gerenciamento de dependência com o Salesforce são bastante simples: - Use o [messaging e o Eventing](/docs/architect/pt-br/well-architected/guide/composable#mensagens-e-eventos) para lidar com transferências simples de informações de estado ou sem estado entre componentes. - Use tipos de metadados personalizados para fornecer informações dinâmicas de tempo de execução e dar suporte a padrões de injeção de dependência. - Permita que os desenvolvedores do Apex usem [classes abstratas ou virtuais](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_extending.htm). No final, você precisará decidir os padrões de design que são permitidos em sua organização em desenvolvimento declarativo e programático. As considerações mais importantes (arquitetonicamente) são definir onde você deseja adicionar mais complexidade de engenharia para ter menos dependências e onde você precisa tolerar mais dependências para simplificar os fluxos de trabalho do criador de aplicativos. Conforme você cria estratégias de gerenciamento de dependência em seus pacotes, considere os dois principais princípios de organização para unidades de pacote: horizontal e vertical. - **Limites horizontais**. Em paradigmas horizontais, a funcionalidade que pode ser necessária para mais de um pacote é extraída para uma camada horizontal. As camadas horizontais então se tornam a origem da funcionalidade comum e são acessadas por meio de uma dependência declarada. Minimizar a funcionalidade redundante entre pacotes é favorável em vez de minimizar as dependências. - **Limitas verticais**. Os paradigmas verticais maximizam o isolamento e o acoplamento entre partes do sistema. A funcionalidade compartilhada é limitada e trabalho semelhante pode aparecer entre unidades. As dependências são estritamente limitadas, a fim de maximizar o isolamento entre as unidades do pacote. Observe que essa não é uma ou mais decisões. Você pode combinar paradigmas verticais e horizontais conforme necessário. Geralmente, a maneira mais rápida de começar um pacote é criar camadas horizontais de serviço. Conforme a escala e a complexidade da adoção do pacote aumentam, a abstração de mais unidades verticais ajudará a simplificar processos complexos de configuração de ambiente ou integração do desenvolvedor. Um sistema com duas unidades funcionais (A e B), por exemplo, pode ser estruturado com dependências de pacote organizadas em paradigmas híbridos vertical, horizontal e vertical-horizontal.

Este é um diagrama mostrando dois pacotes, A e B, construídos para não ter dependências compartilhadas (fatia vertical), construídos para ter muitos serviços comuns (horizontal) e uma mistura de cada um (híbrido).

Independentemente do paradigma de organização de pacote que você escolher, há alguns absolutos a serem considerados: - **Não duplique metadados entre pacotes**. Os metadados necessários para mais de um pacote devem ser extraídos para um ou mais pacotes declarados como dependências. - **Use as dependências integradas dos metadados da Salesforce Platform**. Para criadores de aplicativos, os serviços integrados oferecidos pela Salesforce Platform fornecem uma grande quantidade de funcionalidades que podem ser configuradas rapidamente. Muitos desses serviços têm dependências integradas que os tornam difíceis de abstrair em unidades funcionais de baixo nível. Para um determinado tipo de metadados, você precisa entender onde ele se enquadra no [espectro de dependências integradas](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail) e usar esse entendimento para [definição de cadeias de dependências de pacote](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2). Não comece a adoção do pacote tentando forçar o acoplamento solto em uma funcionalidade de plataforma padrão com muitas dependências integradas. Ele aumentará a complexidade (não o valor) à medida que você alcança funcionalidades de ordem superior. É também outra maneira de cair em [padrão vs. custom](/docs/architect/pt-br/well-architected/guide/intentional#funcionalidade-padrão-versus-personalizada) [anti-padrões](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-capacidade-de-manutenção-e-antipadrões). Empacote metadados de baixo para cima (menos dependências) e itere ao longo do tempo. - **Cuidado com suas cadeias de dependência**. Evite criar cadeias de dependência de pacote que exigem que os desenvolvedores dividam suas alterações em muitos pacotes diferentes a qualquer momento. - **Pense sobre o que faz sentido para o controle de origem**. Há duas maneiras básicas de gerenciar seus pacotes no controle de origem. O primeiro é um único _monorepo_ com pacotes isolados dentro de pastas. A segunda é de vários repositórios com pacotes isolados em seu próprio repositório. Há complexidades para gerenciar cada tipo de estratégia de origem a longo prazo. Em termos de integração do desenvolvedor, os limites verticais são mais eficientes em vários paradigmas de repositório. Os limites horizontais são mais compreensíveis em um monorrepo. Novamente, você pode combinar e combinar estratégias conforme sua arquitetura amadurece. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/composable#padrões-de-capacidade-de-empacotamento-e-antipadrões) abaixo mostra como é o gerenciamento de dependência adequado (e ruim) com pacotes do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas. Para aprender mais sobre ferramentas do Salesforce para gerenciamento de dependência, consulte [Ferramentas relevantes para componíveis](/docs/architect/pt-br/well-architected/guide/composable#ferramentas-relevantes-para-composáveis). ### Padrões de capacidade de empacotamento e antipadrões 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 empacotamento no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/adaptable-packageability).

	Padrões	Antipadrões
Acoplamento solto	Em seus padrões de design: - Convenções de nomenclatura endereçam como denotar unidades de pacote - É possível pesquisar e localizar uma lista de todas as unidades de pacote definidas no momento (e convenções de nomenclatura relacionadas) - Existem padrões para propor alterações ou adições à unidade do pacote - (Opcional) Todos os casos de uso aprovados para configurações personalizadas são listados claramente (se houver)	Em seus padrões de design: - Os padrões de design não existem ou não lidam com unidades de pacote e casos de uso
	Em sua organização: - Os tipos de metadados personalizados fornecem informações dinâmicas de tempo de execução para personalizações declarativas e de código - Não há configurações personalizadas ou poucas configurações personalizadas e nenhuma está relacionada à funcionalidade do pacote - Não existem objetos personalizados para fornecer informações dinâmicas de tempo de execução para personalizações declarativas ou de código	Em sua organização: - As configurações personalizadas são usadas - Existem objetos personalizados para fornecer informações dinâmicas de tempo de execução para personalizações declarativas ou de código - Os tipos de metadados personalizados não são usados (ou não são usados de maneira consistente) para fornecer informações dinâmicas de tempo de execução para personalizações declarativas e de código
	No Apex: - Serviços comuns e código de caldeira são definidos usando classes abstratas ou virtuais do Apex - Métodos dependentes de informações dinâmicas de tempo de execução fazem referência a tipos de metadados personalizados apropriados	No Apex: - Serviços comuns e código de caldeira não são facilmente distinguidos de outras classes - Referências internas entre classes e métodos são difíceis de seguir e são inconsistentes em toda a base de códigos - Os métodos não usam uma abordagem consistente para acessar informações dinâmicas de tempo de execução ou consultam objetos personalizados para informações de comportamento de tempo de execução, ou o código faz referência a configurações personalizadas
	Em ambientes de controle e desenvolvimento de origem: - arquivos package.xml aparecem apenas em manifestos de projeto de prova de conceito ou estágio inicial	Em ambientes de controle e desenvolvimento de origem: - arquivos package.xml são usados para controlar implantações de metadados
	Em embalagens: - Pacotes desbloqueados dependentes da organização são usados apenas para experiências de estágio inicial ou de prova de conceito - Nenhum pacote não gerenciado é definido em produção ou sandboxes	Em embalagens: - Todos os pacotes são pacotes desbloqueados dependentes da organização - Os pacotes não gerenciados são definidos em produção ou sandboxes
Gerenciamento de dependência	Em seus padrões de design: - Existem padrões para declarar dependências - Existem padrões para introduzir ou modificar dependências	Em seus padrões de design: - Os padrões de design não existem ou não tratam de como declarar dependências
	No controle de origem: - Versões de pacote para pacotes desbloqueados usam alias (`LATEST`) para declarar dependências em manifestos `sfdx-project.json` - Os desenvolvedores podem criar organizações teste e implementar metadados de pacote com sucesso a partir do controle de origem	No controle de origem: - Versões de pacote para pacotes desbloqueados são declaradas explicitamente (sem alias `ÚLTIMO`) nos manifestos `sfdx-project.json` - Os desenvolvedores não podem trabalhar com sucesso com organizações teste usando o controle de origem
	Em seus pacotes: - Nenhum metadado é duplicado entre pacotes - Para desenvolvimento de pacote, todo o trabalho de desenvolvimento de estágio inicial acontece em organizações teste	Em seus pacotes: - As dependências são contornadas duplicando metadados em diferentes pacotes - O desenvolvimento de pacotes iniciais acontece em sandboxes do desenvolvedor ou o desenvolvimento de pacotes iniciais não pode acontecer em organizações teste
	Consulte também: Acoplamento solto

## Ferramentas relevantes para composáveis

Ferramenta	Descrição	Separação de preocupações	Interoperabilidade	Capacidade de empacotamento
Serviços da Web REST do Apex	Exponha suas classes e métodos do Apex a aplicativos externos por meio do REST		X
Serviços da Web SOAP do Apex	Exponha suas classes e métodos do Apex a aplicativos externos por meio do SOAP		X
Captura de dados de alteração	Publicar alterações em registros do Salesforce		X
Tipo de metadados personalizados	Definir a funcionalidade reutilizável, personalizável e empacotável			X
Decorações	Expor funções ou propriedades publicamente como uma API	X	X
Dev Hub	Gerencie organizações teste, pacotes de segunda geração e recursos do Einstein.	X	X	X
Eventos genéricos (legado)*	Enviar eventos personalizados que não estejam vinculados a alterações de dados do Salesforce		X
Lightning Data Service	Armazenar em cache e compartilhar dados entre componentes	X	X
Metadata API	Implementar personalizações entre ambientes do Salesforce			X
Relatório de cobertura de metadados	Determine a cobertura de metadados com suporte em vários canais			X
MuleSoft Composer	Crie automação de processo para dados usando cliques em vez de código		X
Mensagens de saída	Envie mensagens para pontos de extremidade externos quando os valores de campo forem atualizados		X
Eventos de plataforma	Envie mensagens seguras e escalonáveis que contenham dados de evento quase em tempo real		X
Pub/Sub API	Assine eventos de plataforma, Captura de dados de alteração ou Monitoramento de evento em tempo real		X
Eventos PushTopic (Legado)*	Enviar e receber notificações de alteração de data que correspondem a uma consulta SOQL definida pelo usuário		X
Salesforce CLI	Desenvolva e crie automação ao trabalhar com sua organização do Salesforce			X
Diagramas do Salesforce	Criar diagramas para mostrar funcionalidades de negócios e detalhes técnicos	X
Extensões do Salesforce para Visual Studio Code (expandido)	Extensões oficiais do VS Code para desenvolvimento do Salesforce			X
Organizações de rascunho	Implemente o código e os metadados do Salesforce em uma organização descartável			X
Pacotes gerenciados de segunda geração	Desenvolver e distribuir aplicativos para o AppExchange			X
API do conjunto de ferramentas	Criar ferramentas ou aplicativos de desenvolvimento personalizados para aplicativos da Plataforma do Lightning			X
Pacotes desbloqueados	Organizar metadados, empacotar um aplicativo ou estender um aplicativo AppExchange			X
*A Salesforce continuará oferecendo suporte a eventos PushTopic e genéricos nos recursos funcionais atuais, mas não planeja fazer mais investimentos nessa tecnologia.

## Recursos relevantes para composáveis

Recurso	Descrição	Separação de preocupações	Interoperabilidade	Capacidade de empacotamento
Uma visão primitiva da Integração Digital	Desenvolver uma linguagem comum para conceitos de conectividade		X
Aplicar design baseado em domínio com o Salesforce	Oriente suas soluções em torno de funcionalidades de negócios	X
Práticas recomendadas para pacotes de segunda geração	Entender os padrões e práticas de empacotamento 2GP			X
Componentes disponíveis em pacotes gerenciados	Entender os componentes de metadados de pacote gerenciado			X
Modelo de padrões de design	Criar padrões de design para sua organização	X	X	X
Guia de decisão de arquitetura orientada por evento	Comparar padrões e ferramentas de arquitetura conduzida por evento		X
Anti-padrões de eventos	Identifique antipadrões para evitar ao usar eventos		X
Como projetar APIs orientadas por mensagem e por evento	Leia sobre as diferenças em um guia de desenvolvimento do MuleSoft	X	X
Conheça a estrutura de trabalhos a serem feitos	Explore JTBD no Trailhead	X
Gerenciar estado global no B2C Commerce	Passe facilmente dados entre componentes para manter o estado	X
Directivas de mensagens	Comunique informações relevantes e crie momentos de prazer		X
Tipo de mensagens	Entenda diferentes tipos de mensagens pela natureza da interação do usuário		X
Tipo de metadados	Entenda os diferentes tipos de metadados em sua organização do Salesforce	X		X
Tipo de notificação de aplicativo móvel	Entenda os tipos de notificação para aplicativos Salesforce móvel		X
Otimização do estado de visualização	Manter o estado em uma página do Visualforce	X
Experiência do desenvolvedor do Salesforce (DX)	Gerenciar e desenvolver aplicativos na Plataforma do Lightning	X	X	X
Tipo de metadados sem suporte	Identifique componentes que não estão disponíveis na API de metadados			X

Classificação/Tipo do acionador	Mitigação
Pessoas	Política
Processo	Playbooks, planos de continuidade
Tecnologia	Redundância

- **Identifique qual é a mitigação básica, intermediária e madura**. Vai levar tempo para criar estratégias de mitigação. Defina os níveis de mitigação para ajudá-lo e sua equipe a ver onde você pode colocar controles em vigor imediatamente e como focar seus esforços ao longo do tempo. Sempre procure oportunidades para usar automação em suas abordagens de mitigação assim que possível. Para ilustrar a aparência dessa abordagem na prática, este exemplo mostra um acionador orientado para pessoas e a aparência da mitigação baseada em política nos níveis básico, intermediário e maduro.

Acionador	Mitigação	Básico	Intermediário	Maduro
Alteração de acesso do usuário para um funcionário novo ou que saiu	Contrato de nível de serviço (SLA) e requisitos para provisionamento ou desprovisionamento de usuários	Provisione e desprovisione usuários manualmente, de acordo com os SLAs para alterações manuais.	Processe as alterações do usuário por meio de trabalhos agendados, de acordo com os SLAs para alterações agendadas.	Automatize o provisionamento e o desprovisionamento de usuários por meio de uma solução de SSO/IDM.

Além de usar manuais de arquitetura e planejamento de continuidade, use o Proactive Monitoring. Com o Proactive Monitoring, você pode configurar alertas em tempo real sobre acionadores de falha, como falhas de login, exceções de tempo limite de CPU ou erros de solicitação de API simultâneos. Essa abordagem de alerta aumenta a mitigação de falhas garantindo que as partes interessadas técnicas e de negócios sejam informadas a tempo para reduzir o impacto de falhas. Os [padrões e antipadrões para disponibilidade](/docs/architect/pt-br/well-architected/guide/reliable#padrões-de-disponibilidade-e-antipadrões) mostram como é a mitigação de falhas adequada e ruim em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar locais no sistema para o refator. Para saber mais sobre ferramentas do Salesforce para mitigação de falhas, consulte [Ferramentas relevantes para confiabilidade](/docs/architect/pt-br/well-architected/guide/reliable#ferramentas-do-salesforce-para-confiabilidade). ### Padrões de disponibilidade e antipadrões Esta tabela 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 disponibilidade no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/trusted-availability).

	Padrões	Antipadrões
Gerenciamento de riscos	No seu negócio: - Uma estrutura de avaliação de risco estabelecida está em uso. - Os riscos são categorizados em áreas de pessoas, processos e tecnologia.	No seu negócio: - A estrutura de avaliação de risco para o Salesforce é ad hoc. - Os riscos não são claramente identificados.
Gerenciamento de riscos	Na sua documentação: - A gravidade do risco é categorizada e avaliada com base no impacto do cliente. - A mitigação de risco e os planos de resposta são priorizados.	Na sua documentação: - A perspectiva do cliente não é considerada ao avaliar a gravidade do risco ou a categoria. - Os planos de mitigação e resposta de risco tentam capturar todos os riscos imagináveis.
Limitação de falhas	Em sua organização: - Os acionadores de ponto de falha e seus planos de mitigação correspondentes são categorizados por pessoas, processos e tecnologia. - Os controles de mitigação são implementados imediatamente, amadurecem ao longo do tempo e incorporam automação assim que possível. - Para garantir a escalabilidade ideal, os testes e otimizações abrangentes são concluídos antes da liberação das alterações para produção. - Antes de eventos críticos para os negócios, o teste e a otimização de escala são realizados conforme os SLAs.	Em sua organização: - Os acionadores de ponto de falha não são classificados. Abordagens de mitigação não existem ou são usadas apenas ad hoc. - Os controles de mitigação não são revisitados nem aprimorados. - A automação não é usada na mitigação.
Monitoramento e observabilidade	Em sua organização: - Para verificações e detecção de anomalias, o Proactive Monitoring está habilitado. - Para uma visibilidade contínua, os alertas Proactive Monitoring são integrados ao Centro de escala.	Em sua organização: - Somente verificações manuais de integridade são realizadas e nenhum monitoramento contínuo está em vigor.

## Desempenho O desempenho da arquitetura do sistema é uma medida de quanto um sistema processa (transferência) e quão rápido ele responde (latência). Você geralmente entende o desempenho do seu sistema por meio de testes e monitoramento de produção. Um sistema de alto desempenho conclui processos em tempo hábil em todos os níveis de demanda previstos. O desempenho ruim vem em conjunto com maior latência e menor taxa de transferência, o que leva a menor produtividade e maior frustração do usuário. Corrigir problemas de desempenho é urgente porque eles podem levar a uma perda de Trust do cliente e perdas financeiras. Você pode melhorar o desempenho de suas soluções otimizando a taxa de transferência e a latência. > Nota: A otimização de taxa de transferência e de latência são aspectos essenciais para melhorar o processamento e a responsividade do sistema. É importante lembrar, no entanto, que o desempenho geral do sistema também depende de quão bem você arquitetura para a [escala](/docs/architect/pt-br/well-architected/guide/reliable#escalabilidade). Você deve considerar ambas as dimensões em seus designs. ### Transmissão No contexto da arquitetura do Salesforce, a taxa de transferência é o número de solicitações simultâneas que um sistema pode concluir dentro de um determinado intervalo de tempo. As soluções do Salesforce dos clientes projetadas e otimizadas para taxa de transferência funcionam melhor dentro dos [limites reguladores](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) integrados da Salesforce Platform. A otimização da taxa de transferência no Salesforce começa com o cálculo preciso das cargas de trabalho no seu sistema e o planejamento para seu crescimento. Sem previsões precisas para as demandas que serão feitas no sistema, não será possível detectar possíveis problemas com os recursos de taxa de transferência do seu sistema. Ao pensar em cargas de trabalho, considere estas três dimensões. - **O número de transações** que seu sistema deve processar em um determinado período de tempo - **O número de usuários** que devem acessar seu sistema simultaneamente - **A complexidade geral da lógica de transação** no sistema Ao pensar no desempenho, as equipes às vezes se concentram muito na computação e nas restrições ao tempo máximo de CPU, que estão entre os limites do controlador da plataforma. Equipes com foco limitado no tempo de CPU ignoram outros métodos para otimizar a taxa de transferência. Expandir seu foco e aplicar esses métodos melhora a taxa de transferência geral e a eficiência da sua arquitetura do Salesforce. Essas melhorias, por sua vez, ajudarão a reduzir a latência e aumentar o desempenho geral do sistema. O ApexGuru detecta proativamente antipadrões que limitam a taxa de transferência, como SOQL em loops, DML em loops, chamadas GGD ineficientes e métodos caros. Essas percepções ajudam as equipes a eliminar riscos de limite do controlador que limitam a taxa de transferência. Para otimizar a taxa de transferência no seu sistema: - **Favorecer processamento assíncrono**. A Salesforce Platform usa contextos de transação para controlar a integridade dos dados e limitar a fuga de código. Veja [transacções em Fundamentos de arquitetura](/docs/architect/pt-br/fundamentals/guide/architecture-basics#transações) em Fundamentos de arquitetura. Por isso, usar processamento assíncrono (assíncrono) sempre que possível pode ajudar a minimizar possíveis gargalos em contextos de execução síncrona. Consulte [Tratamento de dados](/docs/architect/pt-br/well-architected/guide/automated#tratamento-de-dados). O uso de computação assíncrona não é uma solução para todos os tipos de problemas de desempenho, e você precisará considerar a latência ao incorporar processos assíncronos. Alguns recursos de plataforma, como o Apex enfileirável, podem aumentar a latência durante picos de tráfego porque fazem as mensagens esperar mais tempo em uma fila. Dependendo do seu caso de uso, você pode decidir tolerar uma possível redução na responsividade para manter ou melhorar a taxa de transferência. Em outros casos, você pode decidir que o aumento da latência não é aceitável. Com Teste de escala, você pode validar essas compensações simulando picos de tráfego em um Sandbox completo. Lá, você pode medir como os trabalhos afetam a taxa de transferência e a latência. - **Sempre use massificação**. Em um nível alto, massificação significa realizar operações com relação a coleções. Geralmente, as equipes que discutem a massificação para suas soluções do Salesforce se concentram em simplificar as operações de dados em relação às coleções. Consulte [Lógica operacional](/docs/architect/pt-br/well-architected/guide/automated#lógica-operacional). No entanto, a massificação em um nível do sistema envolve mais do que apenas operações de dados. Considere também determinadas tarefas, como chamadas ou cálculos complexos, como candidatos para massificação. Massificação adequada reduz a sobrecarga. Ele executa várias operações com uma solicitação, em vez de uma solicitação por operação. O ApexGuru apresenta padrões anti-bulkification como [DML ou SOQL dentro de loops](https://help.salesforce.com/s/articleView?language=en_US&id=xcloud.apexguru_antipatterns.htm&type=5), que você pode corrigir antes de escalar para produção. Consulte [Operações em massa](/docs/architect/pt-br/fundamentals/guide/platform-multitenant-architecture#operações-em-massa). - **Use SOSL para pesquisas e trate SOQL como uma operação de dados**. Pode parecer óbvio que usar instruções SOQL excessivamente complexas aumentará o tempo que o sistema leva para recuperar registros. O SOQL adiciona sobrecarga ao [base de dados relacional subjacente](/docs/architect/pt-br/fundamentals/guide/platform-multitenant-architecture#a-camada-de-dados-da-plataforma), desacelerando o processamento. Ao usar critérios de texto ou curinga, o SOSL tem um melhor desempenho. O SOSL usa o mecanismo de pesquisa da plataforma, que é otimizado para indexação de texto completo e pesquisas universais. Para otimizar os padrões de recuperação de registro, certifique-se de que seus padrões de design especifiquem quando usar o SOSL para localizar dados no seu sistema. Certifique-se também de que eles especifiquem como usar SOQL para operações de dados eficientes. Consulte [Lógica operacional](/docs/architect/pt-br/well-architected/guide/automated#lógica-operacional)). - **Use o Cache da plataforma e o ApexGuru**. A camada [Cache da Plataforma do Lightning](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm) proporciona um desempenho mais rápido e uma maior confiabilidade ao armazenar em cache dados da sessão do Salesforce e da organização. O Cache da plataforma melhora o desempenho distribuindo espaço em cache para que alguns aplicativos ou operações não roubem capacidade de outros. O ApexGuru detecta oportunidades perdidas para armazenar em cache consultas repetidas (por exemplo, [Cache da plataforma para resultados de SOQL](https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipattern_soql_without_platform_cache.htm&type=5)), o que melhora a taxa de transferência em ambientes de grande escala. Os [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/reliable#padrões-de-desempenho-e-antipadrões) para desempenho mostram a aparência de taxa de transferência adequada e baixa em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou para identificar oportunidades para otimização adicional. Para aprender mais sobre ferramentas do Salesforce para otimização de rendimento, consulte [Salesforce Tools for Reliability](/docs/architect/pt-br/well-architected/guide/reliable#ferramentas-do-salesforce-para-confiabilidade). ### Latência A latência é uma medida da velocidade com que um sistema conclui um caminho de execução. Otimizar a taxa de transferência do seu sistema contribuirá para melhorar a latência. Outra dimensão da latência é o desempenho percebido ou o grau de responsividade do sistema para os usuários. As pessoas não querem esperar o carregamento das páginas ou o fim dos processos. Os usuários do seu sistema ficarão frustrados se tiverem frequência com longos tempos de carregamento ao tentar navegar em exibições de lista, páginas de registro, relatórios etc. Quando isso acontece, os clientes ou parceiros podem optar por levar seus negócios para outro lugar em vez de lidar com sistemas com baixo desempenho. Interna, os funcionários podem criar soluções alternativas para evitar o uso do sistema conforme projetado, o que pode causar problemas a jusante na segurança e na integridade dos dados. O desempenho percebido pode ser difícil de diagnosticar. Quando um usuário relata desempenho lento, as equipes de suporte talvez não consigam reproduzir o problema. O aumento da latência geralmente é resultado de uma combinação de problemas menores que se baseiam uns nos outros, o que pode dificultar o diagnóstico da causa exata dos problemas de desempenho percebidos. Para reduzir a latência e melhorar a responsividade em seu sistema do Salesforce: - **Otimize relatórios**. Certifique-se de que cada relatório atenda a uma única finalidade específica. Identifique claramente o público e a finalidade de cada relatório em seu sistema. Em relatórios, inclua apenas a quantidade mínima de dados de que os membros do público precisam para tomar decisões. Remover colunas que não estejam alinhadas à finalidade de um relatório irá melhorar o desempenho do relatório reduzindo a quantidade de dados que precisa ser recuperada e exibida. - **Otimize os filtros**. Filtros eficientes aceleram o desempenho do relatório e do modo de exibição de lista definindo com precisão o escopo do número de linhas recuperadas do banco de dados. Como regra geral, quanto mais específica for a lógica de filtro, mais eficiente será a consulta subjacente para dados. As maneiras de otimizar os filtros incluem: - Usar "igual a" e "não igual a" em vez de "contém" e "não contém" - Evitando a filtragem por campos de fórmula - **Simplifique seu modelo de compartilhamento**. Um modelo de compartilhamento excessivamente complexo pode desacelerar vários processos porque o sistema deve verificar o modelo de compartilhamento e visibilidade para determinar se um usuário tem acesso aos dados a serem exibidos ou processados. Cálculos de compartilhamento complexos podem aumentar a latência em relatórios, modos de exibição de lista e automação em execução no contexto do usuário. Consulte [Compartilhamento e visibilidade](/docs/architect/pt-br/well-architected/guide/secure#compartilhamento-e-visibilidade). - **Otimize componentes de IU personalizados**. Componentes da interface de usuário (UI) personalizados podem aumentar a latência. Para otimizar o desempenho em componentes de IU personalizados, considere fazer o seguinte. - **Use Componentes da Web Lightning (LWC)**. A estrutura do LWC está estreitamente alinhada aos padrões da Web modernos. Componentes personalizados escritos no LWC são renderizados com mais eficiência em navegadores da Web e permitem que os desenvolvedores usem métodos JavaScript com mais desempenho. Sempre tente usar o LWC em vez de tecnologias de interface do usuário mais antigas, como o Aura ou Visualforce. - **Use o Lightning Data Service**. O Lightning Data Service lida com a criação e manutenção de cache seguro, eficiente e compartilhado entre componentes. Use-o para evitar viagens de ida e volta desnecessárias para o servidor para obter dados e para aumentar a responsividade geral do aplicativo. - **Use classificação e filtragem no lado do cliente para dados de lista**. Para componentes do LWC (preferencial) e do Aura (caso contrário), os desenvolvedores podem usar a funcionalidade de matriz JavaScript padrão para classificar, filtrar e selecionar valores no lado do cliente, reduzindo o número de viagens necessárias ao servidor. Os [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/reliable#padrões-de-desempenho-e-antipadrões) mostram como é a latência adequada e a baixa em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou para identificar oportunidades para otimização adicional. Para aprender mais sobre ferramentas do Salesforce para otimização de latência, consulte [Salesforce Tools for Reliability](/docs/architect/pt-br/well-architected/guide/reliable#ferramentas-do-salesforce-para-confiabilidade). ### Padrões de desempenho e antipadrões Esta tabela 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 desempenho no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/trusted-performance).

	Padrões	Antipadrões
Transferência	Em seus padrões de design: - Orientação sobre como usar o Cache da plataforma adere às Práticas recomendadas de cache da plataforma	Em seus padrões de design: - Se houver orientação para o uso do Cache da plataforma, ela não estará clara ou não está alinhada às práticas recomendadas.
Transferência	Em sua organização: - A massificação é usada para operações de dados e do sistema. - Métodos de DML ou banco de dados sempre operam em relação a coleções no Apex. - Os campos usados durante DML para elapsedTime mais curto no banco de dados são limitados. - Todos os critérios curingas são usados em SOSL. - As instruções SOQL são seletivas.: -- Eles não usam comparações LIKE nem comparações de texto parcial. -- Operadores de comparação usam lógica positiva (em outras palavras, INCLUDES ou IN) como lógica principal ou única. -- = NULL e != NULL são usados apenas raramente sempre segue um operador de comparação positivo. – Para minimizar a carga de dados e maximizar o desempenho, somente os campos necessários em consultas SOQL são recuperados. -- Nenhuma instrução LIMIT 1 é usada. -- A palavra-chave TODAS as linhas não é usada. - O processamento assíncrono é favorecido quando possível. - As partições de Cache da plataforma são configuradas.	Em sua organização: - As instruções DML não são massificadas. - Métodos de DML ou banco de dados operam em registros únicos no Apex. - SOSL raramente é usado ou não é usado de modo consistente para critérios de seleção de curinga. - As instruções SOQL não são seletivas: -- Eles incluem critérios de filtro curinga e LIKE. -- Comparações usando critérios !=, NOT ou NOT IN são usadas como o operador de comparação principal ou único. -- Usos = critérios NULL e != NULL como os operadores de comparação primários ou únicos. As instruções -- LIMIT 1 são usadas. -- A palavra-chave TODAS as linhas é usada. - SOQL aparece dentro de loops. - Processos síncronos são favorecidos.
Latency	Em sua organização: - Os relatórios atendem a uma única finalidade específica e contêm o número mínimo de linhas e colunas necessárias para tomar decisões. - Os filtros usam "igual a" e "não igual a". - Os filtros não contêm campos de fórmula. - Os modelos de compartilhamento são simplificados ao máximo possível. - Os componentes personalizados da IU usam Componentes da Web Lightning (LWC). - O LWC usa o Lightning Data Service para operações de dados. - A classificação e filtragem de dados de lista são tratadas no lado do cliente em JavaScript. - O Salesforce Edge está habilitado.	Em sua organização: - Os relatórios atendem a vários fins ou contêm linhas e colunas extras que não são necessárias para tomar decisões. - Os filtros usam "contém" e "não contém". - Os filtros contêm campos de fórmula. - Os modelos de compartilhamento são complexos. - Os componentes personalizados da IU usam estruturas que podem resultar em renderização menos eficiente do que o LWC (por exemplo, Aura ou Visualforce). - O LWC usa Apex para operações de dados. - A classificação e filtragem de dados de lista é tratada no lado do servidor usando o Apex. - O Salesforce Edge não está habilitado.

## Escalabilidade A escalabilidade é a capacidade de um sistema de realizar um desempenho consistente conforme ele evolui e cresce. Um sistema dimensionável lida com grandes aumentos nos volumes de transações ou acesso simultâneo sem alterações fundamentais. Os serviços de plataforma do Salesforce são projetados para dar suporte à escalabilidade do aplicativo. Consulte [Processamento interno da plataforma](/docs/architect/pt-br/fundamentals/guide/platform-multitenant-architecture#processamento-de-plataforma-interna). Com isso dito, à medida que sua organização cresce e a demanda por seus produtos e serviços aumenta, você é responsável por criar um sistema que possa funcionar de modo eficaz e conforme o esperado. O arquiteto para escalabilidade desde o início resulta em entrega mais rápida de novos recursos e menos interrupções de serviço conforme o tráfego do usuário aumenta. No início da fase de design, antes de implementar novos recursos na produção, use o **Teste de escala** para simular cargas de trabalho projetadas e validar se a arquitetura pode ser dimensionada para suportá-las. Sistemas não projetados para escalabilidade exigem solução de problemas constante e dispendiosa, reprojeto e refatoramento. Os problemas de escalabilidade se complicam ao longo do tempo, reduzindo o desempenho em todo o sistema. Em alguns casos, as empresas se encontram gastando a maioria dos recursos de desenvolvimento e manutenção para lidar com problemas de escalabilidade em vez de novos recursos que criam valor. Às vezes, uma empresa atinge um ponto crítico. O design original do sistema não pode dar suporte ao crescimento dos negócios, e eventos inesperados tornam o sistema instável. Use percepções do **Scale Center** para identificar pontos de escalabilidade precocemente. O Centro de escala detecta hotspots de exceção, transações de execução longa e gargalos de fila que pioram ao longo do tempo. Você pode arquitetar melhor para escala focando a otimização do modelo de dados e o gerenciamento de volume de dados. _Nota: Embora não seja discutido aqui, o teste de escalabilidade é uma parte crítica da validação de suas arquiteturas de aplicativo. Para orientação, consulte [estratégia de teste](/docs/architect/pt-br/well-architected/guide/resilient#estratégia-de-teste)._ ### Modelagem de dados A modelagem de dados envolve estruturar os objetos em sua organização e relacioná-los entre si de maneira que permita que seus usuários e processos automatizados recuperem os dados de que precisam o mais rapidamente possível. Tomar medidas para [melhorar a taxa de transferência](/docs/architect/pt-br/well-architected/guide/reliable#transmissão) resolve muitos problemas de desempenho, mas seus esforços não serão tão eficazes sem um modelo de dados otimizado. Os impactos negativos de um modelo de dados mal projetado não são imediatamente perceptíveis; suas fraquezas são expostas à medida que o sistema cresce em termos de volume de dados, processos, usuários e integrações. Um modelo de dados bem projetado facilita o refator contínuo do seu aplicativo conforme os requisitos são adicionados e estendidos. O **ApexGuru** detecta antipadrões de acesso a dados, como SOQL não seletivo, campos não utilizados e ineficiências de esquema que afetam diretamente a escalabilidade do modelo de dados. Para otimizar seu modelo de dados: - **Use os modelos de dados predefinidos do Salesforce**. O Salesforce fornece modelos de dados predefinidos para Vendas, Serviços e uma variedade de verticais do setor. Usar os modelos de dados fornecidos pelo Salesforce garante que os recursos em seu sistema sejam definidos apenas uma vez, eliminando redundância e silos e estabelecendo uma única fonte da verdade em todo o sistema. Como você usou modelos de dados pré-criados do Salesforce para essa única origem, ficou mais fácil entender os dados do aplicativo com análise e usar os serviços de inteligência artificial pré-criados do Salesforce. Além disso, reduzir as personalizações que você deve suportar reduz os custos de manutenção e reduz o débito técnico. - **Escolha os tipos de dados certos**. Entenda os diferentes tipos de campos compatíveis com o Salesforce e suas limitações. Considere os requisitos de relatórios e criptografia para evitar a necessidade de converter dados entre tipos no futuro. - **Escolha as relações certas**. O Salesforce oferece suporte a dois tipos de relacionamentos entre objetos: mestre-detalhes e pesquisa. Os relacionamentos entre mestre e detalhes oferecem dois benefícios principais. Um deles é os recursos de resumo de totalização integrados, que contam e agregam detalhes de registros filho. A outra é uma funcionalidade de exclusão em cascata integrada, por meio da qual a exclusão de um registro pai também exclui seus registros filhos. No entanto, certifique-se de que entende as [implicações de compartilhamento e distorção de dados](/docs/architect/pt-br/well-architected/guide/reliable#volume-de-dados) de relacionamentos entre mestre e detalhes antes de decidir usá-los. - **Denormalize para escala.** A normalização é o processo de estruturar seu modelo de dados para reduzir a redundância de dados e melhorar a integridade dos dados. Infelizmente, a normalização às vezes causa problemas de escala. Tabelas não normalizadas podem ter um desempenho melhor em escala, mas lembre-se de considerar a integridade e a redundância dos dados. Os [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/reliable#padrões-de-escalabilidade-e-antipadrões) mostram como é a otimização de modelo de dados adequada e ruim em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou para identificar oportunidades para otimização adicional. Para aprender mais sobre ferramentas do Salesforce para otimização de modelo de dados, consulte [Salesforce Tools for Reliability](/docs/architect/pt-br/well-architected/guide/reliable#ferramentas-do-salesforce-para-confiabilidade). ### Volume de dados O volume de dados é uma medida da quantidade de dados armazenados em seu sistema com base em contagens e tamanhos de registro. Se sua organização tiver dezenas de milhares de usuários, dezenas de milhões de registros ou centenas de gigabytes de armazenamento total de registros, você terá um grande volume de dados. O volume de dados e os relacionamentos entre objetos em sua organização afetam a escalabilidade e provavelmente terão um impacto maior sobre a escalabilidade do que apenas o número de registros. Para melhorar a escalabilidade de organizações com grandes volumes de dados: - **Distribuir registros filhos**. Evite distorção de dados de pai e filho garantindo que nenhum pai tenha um grande número de registros filhos. A recomendação geral é que nenhum pai deve ter mais de 10 mil registros filhos. Por exemplo, em uma implantação que tem muitos contatos, mas não usa contas, considere configurar vários registros de conta e distribuir registros de contato relacionados entre eles. - **Distribuir propriedade dos registros**. Evite distorção de propriedade garantindo que nenhum único usuário ou fila seja proprietário, nem que todos os membros de um único papel ou grupo público sejam proprietários de mais de 10.000 registros do mesmo objeto. "Estacionar" dados com um "usuário simulado" é uma prática que geralmente leva a um desvio de propriedade. Se você encontrar esse problema, lembre-se do impacto que ele terá sobre os [cálculos de compartilhamento](/docs/architect/pt-br/well-architected/guide/reliable#latência). Se você não puder redistribuir registros para aliviar o desvio de propriedade, evite atribuir o usuário proprietário dos dados a um papel. Se o modelo de compartilhamento da sua organização exigir uma atribuição de papel, coloque o usuário proprietário dos dados em um papel distinto no topo da hierarquia de compartilhamento. Não permita alterações frequentes ou não planejadas no papel desse usuário, pois qualquer alteração terá impactos significativos sobre o desempenho devido a recálculos de compartilhamento. Mantenha esse usuário fora de grupos públicos que possam ser referenciados em qualquer regra de compartilhamento. - **Reduza a quantidade de dados de registro no Salesforce**. O Salesforce é projetado para fornecer às empresas uma única visualização dos clientes. Pode parecer contraintuitivo que a limitação de dados no Salesforce seja uma prática recomendada. No entanto, o poder da visualização única reside no quão bem ela permite que os usuários de negócios entendam e realizem ações em relação aos dados do cliente. Conforme o volume de dados aumenta, dados que não são atuais ou relevantes para processos ou análises cotidianas levam a vários problemas. Esses problemas incluem desempenho reduzido do aplicativo, maior risco de segurança de dados e impactos negativos sobre pesquisa, relatórios e análise. Para evitar esses problemas, defina um ciclo de vida de dados para cada objeto em seu modelo de dados, com linhas do tempo e classificações para os dados conforme ele envelhece e perde valor comercial imediato. De acordo com o ciclo de vida dos dados, implemente estes procedimentos para gerenciar dados ao longo do tempo. - **Arquivamento e limpeza de dados** – Para manter os volumes de dados o mais baixos possível, remova os registros que não são necessários pela empresa para ajudar a manter os volumes de dados o mais baixos possível. Use a função de exclusão permanente da API em massa 2.0 para excluir grandes volumes de dados. - **Agrupamento de dados –** Crie objetos personalizados de agregação que resumem as principais tendências históricas ou dados resumidos em um formato compatível com relatórios. Preencha os objetos personalizados usando o [Apex lote](/docs/architect/pt-br/well-architected/guide/reliable#transmissão). Os usuários então podem executar relatórios com base nos registros de objeto agregado. - **Nível de dados**. Mantenha conjuntos de dados grandes em um aplicativo diferente se não forem necessários para relatórios do Salesforce ou trabalho diário. Disponibilize os dados no Salesforce conforme necessário por meio de mashups, chamadas ou objetos externos. Na prática, nem sempre é possível lidar imediatamente com a causa-raiz de um problema de escalabilidade quando ocorrem problemas. Por isso, o Salesforce oferece opções para ajudar a aliviar problemas imediatos. É importante saber que habilitar esses recursos em sua organização não é uma estratégia de arquitetura de longo prazo viável para lidar com grandes volumes de dados. Essas soluções alternativas de curto prazo podem ajudar a reduzir a latência em sistemas com arquitetura de dados ruim, mas também podem adicionar débito técnico à sua organização. As soluções alternativas de curto prazo para problemas de escala incluem: - **Índices personalizados** Os índices são armazenados em uma tabela interna especial que o otimizador de consulta da plataforma usa para acelerar operações de acesso a dados. Consulte [Multitenant Indexes](/docs/architect/pt-br/fundamentals/guide/platform-multitenant-architecture#índices)). A plataforma indexa automaticamente determinados tipos de campos por padrão. Para acelerar consultas com baixo desempenho, você pode solicitar índices personalizados adicionais entrando em contato com o Suporte ao cliente da Salesforce. Use a ferramenta Plano de consulta para determinar se os índices personalizados melhorarão o desempenho de suas consultas. - **Tabelas sujas**. Se você precisar otimizar ainda mais as consultas para conjuntos comuns de campos em objetos com mais de um milhão de registros, as tabelas mínimas podem ajudar. As tabelas mínimas eliminam a [junção de fundo](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm) que ocorre ao usar campos personalizados e padrão do mesmo objeto em um relatório ou automação. Para que você possa usar tabelas mínimas, o Suporte ao cliente da Salesforce deve habilitá-las para sua organização. Os [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/reliable#padrões-de-escalabilidade-e-antipadrões) para escalabilidade mostram como é o gerenciamento de volume de dados adequado e ruim em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou para identificar oportunidades para otimização adicional. Para aprender mais sobre ferramentas do Salesforce para gerenciar volumes de dados, consulte [Salesforce Tools for Reliability](/docs/architect/pt-br/well-architected/guide/reliable#ferramentas-do-salesforce-para-confiabilidade). ### Padrões de escalabilidade e antipadrões Isso 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 escalabilidade no [Pattern & Anti-Pattern Explorer](/docs/architect/pt-br/well-architected-tools/guide/trusted-scalability).

	Padrões	Antipadrões
Modelagem de dados	Em seus padrões de design: - Padrões e diretrizes para as quais justificativas de negócios justificam a existência de um objeto personalizado.	Em seus padrões de design: - Não há padrões para criar objetos personalizados.
	No modelo de dados: - Objetos padrão são usados quando possível. - As verificações do ApexGuru para antipadrões confirmam que as consultas SOQL são seletivas e evitam o uso de esquema ineficiente. - As tabelas são não normalizadas para escala.	No modelo de dados: - Você tem objetos padrão replicados. - As tabelas são normalizadas para evitar redundância.
	Dentro do seu negócio: - Os criadores de código baixo entendem os diferentes tipos de campo compatíveis com o Salesforce e avaliam os requisitos de relatórios e criptografia antes de selecionar os tipos de dados de campo. - Antes de decidir estabelecer um relacionamento entre mestre e detalhes entre objetos, você avalia as implicações de compartilhamento e desvio de dados desse relacionamento.	Dentro do seu negócio: - Os criadores de código baixo selecionam tipos de dados sem avaliar os requisitos de relatórios e criptografia a jusante. - Antes de decidir estabelecer relacionamentos entre mestre e detalhes entre objetos, você não avalia as implicações de compartilhamento e desvio de dados desse relacionamento.
Data Volume	Em seus dados: - Nenhum registro pai tem mais de 10 mil registros filhos. - Nenhum usuário é atribuído a mais de 10 mil registros do mesmo tipo de objeto. - Nenhuma instância inclui mais de 10 mil registros que têm campos de pesquisa apontando para o mesmo registro. - Os carregamentos de dados em massa são classificados em lotes de acordo com os valores do campo ParentId. - Para garantir que as estratégias de lote não quebrem em simultâneo, o Teste de escala é usado para validar padrões de carga em massa em escala de produção. - Os carregamentos de dados em massa na produção não ocorrem durante o horário comercial de pico. - As cargas de dados em massa incluem apenas os dados mínimos necessários para decisões de negócios.	Em seus dados: - Existem registros com mais de 10 mil registros filho. - Os usuários são atribuídos a mais de 10 mil registros do mesmo tipo. - Existem instâncias em que mais de 10 mil registros têm campos de pesquisa que apontam para o mesmo registro. - Os carregamentos de dados em massa não são classificados em lotes de acordo com os valores de campo ParentId. - Carregamentos de dados em massa em produção ocorrem durante o horário comercial de pico. - As cargas de dados em massa não estão limitadas ao mínimo de dados necessários para decisões de negócios.
	No Fluxo e no Apex: - Há lógica para distribuir o número de registros filho entre vários registros pai em cenários em que o desvio de dados é uma preocupação. - Ao importar ou replicar registros por meio de integração, a lógica os atribui aos usuários humanos adequados. - Para coleções do Apex, como listas e conjuntos, existe lógica para processar vários registros para minimizar consultas e otimizar o tratamento de dados. - Código eficiente do Apex que segue os padrões e as melhores práticas para código escalável é escrito e implementado.	No Fluxo e no Apex: - Os registros filho são atribuídos arbitrariamente aos registros pai, independentemente do número de registros filho já atribuídos. - Os registros criados por meio de carregamentos de dados ou integrações são atribuídos a um "usuário de integração" genérico. - Várias consultas SOQL recursivas do mesmo objeto estão em transações síncronas, levando a alto uso de heap. - Quando os desenvolvedores escrevem Apex code, eles introduzem ineficiências e antipadrões de desempenho.
	Dentro do seu negócio: - Você documentou e implementou uma estratégia de depuração e arquivamento de dados	Dentro do seu negócio: - Você não tem uma estratégia de depuração e arquivamento de dados ou sua estratégia foi documentada, mas não implementada

## Ferramentas do Salesforce para confiabilidade

Ferramenta	Descrição	Desempenho	Escalabilidade
Objetos grandes	Armazene e gerencie grandes volumes de dados na plataforma.		X
Scanner de código	Verifique o Apex code quanto a problemas de desempenho.	X
Índices personalizados	Melhore o desempenho da consulta com índices personalizados.		X
Exclusão de dados	Remova dados desnecessários para melhorar o desempenho.	X	X
Divisões	Particione dados para limitar contagens de registros em consultas e relatórios.		X
Teste de escala	Teste o desempenho do sistema e interprete os resultados. Antes de implantar na produção, para validar a escalabilidade e o desempenho, simule as cargas de trabalho de API e UI em grande escala usando scripts do Playwright ou do JMeter.	X	X
Centro de escala	Obtenha percepções em tempo real e por autoatendimento sobre o desempenho do sistema. Encontre transações de execução longa, hotspots de exceção e gargalos de taxa de transferência. Diagnosticar problemas de escala anteriormente em seu ciclo de desenvolvimento.	X	X
ApexGuru	Use esse recurso baseado em GenAI no Centro de escala para detectar antipadrões do Apex, SOQL e classe de teste em tempo de execução. Por meio da integração do ApexGuru com o Salesforce Code Analyzer, obtenha recomendações habilitadas por IA e correções em linha no fluxo de trabalho de desenvolvimento. Use essas recomendações e correções para resolver hotspots e melhorar a seletividade da consulta, a massificação, o uso de cache e a qualidade de testes.	X	X
Analisador de código do Salesforce	Verifique o código com IDE, CLI ou CI/CD para garantir que ele cumpra as práticas recomendadas. Por meio da integração do Salesforce Code Analyzer com o ApexGuru, obtenha percepções sobre antipadrões de desempenho diretamente no fluxo de trabalho do desenvolvedor.	X
Salesforce Edge Network	Melhore os tempos de download e a experiência do usuário roteando seu Meu domínio pela Salesforce Edge Network.	X
Tabelas Skinny	Evite junções em tabelas que tenham campos usados com frequência.		X
Monitoramento proativo	Monitore continuamente anomalias em crescimento de registro, distorção de propriedade e regressões de desempenho. Alerte sobre problemas de escala antes que eles se tornem críticos.	X	X

## Recursos do Salesforce para confiabilidade

Recurso	Descrição	Disponibilidade	Desempenho	Escalabilidade
Os desafios de escala custam milhões — Veja como promover seu negócio no futuro	Descubra como a implementação da escalabilidade leva ao crescimento sustentável e ao sucesso de longo prazo.		X	X
Criar e implementar aplicativos dimensionáveis usando o Centro de escala	Entenda como avaliar e resolver de modo proativo problemas de desempenho em suas implementações do Salesforce.
Analisar hotspots de desempenho e escala em aplicativos Salesforce complexos	Lide com problemas de desempenho e escalabilidade na sua organização.		X	X
Seu aplicativo não deve entrar em pânico no tráfego de horário rápido - Aqui está como se preparar	Aprenda quatro etapas importantes para testes de escala bem-sucedidos.
O mecanismo de IA do ApexGuru explicado	Saiba como o ApexGuru usa modelos treinados personalizados, telemetria da organização do mundo real e filtragem inteligente para fornecer percepções precisas, contextuais e acionáveis.		X	X
Otimize seu Apex para aplicativos e Agentforce com o ApexGuru	Saiba como o ApexGuru ajuda os desenvolvedores a detectar e corrigir antipadrões de desempenho, incluindo SOQL, DML, depuração e ineficiências de teste. Use o ApexGuru como um instrutor baseado em IA para o desenvolvimento escalonável de seus aplicativos e sua implementação do Agentforce.		X	X
ApexGuru Antipatterns	Aprenda na biblioteca oficial de antipadrões detectados pelo ApexGuru, que é atualizada para cada versão principal do Salesforce.		X	X
Práticas recomendadas para implantações com grandes volumes de dados	Entenda os impactos do processo de grandes volumes de dados.			X
Considerações sobre a Salesforce Edge Network	Descubra como preparar sua organização para usar a Salesforce Edge Network.		X
Modelo de padrões de design	Crie padrões de design para sua organização.	X	X	X
Considerações sobre o projeto de modelo de dados	Otimize modelos de dados para escala e manutenção.		X	X
Construindo o acesso ao registro em escala corporativa	Otimize o desempenho do controle de acesso por meio da configuração.			X
Infraestrutura para sistemas com grandes volumes de dados	Aprenda sobre os recursos que dão suporte ao desempenho do sistema para implantações com grandes volumes de dados.			X
Recursos de aprendizado para gerenciamento em lote	Aprenda mais sobre o Gerenciamento em lote.		X	X
Otimização de desempenho do Lightning Experience	Melhore o Lightning Experience em sua organização para ajudar seus usuários a trabalhar mais rapidamente.		X
Gerenciar o seletor de pesquisa no Salesforce para evitar exceções de bloqueio de registro	Entenda como minimizar os efeitos de discrepâncias de pesquisa.		X	X
Práticas recomendadas de SOQL e SOSL	Siga as práticas recomendadas de SOQL e SOSL para implantações com grandes volumes de dados.		X	X
Ferramentas para realinhamentos em grande escala	Planeje e execute realinhamentos de modo eficaz.			X
Usando Mashups	Mantenha conjuntos de dados grandes em um aplicativo diferente.		X	X

Seguro
Um sistema seguro protege a empresa, as partes interessadas e os dados. Arquiteturas seguras garantem que apenas usuários aprovados possam obter acesso, restringir o acesso do usuário ao que é essencial para o trabalho e proteger os dados no sistema contra compromissos.
Segurança organizacional	Segurança da sessão	Segurança de dados
Autenticação Autorização	Gerenciamento de sessão Acesso ao dispositivo Detecção e resposta a ameaças	Compartilhamento e visibilidade Uso da criptografia
Conformidade
As soluções em conformidade seguem diretrizes legais e éticas. Arquiteturas em conformidade seguem os regulamentos legais e os padrões do setor, respeitam políticas éticas e atendem a todos os usuários de modo justo.
Atenção jurídica	Padrões Éticos	Acessibilidade
Privacidade de dados Localização	Políticas da empresa Inteligência artificial	Entrada de dados Navegação
Confiável
Soluções confiáveis operam de modo eficiente e confiável sob uma variedade de condições. Arquiteturas confiáveis estão disponíveis quando e onde os usuários esperam, têm um desempenho consistente e têm escala com os negócios.
Disponibilidade	Desempenho	Escalabilidade
Gerenciamento de risco Mitigação de falha	Transmissão Latência	Modelagem de dados Volume de dados

> Leia sobre nossas agendas de atualização [aqui](/docs/architect/pt-br/well-architected/guide/contributors). Aviso de isenção de responsabilidade legal: Esse documento é distribuído apenas para uso informativo; ele não constitui consultoria jurídica e não deve ser usado como tal. ## Introdução Um sistema em conformidade é projetado para cumprir as diretrizes legais e éticas aplicáveis, sendo sua adesão mensurável e auditável. Isso é demonstrado restringindo o acesso a dados a indivíduos autorizados para fins pretendidos, cumprindo regulamentos legais relevantes e garantindo acesso equitativo para todos os usuários autorizados. Medidas proativas são essenciais para prevenir e detectar violações de conformidade. Uma abordagem reativa aos regulamentos e normas pode erodir o Trust do cliente, especialmente se as mudanças ocorrerem apenas em resposta a pedidos ou reclamações do cliente. Essas reclamações podem prejudicar a marca e a reputação da sua organização e levar a perdas de receita. Você pode criar conformidade em suas soluções do Salesforce focando três hábitos importantes: adesão legal, padrões éticos e acessibilidade. ## Adesão legal A adesão a mandatos legais envolve seguir leis regionais e normas do setor. Como um arquiteto, depois que a equipe jurídica da sua organização ou um auditor de terceiros tiver determinado os requisitos de conformidade específicos, sua responsabilidade é entender esses requisitos e identificar e sinalizar proativamente possíveis problemas de conformidade logo no início do processo de design para reduzir o risco de multas e processos. Você pode melhorar a adesão legal em suas soluções do Salesforce por meio de privacidade e localização de dados. ### Privacidade de dados A privacidade de dados trata de como sua solução coleta, armazena e processa informações de identificação pessoal (PII), junto com as normas relevantes e a capacidade de um indivíduo controlar o acesso aos seus dados pessoais. O cumprimento dessas normas pode exigir atualizações do seu [modelo de compartilhamento e visibilidade](/docs/architect/pt-br/well-architected/guide/secure#compartilhamento-e-visibilidade), modificações de configurações de metadados para restringir o acesso, implementação de criptografia em nível de campo, monitoramento de registros e eventos, criação de automações para exportar ou excluir dados de um cliente mediante solicitação e desenvolvimento de políticas que regulem o uso de dados em automações e IA. A não conformidade com os regulamentos de privacidade de dados pode levar a multas e processos substanciais. Além disso, a exposição dos dados das partes interessadas devido a controles insuficientes ou uma violação de segurança pode resultar em perda de receita e erosão da Trust do cliente. Considere o seguinte ao trabalhar para garantir a adesão aos requisitos de privacidade de dados: - **Consulte especialistas regulatórios**. Trabalhe com sua equipe jurídica ou um auditor de terceiros para avaliar as normas de conformidade específicas do setor aplicáveis ao seu negócio. Por exemplo, as empresas de saúde devem cumprir a Lei de portabilidade e responsabilidade de seguro de saúde (HIPAA). - **Classifique seus dados**. A classificação de dados ajuda as equipes do projeto a entender quando os vários elementos de dados em sua organização podem ou não ser usados. Ele também dá à sua empresa a capacidade de [relatar](https://help.salesforce.com/s/articleView?id=sf.data_classification_report.htm&type=5) a conformidade da política de gerenciamento de dados. Classifique os dados em sua organização especificando regulamentos aplicáveis [no nível do campo](https://help.salesforce.com/s/articleView?id=sf.data_classification_intro.htm&type=5) para capturar quem é o proprietário, o nível de confidencialidade e se o campo está ou não em uso no momento. Durante o processo de classificação, é importante pensar em como todos os campos em seu modelo de dados podem ser usados e não apenas aqueles que parecem ser confidenciais na primeira vista. Em alguns casos, campos que parecem irrelevantes podem se tornar confidenciais se usados no contexto errado. Por exemplo, códigos postais nos Estados Unidos podem ser um proxy para raça e, portanto, se usados em um modo preditivo, podem adicionar inadvertidamente viés ou causar dano. Os nomes podem ser usados para prever gênero, país de origem, raça, religião e até mesmo idade, pois os nomes populares tendem a mudar de geração em geração. Inclua classificações de todos os campos e uma descrição clara de como qualquer funcionalidade de IA associada os usará em sua documentação. Use ferramentas como a [Data Detection](https://help.salesforce.com/s/articleView?id=sf.einstein_data_detect.htm&type=5) para identificar dados confidenciais na sua organização. Se os campos forem classificados como confidenciais ou se você souber quais são confidenciais, ferramentas como a Seleção de conteúdo do Einstein também identificarão campos que estão [altamente correlacionados](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.mc_pb_manage_einstein_content_selection_attributes_and_bias.htm) e, portanto, podem ser proxies para esses campos confidenciais. - **Estabelecer práticas recomendadas para a governança dos dados**. Garanta que toda a documentação relevante esteja completa, atualizada e armazenada centralmente para que fique facilmente disponível para todas as partes interessadas. Isso adicionará uma camada de proteção para sua organização contra responsabilidade legal, ao mesmo tempo que mantém o Trust com seus clientes e parceiros. Por exemplo, um dicionário de dados documenta as definições e classificações em nível de objeto e campo para todos os elementos de dados que serão armazenados em seu sistema, os documentos de design contêm detalhes sobre qualquer automação que você tenha criado para cumprir as normas e uma matriz de segurança descreve o que os usuários de dados têm acesso. Criticamente, esta documentação abrangente se torna a fonte autorizada para a Geração Aumentada de Recuperação (RAG), baseando diretamente sistemas agentes como Agentforce em contexto operacional verificado e compatível, evitando, assim, saídas inconsistentes ou alucinadas. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/compliant#padrões-de-adesão-legal-e-antipadrões) abaixo mostra como é o gerenciamento adequado (e ruim) de privacidade de dados em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas. Para saber mais sobre ferramentas do Salesforce para privacidade de dados, consulte [Ferramentas relevantes para estar em conformidade](/docs/architect/pt-br/well-architected/guide/compliant#ferramentas-relevantes-para-estar-em-conformidade). ### Localização A localização é sobre adaptar um produto para se alinhar a um idioma específico, cultura e estética local desejada. Isso também inclui a adaptação a regulamentos específicos da região, como leis de residência de dados, que podem diferir significativamente entre países e até mesmo municípios. Consequentemente, seus sistemas podem precisar cumprir várias estruturas regulatórias, dependendo de onde seus clientes estão localizados e de como sua empresa lança seus produtos e serviços no mercado. Além das variações nas leis de privacidade de dados, muitos países também estão adoptando leis de residência de dados. No mínimo, as leis de residência de dados exigem que todos os dados relacionados aos cidadãos de um país sejam armazenados fisicamente dentro dos limites desse país. Algumas leis vão além, exigindo o armazenamento local de todos os dados (incluindo dados sobre produtos e serviços) que possam ser acessados pelos cidadãos. Em determinados casos, as normas exigem que os dados de cidadãos sejam mantidos apenas por outros cidadãos daquele país ou região. A não conformidade pode levar a grandes multas e processos judiciais. Por exemplo, as autoridades de proteção de dados da UE podem impor multas até 20 milhões de euros ou 4% da receita global, o que for maior. Nos EUA, o escritório do procurador-geral da Califórnia pode pedir sanções significativas por violações intencionais e não intencionais. Considere o seguinte para gerenciar melhor os requisitos de localização e residência de dados: - **Consulte especialistas regulatórios**. Trabalhe com sua equipe jurídica ou um auditor de terceiros para avaliar as leis nas regiões em que sua empresa opera para determinar quais são aplicáveis. Exemplos incluem o Regulamento geral de proteção de dados (GDPR) da UE e a Lei de IA da UE e a Lei de privacidade do consumidor da Califórnia (CCPA). - **Armazenar dados localmente**. Garanta que os dados específicos de uma região permaneçam em sua própria organização separada. Use o [Hyperforce](https://help.salesforce.com/s/articleView?id=000356459&type=1), o substrato de nuvem pública do Salesforce para hospedar sua organização em uma região específica. - **Evite replicação de dados**. O armazenamento local de dados significa que os dados são armazenados _em repouso_ no país; é claro, podem surgir problemas de conformidade quando os dados são transferidos para fora do país por meio de interfaces padrão. Por exemplo, criar e manter registros localmente, mas replicá-los para um armazém de dados em outro país para relatórios, violará as leis de residência de dados. Se você trabalhar para uma empresa global com requisitos de relatórios entre regiões, primeiro agregue seus dados dentro do país em que eles são armazenados, remova todas as informações que possam identificar os cidadãos associados a eles e replique apenas as informações agregadas. Essa abordagem pode exigir que você comunique as limitações de relatórios às suas partes interessadas para que elas saibam que, embora dados mais granulares estejam disponíveis em um nível de país ou região, apenas dados resumidos estarão disponíveis globalmente. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/compliant#padrões-de-adesão-legal-e-antipadrões) abaixo mostra a aparência dos processos de localização e residência de dados adequados (e ruins) em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou identificar áreas que precisam ser refatoradas. Para saber mais sobre ferramentas do Salesforce para localização, consulte [Ferramentas relevantes para estar em conformidade](/docs/architect/pt-br/well-architected/guide/compliant#ferramentas-relevantes-para-estar-em-conformidade). ### Padrões de adesão legal e antipadrões 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 adesão legal no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/trusted-legal-adherence).

	Padrões	Antipadrões
Privacidade dos dados	Na sua documentação: - Você tem um dicionário de dados atualizado contendo nomes de nível de campo, descrições e classificações - Você tem uma matriz de segurança atualizada que identifica quais usuários têm acesso a quais dados - Você tem a documentação de design atualizada, incluindo padrões e diagramas para qualquer automação criada para atender aos requisitos regulatórios	Na sua documentação: - Um dicionário de dados não existe ou não foi mantido atualizado - A documentação de compartilhamento e visibilidade não existe ou não foi mantida atualizada - Projetar padrões, diagramas e documentação para automações que atendem aos requisitos regulatórios não existe ou não foi mantido atualizado
Privacidade dos dados	Em sua organização: - Todos os objetos e campos que contêm informações confidenciais ou estão sujeitos a normas de privacidade de dados têm Categorização de conformidade, Proprietário de dados, Nível de confidencialidade de dados e Uso de campo configurados	Em sua organização: - Objetos e campos que contêm informações confidenciais ou estão sujeitos a normas de privacidade de dados estão sem configuração para Categorização de conformidade, Proprietário de dados, Nível de confidencialidade de dados ou Uso de campo
Localização	Na sua documentação: - Você tem uma estratégia da organização que descreve onde os dados serão armazenados e mantidos para cumprir todos os requisitos de residência de dados aplicáveis - Você tem uma estratégia de integração que descreve cenários e processos aceitáveis para replicar dados entre fronteiras - Você tem uma estratégia de análise que descreve o nível de granularidade que os relatórios e painéis podem conter em níveis regional, nacional e global	Na sua documentação: - Você não tem uma estratégia da organização ou sua estratégia da organização não lida com localização de dados e requisitos de residência - Você não tem uma estratégia de integração ou sua estratégia de integração não lida com localização de dados e requisitos de residência - Você não tem uma estratégia de análise ou sua estratégia de análise não lida com localização de dados e requisitos de residência

## Padrões éticos Em contextos de negócios, os padrões éticos são as diretrizes para como as empresas e os indivíduos se comportam de um ponto de vista baseado em valores ou moral. Na Salesforce, [nossos valores centrais](https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values/explore-salesforce-culture-and-values) guiam tudo o que fazemos como empresa e como funcionários. Também temos uma equipe de [política de uso ético](https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/) que ajuda a garantir que os clientes estejam usando nosso software de forma ética. Nossa [Política de Uso Aceitável (AUP)](https://sfdc.co/AUP) e nossa Política de Uso Aceitável de [IA (AI AUP)](http://sfdc.co/AI-Policy) são uma extensão de nossos valores centrais e ajudam a orientar nossa tomada de decisão se surgirem dúvidas sobre o uso. Sua organização pode ter um conjunto adicional de políticas que vão além de cumprir apenas as normas locais. Essas políticas podem assumir várias formas, desde aderir às normas de outras regiões, recusar fazer negócios com determinadas organizações ou mercados ou monitorar interações funcionário-cliente para evitar discriminação ou comportamentos com viés. Para manter essas políticas, você pode precisar atualizar seus padrões de design ou configuração do sistema como faria para a [cumprimento legal](/docs/architect/pt-br/well-architected/guide/compliant#adesão-legal). Para promover maior adesão a padrões éticos em suas soluções do Salesforce, alinhe-se às políticas da empresa e avalie seu uso de inteligência artificial. ### Políticas da empresa As políticas da empresa são diretrizes que definem como vários aspectos dos negócios (incluindo pessoas, processos e tecnologia) devem funcionar. Os clientes preferem fazer negócios com organizações em que Trust. A maioria das políticas da empresa é projetada para refletir esse princípio. A Trust do cliente será rapidamente corrompida se seus sistemas criarem experiências de usuário que não estejam alinhadas às suas políticas declaradas. As políticas eficazes derivam naturalmente de [uma cultura de ética](https://www.salesforce.com/blog/new-research-ethical-leadership-business/). Cada funcionário, da engenharia e do design à ciência de dados, ao marketing e às vendas, deve ser instruído sobre sua responsabilidade de uso ético. Nessa cultura, os funcionários veem estruturas de incentivo claras para recompensar comportamentos éticos e consequências claras e consistentes para comportamentos não éticos. Considere o seguinte para garantir que as políticas da sua organização sejam refletidas nos seus designs: - **Seja consciente das consequências indesejadas**. Como arquiteto, é sua responsabilidade prever os possíveis impactos de suas soluções e como elas serão usadas. Não caia na armadilha de apenas considerar ou testar caminhos felizes. Em vez disso, aplique seu conhecimento em testar casos de ponta e avaliar compensações para considerar cuidadosamente as implicações éticas de suas soluções. Pense em todos que serão afetados pelo produto, especialmente aqueles que estão subrepresentados, marginalizados ou vulneráveis. Avalie as várias maneiras como alguém, ou algo parecido, pode interagir com sua solução e criar consequências indesejadas. Use o [Build With Intention Toolkit](http://sfdc.co/BuildwithIntention) para projetar com inclusão em mente. - **Integre ética à política de uso aceitável da sua empresa**. Trabalhe com sua equipe jurídica ou um terceiro para incluir ética em sua política de uso aceitável para garantir que o uso de suas soluções esteja alinhado aos valores da sua empresa. Sua documentação deve incluir informações sobre quais dos valores e políticas da sua organização têm suporte em suas soluções, sejam elas desenvolvidas com ferramentas de código baixo ou de código profissional. Publique sua política de uso aceitável para demonstrar seu compromisso de criar Trust com seus funcionários e clientes. - **Use linguagem inclusiva**. Entenda as diferentes maneiras como as pessoas experimentam sua solução e [refine a linguagem](https://www.salesforce.com/news/stories/salesforce-updates-technical-language-in-ongoing-effort-to-address-implicit-bias/) na interface do usuário, no código e na documentação para refletir com mais precisão a inclusão. Comece identificando e removendo primeiro linguagem exclusiva e, em seguida, compromete-se a entender os tipos de hábitos ou práticas que podem levar à exclusão. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/compliant#padrões-éticos-e-antipadrões) abaixo mostra como é a adesão adequada (e ruim) às políticas da empresa em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou identificar áreas em seu sistema que precisam ser refatoradas. Para saber mais sobre ferramentas do Salesforce para alinhar designs a políticas da empresa, consulte [Ferramentas relevantes para estar em conformidade](/docs/architect/pt-br/well-architected/guide/compliant#ferramentas-relevantes-para-estar-em-conformidade). ### Inteligência artificial A inteligência artificial usa sistemas computacionais para realizar tarefas que normalmente exigem inteligência humana, como raciocínio, percepção e tomada de decisão. Os recursos de IA da Salesforce Platform abrangem tecnologias preditivas, generativas e agentes, oferecendo um conjunto abrangente de ferramentas para aprimorar as experiências do cliente e as operações de negócios: - A **IA preditiva** analisa dados históricos e prevê resultados futuros, como tendências de vendas ou rotatividade de clientes. O Einstein AI fornece essas percepções analisando padrões em seus dados para fornecer recomendações e prever resultados de negócios. - A IA **gerativa** foca na criação de novos conteúdos usando modelos de idioma grandes. O Einstein GPT é um componente essencial que trabalha com seus dados de CRM para gerar conteúdo personalizado, como emails, respostas de chat e comunicações com o cliente. - A IA **agente** leva a IA um passo adiante, permitindo que os agentes raciocinem e atuem de modo autônomo para atingir um objetivo específico. Agentforce é a plataforma para criar esses agentes inteligentes, que podem automatizar processos de negócios complexos, como resolver casos de clientes ou otimizar campanhas de marketing. Esses agentes podem interagir com dados em tempo real por meio do Data 360 e aproveitar os fluxos de trabalho e as APIs existentes. Todos esses recursos de IA são protegidos pela Camada de Trust do Einstein, que garante o uso ético. A maioria dos algoritmos principais da IA do Einstein não é configurável, mas, para alguns recursos, os clientes podem ajustar os modelos usando seus próprios dados, conforme indicado na documentação. Além disso, você pode basear modelos de IA em seu próprio CRM, artigos da base de Knowledge e outros documentos por meio da Fundamentação ampliada de recuperação (RAG) para tornar as saídas ainda mais precisas para sua organização, clientes e casos de uso. No entanto, se seus dados subjacentes forem com viés ou discrepância, suas saídas também poderão se tornar com viés e imprecisas. Um exemplo de viés é não incluir membros de uma determinada raça, gênero ou etnia na sua lista de contatos, embora sua base de clientes seja diversa e inclua membros desse grupo. Consulte o módulo Salesforce [Criação responsável de IA Trailhead](https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence), [Compreensão de IA de agente confiável Trailhead](https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai), [Modelo de maturidade de ética de IA](https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf), os [princípios de IA confiável](https://www.salesforceairesearch.com/trusted-ai) da Salesforce, as [Directivas de IA generativa responsável](https://www.salesforce.com/news/stories/generative-ai-guidelines/) e as [Directivas de IA de agente responsável](https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/) para obter mais informações. Não levar em conta os regulamentos legais aplicáveis e os próprios padrões éticos da sua empresa pode levar a vieses dentro de sua IA, resultando em processos, perda de receita, problemas de Customer Trust e dano à imagem pública da sua empresa. Estes são os aspectos a serem considerados para o uso responsável e ético da IA: - **Examine seus conjuntos de dados e documentos**. Garanta que seus conjuntos de dados sejam representativos de todos que sua funcionalidade de IA afetará. Isso pode exigir pesquisa do usuário para entender quem eles são e confirmar que seus dados representam todos com precisão para mitigar possíveis vieses. Também é essencial revisar os dados do CRM, artigos do Knowledge e qualquer outra documentação em que você baseia seus modelos para garantir que eles estejam atualizados, precisos e completos. A fundamentação de seus modelos em muitos dados não é útil e pode resultar em alucinações se esses dados forem antigos, contraditórios ou incompletos. - **[Mantenha um humano no comando](https://www.salesforce.com/news/stories/human-at-the-helm/)**. Você não quer que os humanos intervenham em cada interação individual de IA, mas, em vez disso, capacita seus funcionários a se concentrarem nos itens de alta estimativa que mais precisam da sua atenção. Teste seus sistemas de IA até ter certeza de que eles podem assumir mais responsabilidade e monitorar os resultados para garantir que continuem trabalhando com precisão e eficiência. Garanta que seus sistemas ou agentes de IA sejam instruídos a escalar para um humano para casos de uso de alto risco e quando o nível de confiança da IA estiver baixo. - **Dê prioridade à segurança das saídas e resultados do modelo**. Realize [avaliações](https://www.salesforce.com/news/stories/developing-ethical-ai/) de viés, explicabilidade e robustez e [colaboração ética](https://www.salesforce.com/blog/red-teaming-ai/). Priorize a proteção de privacidade por meio de respostas e ações do agente para quaisquer informações de identificação pessoal (PII) presentes nos dados usados para treinamento e crie proteções para evitar danos adicionais. Se você descobrir resultados prejudiciais durante o teste, adicione instruções aos avisos do sistema e teste novamente. Você também pode precisar melhorar a qualidade ou a representatividade dos dados que está usando para Geração de recuperação ampliada (RAG). - **Seja preparado para regulamentos**. Além das preocupações éticas com a IA, muitos governos aprovaram ou estão aprovando legislação para regular o uso da IA por organizações que operam em suas jurisdições. Essa legislação pode incluir a exigência de publicar cartões de modelo descrevendo como uma solução de IA foi criada e funciona. Antes de implementar uma solução baseada em inteligência artificial, esteja ciente de qual tipo de funcionalidade relacionada a IA é ou não aceitável nas regiões em que seus sistemas serão usados e faça os ajustes necessários à sua estratégia. Talvez seja necessário desabilitar determinados recursos em algumas regiões para cumprir os regulamentos locais. Em caso afirmativo, garanta que seus sistemas possam continuar operando sem esses recursos. Muitas jurisdições também exigem transparência quando clientes ou usuários finais estão interagindo com sistemas de IA. - **Monitore os modelos de IA da sua organização**. Os usuários afetados devem saber quando uma IA foi usada e ter a oportunidade de facilmente relatar danos e solicitar remediação. É importante observar que os relatórios sozinhos podem não ser suficientes para determinar se sua funcionalidade de IA está causando dano aos usuários. Monitore continuamente seus modelos quanto ao desvio de dados, alterações nas pontuações de fairness/bias, precisão e robustez. Verifique se você tem planos para [gerir alertas de qualidade](https://help.salesforce.com/s/articleView?id=sf.bi_edd_quality_alert.htm&type=5) e responder rapidamente quando impactos negativos forem identificados. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/compliant#padrões-éticos-e-antipadrões) abaixo mostra qual é o design de IA adequado (e ruim) em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas. Para saber mais sobre as ferramentas do Salesforce para implementar políticas de IA mais éticas, consulte [Ferramentas relevantes para estar em conformidade](/docs/architect/pt-br/well-architected/guide/compliant#ferramentas-relevantes-para-estar-em-conformidade). ### Padrões éticos e antipadrões 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 padrões éticos no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/trusted-ethical-standards).

	Padrões	Antipadrões
Políticas da empresa	Em seus padrões de design: - Os padrões incluem diretrizes claras para áreas afetadas por políticas da empresa	Em seus padrões de design: - Não existem padrões de design ou não fornecem diretrizes claras sobre áreas sujeitas às políticas da empresa
	Na sua documentação: - A documentação para configuração e personalizações inclui referências aos valores da empresa com suporte	Na sua documentação: - A documentação para configuração e personalizações não faz referência a valores ou políticas da empresa
	Em sua organização: - Todos os objetos e campos que estão sujeitos à conformidade relacionada à política da empresa têm Categorização de conformidade, Proprietário de dados, Nível de confidencialidade de dados e Uso de campo configurados	Em sua organização: - Objetos e que estão sujeitos à conformidade relacionada à política da empresa estão sem configuração para Categorização de conformidade, Proprietário de dados, Nível de confidencialidade de dados ou Uso de campo
Inteligência Artificial	Em seus padrões de design: - As políticas e os casos de uso aprovados para aplicativos de IA são claros e fáceis de encontrar - Garanta que os dados e documentos usados para RAG sejam representativos, completos, precisos e atualizados. Procure conteúdo com viés, tóxico e outro conteúdo prejudicial que possa estar em seus conjuntos de dados ou documentação - Respostas generativas sempre identificam fontes de dados usadas por modelos de IA - Os conjuntos de dados que podem/não podem ser usados para engenharia de prompts foram documentados - Os bots e as respostas de IA generativa são claramente identificados para os usuários - Os padrões para quando e como usar isenções de responsabilidade para IA generativa são definidos claramente - Existem requisitos claros para como documentar pontos de envolvimento humano em designs de soluções de IA - Existem padrões para documentar caminhos de feedback direto e indireto em designs de soluções de IA - Os pontos em que a IA deve ser identificada para um usuário são definidos claramente - Mantenha uma pessoa no comando, especialmente em casos de uso regulados ou de alto risco	Em seus padrões de design: - Não existem padrões de design ou não incluem políticas claras e casos de uso aprovados para aplicativos de IA - As respostas generativas não identificam fontes de dados usadas por modelos de IA - Os conjuntos de dados usados para engenharia de prompts não são documentados - Os bots e as respostas de IA generativa não são identificados para os usuários - Não há isenções de responsabilidade sobre respostas generativas - Não há requisitos para documentar pontos de envolvimento humano em designs de soluções de IA - Não há padrões para documentar caminhos de feedback direto e indireto para designs de soluções de IA - Os padrões de design não indicam pontos em que a IA deve ser identificada para os usuários
Inteligência Artificial	Na sua documentação: - A documentação para configuração e personalizações envolvendo a funcionalidade de IA contém uma descrição completa de toda a lógica do processo e é armazenada em um local central acessível por equipes jurídicas ou auditores - Os modelos que você cria ou leva para o Salesforce são claramente documentados, incluindo todos os segmentos de dados aplicáveis - A lógica da conversa e as conversas agentes são fundamentalmente documentadas - Processos estão em vigor para monitorar os modelos de IA da sua organização quanto ao desvio de dados, alterações nas pontuações de fairness e viés, precisão e robustez - As descrições são mantidas para os dados de treinamento, avaliação e teste usados para todos os processos de IA - As descrições são mantidas para qualquer limpeza de dados relacionada à IA junto com testes de viés, resultados associados e pontuações de desempenho/precisão (por exemplo, pontuações F1)	Na sua documentação: - A documentação para ajustes e personalizações envolvendo a funcionalidade de IA está ausente, incompleta ou armazenada em um local inacessível - Modelos ou sistemas de IA são implementados em sua organização sem documentação de seus modelos - Os agentes são implementados em sua organização sem documentação de mensagens e fluxo de conversa - Os processos de monitoramento de IA não existem ou não estão documentados - As informações sobre dados de treinamento, avaliação e teste usados para todos os processos de IA não estão claras ou estão indisponíveis - As informações sobre limpeza de dados, testes de viés e resultados relacionados a IA estão indisponíveis ou não estão claras

## Acessibilidade A _acessibilidade_ na tecnologia refere-se à usabilidade de sistemas ou soluções para pessoas com diferentes habilidades. Projetar sistemas que funcionem para todos os usuários, independentemente da habilidade, é uma obrigação legal em alguns locais e setores. Além dos requisitos legais, a criação de sistemas acessíveis ajuda sua organização a fomentar e reforçar o Trust com suas partes interessadas. Para aplicativos voltados para o cliente, isso pode até mesmo aumentar a receita, pois os clientes podem optar por usar seus sistemas em vez de alternativas menos acessíveis. A Salesforce publica os [Relatórios de conformidade de acessibilidade (ACRs)](https://www.salesforce.com/company/legal/508_accessibility/), documentos padrão do setor que detalham como nosso software está em conformidade com os padrões de acessibilidade. A maioria dos nossos controles baseados em UI, incluindo Componentes da Web Lightning e Modelos do Experience Cloud, são projetados para cumprir esses padrões. Embora nossos recursos de acessibilidade de linha de base possam ser suficientes para muitas empresas, é importante revisar nossos ACRs e notas de versão antes de iniciar qualquer projeto. Isso o ajudará a identificar e documentar quaisquer requisitos de acessibilidade adicionais que se estendam além de nossos padrões, dependendo da abordagem de comercialização do produto ou serviço. Você pode melhorar a acessibilidade dos seus sistemas focando duas áreas importantes: entrada de dados e navegação. ### Entrada de dados As atividades de entrada de dados acontecem sempre que um usuário precisa inserir informações em um campo, formulário ou outra parte de uma interface do usuário. Embora teclados e ratos sejam os métodos de entrada mais comuns, alguns usuários podem depender de dispositivos de fala para texto ou similares. Além disso, seus usuários podem se comunicar em diferentes idiomas. As soluções não projetadas com a acessibilidade em mente podem impedir que indivíduos com determinadas deficiências interajam com elas. Considere o seguinte ao projetar para acessibilidade: - **O idioma que seus usuários preferem**. Dependendo de onde sua empresa opera, você pode decidir definir um único idioma padrão para seus sistemas ou oferecer funcionalidades multilíngues. Se estiver exibindo texto em vários idiomas, seus padrões de design devem incluir uma lista de rótulos de campo e outros elementos da interface do usuário (como notificações e mensagens de erro) que precisam de tradução. Engaje um falante nativo para revisar as traduções quanto à precisão e ao significado. Use os [funcionamentos de tradução](https://help.salesforce.com/s/articleView?id=sf.workbench_overview.htm&type=5) do Salesforce para traduções de metadados e dados em tempo real e teste cuidadosamente todos os recursos multilíngues. - **Os tipos de dispositivos de entrada que serão usados**. Lista todas as ferramentas que podem ser usadas para entrada de dados além de um teclado e um mouse padrão em seus padrões de design. Inclua testes de acessibilidade em seus planos de teste e certifique-se de que todas as entradas sejam testadas com vários tipos de dispositivos de entrada. - **A usabilidade dos seus formulários**. Garanta que seus formulários incluam rótulos visíveis, forneçam mensagens de erro úteis, conduzam o usuário para a conclusão, informam o usuário sobre seu progresso e permitem que ele revise, confirme e edite suas entradas. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/compliant#padrões-de-acessibilidade-e-antipadrões) abaixo mostra a aparência da entrada de dados quando projetada corretamente (e mal) para acessibilidade em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou identificar áreas em seu sistema que precisam ser refatoradas. Para saber mais sobre ferramentas do Salesforce para criar entrada de dados mais acessível, consulte [Ferramentas relevantes para estar em conformidade](/docs/architect/pt-br/well-architected/guide/compliant#ferramentas-relevantes-para-estar-em-conformidade). ### Navegação A navegação envolve os usuários movendo o foco entre telas e entre campos em uma tela. Os usuários podem precisar navegar pelos vários elementos da IU em seu sistema de várias maneiras, incluindo por meio de cliques e teclas, ao mesmo tempo que dependem de visão, audição e toque. Certifique-se de que seus padrões de design incluam uma lista de dispositivos de navegação aos quais você planeja dar suporte. As equipes de implementação devem consultar essa lista ao testar para garantir que todas as possibilidades de navegação sejam consideradas. Considere as seguintes perguntas e respostas ao projetar a navegação acessível: - **Como os usuários irão navegar pela sua solução?** Lista todos os dispositivos que podem ser usados para navegação além de um teclado e um mouse padrão em seus padrões de design. - **A sua navegação é consistente?** Estabeleça padrões de design para controles de navegação para garantir a consistência em todo o seu sistema. Os caminhos de navegação devem ser semelhantes em todo o sistema. Navegação inconsistente, como um botão "Avançar" azul na parte inferior direita de uma tela e um botão "Avançar" verde no centro da próxima, pode ser um problema leve para alguns usuários, mas pode tornar o aplicativo inutilizável para pessoas com deficiência. - **Os testes levam em conta a acessibilidade?** Inclua testes de acessibilidade em seus planos de teste e certifique-se de que todos os fluxos de navegação sejam testados com vários tipos de dispositivos de entrada. - **O foco do teclado está consistentemente visível?** Sempre exiba visualmente o estado atual do foco do teclado para ajudar os usuários que dependem de um teclado a navegar. - **A sua navegação depende da cor?** Evite usar apenas cores para apresentar informações ou solicitar uma ação. Siga as [Directivas de Acessibilidade de Conteúdo Web (WCAG) 2.0](https://www.w3.org/TR/WCAG20/#visual-audio-contrast) para o uso adequado da cor para transmitir significado e aplicar o nível certo de contraste. - **Vossos projetos foram revisados?** Realize análises regulares para garantir que sua interface de usuário seja consistente e fácil de entender. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/compliant#padrões-de-acessibilidade-e-antipadrões) abaixo mostra como é a navegação quando projetada corretamente (e mal) para acessibilidade em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou identificar áreas do seu sistema que precisam ser refatoradas. Para saber mais sobre ferramentas do Salesforce para criar navegação mais acessível, consulte [Ferramentas relevantes para estar em conformidade](/docs/architect/pt-br/well-architected/guide/compliant#ferramentas-relevantes-para-estar-em-conformidade). ### Padrões de acessibilidade e antipadrões 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 acessibilidade no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/trusted-accessibility).

	Padrões	Antipadrões
Entrada de dados	Em seus padrões de design: - Todos os dispositivos que podem ser usados para entrada de dados além de um teclado e um mouse padrão são listados - Os valores de texto e suas traduções para todos os idiomas com suporte são listados	Em seus padrões de design: - Somente alguns, ou nenhum, dos dispositivos que podem ser usados para entrada de dados além de um teclado e um mouse padrão são listados - Os idiomas com suporte são listados junto com os elementos da IU a serem traduzidos
	Em seus planos de teste: - As etapas de teste incluem o uso de vários tipos de dispositivos de entrada para inserir dados - As etapas de teste incluem entrada de dados em vários idiomas	Em seus planos de teste: - O teste de acessibilidade não está incluído ou o teste para entrada de dados acessível é feito ad hoc
	Em sua organização: - As traduções para idiomas com suporte são armazenadas no Workbench de tradução	Em sua organização: - As traduções são armazenadas em rótulos personalizados
Navegação	Em seus padrões de design: - Todos os dispositivos que podem ser usados para navegação (não apenas teclado e mouse padrão) são listados claramente - Os padrões de UI/UX especificam o tipo e o estilo de todos os controles de navegação - Os tipos de dicas visuais aprovados para transmitir significado ou estado são listados claramente e a cor não é uma dica principal	Em seus padrões de design: - Os padrões de design não existem ou não consideram os requisitos de acessibilidade para controles de navegação - Os padrões de UI/UX para navegação são inconsistentes - As dicas visuais para significado ou estado dependem da cor ou não há listas claras de dicas visuais para criadores
Navegação	Em seus planos de teste: - As etapas de teste incluem o uso de vários tipos de dispositivos de entrada para navegar - Os planos de teste incluem o uso de testes de UI/UX para garantir caminhos de navegação consistentes	Em seus planos de teste: - O teste de acessibilidade não está incluído ou o teste para navegação acessível é feito ad hoc

## Ferramentas relevantes para estar em conformidade

Ferramenta	Descrição	Adesão legal	Padrões éticos	Acessibilidade
Agentforce Analytics	Obtenha percepções sobre o desempenho dos seus agentes		X
Central de testes do Agentforce	Execute até 10 trabalhos de teste com até 1.000 casos de teste por teste para que você possa rapidamente criar e avaliar vários cenários.		X
Citações	As citações ajudam a identificar possíveis imprecisões ou alucinações nas respostas geradas, aumentando sua confiança no uso de ferramentas de IA.		X
API de consentimento	Rastrear as preferências do cliente para consentimento	X
Fluxo de eventos de consentimento	Enviar notificações sobre alterações a informações de consentimento ou contato	X
Objetos de gerenciamento de consentimento	Gerenciar as preferências de consentimento e privacidade do cliente	X
Acesso a dados e portabilidade	Exportar dados relacionados ao cliente mediante solicitação	X
Classificação de dados	Informações de auditoria e conformidade da chave de registro para campos de objeto	X
Relatórios do Data 360	Monitorar a adesão às instruções do agente		X
Exclusão de dados	Excluir dados para cumprir normas legais	X
Preferências de privacidade de dados	Armazenar as preferências de privacidade de dados do cliente	X	X
Tradução de dados	Traduzir dados apresentados aos usuários	X		X
Detecção de dados	Alinhar categorias e níveis de confidencialidade aos dados reais	X
Explorador do Data 360	Gerenciar permissões de projeto e objeto para cientistas de dados	X	X
Einstein Data Prism	Uma solução de fundamentação para aplicativos de IA generativa no Salesforce, melhorando a precisão das soluções de IA que usam seus recursos de fundamentação		X
Camada Einstein Trust	Uma coleção de recursos, processos e políticas projetados para proteger a privacidade dos dados, aprimorar a precisão da IA e promover o uso responsável da IA em todo o ecossistema do Salesforce		X
Registros de evento aprimorados	Os registros de evento capturam os eventos e as mensagens do usuário em uma sessão do agente para revisar a adesão à instrução, testar e solucionar problemas do agente.		X
Files Connect	Procurar, pesquisar e compartilhar arquivos externos no Salesforce	X
Hyperforce	Conformidade com os requisitos de armazenamento de dados locais	X
Tradução de metadados	Traduzir idiomas para localizar aplicativos	X		X
API de portabilidade	Compilar dados do cliente identificados em sua política de portabilidade	X	X
Centro de preferências	Coletar preferências de comunicação do cliente	X	X
Centro de Privacidade	Atenda a solicitações do cliente e leis de privacidade de dados	X	X
Restruturação do processamento de dados	Restringir métodos de processamento de dados pessoais	X	X
Direito de ser esquecido	Excluir dados individuais do cliente mediante solicitação	X
Arquivos do Salesforce	Compartilhar e armazenar arquivos de modo privado	X
Centro de Segurança	Visualizar configurações de segurança e privacidade em várias organizações	X
Shield Platform Encryption	Criptografe dados em repouso e em trânsito	X
Workbench de tradução	Manter valores traduzidos para rótulos de metadados e dados	X		X

## Recursos relevantes para estar em conformidade

Recurso	Descrição	Adesão legal	Padrões éticos	Acessibilidade
5 Princípios para Design de IA Responsável	Projete a funcionalidade de Inteligência Artificial (IA) de modo ético		X
Princípios de acessibilidade (Trailhead)	Saiba por que a acessibilidade é importante			X
Relatórios de conformidade de acessibilidade (ACRs)	Entenda como o Salesforce atende aos padrões de acessibilidade			X
Visão geral de acessibilidade	Entender a acessibilidade no Salesforce Lightning			X
Modelo de maturidade de ética de IA	Desenvolva um roteiro para operacionalizar princípios éticos		X
AI Red Teaming: Testando para Trust	Descubra como os "hackers éticos" do Salesforce desenvolvem IA responsável por meio da equipe vermelha.		X
Automando o Adversário: Projetando uma estrutura escalável para a IA da equipe vermelha	Aprenda como o Salesforce automatiza a geração de prompts adversários e a validação de respostas. Fuzzai ajuda a proteger interações de IA enquanto reduz a exposição humana a conteúdo prejudicial.		X
Práticas recomendadas para design de conversa	Siga as práticas recomendadas ao projetar chatbots		X	X
Práticas recomendadas para design sustentável (Trailhead)	Incorpore a sustentabilidade aos seus designs		X
Gerenciamento de consentimento	Rastrear e cumprir solicitações de consentimento e recusa	X
Políticas de dados do Einstein	Controle o uso de dados em todas as funcionalidades do Einstein	X	X
Modelo de padrões de design	Criar padrões de design para sua organização	X	X	X
Práticas éticas de hacking demonstram sucesso na criação de produtos IA confiáveis	Saiba como a Salesforce utiliza práticas de equipe vermelha para melhorar a segurança de nossos produtos de IA testando uso mal-intencionado, ataques intencionais de integridade, uso indevido benigno e identificando problemas de IA responsável.		X
Liderança Ética e Negócios	Percepções sobre tecnologia, igualdade e ética		X
Política de Uso Ético	Explorar a política do Salesforce sobre o uso ético de nossos produtos e serviços		X
Ética por Design (Trailhead)	Incorporar design ético ao desenvolvimento de tecnologia		X
Explore a cultura e os valores do Salesforce (Trailhead)	Explorar os valores centrais do Salesforce		X	X
Seguir Diretrizes de design móvel acessível	Siga as práticas recomendadas para tornar seus designs acessíveis		X	X
Introdução ao Web Accessibility (Trailhead)	Aprenda as noções básicas de como tornar sites e aplicativos acessíveis			X
Como a Salesforce cria uma infraestrutura red teaming reprodutível	Quatro componentes que recomendamos ao projetar, implementar e executar testes adversários		X
Como executar uma oficina de digitalização de consequência	Considere todos os resultados possíveis durante a inovação		X
Implementação da Proteção de Dados e Privacidade	Avaliar requisitos de proteção de dados e privacidade	X
Design inclusivo (Trailhead)	Promover a inovação com princípios de design inclusivos		X	X
Modelo de planilha de KPI	Definir indicadores-chave de desempenho (KPIs) para sua organização	X
Informação jurídica	Explorar o Centro de informações legais do Salesforce	X
LWC Cookie Consent Module	Controlar o acesso a cookies do usuário em sites do Experience Cloud	X	X
Visão geral de privacidade	Saiba mais sobre privacidade de dados por região e setor	X
Promover agentes responsáveis e éticos	Saiba como implementar estratégias de teste e equipe ética e desenvolver princípios e padrões de orientação para sua organização.		X
Directivas de IA agente responsável			X
Criação responsável do módulo Trailhead de IA	Saiba como remover viés de seus dados e algoritmos para criar sistemas de IA éticos em sua empresa.		X
Directivas de IA generativa responsável	Construímos nossos Princípios IA confiáveis com um novo conjunto de diretrizes focadas no desenvolvimento e implementação responsáveis de IA generativa.		X
Certificações de conformidade da Salesforce	Revisar as certificações e atestados de conformidade da Salesforce	X
Design sustentável (Trailhead)	Reforce o relacionamento entre negócios e sociedade		X
Teste para acessibilidade na Web (Trailhead)	Utilizar testes automatizados e manuais para garantir a acessibilidade			X
IA agente confiável	Saiba como a Agentforce usa salvaguardas e princípios de IA responsável para criar IA ética.		x

## Diga-nos o que você pensa Ajude-nos a manter o Salesforce Well-Architected relevante para você; faça nossa [pesquisa](https://sfdc.co/bxNtvh) para fornecer feedback sobre esse conteúdo e diga-nos o que você gostaria de ver em seguida. ## Introdução O Salesforce Bem-Arquivado representa orientação e práticas recomendadas de um especialista em todo o Salesforce e em todo o nosso ecossistema. Obrigado a todos que contribuíram recursos e Knowledge para bem arquitetado. Atualizamos documentos bem-arquitetos duas vezes ao ano. Anunciaremos como contribuir com a opção Bem-arquitetos durante nossa próxima janela de manutenção. Você pode enviar feedback sobre Well-Architected a qualquer momento [aqui](https://sfdc.co/bxNtvh). ## Diga-nos o que você pensa Ajude-nos a manter o Salesforce Well-Architected relevante para você; faça nossa [pesquisa](https://sfdc.co/bxNtvh) 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](/docs/architect/pt-br/well-architected/guide/contributors). ## Introdução Os sistemas demonstram comportamentos interessantes facilitando o acesso e o uso de aplicativos pelas pessoas, fazendo com que os usuários sintam que estão fazendo mais trabalho de alta qualidade e fazendo com que as pessoas queiram usar aplicativos no sistema. A realização de um comportamento envolvente é importante para os negócios, pois está diretamente correlacionado à adoção do usuário, bem como à satisfação geral do trabalhador e do cliente. Os comportamentos de engajamento também ajudam a reduzir as solicitações de suporte e podem ajudar a aumentar a qualidade das solicitações de recurso dos usuários. Um dos desafios da criação de comportamento envolvente é que é difícil medir apenas pelas métricas de objetivo. Em vez disso, ele é medido pelas experiências subjetivas dos usuários; os usuários acham que os aplicativos de engajamento fornecem verdadeiro valor. Os aplicativos interessantes são [acessíveis](/docs/architect/pt-br/well-architected/guide/compliant#acessibilidade), não intrusivos e fáceis de entender. Eles exigem uma quantidade mínima de integração e treinamento. Eles usam métodos claros para prevenir de modo proativo erros do usuário. Outro desafio é que as metas de engajamento geralmente variam com os diferentes tipos de interações do usuário no seu sistema. Por exemplo, você pode ter um conjunto de metas para usuários internos que estão gerenciando casos e outro para usuários externos que estão enviando informações por meio de um formulário em seu site. Para projetar sistemas interessantes, você precisa considerar cuidadosamente o tipo de engajamentos que está tentando criar e por que os usuários gostariam de se engajar antes de começar a montar recursos e páginas. A parceria com designers de experiência do usuário (UX) ajudará você a tomar decisões muito mais eficientes quando se trata de entregar aplicativos interessantes. De uma perspectiva arquitetônica, a adoção e a retenção de usuários são componentes cruciais de um sistema saudável. Arquiteturas envolventes reduzem a probabilidade de Problemas de qualidade dos dados causados por usuários que se apressam em processos ou ignoram etapas para evitar ter que gastar tempo em um sistema que eles não gostam de usar. Para sistemas voltados para o público externo, uma arquitetura envolvente pode aumentar a receita e a retenção de clientes à medida que os clientes que acham seus sistemas mais fáceis de usar escolhem fazer mais negócios com sua organização. Você pode criar aplicativos mais interessantes focando a entrega de experiências simplificadas e úteis. ## Simplificado Os aplicativos simplificados são fáceis de navegar, apresentam informações e tarefas de entrada de dados claramente e se adaptam a vários formatos. Os aplicativos simplificados também apresentam padrões de experiência aos quais os usuários se acostumaram em outros aplicativos comumente usados. Por exemplo, a maioria dos navegadores da Web apresenta "abrir em nova guia" como a opção principal quando os usuários clicam com o botão direito em um link. Um aplicativo simplificado que contém guias seguirá o mesmo padrão. Os impactos de experiências de aplicativo ineficientes podem ir muito além de um aplicativo individual. Uma má experiência de aplicativo erode o Trust dos usuários. À medida que mais tipos de aplicativos críticos para os negócios e voltados para o cliente passam para canais digitais, isso pode custar às empresas a fidelidade das principais partes interessadas. Você pode simplificar melhor seus aplicativos sendo intencional em como abordar a complexidade do aplicativo, o design do formulário e os fatores formais. ### Complexidade do aplicativo Minimizar a complexidade do aplicativo significa que os usuários veem apenas itens de menu, guias e controles de navegação relevantes. Você precisará criar mapeamentos entre grupos de usuários, permissões de usuário e a experiência de aplicativo correta. Use esses mapeamentos para entender qual experiência de aplicativo apresentar a um determinado usuário e, em seguida, garanta que seu aplicativo tenha os controles lógicos necessários para oferecer essa experiência. Aplicativos que apresentam aos usuários uma complexidade excessiva podem causar uma variedade de experiências ruins: - Os usuários costumam ver guias desnecessárias ou irrelevantes, navegar para telas em branco e encontrar links desabilitados ou bloqueados. - Instruções desnecessárias ou inúteis, como "ignorar esta guia se seu papel for X..." aparecem em materiais de treinamento e capacitação. - Menus de navegação confusos obrigam os usuários a gastar mais tempo localizando os itens de que precisam para concluir o trabalho. Essas experiências ruins levam a baixas taxas de adoção e níveis de satisfação. Considere o seguinte ao determinar o nível certo de complexidade do aplicativo: - Organize menus, guias e outros controles de navegação com base na prioridade do trabalho que os usuários precisam realizar. - Evite introduzir novos comportamentos que um usuário precisa aprender apenas para que ele possa usar seu aplicativo. - Não remova o acesso a recursos que permitem aos usuários personalizar aspectos da interface do usuário. - Use conjuntos de permissões para fornecer opções de navegação expandidas ou reduzidas. - Simplifique as [atribuições de ativação de](https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm) página do Lightning. Minimize o número de páginas ativas do Lightning por aplicativo. Use formulários dinâmicos, conjuntos de permissões e renderização condicional para adicionar itens a páginas do Lightning em seu aplicativo. Faça isso em vez de manter várias páginas do Lightning ativadas e atribuídas por perfil. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/engaging#padrões-de-aplicativo-simplificados-e-antipadrões) abaixo mostra como é o gerenciamento de complexidade de aplicativos adequado (e ruim) em uma organização do Salesforce. Você pode usá-los para validar ou melhorar seus designs de aplicativo. Para saber mais sobre as ferramentas do Salesforce que podem ajudá-lo a gerenciar a complexidade do aplicativo, consulte [Ferramentas relevantes para engajamento](/docs/architect/pt-br/well-architected/guide/engaging#ferramentas-relevantes-para-engajamento). ### Formulários Os formulários simplificados organizam informações em sequências lógicas, dão suporte à entrada rápida de dados e minimizam as etapas necessárias. Eles também permitem mensagens de validação de dados do lado do cliente [útiles](/docs/architect/pt-br/well-architected/guide/engaging#útil) e eliminam ciclos repetidos de envio de formulários. Considere o seguinte ao projetar formulários: - **Agrupar campos relacionados**. Campos de grupo relacionados à mesma etapa em um processo ou tarefa de entrada de dados. Elimine campos que não sejam diretamente relevantes para a tarefa em questão. - **Inserir dados e validar antecipadamente**. Os campos que exigem que os usuários insiram dados devem aparecer mais cedo nos formulários. É uma prática recomendada detectar problemas com formatação de dados ou dados ausentes no nível do campo e o mais rapidamente possível (ou seja, antes de um usuário tentar navegar para a próxima etapa ou enviar o formulário). Além disso, evite exibir erros no nível do campo antes que os usuários tenham tido a chance de inserir dados nos campos. - **Minimizar tarefas de entrada de dados**. Preencha ou preencha automaticamente o máximo possível de campos para minimizar erros de entrada de dados e melhorar a eficiência. Peça para os usuários inserirem apenas dados essenciais ou críticos. Elimine todas as entradas de dados que não sejam relevantes para o processo de negócios em questão. Use listas de opções em vez de campos de texto de formulário livre quando possível para impor a seleção de opções válidas e reduzir variações da mesma resposta. - **Minimizar envios ao servidor**. Não use formulários de várias etapas para enviar dados ao servidor várias vezes. Garanta que todos os componentes personalizados do [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching) ou do [Aura](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_storable_actions.htm) usem cache no lado do cliente para lidar com ações de navegação ou paginação. (O Salesforce Lightning Experience e o aplicativo Salesforce móvel usam o armazenamento em cache no lado do cliente por padrão.) Projete formulários para que os usuários enviem dados ao servidor apenas uma vez. Valide as entradas do usuário no lado do cliente antes do envio dos formulários. Isso minimizará envios de usuários indesejados, impedirá que transações duplicadas ou sujas consumam largura de banda no back-end e ajudará você a projetar para um melhor [tratamento de dados](/docs/architect/pt-br/well-architected/guide/automated#tratamento-de-dados). - **Gerenciar estado do formulário**. O armazenamento em cache no lado do cliente não apenas ajuda com comportamentos como navegação e paginação, como também ajuda a minimizar a perda de dados devido a problemas de conectividade intermitentes. Gerenciar o estado de modo eficaz também significa que os aplicativos podem orquestrar adequadamente o envio de dados ao servidor e evitar transações duplicadas, além de apresentar mensagens relevantes e oportunas aos usuários com base no status das ações no lado do servidor. Formulários simplificados enviam operações de dados apenas uma vez e não exigem que os usuários aguardem a conclusão de operações de execução longa no servidor. - **Siga as normas de acessibilidade**. Para maximizar o público para seus aplicativos e ajudar a garantir que eles incluam todos os seus clientes, aplique padrões de [acessibilidade](/docs/architect/pt-br/well-architected/guide/compliant#acessibilidade) em seus designs de formulário. Os formulários simplificados ajudam a aumentar a [integridade dos dados](/docs/architect/pt-br/well-architected/guide/automated#integridade-de-dados) nos seus aplicativos e a [utilidade](/docs/architect/pt-br/well-architected/guide/engaging#útil) dos aplicativos para os usuários. Eles também podem reduzir pedidos e solicitações de suporte, pois os usuários podem melhor lidar com erros e entender claramente o estado de seus envios de formulário. Além disso, os formulários simplificados permitem uma entrada de dados rápida e eficiente e garantem que os usuários não precisem esperar a conclusão de processos de execução mais longa para realizar um trabalho adicional. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/engaging#padrões-de-aplicativo-simplificados-e-antipadrões) abaixo mostra qual é o design de formulário adequado (e ruim) em uma organização do Salesforce. Você pode usá-los para validar ou melhorar seus designs de formulário. Para saber mais sobre as ferramentas do Salesforce que podem ajudá-lo a criar formulários mais simplificados, consulte [Ferramentas relevantes para engajamento](/docs/architect/pt-br/well-architected/guide/engaging#ferramentas-relevantes-para-engajamento). Para obter orientações mais específicas sobre como escolher a ferramenta de formulário certa para seu caso de uso, consulte o Guia de decisão do [arquiteto para criar formulários com o Salesforce](/docs/architect/pt-br/decision-guides/guide/build-forms#principais-transferências). ### Fator de forma Os aplicativos de engajamento se adaptam perfeitamente a diferentes dispositivos e tipos de interação ou formatos. Dependendo do tipo de dispositivo, diferentes tipos de interações com o usuário serão mais fáceis (ou mais difíceis) e a legibilidade de formulários e campos mudará. Lembre-se de que, além das dimensões da tela, o fator forma também se refere a como seus usuários interagem com a tela. Um número crescente de dispositivos agora tem telas de toque e alguns usuários também podem usar dispositivos especiais para a [acessibilidade](/docs/architect/pt-br/well-architected/guide/compliant#acessibilidade). Lembre-se de considerar estes fatores ao projetar formulários. Não considerar variações de formato pode levar a vários problemas, incluindo: - Má qualidade dos dados - Interfaces de aplicativo não utilizáveis - Mais sessões de solução de problemas ou "pedido em nome de" para agentes de suporte - Pobre adoção do usuário, baixo número de usuários ativos e altas taxas de abandono do aplicativo Para projetar a interoperabilidade entre formatos em seus aplicativos Salesforce, considere o seguinte: - **Identifique os formatos com suporte para cada aplicativo**. - **Identifique os métodos de entrada e as necessidades de acessibilidade dos seus usuários**. Consulte [Acessibilidade](/docs/architect/pt-br/well-architected/guide/compliant#acessibilidade) para obter mais informações. - **Use a [funcionalidade padrão](/docs/architect/pt-br/well-architected/guide/intentional#funcionalidade-padrão-versus-personalizada) para proporcionar experiências adaptáveis entre dispositivos sempre que possível**. - Por padrão, os [modelos de página do Lightning](https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5) fornecidos pelo Salesforce oferecem suporte a diferentes formatos. Se você optar por desenvolver modelos de página personalizados do Lightning com o Aura, os desenvolvedores precisarão incorporar informações de formato no arquivo de design do componente. - Os [componentes de página padrão](https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5) fornecidos pelo Salesforce tratam de renderizar em todos os formatos suportados para você. Se você criar componentes personalizados com o LWC ou o Aura, os desenvolvedores precisarão lidar com a consciência da largura (há diferenças de implementação entre o [Aura](https://developer.salesforce.com/docs/atlas.en-us.238.0.lightning.meta/lightning/components_config_for_app_builder_width_aware.htm?q=width) e o [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_width_aware)) e declarar o suporte do formato no arquivo de design de seus componentes. - **Siga as instruções para simplificar os [formulários em todos os dispositivos](/docs/architect/pt-br/well-architected/guide/engaging#formulários)**. - **Criar planos de teste (e bons testes) para os principais fatores de forma**. O ideal é testar todos os dispositivos e os formatos de todos os seus aplicativos. No entanto, configurar os dispositivos corretos (ou simuladores de dispositivo) para testes de formato pode ser um investimento significativo. Se você souber que um determinado aplicativo ou conjunto de aplicativos terá um conjunto significativo de usuários em celulares ou tablets, priorize testes precisos para esses aplicativos em formatos de celulares e tablets. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/engaging#padrões-de-aplicativo-simplificados-e-antipadrões) abaixo mostra como é a conscientização de fator adequado (e ruim) em uma organização do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar páginas que precisam ser refatoradas. Para saber mais sobre ferramentas do Salesforce para design de formato eficaz, consulte [Ferramentas relevantes para engajamento](/docs/architect/pt-br/well-architected/guide/engaging#ferramentas-relevantes-para-engajamento). ### Padrões de aplicativo simplificados e antipadrões 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 aplicativos simplificados no [Pattern & Anti-Pattern Explorer](/docs/architect/pt-br/well-architected-tools/guide/easy-streamlined).

	Padrões	Antipadrões
Complexidade do aplicativo	Em sua organização: - Os aplicativos têm menos de 10 guias na configuração padrão fornecida pelo administrador - Nenhum aplicativo tem "Desabilitar personalização do usuário final de itens de navegação neste aplicativo" definido como true	Em sua organização: - Os aplicativos normalmente têm mais de 10 guias na configuração padrão fornecida pelo administrador - Muitos aplicativos têm "Desabilitar personalização do usuário final de itens de navegação neste aplicativo" definido como verdadeiro ou a permissão para personalizar itens de navegação está desabilitada em toda a organização
Formulários	Em seus aplicativos: - Campos seguem agrupamentos lógicos - Campos de entrada de dados aparecem juntos, em grupos de cinco ou menos - Os erros de entrada de dados são claros e aparecem no nível do campo antes de os usuários sairem ou enviarem dados - Os controles de paginação permitem a movimentação entre as etapas - O envio de dados acontece uma vez - Rótulos para ações e navegação são claros - Feedback oportuno e visual é fornecido para confirmar ações do usuário, como cliques em botões - Os botões de navegação (por exemplo, "Ir", "Avançar" e "Voltar") são colocados de modo consistente em toda a IU	Em seus aplicativos: - Os campos de entrada de dados não são agrupados de modo lógico, exigindo uma grande quantidade de alternância de contexto pelos usuários que preenchem formulários - Os erros de entrada de dados contêm informações cretinas que só podem ser interpretadas por alguém que entende o funcionamento interno do sistema - Erros de entrada de dados aparecem apenas quando o botão de envio de um formulário é clicado - Etapas e agrupamentos não são definidos claramente, dificultando a navegação - O envio de dados ocorre várias vezes ao longo do processo de entrada de dados - Rótulos para ações e navegação estão confusos para usuários que não estão familiarizados com a funcionalidade do sistema subjacente - A confirmação visual de ações do usuário não é fornecida - Os botões de navegação aparecem em locais arbitrários em toda a IU
Formulários	Na sua lógica de forma: - Os campos são pré-preenchidos ou preenchidos automaticamente o máximo possível - Os usuários não precisam esperar a conclusão de ações no lado do servidor de execução longa - Componentes personalizados usam `cacheable=true` para ações baseadas em servidor que não envolvem operações de dados - As operações de dados são realizadas uma vez - Os adaptadores LWC `@wire` lidam com todas as ações que não envolvem operações de dados	Na sua lógica de forma: - Campos que podem ser pré-preenchidos ou preenchidos automaticamente exigem entrada manual - Os usuários precisam parar de trabalhar durante o processo de envio para aguardar a conclusão das ações no lado do servidor - Componentes personalizados definidos `cacheable=false`
Fator de forma	Em sua organização: - Modelos de página do Lightning fornecidos pelo Salesforce são usados para todas ou a maioria das páginas - Modelos de página personalizados do Lightning usam `design:supportedFormFactors` e `design:supportedFormFactor` em arquivos de design de componente do Aura - Componentes personalizados do LWC ou do Aura disponíveis no Criador de aplicativo declaram formatos com suporte em seus respectivos arquivos de design e implementam padrões de estilo sensíveis à largura	Em sua organização: - O Classic ainda está ativo - Modelos de página personalizados do Lightning não usam uniformemente `design:supportedFormFactors` e `design:supportedFormFactor` em arquivos de design de componente do Aura - Componentes personalizados do LWC ou do Aura disponíveis no Criador de aplicativo não declaram consistentemente formatos com suporte em seus respectivos arquivos de design - Em componentes personalizados do LWC ou do Aura, o estilo sensível à largura não é implementado por interfaces fornecidas pelo Salesforce - Em componentes personalizados do LWC ou do Aura, o estilo para diferentes fatores de forma é conduzido puramente por valores de `px` ou `%` embutidos em código no CSS
	No desktop: - Campos de entrada de dados e controles de navegação se encaixam na tela e podem ser interagidos conforme o desejado - As páginas de registro e aplicativo aparecem corretamente com base nas regras de atribuição de ativação de página	No desktop: - Campos de entrada de dados e controles de navegação não aparecem em seus locais desejados na tela - Interações com campos de entrada de dados e controles de navegação não correspondem aos comportamentos obrigatórios - A ausência de regras de atribuição de ativação de página significa que todos os usuários veem as mesmas páginas de registro e aplicativo
	Em celulares e tablets: - Entradas de dados e controles de navegação aparecem corretamente - Os usuários podem inserir dados facilmente - Aparecem menus de navegação móveis, otimizados para formatos menores - Layouts compactos aparecem no nível do registro	Em celulares e tablets: - Entradas de dados e controles de navegação não são renderizados de maneira consistente ou correta - Os usuários não podem inserir dados facilmente - Menus de navegação móveis não podem ser distinguidos da navegação em desktop - Layouts compactos não são configurados no nível do registro

## Útil Os aplicativos úteis permitem que os usuários se sintam mais poderosos e eficientes, com menos distrações ou interrupções. Aplicativos úteis ajudam a manter a [integridade dos dados](/docs/architect/pt-br/well-architected/guide/automated#integridade-de-dados), reduzindo erros manuais e fornecendo feedback aos usuários quando e onde eles precisam. Eles ajudam os usuários a entender quais ações eles precisam focar agora e em seguida e fornecem informações relevantes para ajudar os usuários a resolver seus próprios problemas mais rapidamente. Eles fornecem uma vinculação clara entre as ações de um usuário e impacto ou realizações significativas. Você pode criar aplicativos mais úteis com três hábitos principais: notificação e mensagens, orientação no aplicativo e reconhecimento e recompensas. ### Notificações e mensagens Notificações e mensagens ajudam os usuários a se manterem informados. Um sistema de notificação e mensagens bem projetado pode aumentar o engajamento e a produtividade fornecendo aos usuários as informações necessárias para tomar decisões críticas em tempo hábil. Um sistema de notificação e mensagens mal projetado, que apresenta mensagens que não são relevantes nem oportunas, terá o efeito oposto. Os usuários internos rapidamente desabilitarão ou ignorarão as notificações, fazendo com que eles percam mensagens legítimas que podem afetar processos comerciais essenciais. Clientes ou outros usuários externos que estão cansados de notificações sem significado podem optar por parar de usar seus sistemas. Ao decidir como os aplicativos lidarão com o envio de notificações e mensagens aos usuários, considere o seguinte: - **Para erros, use notificações e mensagens como um último recurso**. Projete o [tratamento de erros](/docs/architect/pt-br/well-architected/guide/automated#manipulação-de-erros) em seu sistema com processamento de back-end que pode corrigir determinados tipos de erros sem intervenção humana. Envie aos usuários apenas mensagens sobre erros críticos que os impedirão de concluir tarefas. Da mesma forma, envie apenas mensagens de erro a usuários de negócios quando houver alguma ação corretiva que eles próprios possam (e precisam) executar. Mensagens de erro adicionais ou detalhes podem ser disponibilizados por meio de relatórios e/ou enviados à equipe de suporte técnico usando métodos assíncronos para acompanhamento adicional. - **Escolha tipos de mensagem com base na relevância, na urgência e na pontualidade**. Diferentes tipos de mensagens têm diferentes níveis de bloqueio ou comportamento de interrupção. Os avisos são um tipo de mensagem de "bloqueio", pois exigem que os usuários os confirmem antes de poderem continuar o trabalho. Como acontece com as mensagens de erro, os avisos devem ser usados com moderação. As notificações de toast são [não bloqueadoras](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_toast), podem ter comportamentos de persistência diferentes e oferecem suporte a diferentes tipos de casos de uso de mensagens. As mensagens menos invasivas são [notificações no aplicativo](https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5) ou emails. Eles são mais bem usados para fornecer informações com as quais os usuários podem lidar quando e como desejarem. - **Considere o que precisa acontecer em seguida**. Embora algumas notificações sejam informativas (como mensagens de sucesso), outras podem exigir que os usuários realizem algum tipo de ação. Ao projetar notificações, lembre-se de considerar não apenas a notificação em si, mas quaisquer informações adicionais que um usuário possa precisar executar. Inclua instruções ou links claros para onde os usuários podem encontrar informações adicionais ou concluir etapas de acompanhamento em todas as notificações acionáveis. - **Foco na legibilidade**. Informe claramente o propósito de cada notificação e as próximas etapas que um usuário precisa seguir em resposta. As mensagens devem ser compreensíveis para usuários de negócios que não estejam familiarizados com o funcionamento interno dos sistemas subjacentes. Ao criar mensagens, siga as [normas de acessibilidade](/docs/architect/pt-br/well-architected/guide/compliant#acessibilidade) e garanta que elas estejam localizadas para dar suporte aos usuários nas regiões em que podem aparecer. Inclua padrões para quando usar notificações ou diferentes tipos de erros em seus [padrões de design](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-design) para ajudar a garantir que os criadores de aplicativos sigam práticas consistentes. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/engaging#padrões-de-aplicativo-úteis-e-antipadrões) abaixo mostra a aparência de notificações e mensagens adequadas (e ruins) em uma organização do Salesforce. Você pode usá-los para validar seus designs antes de criar ou identificar usos que precisam ser refatorados. Para aprender mais sobre ferramentas do Salesforce para notificações e mensagens, consulte [Ferramentas relevantes para engajamento](/docs/architect/pt-br/well-architected/guide/engaging#ferramentas-relevantes-para-engajamento). ### Orientação no aplicativo A orientação no aplicativo pode ser uma maneira eficiente de desmistificar fluxos de trabalho complexos (embora você deve certificar-se de tê-los [otimizado](/docs/architect/pt-br/well-architected/guide/automated#design-de-processos) primeiro) ou ajudar a integrar novas equipes. Pode ser uma ótima maneira de introduzir alterações de processo, destacar novos recursos ou distribuir treinamento de maneira automatizada e escalonável. No entanto, se não for implementada com cuidado, a orientação no aplicativo poderá ser usada em excesso. Pop-ups ou alertas frequentes podem criar uma quantidade enorme de ruído e interrupção para os usuários, levando à perda de produtividade. A orientação no aplicativo também pode ser subutilizada, resultando em processos mais complicados de gerenciamento de alteração e liberação (especialmente para recursos simples). Por fim, tanto o uso excessivo quanto o uso insuficiente da orientação no aplicativo levam a vários problemas que representam riscos para os negócios, incluindo: - Integridade de dados menor - Maior número de erros do usuário - Níveis maiores de frustração do usuário e menor satisfação do usuário - Menor produtividade do usuário Lembre-se de que talvez você queira usar a orientação no aplicativo de maneira diferente em diferentes cenários, pois a mentalidade de um usuário vai ditar quanto de orientação é "muito demais" versus "não suficiente". Os usuários que estão sendo introduzidos em um novo sistema pela primeira vez provavelmente precisarão de mensagens mais frequentes do que os usuários que estão simplesmente aprendendo sobre um novo recurso em um sistema com o qual já estão familiarizados. Aqui estão algumas chaves para criar uma orientação no aplicativo eficaz: - **Desenvolver padrões de design**. É importante lembrar que a exposição excessiva à orientação no aplicativo pode fazer com que os usuários comecem a descartar ou ignorar mensagens de modo rotineiro. Nesse ponto, a orientação no aplicativo se torna uma irritação, em vez de um recurso. Defina [padrões de design](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-design) para deixar claro quando usar avisos, guias passo a passo, texto de ajuda em nível de campo, mensagens de validação, caminhos, fluxos de tela e assim por diante. - **Criar um sistema de priorização para implementações de orientação**. Nem todos os casos de uso para orientação no aplicativo devem ser implementados. Em vez disso, considere as seguintes perguntas para priorizar. Onde você pode simplesmente usar melhores nomes de campo, rótulos mais explícitos em botões, melhor [design de formulário](/docs/architect/pt-br/well-architected/guide/engaging#formulários) e [otimização de processo](/docs/architect/pt-br/well-architected/guide/automated#design-de-processos) para criar fluxos de trabalho mais intuitivos? Onde você pode adicionar texto ou links mais úteis a um caminho? Qual será o impacto do [custo comercial](/docs/architect/pt-br/resources/guide/kpi-spreadsheet-template) da orientação no aplicativo? Com que frequência você deseja entregar mensagens aos seus usuários? Além disso, certifique-se de que todas as implementações estejam incluídas no seu [roteiro](/docs/architect/pt-br/well-architected/guide/intentional#roteiro) para que todas as partes interessadas tenham visibilidade. - **Mapeie os usuários para orientação no aplicativo ativa (e sugerida**). O mapeamento de usuários para a orientação no aplicativo ajudará a identificar e evitar a "sobrecarga de utilidade" devido à excesso de orientação no aplicativo para um usuário. Muitas vezes, isso é resultado de desenvolvimento isolado, pois as equipes pensam muito sobre seu caso de uso específico. Manter uma visão holística do que os usuários serão expostos é especialmente crucial para organizações grandes. Incluir implementações de orientação no seu roteiro também pode ajudar. - **Reunir e usar feedback para melhorar**. Revise os dados sobre o uso de orientação no aplicativo e use-os para avaliar a eficácia das implementações de orientação no aplicativo. Certifique-se de fornecer maneiras de os usuários também darem feedback abertos para ajudar os criadores de orientação. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/engaging#padrões-de-aplicativo-úteis-e-antipadrões) abaixo mostra a aparência adequada (e ruim) da orientação no aplicativo em uma organização do Salesforce. Você pode usá-los para validar designs antes de criar e identificar implementações que precisam ser refatoradas. Para aprender mais sobre ferramentas do Salesforce para orientação no aplicativo, consulte [ferramentas relevantes para engajamento](/docs/architect/pt-br/well-architected/guide/engaging#ferramentas-relevantes-para-engajamento). ### Reconhecimento e recompensas Criar reconhecimento e recompensas em um aplicativo ajuda os indivíduos que usam esse aplicativo a se sentirem mais conectados ao impacto de seu trabalho e a entender melhor o valor de suas contribuições, produtividade e desempenho. Também é uma maneira eficiente de desbloquear fidelidade e engajamento. Não projetar experiências de aplicativo para reconhecimento ou recompensa pode contribuir para uma variedade de problemas, incluindo: - Usuários que têm dificuldade para entender seu progresso ou velocidade - Confusão sobre o progresso para metas ou trabalho não concluído - Usuários mais não produtivos, que não veem uma conexão entre suas tarefas e o "plano geral" - Tempo de gerenciamento desperdiçado em relatórios manuais de meta de baixo nível Experiências de aplicativo recompensadoras podem ser difíceis de projetar e entregar, pois dependem da cultura, das políticas e dos padrões da empresa, bem como do contexto e das preferências dos usuários individuais. Recursos que podem ajudar os usuários de desktop a sentir momentos de prazer ou apreciação podem se tornar uma irritação para um usuário no celular ou um usuário que está tentando trabalhar em um escritório residencial ruidoso e ocupado. As pessoas que usam um aplicativo para trabalhar com informações privadas ou altamente confidenciais podem não apreciar a comunicação sobre marcos na forma de celebrações de confete ou emblemas. Uma equipe de vendas distribuídas, por outro lado, pode ver essa gamificação como uma experiência de aplicativo adequadamente recompensadora. Por fim, os padrões de implementação escolhidos podem ser mais bem determinados trabalhando com designers de experiência do usuário (UX) em uma equipe. Quando se trata de arquitetura, é importante identificar como e onde os aplicativos podem implementar recursos que ajudam os usuários a se sentir reconhecidos e recompensados. Também é essencial entender como e onde esses recursos podem tornar os aplicativos menos [reutilizáveis](/docs/architect/pt-br/well-architected/guide/composable) ou deixar de oferecer [valor comercial real](/docs/architect/pt-br/well-architected/guide/automated#valor-de-negócios). Estas são algumas perguntas a serem consideradas ao avaliar reconhecimento e recompensas em aplicativos Salesforce: - **Como e onde os usuários podem ver seu próprio progresso, bem como estatísticas gerais da equipe?** Os relatórios são importantes, mas geralmente contêm dados resumidos que podem perder o contexto do trabalho diário. Você pode usar uma ferramenta como o Criador de aplicativo Lightning para integrar gráficos ou painéis em telas de registro no contexto de um aplicativo, ajudando os usuários a entender o impacto ou o progresso das tarefas diárias. - **Como os usuários devem ser reconhecidos?** Isso pode variar de acordo com as preferências da equipe ou do indivíduo. Em alguns casos, os supervisores podem querer ver mensagens sobre o progresso do usuário para que possam ser compartilhados com um grupo maior. O reconhecimento também pode ser uma vantagem adicional para ajudar com o moral do funcionário. Em outros casos, os usuários podem simplesmente preferir ser os únicos notificados sobre seu progresso em uma determinada tarefa ou projeto. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/engaging#padrões-de-aplicativo-úteis-e-antipadrões) abaixo mostra como é o reconhecimento e as recompensas adequados (e ruins) em uma organização do Salesforce. Você pode usá-los para validar designs antes de criar e identificar implementações que precisam ser refatoradas. Para saber mais sobre ferramentas do Salesforce para reconhecimento e recompensas, consulte [Ferramentas relevantes para engajamento](/docs/architect/pt-br/well-architected/guide/engaging#ferramentas-relevantes-para-engajamento). ### Padrões de aplicativo úteis e antipadrões 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 aplicativos úteis no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/easy-helpful).

	Padrões	Antipadrões
Notificações e Mensagens	Os seus padrões de design incluem: - Casos de uso aprovados para notificações, toasts e avisos - Padrões de design para notificações e variantes de toast - Padrões de design para mensagens de erro	Se padrões de design forem definidos, eles não abordarão erros e notificações
	Em sua organização: - As notificações são o formato de mensagens predominante - Mensagens de toast usam variantes - Mensagens de toast com o `modo` definido como `colado` não existem - Os avisos são usados raramente, se houver - As respostas generativas sempre identificam as fontes de dados usadas - Os bots identificam-se claramente antes da primeira interação com os usuários - Avisos de isenção de responsabilidade por riscos associados à IA generativa aparecem para os usuários antes da primeira interação - As isenções de responsabilidade por IA estão em linguagem clara e compreensível para os usuários	Em sua organização: - Emails são o formato de mensagens predominante - Não há abordagem consistente para tipos de mensagem - As mensagens de toast não usam variantes de modo consistente - Mensagens de toast com o `modo` definido para existir `colado` - Os avisos são usados ad hoc - As respostas generativas não identificam as fontes de dados usadas - Os bots não identificam-se claramente antes da primeira interação com os usuários - Nenhum aviso de isenção de responsabilidade por riscos de IA generativa aparece para os usuários - As isenções de responsabilidade por IA não estão em linguagem clara e compreensível para os usuários
	Em seus aplicativos: - Nenhuma resposta generativa é enviada diretamente aos usuários finais sem pontos de engajamento humano	Em seus aplicativos: - As respostas generativas são enviadas diretamente aos usuários finais sem pontos de engajamento humano
Consulte também: Tratamento de erros
Orientação no aplicativo	Suas normas de design e documentação incluem: - Casos de uso aprovados para orientação no aplicativo - Padrões de design para avisos e guias passo a passo - Uma matriz clara de usuários, aplicativos e orientação no aplicativo ativa	Se houver padrões de design e documentação, eles: - Não abordar a orientação no aplicativo - Não inclua uma matriz clara mostrando usuários, aplicativos e orientação no aplicativo ativa
Orientação no aplicativo	Em sua organização: - A configuração para "Atraso entre orientação no aplicativo" usa o valor padrão ou um valor personalizado que seja maior que o período padrão (24 horas) fornecido pelo Salesforce - Nenhum aplicativo tem mais de um guia passo a passo ativo - Nenhum guia passo a passo tem uma configuração "Hora para mostrar" maior que 10 - Nenhum aviso é ativado para "Qualquer página, qualquer aplicativo" ou "Esta página, qualquer aplicativo"	Em sua organização: - A configuração para "Atraso entre orientação no aplicativo" é definida para um período menor que o período padrão (24 horas) fornecido pelo Salesforce - Os aplicativos têm mais de um guia passo a passo ativo - Muitos guias passo a passo têm uma configuração "Hora para mostrar" maior que 10 (e alguns têm o valor máximo de 30) - Os avisos são ativados ad hoc, muitos com a configuração "Qualquer página, qualquer aplicativo" ou "Esta página, qualquer aplicativo"
Reconhecimento e recompensas	Em sua organização: - Os aplicativos usam análise integrada para mostrar aos usuários estatísticas de produtividade e progresso da meta relevantes - As celebrações de caminho são habilitadas apenas com o consentimento do usuário - Notificações e mensagens incluem reconhecimento do usuário e refletem as preferências do usuário no design de quem é notificado e o que aciona as notificações	Em sua organização: - A análise relacionada ao progresso da meta e às estatísticas de produtividade está disponível apenas em relatórios ou painéis do gerente - As celebrações de caminho são habilitadas sem verificar o consentimento do usuário - As notificações e as mensagens não incluem nenhum tipo de reconhecimento de usuário ou não refletem as preferências dos usuários e se sentem ruidosas ou irritantes

## Ferramentas relevantes para engajamento

Ferramenta	Descrição	Simplificado	Útil
Ativar sua página do aplicativo Lightning	Gerenciar a disponibilidade, o nome, a visibilidade e o posicionamento da página	X
Painéis de adoção	Revise o histórico de login, a adoção de recursos e a produtividade	X	X
Alerta	Manter alertas em sessões e exibi-los sem início do usuário		X
Armazenamento em cache no lado do cliente dos resultados do método do Apex	Avaliar o desempenho com dados em cache do lado do cliente	X
Formulários dinâmicos	Exibir apenas campos obrigatórios e seções de página para os usuários	X
Insights de engajamento	Monitorar atividades recentes do usuário e agir conforme necessário	X	X
Orientação no aplicativo	Use avisos e guias passo a passo para treinamento e integração		X
Caminhos de aprendizagem	Personalizar experiências de aprendizado do usuário		X
Criador de aplicativo Lightning	Crie páginas móveis e do Lightning personalizadas sem código	X
Lightning Data Service	Armazenar em cache e compartilhar dados entre componentes	X
Validador do sistema de design do Lightning para VS Code	Validar marcação em relação às diretrizes SLDS	X	X
Modelos de página do Lightning	Criar páginas do Lightning para diferentes formatos	X
Filtros de pesquisa	Filtrar valores para relacionamentos de pesquisa, entre mestre e detalhes e hierárquicos	X
Gerenciar várias moedas	Usar várias moedas em transações		X
Mensagens	Enviar mensagens SMS, Facebook Messenger ou WhatsApp		X
Mobile Publisher	Criar versões móveis de aplicativos Lightning e sites do Experience Cloud	X
Componentes prontos para dispositivos móveis	Crie componentes com bom desempenho em experiências móveis	X
Sites multilíngues	Criar versões de seu site em diferentes idiomas	X	X
Criador de notificações	Criar notificações personalizadas para apresentar informações		X
Caminho	Guie os usuários pelos processos de negócios e celebre o sucesso	X	X
Cache da plataforma	Melhore o desempenho e a confiabilidade ao armazenar em cache os dados	X
Visualizar páginas de aplicativo móvel no Lightning App Builder	Visualizar páginas de registro e aplicativo em um dispositivo móvel	X
Aviso	Alerta os usuários sobre atualizações e problemas relacionados ao sistema		X
Emblemas de reconhecimento	Reconhecer e celebrar as realizações do usuário		X
Reconhecimento com WDC	Aprovar habilidades e agradecer		X
Tipo de registro	Personalize processos de negócios, valores de lista de opções e layouts de página	X	X
Visão geral de reputação	Reconhecer participação e compartilhamento de Knowledge		X
Regras de restrição	Impedir que usuários acessem registros que possam conter dados desnecessários	X
Componentes de página padrão	Entenda os componentes padrão do Salesforce Lightning	X
Traduções	Gerenciar traduções para usuários globais	X	X
Regras de validação	Verifique se os dados atendem aos padrões especificados antes de salvar	X

## Recursos relevantes para engajamento

Recurso	Descrição	Simplificado	Útil
Guia do arquiteto para formulários de construção	Avaliar as considerações de design de formulário e selecionar a melhor ferramenta	X
Configurar seu componente para diferentes formatos	Configure componentes para renderizar em desktops e telefones	X
Personalizar conteúdo da Ajuda	Personalizar o conteúdo da ajuda para sua implementação exclusiva		X
Valores de campo padrão	Definir valores de campo padrão, dinâmico ou estático	X
Directivas de design	Criar interfaces de usuário consistentes com as melhores práticas	X	X
Modelo de padrões de design	Criar padrões de design para sua organização	X	X
Habilidades de teste de design (Trailhead)	Métodos de planejamento para validar e testar um design	X	X
Diretrizes de feedback no aplicativo	Revise as diretrizes para coletar feedback de dentro do seu sistema	X	X
Biblioteca estática do Lightning Design System para Android	Crie aplicativos nativos para Android com a aparência das páginas do Lightning	X
Biblioteca estática do Lightning Design System para iOS	Crie aplicativos nativos para iOS com a aparência das páginas do Lightning	X
Directivas de mensagens	Comunique informações relevantes e crie momentos de prazer		X
Tipo de mensagens	Entenda os diferentes tipos de mensagens com base na interação do usuário		X
Directivas de navegação	Ajude os usuários a alternar entre páginas e se situarem em um aplicativo	X
Teste para acessibilidade na Web (Trailhead)	Utilizar testes automatizados e manuais para garantir a acessibilidade	X	X
Directivas de engajamento do usuário	Revise as diretrizes para integração, adoção, assistência e aprendizado	X	X

Intencional
As soluções intencionais proporcionam valor de negócios imediatamente e ao longo do tempo. As arquiteturas intencionais são planejadas e entregues estrategicamente, podem ser mantidas de modo eficaz e são fáceis de ler e entender pelos humanos.
Estratégia	Manutenção	Lerabilidade
Priorização Roteiro Governança	Padrão vs. personalizado Dívido técnico	Padrões de design Documentação
Automatizado
As soluções automatizadas permitem que a empresa faça o trabalho de forma mais rápida e em escala. Automação saudável reduz o tempo gasto em tarefas manuais repetitivas ou entrada de dados complexo.
Eficiência	Integridade dos dados
Design de processos Lógica operacional KPIs	Tratamento de dados Manipulação de erros
Engajamento
As soluções com engajamento encantarão os usuários e promoverão a adoção. Arquivar para engajamento significa criar experiências de usuário intuitivas e úteis.
Simplificado	Útil
Complexidade do aplicativo Formulários Fator de forma	Notificações e mensagens Orientação no aplicativo Reconhecimento e recompensas

> Leia sobre nossas agendas de atualização [aqui](/docs/architect/pt-br/well-architected/guide/contributors). ## Introdução As soluções intencionais proporcionam valor de negócios imediatamente e ao longo do tempo. As arquiteturas intencionais são planejadas e entregues estrategicamente, podem ser mantidas de modo eficaz e são fáceis de ler e entender pelos humanos. Recursos e correções são priorizados e entregues de maneiras transparentes para as partes interessadas de negócios e tecnologia. As opções de engenharia criam implementações fáceis para que as equipes de entrega e manutenção trabalhem sem recursos adicionais ou complicações. As arquiteturas intencionais são mais fáceis de possuir, manter e evoluir com os negócios porque seguem padrões de implementação claros e consistentes. Os criadores podem interpretar e implementar designs para novos recursos, e as equipes de manutenção podem entender a documentação do que foi implementado. Você pode criar sistemas mais intencionais focando três áreas principais: estratégia, capacidade de manutenção e legibilidade. ## Estratégia Estratégia na arquitetura significa que os sistemas são planejados e entregues com cuidado. Isso significa que as equipes de entrega e manutenção têm uma visão clara do trabalho a ser feito hoje e no futuro e todos estão alinhados com o "por quê" do trabalho a ser feito. Isso significa que as solicitações urgentes podem ser classificadas de modo eficiente e eficiente, e as partes interessadas podem entender claramente os impactos e os prós e os contras das solicitações. Você pode criar uma estratégia mais clara em sua arquitetura focando a priorização, o roteiro e a governança. ### Priorização Priorização significa planejar a ordem e o escopo do trabalho que você entregará. A priorização envolve entender o verdadeiro impacto das entregas no negócio, avaliando esses impactos em relação a outras solicitações de trabalho e o roteiro geral para seu produto ou programa. Uma maneira de avaliar o impacto de um determinado item de trabalho é analisar o custo real ou o benefício para o negócio. Depois de identificar os [KPIs](/docs/architect/pt-br/well-architected/guide/automated#kpis) para a automação, você pode usar uma planilha de cálculo de impacto [de negócios](/docs/architect/pt-br/resources/guide/kpi-spreadsheet-template) para avaliar o custo ou benefício geral da implementação. Esses cálculos podem ajudá-lo a obter alinhamento e aprovação de suas partes interessadas sobre quais automações criar e em que ordem. Eles também podem ajudá-lo a identificar automações para adiar ou evitar. Para automações, consulte [design de processo](/docs/architect/pt-br/well-architected/guide/automated#design-de-processos) para obter mais informações sobre a identificação de trabalho eficaz. Estabelecer uma estrutura de priorização para entrega também ajudará você e suas equipes de manutenção a gerenciar as expectativas do usuário e se manter alinhado ao seu roteiro. Algumas considerações que você pode usar para priorização incluem: - Impacto comercial (custo/benefício) do entregável - Quantidade de novo trabalho necessária para o entregável - Quantidade de trabalho necessária para manter o entregável A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-estratégia-e-antipadrões) abaixo mostra como é a priorização correta (e ruim) quando se trata de trabalho do Salesforce. Você pode usá-los para validar seus planos de implementação ou identificar onde é necessário identificar melhor as prioridades antes de criar. Para saber mais sobre as ferramentas disponíveis no Salesforce para obter ajuda com a priorização, consulte [Ferramentas relevantes para intencional](/docs/architect/pt-br/well-architected/guide/intentional#ferramentas-relevantes-para-intencional). ### Roteiro Um roteiro é uma visualização priorizada, validada e bem definida do que deve ser feito. Os roteiros efetivos fornecem uma visão clara do impacto comercial e do impacto tecnológico do trabalho futuro. Engajar suas partes interessadas comerciais e técnicas é uma parte importante do roteiro. Os roteiros permitem que você receba feedback e conselhos sobre a abordagem e os resultados antes de qualquer trabalho começar. Por fim, os roteiros alinham todas as partes interessadas sobre o "por quê" do trabalho no futuro. Se sua equipe usa uma pendência, é importante entender que seu roteiro não é um resumo ou uma lista dos itens na pendência. O relacionamento é o oposto: Os itens devem entrar na pendência apenas se puderem ser vinculados de modo claro e confiável a um entregável no seu roteiro. Os roteiros de alta qualidade, criados com o engajamento das partes interessadas, fornecem às equipes de entrega e manutenção uma visão clara do que elas devem focar e como priorizar solicitações, tornando mais fácil classificar solicitações conflitantes e gerenciar as expectativas das partes interessadas. Um roteiro ruim ou não existente leva a: - Falta de clareza quanto a quando novos recursos e funcionalidades estarão disponíveis - Prioridades conflitantes entre as partes interessadas - Uma desconexão entre as soluções que estão sendo entregues e a visão geral da organização - Dificuldade para entender o trabalho em andamento - Cargas de trabalho desiguais entre equipes - Falta de visibilidade de relacionamentos e dependências entre itens de trabalho - Implementações paralisadas devido a dependências mal gerenciadas As partes interessadas geralmente precisam de informações alinhadas aos seus papéis para tomar decisões. Criar roteiros eficazes requer uma compreensão clara do público e do tipo de informação de que ele precisa. Os roteiros são divididos em dois estilos para dar suporte a públicos de negócios e técnicos. Cada estilo contém dois níveis de granularidade para dar suporte a diferentes tipos de informações. Os roteiros de negócios ajudam as partes interessadas a planejar mudanças organizacionais, aproveitar oportunidades de crescimento e manter-se alinhadas aos objetivos corporativos. Os roteiros de negócios também fornecem uma maneira de garantir que os gastos de TI estejam alinhados à visão geral dos negócios. - Crie um roteiro de funcionalidade de negócios para mostrar às partes interessadas executivas os recursos que serão habilitados. Esse tipo de roteiro contém detalhes gerais sobre os recursos em si e como eles se alinham aos objetivos de negócios, como aumentar a eficiência operacional ou lançar uma nova linha de produtos. - Crie um roteiro de recursos de negócios para detalhar um recurso específico e mostrar seus recursos e funcionalidades de suporte quando precisar ajudar as partes interessadas de negócios com planejamento de recursos, orçamento e gerenciamento de mudanças. Os roteiros de tecnologia ajudam as partes interessadas técnicas com o planejamento de orçamento e alocação de recursos. Eles também ajudam as equipes de implementação a entender onde seus projetos se encaixam como parte de um panorama geral maior e identificar dependências entre equipes. - Crie um roteiro do sistema de tecnologia para mostrar os sistemas específicos que serão implementados, junto com quaisquer dependências no nível do sistema. Esse tipo de roteiro mostra informações de alto nível do sistema e o alinhamento entre sistemas e funcionalidades de negócios. - Crie um roteiro de componente de tecnologia para detalhar os componentes específicos de um sistema que serão implementados para ajudar com os requisitos de planejamento e habilitação de recursos. Esse tipo de roteiro mostra informações no nível do componente e requisitos de implementação (por exemplo, desenvolvimento declarativo, pro-código etc.). Certifique-se de que seus roteiros contenham linhas do tempo realistas. Um erro comum é incluir apenas o tempo necessário para implementar um sistema sem considerar também o tempo necessário para concluir as atividades relacionadas. Isso pode resultar em alocação excessiva de membros da equipe de implementação e atrasos mais longos que o esperado. Ao criar um roteiro, considere o tempo que levará para concluir o seguinte: - Documentação de todas as funcionalidades novas e atualizadas - Manutenção da funcionalidade existente necessária para dar suporte a novos recursos - Atualizações a sistemas relacionados necessárias para dar suporte a integrações - Suporte elevado das equipes do projeto imediatamente após a ativação - Testes, treinamento e gerenciamento de mudanças Os roteiros de negócios e tecnologia bem alinhados comunicam uma visão holística de quando os recursos serão disponibilizados e qual tecnologia está por trás deles. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-estratégia-e-antipadrões) abaixo mostra a aparência dos roteiros adequados (e ruins) para uma organização do Salesforce. Você pode usá-los para validar ou melhorar sua estratégia de roteiro. Para saber mais sobre ferramentas do Salesforce que podem ajudá-lo com o roteamento, consulte [ferramentas relevantes para intencional](/docs/architect/pt-br/well-architected/guide/intentional#ferramentas-relevantes-para-intencional). ### Governança A governança é a estrutura que você usa para lidar com priorização, tomada de decisão e gerenciamento de mudanças com suas partes interessadas. A governança torna claro como as decisões são tomadas e comunicadas. Ele fornece maneiras consistentes para que o feedback e as solicitações entrem no processo de tomada de decisão e para que todas as partes interessadas entendam o status do trabalho de manutenção e desenvolvimento. A governança ajuda os processos de gerenciamento de versão a serem claros e consistentes e ajuda todos os membros da equipe a entender seus papéis e responsabilidades. Sem a governança adequada, as equipes terão vários problemas, incluindo: - Solicitações sobre recursos e funcionalidades sobrepostos chegam ad hoc - As equipes de implementação priorizam esforços ou solicitações "mais fáceis" de partes interessadas mais influentes, sem consideração adequada de valor comercial, compensações ou metas organizacionais gerais - Falta de processos de aprovação e revisão consistentes - Ritmos de versão inconsistentes e qualidade - Alta taxa de defeito, substituições, conflitos e trabalho redundante em esforços de desenvolvimento Talvez o sinal mais claro de que um sistema não tem uma governança eficaz sejam versões lentas e complicadas. É importante reconhecer que o tamanho de um sistema de governança não é uma medida de sua eficácia. Na verdade, sistemas elaborados para governança (como aqueles encontrados em muitas grandes empresas) podem reduzir a velocidade e a frequência das versões. A boa governança é sobre tornar difícil que personalizações ruins passem pelos estágios iniciais de desenvolvimento e colocar boas personalizações em produção de maneira previsível e consistente. Muitas vezes, os esforços de governança são reativos. Eles são iniciados ou duplicados quando um problema, como débito técnico excessivo, começa a se tornar um problema de negócios. Em muitos casos, a resposta infeliz é que a empresa “bloqueia” os esforços de desenvolvimento e as versões, em vez de criar [normas de design](/docs/architect/pt-br/resources/guide/design-standards-template) e automação de construção eficazes para impor esses padrões em cadeias de ferramentas de desenvolvedores e sistemas de controle de origem. Ao criar a estrutura para seu sistema de governança do Salesforce, inclua os seguintes elementos e considere estas principais perguntas a serem respondidas: - **Pedidos de trabalho.** Como os usuários podem solicitar funcionalidades ou recursos? Como os bugs são relatados? - **Priorização e planejamento de trabalho.** Quem decide o que as solicitações de trabalho importam? Como o trabalho é delimitado, priorizado e aceito ou desconectado? - **Ambiente e planejamento de lançamento.** Qual é o pipeline de ambiente para desenvolvimento, teste e liberação? Quem faz o que provisionar, atualizar e fornecer acesso? Quem lida com implantações e validação? Como e quando as alterações são liberadas? Como você lida com implantações ou ambientes durante um ciclo de liberação do Salesforce? (Para obter mais informações sobre isso, consulte [Gerenciamento de ciclo de vida do aplicativo](/docs/architect/pt-br/well-architected/guide/resilient#gerenciamento-de-ciclo-de-vida-do-aplicativo).) - **Propriedade do serviço e suporte à produção.** Quem dá suporte a quê? Quem lida com problemas de produção de "correção rápida"? Como esses itens são testados e liberados? Quem é responsável pelos padrões gerais de segurança da organização? A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-estratégia-e-antipadrões) abaixo mostra como é a governança adequada (e ruim) para uma organização do Salesforce. Você pode usá-los para validar ou melhorar sua estratégia de governança. Para saber mais sobre as ferramentas do Salesforce disponíveis para governança, consulte [Ferramentas relevantes para intencional](/docs/architect/pt-br/well-architected/guide/intentional#ferramentas-relevantes-para-intencional). ### Padrões de estratégia e antipadrões 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 estratégia no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/easy-strategy).

	Padrões	Antipadrões
Prioridade	Na sua documentação: - Todos os novos itens de trabalho têm métricas de valor comercial claras (por exemplo, aumentos de receita, poupança de custos de otimizações de processos etc.) - Os roteiros mostram o trabalho priorizado com base no valor dos negócios	Na sua documentação: - O valor comercial associado ao trabalho não está claro ou não existe - Não existem roteiros
Prioridade	Dentro da sua empresa: - Os custos de implementação e manutenção foram identificados para todos os itens de trabalho - As solicitações de recursos são priorizadas com base no impacto dos negócios, na quantidade de novo trabalho necessário para entregar e na quantidade de trabalho necessário para manter	Dentro da sua empresa: - Os custos associados à implementação e manutenção de recursos não estão claros - As solicitações são entregues ad hoc ou primeiro a entrar/primeiro a sair
Roteiro	Roadmaps: - Comunicar informações personalizadas para seu público (negócios ou técnicos) - Comunicar informações no nível correto de detalhes - Mostrar datas de início e término - Mostrar pré-requisitos e dependências	Caminhos (se houver): - São usados como materiais de início do projeto e não artefatos para entrega - Não ajude a alinhar partes interessadas e equipes de entrega - Misture níveis de detalhes (por exemplo, incluindo sistemas e componentes no mesmo roteiro) - Contém informações que não são personalizadas para o público (por exemplo, funcionalidades de negócios e sistemas no mesmo roteiro)
Roteiro	Dentro do seu negócio: - As partes interessadas entendem o "por quê" dos itens de trabalho - As equipes de entrega sabem como avaliar itens pendentes em relação a prioridades de longo prazo - As equipes sabem quem está fazendo o que e como gerenciar dependências - O trabalho é intencional, mesmo quando as prioridades precisam mudar rapidamente	Dentro do seu negócio: - O trabalho é extraído do que estiver na pendência e não há "por quê" claro - As equipes têm dificuldade para coordenar o trabalho interdependente e muitas vezes replicam o trabalho sem perceber - O trabalho costuma ser reativo - As partes interessadas frequentemente se sentem frustradas e confusas sobre o que está sendo feito e estão desorientadas quando novos recursos serão entregues
Governance	Dentro do seu negócio: - Os usuários podem facilmente relatar bugs e recursos de solicitação - O processo de priorização para itens de trabalho é documentado e transparente para todas as partes interessadas - A estratégia de ambiente está claramente documentada e os ambientes de desenvolvimento correspondem à documentação - O planejamento da versão é previsível e transparente para todos os membros da equipe de entrega - Os membros da equipe sabem quem é responsável por o que ao longo do ciclo de vida do aplicativo - As versões estão claras para usuários e equipes de entrega/manutenção - Os processos de suporte de produção são claros e as correções rápidas têm um caminho claro para a produção - Equipes e projetos usam apenas modelos de IA aprovados para uso comercial	Dentro do seu negócio: - Relatórios de bug e solicitações de recurso são ad hoc - Os itens de trabalho não têm uma priorização clara - Os ambientes são provisionados ad hoc e podem não ser atualizados de modo previsível; os desenvolvedores geralmente não têm os ambientes e o acesso necessários - As versões são imprevisíveis para equipes de entrega e usuários - As equipes não sabem quem é responsável por quê - As correções fixas são tratadas ad hoc - Sua pendência se tornou um "banco de ideias" obsoleto e estagnado - Os órgãos de governança atuam como um help desk que soluciona problemas de solicitações de suporte - A documentação não está facilmente acessível - Equipes selecionam modelos de IA ad hoc

## Capacidade de manutenção A capacidade de manutenção significa que um sistema pode ser mantido em um estado saudável, com novos recursos entrando e débito técnico saindo do sistema regularmente e de forma previsível. Os sistemas de manutenção permitem que suas equipes proporcionem valor aos negócios com velocidade e qualidade previsíveis. A capacidade de manutenção de um sistema depende de vários fatores, incluindo o quão legível ele é, o quão solto ele está acoplado e o quão completa sua estratégia de teste é. O mais importante é que a capacidade de manutenção de um sistema depende da simplicidade de seu design. Esta seção abrange maneiras de criar designs de soluções mais simples e aumentar a capacidade de manutenção. Você pode criar soluções mais fáceis de manter focando duas chaves: usar funcionalidade padrão sobre personalizada e lidar com débito técnico. ### Funcionalidade padrão versus personalizada O Salesforce oferece uma gama de soluções pré-criadas (Sales Cloud, Service Cloud e muitas soluções do setor do Salesforce), além da flexibilidade para criar suas próprias soluções personalizadas. Os serviços básicos que alimentam as próprias soluções de nuvem da Salesforce também estão disponíveis para quaisquer soluções personalizadas criadas na Salesforce Customer 360 Platform. Use os serviços e soluções predefinidos do Salesforce como uma base confiável para o máximo possível de suas soluções. O uso de serviços de plataforma predefinidos tem dois benefícios distintos. Primeiro, seus aplicativos naturalmente se beneficiam das inovações mais recentes do Salesforce a cada versão. Em segundo lugar, suas equipes de desenvolvimento podem se concentrar em expandir e aprofundar os recursos de negócios fornecidos por suas soluções do Salesforce em vez de lidar com o trabalho pesado arquitetônico básico. Escolher adequadamente quando usar a funcionalidade padrão e quando criar a funcionalidade personalizada não é um desafio do ponto de vista arquitetônico. As chaves são: - **Personalizar a plataforma significa modificar e estender, não copiar**. Ao projetar ou avaliar sua arquitetura, você deve perguntar: Isso já existe em algum lugar na Salesforce Platform? Se a resposta for "_Sim, mas...\[insira alterações que uma parte interessada quer aqui...]"_, use o recurso pré-construído na plataforma. O trabalho arquitetônico a ser feito é identificar as maneiras mais úteis de configurar o recurso pré-construído do Salesforce para atender às expectativas de negócios. - **Nenhuma personalização é trivial**. Ao longo do tempo, cada alteração tem consequências. Se você precisar implementar uma solução personalizada, pode mitigar a inevitável [débeda técnica](/docs/architect/pt-br/well-architected/guide/intentional#dívido-técnico) que seu sistema vai acumular escolhendo usar tecnologia de baixo código sempre que possível e criando [unidades compostables](/docs/architect/pt-br/well-architected/guide/composable) em suas implementações. - **Considere o espectro build-buy**. O [Salesforce AppExchange](https://appexchange.salesforce.com/) é um mercado de aplicativos e soluções para estender o Salesforce. Os aplicativos AppExchange podem fornecer funcionalidade sem a sobrecarga envolvida na criação e manutenção de uma solução personalizada. Considere o seguinte ao avaliar soluções do AppExchange: - Identifique os recursos e lacunas da solução. O ideal é encontrar um aplicativo que atenda a todos os seus requisitos de negócios. Na realidade, talvez você não encontre um ajuste perfeito. Conforme você avalia soluções, mapeie a funcionalidade na solução potencial para uma lista priorizada de requisitos de negócios. Isso vai ajudá-lo a encontrar a solução que melhor atende aos seus requisitos mais críticos. - Use sandboxes e avaliações gratuitas. Use períodos de avaliação gratuitos para avaliar aplicativos em ambientes de sandbox e identificar o melhor ajuste. Determine se os aplicativos exigirão que você faça alterações de configuração que entrem em conflito com sua configuração existente. - Considere os custos de curto e longo prazo. Avalie as economias de manutenção de aplicativo de longo prazo em relação aos custos recorrentes de aplicativos baseados em assinatura. Evite cenários em que você tenha que pagar custos recorrentes por muitas funcionalidades que suas partes interessadas de negócios nunca usarão. - **Use os modelos de dados predefinidos do Salesforce.** O Salesforce fornece modelos de dados predefinidos para Vendas, Serviços e uma variedade de verticais do setor. Usar os modelos de dados fornecidos pelo Salesforce garante que os recursos no seu sistema sejam definidos apenas uma vez (elimina redundância e silos), estabelece uma única fonte de verdade em todo o sistema, facilita a compreensão dos dados do aplicativo com análise, facilita o uso dos serviços de inteligência artificial predefinidos do Salesforce, reduz os custos de manutenção (reduzindo as personalizações que você precisa dar suporte) e reduz o débito técnico. É assim tão simples. Como você pode ver nos [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-capacidade-de-manutenção-e-antipadrões) abaixo, os antipadrões se resumem a replicar recursos padrão em uma solução personalizada, ou usar tecnologia mais complexa para entregar personalizações. Na prática, você pode encontrar um cenário em que um antipadrão de funcionalidade personalizada é visto pelas partes interessadas da empresa como a melhor ou única maneira viável de avançar. Nesses casos, é essencial que você explique às partes interessadas as compensações envolvidas na escolha desse caminho e, em seguida, documente cuidadosamente a decisão, sua fundamentação e sua implementação. Essa também é uma área em que fornecer valor essencial antecipadamente e se adaptar ao longo do tempo pode ajudar as partes interessadas a entender melhor o melhor caminho a seguir. Para saber mais sobre ferramentas do Salesforce que podem ajudá-lo a aumentar a capacidade de manutenção, consulte [ferramentas relevantes para intencional](/docs/architect/pt-br/well-architected/guide/intentional#ferramentas-relevantes-para-intencional). ### Dívido técnico O débito técnico é uma parte natural de qualquer sistema. Os designs de som de ontem podem se tornar antipadrões quando a tecnologia ou as necessidades de negócios mudam. Talvez algo criado para preencher uma lacuna na funcionalidade da Salesforce Platform repentinamente se torne redundante com uma nova versão do Salesforce ou lançamento de produto. Talvez uma tecnologia mais eficiente ou flexível substitua uma tecnologia que você já implementou. O débito técnico pode ser criado de várias maneiras. Um dos principais benefícios da criação de aplicativos com a Salesforce Customer 360 Platform é a [compatibilidade retroativa integrada na plataforma](/docs/architect/pt-br/fundamentals/guide/architecture-basics#apis-da-plataforma). Isso significa que as novas inovações de plataforma podem alterar o padrão que você deve usar para soluções avançando, mas a função diária das soluções que você criou em tecnologias anteriores do Salesforce continuará funcionando. Ao longo do tempo, qualquer solução baseada em tecnologia mais antiga começará a criar riscos ou gargalos para adicionar novos recursos aos seus aplicativos e diminuirá a integridade geral da solução. Planejar e realizar trabalho regular para lidar com o débito técnico é essencial para manter designs saudáveis e simples em uma solução do Salesforce. Não planejar, auditar e remediar o débito técnico é uma maneira segura de criar um sistema mal arquitetado. Uma maneira de minimizar a dívida técnica é evitá-la o máximo possível, evitando atalhos e preferindo a [funcionalidade padrão em vez da funcionalidade personalizada](/docs/architect/pt-br/well-architected/guide/intentional#funcionalidade-padrão-versus-personalizada). Atalhos, como valores embutidos em código, podem ser tentadores para economizar tempo, mas, no longo prazo, criam débito que deve ser reembolsado. As chaves para lidar com o débito técnico de uma perspectiva arquitetônica incluem: - Identificar o [custo ou os benefícios reais](/docs/architect/pt-br/resources/guide/kpi-spreadsheet-template) da ação e da inatividade - [Roadmapping](/docs/architect/pt-br/well-architected/guide/intentional#roteiro) adequado - Criação de [soluções compostas](/docs/architect/pt-br/well-architected/guide/composable) A dificuldade pode ser alinhar as partes interessadas a tomar medidas. Algumas partes interessadas podem perceber a manutenção em andamento como abordando "erros de ontem" ou removendo dos recursos que desejam que seu orçamento suporte. Mostrar os reais impactos de negócios de ação e inatividade, junto com entregas e cronogramas claramente definidos, pode ajudar suas partes interessadas a entender o valor e a prioridade relativa de lidar com o débito técnico. Fazer o trabalho consistentemente para conectar o débito técnico aos impactos de negócios não apenas ajudará suas partes interessadas a entender melhor o trabalho a ser feito. Ela também o ajudará a garantir que você esteja identificando e lidando com o débito técnico de maneiras que realmente beneficiam os usuários. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-capacidade-de-manutenção-e-antipadrões) abaixo mostra como é um gerenciamento de débito técnico adequado (e ruim) para uma organização do Salesforce. Para saber mais sobre as ferramentas do Salesforce que podem ajudá-lo com dívidas técnicas, consulte [Ferramentas relevantes para intencional](/docs/architect/pt-br/well-architected/guide/intentional#ferramentas-relevantes-para-intencional). ### Padrões de capacidade de manutenção e antipadrões 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 manutenção no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/easy-maintainability).

	Padrões	Antipadrões
Padrão vs. Personalizado	Em seus padrões de design: - Há um princípio diretor claro para evitar a personalização desnecessária das soluções - O princípio de orientação para soluções usa a seguinte prioridade: 1. Usar serviços de plataforma integrados, 2. Considere os aplicativos AppExchange antes de criar uma solução personalizada, 3. Usar personalizações com pouco código antes de escrever código	Em seus padrões de design: - Os padrões de design não existem ou não têm uma justificativa clara para evitar personalizações e códigos desnecessários
	Na sua documentação: - Os registros de decisão mostram o cálculo para custos de curto e longo prazo ao escolher criar ou comprar soluções	Na sua documentação: - Os registros de decisão não consideram custos de curto e longo prazo ao escolher criar ou comprar soluções
	Em modelos de dados: - Nenhum objeto tem nomes ou funcionalidade que duplique objetos padrão - Objetos padrão não são usados para fins que estejam longe de seu escopo desejado	Em modelos de dados: - Os objetos duplicam os nomes e/ou a funcionalidade de objetos padrão - Objetos padrão são usados para fins muito fora do escopo desejado
	No LWC, no Aura ou no Visualforce: - Não existe código para substituir mecanismos de visualização de página padrão	No LWC, no Aura ou no Visualforce: - O código existe para substituir mecanismos de visualização de página padrão, geralmente na forma de um aplicativo de página única
	No LWC, Aura ou Apex: - Nenhuma tentativa de código para substituir ou contornar a ordem de execução da plataforma	No LWC, Aura ou Apex: - Tentativas de código para substituir ou contornar a ordem de execução da plataforma
Devido técnico	No seu roteiro: - O trabalho para lidar com o débito técnico está planejado - As datas de entrega e início/término estão claras	No seu roteiro: - Nenhum trabalho para lidar com o débito técnico está planejado - As entregas são vagas; as datas de início/término não são claras
	Nos seus registros de decisão: - Os KPIs para remediação de débito pré-/pós-tecnológica são claramente documentados - Discussões de compensação para ação e inatividade focam os custos ou os benefícios dos negócios	Nos seus registros de decisão: - A remediação de débito técnico não tem KPIs mensuráveis - O débito técnico é considerado em termos técnicos ou focados em TI, sem relevância para o negócio
	Em sua organização: - Nenhuma tecnologia sem suporte ou legada está ativa, incluindo: -- Todos os usuários trabalham no Lightning Experience -- nenhum ou muito poucos usos de `@future` no Apex (é usado Queueable) -- Todos os Apex de terceiros pertencem aos pacotes do AppExchange -- nenhuma regra de fluxo de trabalho ativa (Fluxo é usado) -- nenhum processo ativo do Criador de processos (Fluxo é usado) -- Eventos PushTopic (É usada a captura de dados de alteração) -- Eventos genéricos (eventos de plataforma são usados) -- Versões da API anteriores à 30.0 -- As conexões da organização do Salesforce usam o adaptador entre organizações para Salesforce Connect	Em sua organização: - Tecnologia sem suporte ou legada está ativa, incluindo: -- Usuários que trabalham no Salesforce Classic -- uso `@futuro` no Apex -- Apex de terceiros de fontes não AppExchange -- Regras de fluxo de trabalho -- Processos do Criador de processos -- PushTopic Events -- Eventos genéricos -- Versões da API anteriores à 30.0 -- Conexões do Salesforce para Salesforce

## Legibilidade No seu núcleo, o conceito de _legibilidade_ é criar consistência que facilite a compreensão das coisas. A criação de sistemas legíveis alinha as equipes de entrega e manutenção e ajuda as pessoas que não conhecem o sistema a entender rapidamente como as peças se encaixam. Isso significa que sua equipe pode ser menos dependente de pessoas individuais com Knowledge institucional ou histórico para integrar efetivamente fornecedores ou novos membros da equipe. Isso significa que indivíduos habilidosos em uma equipe podem se concentrar na qualidade e nos prós e os contras das escolhas que estão sendo feitas, pois a configuração e o código do sistema são fáceis para os humanos lerem e entenderem. A legibilidade pode acelerar os processos de governança e garantia de qualidade e ajudar as equipes a identificar melhor quando podem estar criando personalizações redundantes. Também pode aumentar as chances de ter um sistema que se comporte de maneiras reutilizáveis e testáveis. Você pode aumentar a legibilidade por meio de padrões de design e documentação eficazes. ### Padrões de design Os [padrões de design](/docs/architect/pt-br/resources/guide/design-standards-template) fornecem orientação para manter todas as personalizações consistentes, mesmo nas fases mais iniciais do desenvolvimento. Os padrões de design atuam como proteções, mantendo todas as equipes de entrega e de manutenção trabalhando em seu sistema alinhadas sobre como abordar e implementar personalizações. Definir padrões de design ajuda a aumentar a produtividade de suas equipes de entrega e manutenção, facilita a realização de revisões de código e arquitetura e fornece uma base para uma melhor [documentação](/docs/architect/pt-br/well-architected/guide/intentional#documentação). Sem padrões de design, as equipes têm maior probabilidade de trabalhar em silos. Sem a consistência que os padrões de design fornecem, as empresas terão dificuldade para: - Fornecedores e equipes de desenvolvimento usando padrões e abordagens ad hoc entre soluções, potencialmente introduzindo antipadrões e reduzindo a reutilizabilidade (consulte [Separação de preocupações](/docs/architect/pt-br/well-architected/guide/composable#separação-de-preocupações)). - Maior tempo para resolver problemas de produção e equipes de suporte necessárias para integrar novos membros da equipe e ajudá-los a entender um conjunto distinto de padrões e abordagens. - Mala colaboração entre equipes, redundâncias no trabalho entre equipes, tempo perdido para resolver conflitos e bugs descobertos durante testes de integração. - Maior frustração e maiores taxas de rotatividade. Um benefício importante dos padrões de design vem das conversas e decisões que as partes interessadas devem tomar para criá-los. Especificamente, o processo oferece aos seus negócios e leads de tecnologia a oportunidade de alinhar o design ideal para seus negócios. Inclua o seguinte em seus [padrões de design](/docs/architect/pt-br/resources/guide/design-standards-template) - **Convenções de nomenclatura para metadados do Salesforce**. Defina um conjunto de convenções para como cada personalização em um sistema deve ser nomeada. Boas convenções de nomenclatura não apenas impõem consistência nos nomes de objetos, campos, códigos, fluxos e outros elementos do seu sistema. As boas convenções de nomenclatura também ajudam as equipes de desenvolvimento a usar nomes que transmitem informações sobre o propósito e a funcionalidade do que estão criando. Como resultado, outras partes interessadas podem entender melhor uma personalização específica apenas vendo seu nome. - **Padrões de projeto aprovados e seus casos de uso**. Estabeleça uma biblioteca de [Padrão e Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/patterns), junto com informações importantes sobre quando (e quando não) usar cada padrão. A biblioteca pode incluir padrões de acionador do Apex obrigatórios ou padrões de orquestração de fluxo com base na [composibilidade](/docs/architect/pt-br/well-architected/guide/composable) desejada no seu sistema. - **Ambiente de desenvolvimento e orientação sobre ferramentas**. Mantenha uma lista clara das ferramentas que as equipes de desenvolvimento devem usar para seu trabalho. Isso pode incluir cadeias de ferramentas e idiomas aprovados para qualquer pessoa que escreva código ou recursos declarativos aprovados (ou não) para desenvolvimento com baixa codificação. Seus padrões podem incluir uma lista de sistemas de controle de origem para personalização e documentação e etapas de check-in/check-out obrigatórias. Eles também podem incluir uma lista de ambientes a serem usados para diferentes tipos de trabalho de desenvolvimento. Junto com a definição desses padrões, você precisará decidir como e onde mantê-los e armazená-los. Se as equipes em toda a sua empresa não conseguirem encontrar seus padrões de design (ou nem sequer souberem que existem), elas não serão eficazes. O ideal é que seus padrões de design fiquem no mesmo sistema que sua documentação (consulte a próxima seção para saber mais). A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-legibilidade-e-antipadrões) abaixo mostra a aparência de padrões de design adequados (e ruins) para uma organização do Salesforce. Você pode usá-los para validar ou melhorar seus padrões de design. Para saber mais sobre ferramentas do Salesforce que podem ajudá-lo a definir padrões de design, consulte [Ferramentas relevantes para intencional](/docs/architect/pt-br/well-architected/guide/intentional#ferramentas-relevantes-para-intencional). ### Documentação A documentação explica o que, como e por quê do seu sistema. Sem uma documentação consistente e consistente, as equipes gastam muito tempo tentando entender o sistema como ele é (e possivelmente mal compreendendo recursos e personalizações). A criação de uma boa documentação leva tempo. Embora a maioria das equipes concorde em que a documentação é importante para projetos grandes, pode ser uma etapa tentadora para ignorar ao fazer alterações rápidas, como atualizações de configuração ou pequenos ajustes em uma automação. Não documentar as alterações feitas no seu sistema é sempre antipadrão. Ignorar a documentação pode economizar um pouco de tempo com antecedência, mas a quantidade de tempo necessária para solucionar problemas de uma organização que não está devidamente documentada vai excluir essas economias de tempo. Sempre inclua tempo suficiente para criar a documentação em todas as suas estimativas, independentemente do nível de esforço necessário para as atualizações que você planeja fazer. A falta de documentação clara pode levar a vários problemas, incluindo: - Ciclos de desenvolvimento gastos em refazer implementações existentes - Discussões repetitivas revisitando ou confundindo decisões anteriores - Integração mais longa para novos membros da equipe ou fornecedores - Excesso de dependência de indivíduos com Knowledge institucional ou histórico - Arquiteturas redundantes para dar suporte a recursos iguais ou semelhantes em todo o negócio - Dificuldade para comunicar o propósito e o valor da sua solução às principais partes interessadas Para soluções do Salesforce, mantenha a documentação para: - **Visões gerais de soluções**. Os [diagramas](/docs/architect/pt-br/reference-diagrams/guide/introduction) permitem que você e suas partes interessadas visualizem soluções em vários níveis de detalhes. A estrutura de diagrama do Salesforce ajuda você a criar diagramas que mostram as funcionalidades de negócios das soluções, bem como os detalhes de implementação técnica. - **Registros de decisão**. Mantenha um registro das opções consideradas, compensações, decisão final e raciocínio em um local central que todos os membros da equipe possam acessar para consulta futura. - **Código**. O formato do código em si é uma parte fundamental da documentação, e isso pode (e deve) estar alinhado às suas [normas de design](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-design). Você também quer ter um registro de informações-chave e atualizá-lo a cada modificação de um código. Para todas as classes, acionadores e componentes, documente o seguinte: - Quem criou o código - Quando o código foi escrito - O que o código deve fazer - Dependências principais - Todas as alterações - **Personalizar declarativo**. Para cada tipo de personalização que pode ser feita aos metadados em sua organização, o Salesforce fornece [atributos integrados](/docs/architect/pt-br/fundamentals/guide/platform-multitenant-architecture#desenvolvimento-de-aplicativo-baseado-em-navegador-sem-código-e-sem-código) para que as equipes forneçam informações úteis sobre o propósito e a intenção dos metadados. Como parte de seus padrões de design, inclua como as equipes devem usar esses recursos integrados e como eles devem dar um nome a personalizações declarativas. Mantenha também um registro de informações-chave idêntico ao que você usa para código. Desenvolver um conjunto de normas de documentação para garantir que todos os membros da equipe atuais e futuros possam interpretar documentos da mesma maneira. (As [normas de design](/docs/architect/pt-br/resources/guide/design-standards-template) podem ajudar com isso.) Também é importante considerar como os usuários poderão pesquisar na documentação para encontrar seções ou termos relevantes. Conforme seu sistema envelhece e cresce em complexidade, sua documentação também aumentará. A utilidade das informações na sua documentação estará diretamente relacionada à frequência, à rapidez e à facilidade com que os usuários podem pesquisar e localizar itens relevantes. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/intentional#padrões-de-legibilidade-e-antipadrões) abaixo mostra a aparência da documentação adequada (e ruim) para uma organização do Salesforce. Você pode usá-los para validar ou melhorar sua estratégia de documentação. Para aprender mais sobre ferramentas do Salesforce para documentação, consulte [Ferramentas relevantes para intencional](/docs/architect/pt-br/well-architected/guide/intentional#ferramentas-relevantes-para-intencional). ### Padrões de legibilidade e antipadrões 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 legibilidade no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/easy-readability).

	Padrões	Antipadrões
Padrões de design	Em sua organização: - Código e personalizações declarativas têm nomes consistentes e legíveis por humanos - Os modelos de dados têm nomes consistentes e uniformes para objetos e campos - As auditorias mostram que os campos são preenchidos de modo consistente e referenciados em relatórios etc.	Em sua organização: - Código e personalizações declarativas não têm nomes consistentes - Os modelos de dados têm nomes inconsistentes e muitos objetos e campos parecem redundantes - As auditorias mostram muitos campos não utilizados ou vários níveis de uso, e não há um link consistente para relatórios etc.
Padrões de design	Dentro do seu negócio: - As equipes sabem que ferramentas usar (e não usar) para concluir o trabalho - Os padrões de design aprovados são fáceis de localizar e identificar por caso de uso - Os modelos de IA aprovados são claramente identificados e incluem um propósito pretendido	Dentro do seu negócio: - As equipes usam muitas ferramentas diferentes para realizar trabalhos semelhantes - Não há padrões de design aprovados - Demora muito para fornecedores ou novos funcionários serem integrados - Os modelos de IA aprovados não são claramente identificados e sua finalidade pretendida não é clara
Documentação	Em sua organização: - Código e personalizações declarativas têm descrições claras	Em sua organização: - Código e personalizações declarativas não têm descrições, têm descrições difíceis de entender ou têm descrições que não parecem corresponder ao que a personalização está realmente fazendo
Documentação	Dentro do seu negócio: - Existem diagramas para funcionalidades de negócios e detalhes de implementação técnica para todas as soluções - Chave quem/quando/quais registros de informações existem para personalizações declarativas e de código - As pessoas podem pesquisar e encontrar documentação relevante	Dentro do seu negócio: - O que/como/por que das soluções é difícil de encontrar e pode estar indisponível para a maioria das equipes - As pessoas têm dificuldade para entender as soluções e o sistema com o qual estão trabalhando - Demora muito para fornecedores ou novos funcionários serem integrados

## Ferramentas relevantes para intencional

Ferramenta	Descrição	Estratégia	Capacidade de manutenção	Legibilidade
ApexDoc	Documente o Apex com páginas HTML estáticas		X	X
Exclusão em massa de valores da lista de opções inativos	Excluir valores inativos não usados de listas de opções		X
Validador do Lightning Design System	Valide a marcação e veja como melhorar seu código		X	X
Migrar para fluxo	Converter regras de fluxo de trabalho e processos do Criador de processos em fluxos		X
Ferramenta de gerenciamento de projetos da Salesforce Labs	Gerenciar projetos em sua organização do Salesforce	X	X
Extensões do Salesforce para Visual Studio Code (expandido)	Analisar o Salesforce code com eficiência com extensões do Visual Studio Code		X	X
Verificação da organização	Analisar rapidamente sua organização e seu débito técnico		X
Analisador de código do Salesforce	Ler código por meio de IDE, CLI ou CI/CD para garantir que ele cumpra as práticas recomendadas		X	X
Explorador de roteiro do Salesforce	Explorar inovações de produto do Salesforce	X
Configurar trilha de auditoria	Rastrear alterações de configuração e histórico de auditoria	X	X

## Recursos relevantes para intencional

Recurso	Descrição	Estratégia	Capacidade de manutenção	Legibilidade
5 estratégias de documentação para melhorar sua organização do Salesforce	Melhorar a documentação de implementação do Salesforce	X
Escolher convenções de nomenclatura (Trailhead)	Saiba como aplicar convenções de nomenclatura			X
Definir, identificar e medir a dívida técnica	Definir, identificar e medir o débito técnico	X	X
Modelo de padrões de design	Criar padrões de design para sua organização	X	X	X
Introdução aos gráficos do Salesforce	Saiba como criar o diagrama certo para seu caso de uso			X
Introdução às Convenções de Codificação (Trailhead)	Definir e seguir convenções de codificação			X
Como lidar com a dívida técnica (Trailhead)	Gerenciar débito técnico em sua organização do Salesforce	X	X
Melhorar seu Apex code (Trailhead)	Aplicar princípios básicos de desenvolvimento conduzido por teste			X
Alinhamento organizacional (Trailhead)	Aprenda o processo V2MOM para alinhamento	X
Priorizar e planejar uma saída da dívida técnica	Formar um plano para reduzir e remover o débito técnico	X	X
Modelo de convenções de nomenclatura do Salesforce	Introdução às convenções de nomenclatura		X	X
Dívida técnica: O que é e por que você deve se preocupar?	Entenda o impacto do débito técnico na sua organização		X
Usar a Tela de Modelo de Negócios na Arquitetura Enterprise	Criar, entregar e ver valor em um modelo de negócios	X

## Diga-nos o que você pensa Ajude-nos a manter o Salesforce Well-Architected relevante para você; faça nossa [pesquisa](https://sfdc.co/bxNtvh) 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](/docs/architect/pt-br/well-architected/guide/contributors). ## Introdução As soluções resilientes mantêm uma alta qualidade de serviço mesmo quando ocorrem falhas. Se o desempenho for reduzido ou o serviço for interrompido, a solução será recuperada de modo rápido e eficaz. A resiliência de uma solução se baseia em duas principais qualidades: - **Rigidez**: Quando ocorrem problemas, a solução resiste e os suporta. - **Elasticidade**: Depois que os problemas são resolvidos, a solução volta ao seu estado ou formato ideal. Para arquitetar sua solução para resiliência, você deve projetar para tenacidade e elasticidade, garantindo durabilidade e recuperação rápida face a alterações planejadas e não planejadas. Em contextos de tecnologia, considere um sistema ou solução como uma coleção de componentes interdependentes que se coordenam para realizar metas compartilhadas. Cada componente tem o potencial de falha. Problemas nesses componentes, de defeitos de código e configuração a problemas de rede e hardware, podem causar comportamento inesperado e indesejado. Um sistema demonstra um comportamento resiliente quando um ou mais componentes falham, mas o sistema geral continua funcionando ou retorna rapidamente a um estado estável. Para melhorar a resiliência de suas soluções do Salesforce, recomendamos focar três hábitos importantes. - [**Gerenciamento de ciclo de vida do aplicativo (ALM)**](/docs/architect/pt-br/well-architected/guide/resilient#gerenciamento-de-ciclo-de-vida-do-aplicativo) – Como as equipes gerenciam o software ao longo de seu ciclo de vida, desde a criação até a aposentadoria - [**Resposta a incidentes**](/docs/architect/pt-br/well-architected/guide/resilient#resposta-de-incidente) – Como as equipes identificam, solucionam e impedem problemas que afetam a disponibilidade ou a segurança de um sistema - [**Planejamento de continuidade**](/docs/architect/pt-br/well-architected/guide/resilient#planejamento-de-continuidade) – Como as equipes planejam que suas pessoas e sistemas continuem funcionando quando eventos não planejados causam problemas ## Gerenciamento de ciclo de vida do aplicativo O Gerenciamento de ciclo de vida do aplicativo (ALM) é uma prática para gerenciar de modo holístico o software ao longo de seu ciclo de vida, da criação até a descontinuação. O ALM é uma pedra angular da resiliência do sistema e engloba pessoas, processos, ferramentas e disciplinas relacionadas ao ciclo de vida do aplicativo. Essas disciplinas incluem DevOps e metodologias de entrega, capacidade de observação, estratégias de teste, governança e CI/CD. Quando uma empresa pratica um ALM eficaz, suas equipes reagem rapidamente às mudanças e seus aplicativos acompanham os requisitos de negócios em evolução sem comprometer a estabilidade ou a qualidade. Por outro lado, sem um ALM saudável, as equipes têm dificuldade em cada estágio do ciclo de vida do aplicativo. Os sintomas de um ALM ruim incluem: - Ciclos de desenvolvimento lentos e sujeitos a erros - Implantações intensivas e difíceis - Problemas de alta gravidade ou bugs descobertos em ambientes de produção e pós-QA - Agentes de IA que alucinam ou se comportam de modo inconsistente - Implantações frequentes de reversões ou correções rápidas necessárias para estabilizar as versões Como o ALM afeta quase todos os aspectos de uma solução, estabelecer práticas de ALM claras e eficazes para sua solução é uma parte essencial do seu trabalho de arquitetura. Crie práticas do ALM melhores focando três áreas importantes. - [**Gerenciamento de lançamento**](/docs/architect/pt-br/well-architected/guide/resilient#gerenciamento-de-versão) – Planejar, sequenciar, controlar e migrar alterações para diferentes ambientes - [**Estratégia ambiental**](/docs/architect/pt-br/well-architected/guide/resilient#estratégia-ambiental) – Uma estratégia para como usar e gerenciar aplicativos em ambientes de destino durante o desenvolvimento e testes - [**Estratégia de sinalização**](/docs/architect/pt-br/well-architected/guide/resilient#estratégia-de-sinalização) – Definição de sinais críticos e instrumentação de aplicação usada para detectar e remediar falhas no sistema antes da degradação ocorrer - [**Estratégia de teste**](/docs/architect/pt-br/well-architected/guide/resilient#estratégia-de-teste) – Os princípios e padrões que orientam como você planeja e executa testes para avaliar o sucesso de suas aplicações durante os processos do ALM ### Gerenciamento de versão O gerenciamento de versão envolve planejamento, sequenciamento, controle e migração de alterações para um ou mais ambientes. Uma única versão é um grupo de alterações planejadas que uma equipe move para um ambiente de destino ao mesmo tempo. Liberar uma alteração em um sistema introduz risco a ela. Se o sistema estiver em um estado estável antes da alteração, ele passará para um novo estado, em que também estará mais vulnerável a riscos de alterações futuras. Se qualquer alteração futura acionar um estado não controlado e instável no sistema, isso poderá causar um incidente crítico. Em uma arquitetura de soluções, projetar para versões resilientes é mais do que apenas [testar alterações individuais de maneira eficaz](/docs/architect/pt-br/well-architected/guide/resilient#estratégia-de-teste). Também envolve planejar como introduzir alterações em seus sistemas e seus usuários com segurança. O trabalho que suas equipes fazem depende de informações de versão previsíveis e precisas. Em seus processos de gerenciamento e habilitação de mudanças, seja claro quais alterações podem ser transferidas para seu sistema. Em seus processos de gerenciamento e habilitação de versão, especifique como e com que frequência as alterações são liberadas para seu sistema. As partes interessadas também se preocupam com as informações da versão, especialmente se estiverem relacionadas a recursos ou correções de bug que solicitam. Para criar Trust em sua solução e demonstrar valor para suas partes interessadas, estabeleça agendas de lançamento consistentes e claras e envie artefatos de lançamento estáveis. Para estabelecer um gerenciamento de versão eficaz para o Salesforce: - **Alinhar-se com a governança de arquitetura e desenvolvimento**. Garanta que as versões sejam planejadas com antecedência para estarem alinhadas a todos os fóruns e controles de governança relevantes. Antes de começar o desenvolvimento, obtenha todos os casos de uso do Agentforce priorizados revisados e aprovados pelo Conselho de IA. Obtenha casos de uso do Agentforce de alto risco revisados por equipes de uso legal e ético.Use listas de verificação e documentação de implementação para rastrear artefatos de implementação, como nomes de API do agente do Agentforce, em relação a atividades de governança. - **Não use [processos de desenvolvimento ou versão baseados em organização](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)**. Esse paradigma reflete tecnologias mais antigas e limitadas para desenvolvimento e liberação. Com o Salesforce CLI, as equipes agora podem adotar recursos de desenvolvimento e liberação orientados por código-fonte. - **Escolha o mecanismo de liberação mais estável possível**. Essa abordagem realiza duas coisas. Primeiro, ele minimiza a duração das janelas de versão e interrupções de serviço. Em segundo lugar, ele permite comportamentos de versão altamente controlados e previsíveis. Quanto mais estável for o mecanismo de liberação, menor será a probabilidade de que as versões introduzam alterações que exigem correções rápidas ou reversões. Caso ocorra um problema imprevisto, os mecanismos de versão estáveis também criam maneiras mais simples para que a equipe de suporte ou os administradores do sistema realizem reversões. Os melhores mecanismos de liberação para sua equipe são as opções mais estáveis para as quais sua equipe tem as habilidades necessárias. Estes são os mecanismos de liberação recomendados, listados em ordem de estabilidade. Todos eles são compatíveis entre si, portanto, use vários deles juntos se isso for melhor para sua empresa. - [**Pacotes desbloqueados**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm) – Os pacotes desbloqueados são o artefato de versão mais estável. Implantar alterações instalando um pacote é a maneira mais rápida e mais previsível de introduzir alterações. Os pacotes usam controle de versões, que permite gerenciamento de alteração robusto e reversões refinadas adequadas ao administrador do sistema. E os pacotes exigem gerenciamento de metadados forte, o que pode ajudá-lo a identificar dependências mal gerenciadas mais cedo. Eles também criam pipelines de desenvolvimento e artefatos auditáveis. Consulte [Pacotabilidade](/docs/architect/pt-br/well-architected/guide/composable#capacidade-de-empacotamento). - [**DevOps Center**](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm&type=5) – O DevOps Center permite que equipes de entrega com conjuntos de habilidades de código reduzido ou pro-código usem o controle de origem, trabalhem de modo colaborativo em alterações e definam caminhos de liberação comuns. O DevOps Center integra-se ao controle de origem e permite o controle de apontar e clicar em alterações e implantações. - **Implantações de metadados e desenvolvimento conduzidos por origem usando o [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli)** – Se você não puder usar pacotes, use o Salesforce CLI para seu desenvolvimento conduzido por origem e implantação de metadados. Não implemente metadados usando o formato package.xml mais antigo, que segue uma estrutura diferente do [formato de origem](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm) recomendado. O formato de origem evoluiu para dar suporte ao desenvolvimento de pacotes, fluxos de trabalho de organização teste e rastreamento de alteração mais granular em sandboxes. O formato é mais legível, permite mais desacoplamento de tipos e dependências de metadados complexos e oferece muito mais controle sobre os manifestos de implementação. - **Nomeie suas versões**. Dê a suas versões identificadores claros para ajudar suas equipes e partes interessadas a se manterem alinhadas. No Salesforce, o nome de cada versão principal começa com "Spring", "Summer" ou "Winter" seguido pelo ano da versão (por exemplo, "Summer '25"). Se você ainda não tiver uma convenção de nomenclatura para definir e organizar versões em sua empresa, estabeleça uma e use-a. Usar nomes de versão claros facilita a manutenção da organização em todos os estágios de planejamento, desenvolvimento e entrega em todos os sistemas de suas equipes. Use seus nomes de versão em seu [roteiro](/docs/architect/pt-br/well-architected/guide/intentional#roteiro) para comunicar claramente às suas partes interessadas quais mudanças estão chegando e quando. Use seus nomes de versão em sua documentação, registros de alteração, descrições de trabalho, comentários de código e ramificações do controle de origem para que você possa rastrear e auditar facilmente seus artefatos de desenvolvimento. - **Em um manifesto de versão, gerencie dependências bem**. Os metadados do Salesforce têm dependências integradas. Um motivo comum para que as implantações do Salesforce falhem é que as dependências não são gerenciadas adequadamente. Escolher um mecanismo de versão estável, conforme descrito anteriormente, pode ajudar a expor dependências mal gerenciadas mais cedo em seu ciclo de desenvolvimento. Um dos principais motivos pelos quais os pacotes desbloqueados são o veículo de versão mais estável é seu gerenciamento de metadados forte, que é necessário para o desenvolvimento e a criação de pacotes. Se você ou suas equipes de gerenciamento de versão não entenderem as dependências integradas entre os tipos de metadados do Salesforce, não será possível detectar proativamente combinações problemáticas em seus manifestos de implementação e versão. Consulte [Gerenciamento de dependência](/docs/architect/pt-br/well-architected/guide/composable#gerenciamento-de-dependência). Os [padrões e antipadrões para ALM](/docs/architect/pt-br/well-architected/guide/resilient#padrões-e-antipadrões-do-alm) mostram como é o gerenciamento de versão adequado e ruim para uma organização do Salesforce. Use os padrões para validar seus designs antes de criar ou para identificar locais em seu sistema que precisam ser refatorados. Para aprender mais sobre ferramentas do Salesforce para gerenciamento de versão, consulte [Salesforce Tools for Resiliency](/docs/architect/pt-br/well-architected/guide/resilient#ferramentas-do-salesforce-para-resiliência). ### Estratégia ambiental O Salesforce oferece uma variedade de [ambiente](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5) para você usar durante os ciclos de desenvolvimento e teste de aplicativos. Uma estratégia de ambiente eficaz para o Salesforce exige entender como usar os ambientes e qual é a aparência de um bom gerenciamento. No ALM, a utilidade de um ambiente de desenvolvimento ou teste depende de sua fidelidade e isolamento da produção. Uma boa estratégia de ambiente oferece vários benefícios. - Maior fidelidade à produção - Configurações e reduções de ambiente mais rápidas - Mais ágil no desenvolvimento e nos testes - Segurança aprimorada em todo o pipeline - Menos ruído e conflito em todos os estágios de entrega - Equipes de desenvolvimento mais felizes As equipes costumam ter dificuldade para realizar esses benefícios. Os desafios para aproveitar ao máximo seus ambientes de desenvolvimento e estratégia podem vir de várias fontes. Uma origem provável é o tipo de modelo de desenvolvimento que suas equipes seguem. Na abordagem de desenvolvimento mais antiga baseada em organização, cada ambiente precisava atender a várias funções. Além de ser o local em que sua equipe realiza seus vários tipos de trabalho, ela precisava ser a origem para seus artefatos de versão (ou seja, os metadados que você queria implementar em uma versão). Como os ambientes não eram fáceis de configurar ou desmontar, eles costumavam estar sobrecarregados e cheios de conflitos de metadados entre equipes, e não contribuíam com velocidade ou flexibilidade significativas para o ALM em geral. Usar um modelo de desenvolvimento baseado em origem muda fundamentalmente o relacionamento que os ambientes têm com suas versões e artefatos de versão. Nesse modelo, o controle de origem é a origem dos metadados que você deseja liberar. Ambientes são apenas locais em que suas equipes trabalham. No entanto, seguir o modelo de desenvolvimento baseado em origem não apenas garante uma boa estratégia de ambiente. Mesmo com o controle de origem, as equipes ainda podem lutar para configurar condições para testar integrações com sistemas externos; configurações que dependem de metadados que não estão no controle de origem, como pacotes gerenciados ou personalizações que dependem de [dados](/docs/architect/pt-br/fundamentals/guide/architecture-basics#metadados-versus-dados)), e assim por diante. Em determinadas circunstâncias, os desafios de um modelo baseado em origem são semelhantes aos desafios típicos de um modelo baseado em organização. Para desenvolver uma estratégia de ambiente eficaz: - **Adote um modelo de desenvolvimento e liberação orientado por origem**. Pare de usar modelos de [desenvolvimento baseados em organização](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models). Consulte [Gerenciamento de versão](/docs/architect/pt-br/well-architected/guide/resilient#gerenciamento-de-versão).) Você deve remover seus ambientes do que você implementa para eles para criar uma estratégia de ambiente saudável e versões mais saudáveis. - **Entenda os tipos de trabalho que cada ambiente suporta**. Os tipos de ambiente compatíveis com o Salesforce têm diferentes recursos e limites. Ao projetar sua estratégia de ambiente, considere o que os ambientes podem e não podem fazer. Certifique-se de que suas equipes trabalhem em um ambiente que tenha as funcionalidades necessárias. Para orientação, consulte esta visão geral dos ambientes de desenvolvimento do Salesforce e seus recursos.

	Organização de rascunho	Developer Sandbox	Developer Pro Sandbox	Sandbox de Cópia parcial	Sandbox completo
Suporta a forma da organização	Sim	Não	Não	Não	Não
Suporta o Rastreamento de origem	Sim	Sim	Sim	Não	Não
Vida útil	1 a 30 dias	Controlado manualmente	Controlado manualmente	Controlado manualmente	Controlado manualmente
Intervalo de atualização	Não disponível	1 dia	1 dia	5 dias	29 dias
Suporte de visualização de versão	Controlado pelo desenvolvedor	Com base na instância de sandbox	Com base na instância de sandbox	Com base na instância de sandbox	Com base na instância de sandbox
Tempo de provisionamento	> 5 minutos	Horas ou dias	Horas ou dias	Horas ou dias	Horas ou dias
Metadados determinados por	Controle de origem	Produção	Produção	Produção	Produção
Dados determinados por	Carregamento manual de dados	Carregamento manual de dados	Carregamento manual de dados	Modelo de sandbox	Produção
Limite de dados	200 MB	200 MB	1 GB	5 GB	Igual ao da produção

Consulte esta tabela para saber quais recursos e ambientes usar para várias tarefas de desenvolvimento comuns.

Tarefa	Forma da organização	Rastreamento de origem	Atualizações frequentes	Suporte de visualização da versão	Todos os metadados da produção	Metadados parciais da produção	Conjuntos de dados grandes da produção	Conjuntos de dados parciais da produção	Ambientes compatíveis
Protótipo	X	X	X	X	X	X		X	Organizações teste, Developer e Developer Pro Sandboxes
Novas investigações de recursos ou desenvolvimento de prova de conceito	X	X	X	X	X	X		X	Organizações teste, Developer e Developer Pro Sandboxes
Teste de aceitação do usuário		X	X	X	X	X		X	Sandboxes de desenvolvedor, Developer Pro e Cópia parcial
Teste de desempenho e escala				X	X		X		Sandbox completo
Treinamento do usuário			X	X	X	X	X*	X	Developer Pro, Cópia parcial e*Sandboxes completos
*Se necessário para concluir um tipo específico de trabalho, caso contrário, use um ambiente menos intensivo em recursos

Além disso, para agentes Agentforce que usam recursos como a Biblioteca de dados do Einstein, artigos do Knowledge e dados não estruturados, os testes abrangentes são limitados, a menos que você tenha um sandbox do Data 360. Você também precisa de um sandbox do Data 360 para garantir condições de teste precisas. - **Desacoplar ambientes de artefatos de liberação.** Não use [desenvolvimento baseado em organização](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models). Trate ambientes como locais em que o trabalho acontece por um período fixo. Considere o estado dos metadados em um ambiente como separado de seus artefatos de versão. Se um código ou ajuste for "descoberto" em um ambiente, ele deverá estar comprometido com o controle de origem, tornando-o um artefato de versão. - Os ambientes são efêmeros. Crie processos para que você possa criá-los e destruí-los o mais rapidamente possível. - Os artefatos duram. Eles pertencem ao controle de origem. - **Desacoplar ambientes dos caminhos de liberação**. É comum ver caminhos de versão obrigatórios que exigem que as alterações sejam implementadas em ambientes específicos. Geralmente, essa abordagem é implementada para estabelecer um proxy para validar a maturidade do aplicativo ou a estabilidade da versão. As equipes também podem usá-lo para tentar minimizar o número de ambientes em que precisam configurar uma infraestrutura de teste complexa. Em paradigmas baseados em origem, você tem mais flexibilidade em como e onde validar e testar alterações. - Os estágios de liberação se aplicam a artefatos de liberação, não a ambientes. Não crie um ambiente apenas com a finalidade de "recolher" todas as alterações em um estágio de versão específico. É para isso que o controle de origem, especialmente a ramificação, serve. Use estratégias de ramificação no controle de código-fonte para organizar quais alterações implementar em quais ambientes. Dependendo do trabalho necessário, talvez seja necessário implementar todos os metadados em uma versão em um ambiente. A ramificação permite fazer isso. Com algumas exceções, todos os ambientes de desenvolvimento devem ser atualizados ou destruídos assim que o trabalho relevante for concluído. Certifique-se de sincronizar quaisquer alterações nos metadados que ocorram em um ambiente específico, e que você deseja manter, com o controle de origem. - Os ambientes são tão úteis quanto sua fidelidade à produção. Otimize os fluxos de trabalho ou a automação de configuração de ambiente para que você possa desfazer ou atualizar os ambientes o mais rapidamente possível. Considere qualquer configuração que impeça que você realize atualizações de ambiente mais rápidas e frequentes como um risco crítico para a resiliência geral de seus processos do ALM. Se você tiver um trabalho de remediação relacionado, adicione-o aos seus planos e priorize-o. Explore como adotar unidades [modulares](/docs/architect/pt-br/well-architected/guide/composable) mais soltas em seu sistema. Eles permitem que as equipes realizem mais tipos de desenvolvimento em organizações teste e liberam alocações de sandbox para outro trabalho. Não se esqueça dos recursos que as organizações teste fornecem para testar recursos que você não tem em produção, seja porque você não adquiriu licenças para elas ou não as habilitou. - Em ambientes que usuários de negócios ou usuários finais podem acessar, permita que esses usuários se concentrem no que é importante para eles. Não tenha ambientes genéricos e não diferenciados em que muitos grupos diferentes de usuários finais ou partes interessadas da empresa tentem realizar trabalhos relacionados ao ALM. Convide e ative partes interessadas específicas em ambientes específicos para realizar trabalhos específicos. Avalie cuidadosamente qualquer processo que coloque os usuários finais ou as partes interessadas da empresa em um ambiente com mais dados do que um sandbox de Cópia parcial pode suportar. Certifique-se de que o volume de dados seja necessário para o trabalho a ser feito. Planeje os testes de aceitação do usuário e os ciclos de desenvolvimento de estágio inicial para que ocorram o mais próximo possível. Otimize todos os estágios de teste para permitir ciclos de iteração e feedback mais rápidos e anteriores para suas equipes de desenvolvimento e usuários finais. Consulte [estratégia de teste](/docs/architect/pt-br/well-architected/guide/resilient#estratégia-de-teste). - **Criar caminhos de versão diferentes para diferentes tipos de alterações**. Nem todas as alterações exigem que os mesmos tipos de trabalho do ALM sejam concluídos na mesma ordem. Fazer com que os usuários finais realizem testes de aceitação para pequenas alterações em componentes de back-end de um sistema provavelmente não é um bom uso do tempo deles. No entanto, a aceitação do usuário e o teste de escala podem ser extremamente valiosos durante o desenvolvimento inicial de um aplicativo móvel. Identifique caminhos de versão para diferentes categorias de alterações, como alto risco, médio risco e baixo risco. - **Alto risco:** As alterações afetam clientes, parceiros ou todos os usuários internos. As alterações afetam a segurança ou a integração. As alterações adicionam uma funcionalidade nova e complexa. - **Risco médio:** As alterações afetam mais do que um limite definido de usuários internos. As alterações afetam modelos de dados, automação que realiza operações de dados ou integração. - **Baixo risco:** Afeta diretamente menos que um limite definido de usuários internos. Não inclui alterações de segurança, modelos de dados ou automações envolvendo operações de dados ou integração. - **Não permita que ambientes sobrecarregados existam**. Uma falta de disciplina na priorização, definição de escopo e sequenciamento de trabalho inevitavelmente leva a ambientes de desenvolvimento sobrecarregados, com volumes de trabalho excessivos, muitos, muito diferentes. Ambientes sobrecarregados criam altos níveis de estresse, ambiguidade e conflito entre as equipes de desenvolvimento. Eles também criam ruído em pipelines de desenvolvimento e impedem os esforços de controle de qualidade. Além desses impactos negativos, ambientes de desenvolvimento sobrecarregados são ameaças graves à manutenção e à segurança do ambiente. Considere a sobrecarga como um sintoma de possíveis problemas em seus processos do ALM. Investigue quaisquer problemas de causa-raiz e solucione-os. Se você ainda enfrentar a sobrecarga, você pode [comprar sandboxes adicionais](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5). A lista de [padrões e antipadrões para ALM](/docs/architect/pt-br/well-architected/guide/resilient#padrões-e-antipadrões-do-alm) mostra como é o gerenciamento de ambiente adequado e ruim em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou para identificar áreas do seu sistema que precisam ser refatoradas. Para aprender mais sobre ferramentas do Salesforce para gerenciamento de ambiente, consulte [Salesforce Tools for Resilience](/docs/architect/pt-br/well-architected/guide/resilient#ferramentas-do-salesforce-para-resiliência). ### Estratégia de sinalização Uma estratégia de sinalização define os sinais críticos e a instrumentação de aplicativo necessários para detectar, diagnosticar e remediar falhas antes que elas entrem em cascata para degradação em todo o sistema. A instrumentação eficaz transforma aplicativos de vítimas passivas de falha em participantes ativos em sua própria resiliência, capazes de detectar problemas, adaptar seu comportamento e coordenar uma degradação agradável quando necessário. Quando os aplicativos implementam uma instrumentação abrangente, eles obtêm a capacidade de se autorregular sob estresse, comunicar seu status de saúde aos operadores e participar de esforços de recuperação coordenados. Esses recursos permitem que os sistemas mantenham a qualidade do serviço mesmo quando componentes individuais sofrem problemas. Por outro lado, sem a instrumentação adequada, os aplicativos se tornam caixas negras que falham silenciosamente até que sintomas catastróficos apareçam. As equipes reagem a problemas apenas depois que os usuários os relatam, e a solução de problemas se torna um exercício em arqueologia, em vez de observação. - **Detecte falhas no aplicativo**. Os aplicativos devem se instrumentar para detectar e responder a padrões de falha comuns que surgem sob carga pesada. Considere a saturação da fila. Quando as filas de mensagens são preenchidas mais rapidamente do que podem ser processadas, os aplicativos não instrumentados continuam aceitando o trabalho até que ocorram escassez de memória ou cascata de tempo limite. Os aplicativos instrumentados adequadamente monitoram a profundidade da fila, as taxas de rejeição e a latência de processamento, acionando respostas defensivas quando os limites são excedidos. - **Gerenciar eficazmente os sinais de fora da aplicação**: O tratamento de sinais do sistema operacional representa outro ponto crítico de instrumentação. Os aplicativos devem registrar manipuladores para sinais de encerramento (SIGTERM, SIGINT) para habilitar o desligamento fácil. Durante o desligamento, os aplicativos devidamente instrumentados param de aceitar o novo trabalho, permitem que as solicitações em andamento sejam concluídas, esvaziam as margens, fecham as conexões de forma limpa e cancelam o registro da descoberta de serviço. Esse desativação orquestrada impede a perda de dados e permite que os balanceadores de carga redirecionem o tráfego sem interrupção. - **Instrumento para cenários de falha complexos:** Além desses padrões básicos, os aplicativos devem instrumentar modos de falha mais sutis. Identificar falhas cinza, em que os componentes parecem saudáveis para alguns observadores enquanto falham para outros, exige correlação de sinais internos e externos. Um aplicativo pode instrumentar seu pool de conexão de banco de dados para relatar verificações de saúde bem-sucedidas enquanto acompanha simultaneamente as taxas de conclusão da transação que revelam degradação crescente. Estratégias de instrumentação efetivas estratificam vários pontos de observação. - As métricas **de negócios** rastreiam indicadores de sucesso específicos do aplicativo, como taxas de conclusão de pedidos ou qualidade dos resultados da pesquisa. - As métricas do **sistema** monitoram a utilização do recurso, as distribuições de latência e as taxas de erro. - As sondas **sintéticas** exercem continuamente caminhos críticos para detectar degradação antes que os usuários a encontrem. - O rastreamento **distribuído** fornece visibilidade em nível de solicitação entre limites de serviço. Esses sinais são expostos por meio de interfaces padronizadas que permitem que sistemas automatizados e operadores humanos avaliem a integridade do aplicativo. A própria instrumentação torna-se parte da estratégia de resiliência da aplicação, permitindo que os disjuntores funcionem com base nas taxas de erro, os escaladores automáticos respondam às profundidades da fila e os [operadores tomem decisões informadas durante incidentes](/docs/architect/pt-br/well-architected/guide/resilient#resposta-de-incidente). Os [padrões e antipadrões para ALM](/docs/architect/pt-br/well-architected/guide/resilient#padrões-e-antipadrões-do-alm) mostram a aparência de uma estratégia de sinalização adequada e ruim em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou para identificar áreas do seu sistema que precisam ser refatoradas. Para aprender mais sobre ferramentas do Salesforce para uma estratégia de sinalização, consulte [Salesforce Tools for Resilience](/docs/architect/pt-br/well-architected/guide/resilient#ferramentas-do-salesforce-para-resiliência). ### Estratégia de teste Uma estratégia de teste é um conjunto de princípios e padrões orientadores para como planejar e executar testes que medem o sucesso e a falha de solicitações durante processos do ALM. Uma estratégia de teste mantém cada parte interessada envolvida no teste informada e alinhada à prioridade, ao propósito e ao escopo de um determinado teste. Também ajuda as equipes de projeto a criar planos de teste eficientes e fundamentados. Geralmente, desenvolvedores ou especialistas em garantia de qualidade e teste estão envolvidos na criação e execução de testes específicos. Uma estratégia de teste ajuda a garantir que esses indivíduos saibam quais tipos de testes devem ser realizados para um determinado projeto e em que sequência realizá-los. Uma estratégia de teste também ajuda a garantir que as equipes tenham o que precisam para criar testes, planos de teste e artefatos bem formados (por exemplo, conjuntos de dados de teste, dispositivos e simuladores de tráfego ou rede). Uma estratégia de teste eficaz cria uma visão clara de como, quando, onde e por que executar diferentes tipos de teste, incluindo testes de unidade, testes de interface do usuário e testes de regressão, em várias combinações e condições para descobrir como seu sistema e quaisquer alterações no voo se comportarão. Uma estratégia de teste eficaz produz testes que mostram a conformidade de um sistema com requisitos não funcionais, como escalabilidade, confiabilidade e usabilidade, que podem ser difíceis de medir por meio de um único tipo de teste. Para criar estratégias de teste eficazes para o Salesforce: - **Teste iterativamente, com frequência e por meios automatizados o máximo possível**. Projete e implemente a automação de teste que permite que as equipes executem uma variedade de tipos de teste com base em uma variedade de cargas de trabalho. Orquestre várias execuções de teste para que aconteçam automaticamente quando as alterações entram no controle de origem. Essa abordagem permite que as equipes identifiquem e lidem com regressões proativamente logo no início. Use integração contínua/entrega contínua (CI/CD) para esse esforço, se possível. Caso contrário, estabeleça planos de teste claros que permitam que as equipes executem sequências de testes com antecedência e frequência, de modo de autoatendimento. Para testes de agentes Agentforce, confie no Centro de testes para testes em lote rigorosos de agentes de IA com várias entradas para garantir que funcionem corretamente em diferentes cenários. - **Reconheça que nem toda mudança requer todo tipo de teste**. Assim como um pipeline de versão eficaz acomoda caminhos para aplicativos de alto, médio e baixo risco, uma estratégia de teste eficaz também. Especifique claramente para as equipes como selecionar e seguir um regime de teste adequado para aplicativos com vários tipos de risco, casos de uso ou complexidade. Consulte [Estratégia ambiental](/docs/architect/pt-br/well-architected/guide/resilient#estratégia-ambiental). - **Defina quais testes podem ser realizados em diferentes tipos de ambiente**. A fidelidade à produção é um componente essencial de testes precisos, mas significa coisas diferentes para diferentes tipos de testes. Por exemplo, o teste de regressão precisa de fidelidade à produção em termos de metadados e, até certo ponto, dados. Defina qual tipo de fidelidade à produção é necessária para um determinado conjunto de testes e classifique claramente quais tipos de ambientes podem suportar as condições adequadas para diferentes testes. Para obter uma visão geral dos tipos de trabalho alinhados a cada tipo de ambiente, consulte [Estratégia ambiental](/docs/architect/pt-br/well-architected/guide/resilient#estratégia-ambiental). - **Use testes de resistência, esforço, desempenho e escala para medir continuamente a maturidade da aplicação**. Esses testes mostram como uma solicitação está pronta para liberação em relação às necessidades no nível de produção. Para novos recursos importantes, execute esses testes a vários intervalos no ciclo de desenvolvimento do aplicativo. É antipadrão considerar esses testes como parte de apenas uma única fase ou estágio de desenvolvimento, em vez de como parte de tarefas em andamento. É mais útil para as equipes obterem feedback sobre o desempenho do aplicativo com antecedência e frequência, o que os ajuda a entender melhor o quão perto ou longe o aplicativo está do nível de produção. A capacidade de identificar e lidar melhor com problemas antes de as alterações entrarem em produção vale muito a complexidade adicional de executar testes mais sofisticados com frequência. - **Sabe quais testes importam**. Você provavelmente terá uma quantidade fixa de tempo para realizar seus testes de escala ou desempenho, tornando imprático testar cada faceta do seu sistema. Nem todos os recursos são usados igualmente e nem todos os gargalos de escala afetarão os negócios igualmente. Garanta que seus testes de escala estejam focados nas partes mais usadas e mais valiosas do sistema. Defina e entenda as oportunidades mais importantes para verificar e melhorar a escala e o desempenho em sua organização. - **Saiba como “bem o bastante” parece.** Definir os critérios de sucesso para seus testes de escala e desempenho é crucial. Você e suas equipes de desenvolvimento devem usar os critérios de sucesso como referências de teste. Além disso, certifique-se de que eles informem os requisitos funcionais para os quais as equipes de desenvolvimento se baseiam. Geralmente, esses critérios incluem dar suporte a um número específico de usuários simultâneos com tempos de resposta inferiores a um valor acordado e seus [objetivos de nível de serviço (SLOs)](/docs/architect/pt-br/well-architected/guide/resilient#tempo-para-recuperar). Defina seus principais critérios de meta e projete testes de escala e desempenho que garantem que os critérios sejam atendidos. - **Verifique-se de que você tem ambientes adequados.** Os testes de escala e desempenho exigem uma fidelidade específica à produção. Seus conjuntos de dados, demografia da solicitação, taxas de solicitação e características da carga de trabalho em ambientes que não sejam de produção devem corresponder ao máximo possível ao que você vê na produção. Para testes de escala, você deve usar um Sandbox completo. Se sua organização não tiver um Sandbox completo para testes de escala, você não poderá executar testes de escala adequados. - **As cargas de trabalho de teste ajudam a medir requisitos não funcionais**. Lembre-se de considerar: - **Dados de teste**-Todos os tipos de teste devem ocorrer em relação aos dados isolados da produção. Em testes de unidade do Apex, implemente [padrões de fábrica de dados](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm) para garantir que o código gere seus próprios dados de teste, isolados dos dados do ambiente. Você também pode criar e manter conjuntos de dados de teste em vários formatos para testar comportamentos de carga de dados, preencher ambientes de desenvolvimento com dados para testes baseados em interface do usuário e ajudar com testes de integração. Todos os dados de teste, sejam eles mantidos como um conjunto de dados externalizado ou criados sob demanda pelo código de fábrica de dados, devem ser removidos de dados confidenciais e de identificação. Deve incluir dados corrompidos, incompletos e malformados para dar suporte a comportamentos de teste de unidade negativos e de limite. - **Serviços de simulador e fragmento** de código – Para testes de integração, você pode usar os serviços de simulador e fragmento de código para simular respostas da API. O Apex oferece suporte a uma [API Stub](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm) para criar estruturas de simulação para uso em testes do Apex. Mocking para criar estruturas de simulação que podem ser usadas em testes do Apex. Silencios e fragmento de código podem ajudar a validar os comportamentos de processamento de dados de um sistema, com menos dependência de fábricas de dados complexas ou conjuntos de dados de teste externos. Os mutirões e os fragmento de código às vezes são mais adequados para serem usados em testes em que o tráfego semelhante à produção ou os volumes de dados não são relevantes. - **Dispositivos e tecnologia assistiva** – Uma parte essencial da criação de aplicativos [interessantes](/docs/architect/pt-br/well-architected/guide/engaging) e [acessíveis](/docs/architect/pt-br/well-architected/guide/compliant#acessibilidade) é garantir que eles atendam às expectativas dos usuários em vários dispositivos e com diferentes tipos de tecnologias assistivas. Testes de usabilidade significativos podem exigir mais investimento e diferentes tipos de conhecimento para serem executados de modo eficaz, mas é uma parte essencial de saber como seus aplicativos voltados para o usuário serão arquitetados quando forem lançados. - **Simuladores**: quando você precisa replicar volumes semelhantes à produção de solicitações de usuário, tráfego de API ou variações de velocidade de rede, pode precisar de ferramentas que simulem essas condições. Nem todos os testes precisam desse nível de investimento. Essas ferramentas costumam ser mais úteis em testes de escalabilidade e desempenho. - **Teste de IA e Agente** – Um objetivo primordial do teste é reduzir alucinações de IA, que são respostas convincentes que são fabricadas e incorretas. Certifique-se de que os casos de uso de IA sejam testados para destacar problemas comuns causados por uma compreensão incompleta do cliente, dados ausentes, campos com metadados incompletos e dados desatualizados. Use o Centro de teste para ajudar a criar os dados de teste necessários para esses testes. ### Padrões e antipadrões do ALM 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 ALM no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/adaptable-application-lifecycle-management).

	Padrões	Antipadrões
Gerenciamento de versão	Em produção: - Os metadados mostram o uso de mecanismos de versão estáveis, como: -- Metadados sendo organizados em pacotes desbloqueados -- DevOps Center estar ativo e instalado -- Implantações por meio da API de metadados usando o formato de origem - Os registros de implementação não mostram nenhuma implementação com falha no histórico disponível. - O histórico de implementação mostra ritmos de versão claros e grupos de implementação bastante uniformes nas janelas de versão.	Em produção: - Metadados indicam o uso de mecanismos de versão baseados em organização, como: -- Uso ativo de conjuntos de alterações -- Implantações por meio da API de metadados usam o formato package.xml - Os registros de implementação mostram instâncias repetidas de implementações com falha no histórico disponível. - As implantações não têm ritmo discernível ou mostram grupos desiguais de implantações, que são sinais de correções rápidas e reversões ad hoc). - DevOps Center não está habilitado e instalado.
Gerenciamento de versão	No seu roteiro e documentação: - Os nomes de versão estão claros. - Os recursos são vinculados claramente a uma versão nomeada específica. - Os nomes de versão são pesquisáveis e descobríveis. - As equipes podem encontrar e seguir diretrizes claras para marcar artefatos, itens de desenvolvimento e outros trabalhos com os nomes de versão corretos. - É possível reunir uma visualização clara de um manifesto de versão por um nome de versão. - Os limites de qualidade para aplicativos de IA generativa são definidos para diferentes estágios de desenvolvimento.	No seu roteiro e documentação: - Os nomes de versão não são incluídos. - Os recursos não estão claramente vinculados a uma versão específica. - Os nomes de versão são usados ad hoc ou não existem. - As equipes se referem a artefatos, itens de desenvolvimento e outros trabalhos de diferentes maneiras. - Não é possível reunir uma visualização clara de um manifesto de versão usando um nome de versão. - Os limites de qualidade para aplicativos de IA generativa não são definidos ou, se forem, não são definidos para diferentes estágios de desenvolvimento.
Estratégia ambiental	Em suas organizações: - Um modelo de desenvolvimento e versão orientado por origem é adotado. - O rastreamento de origem está habilitado para sandboxes Developer e Developer Pro. - Os metadados em um determinado ambiente são independentes dos artefatos de versão. - Os ambientes não correspondem diretamente a um caminho de versão. - Os caminhos de liberação para uma alteração dependem do tipo da alteração (risco alto, risco médio ou risco baixo). - Os ambientes sobrecarregados não existem. - Alterações de configuração arriscadas nunca são feitas diretamente na produção. - Nenhuma versão ocorre durante o horário comercial máximo. - Os sandboxes do Data 360 são usados para testar adequadamente casos de uso agênticos que exigem a Biblioteca de Dados do Einstein, artigos do Knowledge e dados não estruturados	Em suas organizações: - Um modelo de desenvolvimento e liberação baseado em organização é adotado. - O rastreamento de origem não está habilitado para sandboxes Developer e Developer Pro. - Metadados em um determinado ambiente são um artefato de versão. - Os ambientes correspondem diretamente a um caminho de liberação. - O caminho da versão para cada alteração é o mesmo, independentemente do tipo de alteração. - Existem ambientes sobrecarregados. - Alterações de configuração arriscadas são feitas diretamente na produção. - As versões ocorrem durante o horário comercial máximo. - Agentes Agentforce que exigem o Einstein Data Library, artigos do Knowledge e dados não estruturados não são testados usando sandboxes do Data 360
Estratégia de sinalização	Em suas organizações: - As equipes colaboram na definição e padronização de APIs e SLOs de verificação de integridade. - A revisão e o refinamento regular de estratégias de sinalização fazem parte das análises de prontidão operacional e pós-mortems. Em produção: - As verificações de integridade são implementadas para todos os aplicativos. - Os aplicativos fornecem sinais explicitos sobre sua saúde, como carregamento e funcionalidades. - Os aplicativos são projetados para ser descontinuados quando as dependências não são saudáveis. - A descarga de carregamento é usada para evitar falhas em cascata. No seu projeto: - Os mecanismos de contrapressão e descarte de carga impedem que os serviços sejam sobrecarregados pelo tráfego. - Supõe-se que as dependências falhem. Os manipuladores de sinal são criados para melhorar falhas.	Em suas organizações: - As equipes operam em silos, criando mecanismos de sinalização de saúde inconsistentes e incompatíveis. - Estratégias de sinalização são uma ideia adicional, tratadas apenas quando ocorre um incidente. Em produção: - Os componentes falham silenciosamente sem indicar seu status de integridade. - Os aplicativos tentam novamente solicitações para serviços não saudáveis indefinidamente. - Todas as solicitações são tratadas com a mesma prioridade, independentemente da importância. - Para identificar problemas, os operadores dependem apenas de medidas reativas, como reclamações do usuário ou falhas críticas do sistema. No seu projeto: - Presume-se que todas as dependências estarão sempre disponíveis e partições de rede, picos de latência ou outros problemas comuns não serão considerados. - Os aplicativos aceitam todas as solicitações recebidas, mesmo quando estão sobrecarregadas, levando a maior latência e maior probabilidade de falha
Estratégia de teste	No seu negócio: - Os testes de usabilidade usam uma variedade de dispositivos e tecnologia assistiva. - Os simuladores são usados para replicar condições semelhantes a produção para escalabilidade e testes de desempenho. - Os testes são automatizados para execução quando as alterações entram no controle de origem. - Testes de resistência, estresse, desempenho e escala são executados a vários intervalos no ciclo de desenvolvimento do aplicativo e considerados tarefas contínuas. - Você inclui o teste de escala como parte do seu processo de QA quando tiver aplicativos em escala B2C, grandes volumes de usuários ou grandes volumes de dados. - Seus testes de escala são focados em aspectos de alta prioridade do sistema. - Seus testes de escala têm critérios bem definidos. - Você realiza testes de escala em um Sandbox completo. - A engenharia de prompt inclui uma revisão de qualidade por um humano. - A central de testes do Agentforce é usada para testes robustos do agente.	No seu negócio: - Os testes de usabilidade não são realizados ou, se forem, são realizados em um conjunto limitado de dispositivos. - Volumes semelhantes a produção de solicitações de usuário, tráfego de API e variações de velocidade de rede não são testados. - A automação de teste não está em vigor. - Testes de resistência, estresse, desempenho e escala são considerados uma fase ou estágio de desenvolvimento. - Você não realiza testes de escala como parte de seu processo de QA e tem aplicativos em escala B2C, grandes volumes de usuários ou grandes volumes de dados. - Seus testes de escala não são priorizados. - Seus testes de escala não têm critérios bem definidos. - Você realiza testes de escala em uma cópia parcial ou Developer Sandbox. - A engenharia de prompt não inclui uma revisão de qualidade por um humano. - Os agentes do Agentforce não são testados ou, se forem, apenas testados ad hoc usando o Agent Builder.
	Em sua organização: - Todos os dados de teste são removidos de dados confidenciais e de identificação.	Em sua organização: - Os dados de teste são idênticos aos dados de produção.
	No Apex: - Os padrões de fábrica de dados são usados para testes de unidade - Mocks e fragmento de código são usados para simular respostas da API.	No Apex: - Os testes de unidade dependem de dados da organização. - Mocks e fragmento de código não são usados.
	Em suas normas de design e documentação: - Os ambientes são classificados pelos tipos de testes que eles podem suportar. - Os regimes de teste adequados são especificados de acordo com o risco, o caso de uso ou a complexidade.	Em suas normas de design e documentação: - Não está claro quais tipos de testes cada ambiente oferece suporte. - Os regimes de teste não são categorizados por risco, caso de uso ou complexidade.

## Resposta de incidente Na engenharia de segurança e confiabilidade do site (SRE), a resposta a incidentes é focada em como as equipes identificam e lidam com eventos que afetam a disponibilidade geral ou a segurança de um sistema, bem como como como as equipes trabalham para lidar com causas-raiz e prevenir problemas futuros. A resposta de incidente envolve os processos, ferramentas e comportamentos organizacionais necessários para lidar com problemas em tempo real e após um problema ocorrer. Como arquiteto, talvez você não seja a pessoa que monitora as operações da sua solução no dia a dia após a ativação. Parte da arquitetura para resiliência é projetar recursos de recuperação que permitem que as equipes de suporte realizem diagnóstico de primeiro nível, estabilizem os sistemas e passem de modo eficaz a investigação e a mitigação da causa raiz para as equipes de desenvolvimento ou manutenção. Equipes que oferecem suporte direto a usuários no dia a dia podem não ter uma compreensão profunda ou conhecimento sobre a arquitetura do sistema. É essencial que essas equipes tenham as ferramentas e os processos necessários para monitorar operações diárias, acessar informações do sistema ao diagnosticar um possível incidente e servir como primeiros respondentes eficazes para quaisquer problemas que afetem a disponibilidade. Você pode melhorar a forma como as equipes respondem a incidentes em suas soluções do Salesforce focando seu [tempo de recuperação](/docs/architect/pt-br/well-architected/guide/resilient#tempo-para-recuperar), a [capacidade de triagem](/docs/architect/pt-br/well-architected/guide/resilient#capacidade-de-triagem) e o [monitoramento e alerta](/docs/architect/pt-br/well-architected/guide/resilient#monitoramento-e-alerta). ### Tempo para recuperar Quando ocorre um incidente, a primeira prioridade deve ser restaurar os sistemas a um estado operacional estável. Geralmente, as empresas acham que a única maneira de se recuperar de um incidente é "corrigir o problema". Essa pressuposição é justa, pois a análise e a remediação da causa raiz precisas são como você resolve problemas críticos em um sistema. No entanto, "corrigir o problema" durante os primeiros estágios da resposta à crise não é a abordagem mais prática. Dependendo da gravidade de um incidente, cada segundo dele e seu impacto podem levar a uma perda de receita ou reputação para o negócio. Geralmente, tentar diagnosticar e lidar com as causas raiz atrasam os esforços para restaurar o funcionamento do sistema. Logisticamente, adotar uma abordagem que solicita que os responsáveis a incidentes lidem com as causas-raiz coloca uma enorme pressão sobre os especialistas no assunto (SMEs) e a equipe de suporte em sua empresa. Trabalhar para encontrar e corrigir as causas-raiz _durante_ um incidente exige que as PME estejam atentas a cada incidente, o que pode impedir a equipe de suporte da linha de frente e voltada para o cliente de agir. Também pode resultar em equipes liberando alterações que, por sua vez, criam mais incidentes. Em última análise, essa abordagem aumenta os custos, consome largura de banda entre as equipes e leva a comportamentos em tempos de crise que podem erodir o Trust do cliente e a reputação da marca. O paradigma de gerenciamento de incidentes certo é priorizar e focar a recuperação como uma primeira etapa. Depois que um sistema é restaurado para a estabilidade, você pode acompanhar com tarefas pós-mortem, investigações de incidentes, remediação da causa raiz e atividades semelhantes. Essa ordem de operações permite que a equipe de resposta a incidentes faça triagem, diagnostique e execute táticas de recuperação, alertando as PME relevantes para ajudar apenas quando necessário. Também permite que as PME identifiquem e corrijam as causas-raiz de um incidente com menos pressão de um relógio. Para adotar uma mentalidade de recuperação em primeiro lugar para resposta a incidentes: - **Estabelecer e atingir SLOs de objetivos de nível de serviço**. SLOs são padrões que você desenvolve com suas partes interessadas para requisitos não funcionais (NFR) específicos de um sistema, como desempenho ou tempo de atividade. Esses objetivos são medidos por indicadores de nível de serviço (SLIs) ao longo de um período de tempo. Sem SLOs, grande parte do trabalho em torno da resposta a incidentes e solução de problemas complexos pode parecer desorganizada e reativa, por exemplo, solicitando uma ação rápida para "parar esse erro específico, para este punhado de usuários que o relataram". Esse ciclo costuma fazer com que as equipes enviem a análise de causa raiz mais perto da resposta ao incidente, pois parece que isso vai ajudar a impedir os comportamentos reativos. A criação de SLOs e SLIs é uma maneira mais eficaz de começar. Para estabelecer SLOs, pense nestas perguntas. - **Qual é o NFR do seu sistema para os próximos 1 a 3 anos?** Por exemplo, sua NFR pode incluir os tempos de resposta, as taxas de solicitação de pico e os usuários simultâneos que seu sistema deve suportar. - **O que você quer que seus clientes e seus usuários experimentem?** Baseie seus SLOs na resposta a essa pergunta, que pode ser "Os usuários podem executar relatórios rapidamente no Salesforce". - **O que você pode medir e por quanto tempo deve medir?** Baseie seus SLIs na resposta a esta pergunta. Um SLI que corresponda ao exemplo anterior pode ser "_x_% dos relatórios são carregados em média em \_n_s, medidos em um período de 30 dias". - **Defina e padronize as táticas de recuperação.** Alterar reversões e implementações alternativas pode ajudar a tornar um sistema funcional novamente e minimizar o impacto de um incidente. Documente táticas e protocolos de recuperação que podem ser executados pelos membros apropriados de suas equipes de suporte ou operações. As táticas de recuperação diferem conforme o tipo de incidente. A próxima tabela mostra uma estrutura geral que mapeia tipos de incidentes para táticas de recuperação. Para obter mais informações sobre a identificação de pontos de falha e a definição de estratégias de mitigação, consulte [Disponibilidade](/docs/architect/pt-br/well-architected/guide/reliable#disponibilidade).

Tipo de incidente	Acionador aparente	Táticas de recuperação
Falência do sistema	Logins corrompidos ou problemas com acesso à conta	Uma política de recuperação de conta
Falência do sistema	Indisponibilidade do serviço	Ativação de serviço de backup redundante; soluções alternativas manuais
Erro de produção	Uma alteração recente	Reverter ou desativar a implementação da versão anterior
Erro de produção	Um bug emergente e inexplicado	Soluções alternativas manuais, desabilitando recursos não essenciais, escalando para SMEs

- **Defina critérios de saída claros**. Use seus SLOs para determinar quando seu sistema está fora do status de incidente ou impacto. - **Definir processos para revisões pós-incidente e remediação da causa raiz.** Reserve tempo para revisar incidentes após a restauração do serviço. Durante as revisões, tome uma abordagem _pós-mortem impecável_. Trabalhar com as partes interessadas para se concentrar em estabelecer fatos claros sobre _o que_ ocorreu e _como_ ocorreu, em vez de tentar atribuir culpa ou culpa a indivíduos. Use diferentes formatos de revisão para examinar maneiras de lidar com problemas em longo prazo. - Uma _revisão pós-ação_ centra-se na resposta ao incidente. É útil para avaliar se os processos e táticas de resposta adequados estão em vigor. - Uma _análise raiz da causa_ se concentra na causa raiz do incidente. Ele pode ajudar a identificar quaisquer bugs ou problemas no design e na implementação do seu sistema que levaram ao incidente. - **Pratique seus protocolos de recuperação acordados periodicamente**. Pratique protocolos de recuperação para garantir que todos saibam como lidar bem com incidentes. Use sandboxes e ambientes de teste para dar às equipes lugares para praticar a simulação e a recuperação de incidentes. Também pratique suas análises pós-incidente. Fazer toda essa prática torna a recuperação parte da sua cultura de engenharia e suporte. Os [padrões e antipadrões para resposta a incidentes](/docs/architect/pt-br/well-architected/guide/resilient#padrões-de-resposta-a-incidentes-e-antipadrões) mostram como é a arquitetura para priorizar a recuperação em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar áreas do seu sistema que precisam ser refatoradas. Para aprender mais sobre ferramentas do Salesforce para ajudar com o tempo de recuperação, consulte [Salesforce Tools for Resiliency](/docs/architect/pt-br/well-architected/guide/resilient#ferramentas-do-salesforce-para-resiliência). ### Capacidade de triagem No contexto da tecnologia, a triagem envolve atribuir categorias e níveis de gravidade a problemas e solicitações de suporte. Não importa o quão bem planejada seja sua solução, surgirão problemas e solicitações de suporte ao usuário. Esses problemas podem resultar da falta de treinamento ou gerenciamento de mudanças adequado, lacunas na IU/UX, comportamentos inesperados do usuário final e problemas de sistema urgentes que não são capturados pelo [monitoramento ou alerta](/docs/architect/pt-br/well-architected/guide/resilient#monitoramento-e-alerta). As equipes de suporte e operações precisam poder investigar consultas de suporte do usuário de maneira eficiente e diagnosticá-las rapidamente. A triagem de problemas para filtrar preocupações menos graves e detectar rapidamente incidentes críticos do sistema é uma competência essencial para essas equipes. Uma triagem deficiente desacelera todos os níveis de suporte ao usuário, prolonga incidentes críticos e aumenta o risco de interrupções adicionais para seus clientes e seus negócios. Embora você possa não estar envolvido em operações e suporte diários, como um arquiteto, é sua responsabilidade ajudar a garantir que suas equipes de suporte e operações possam fazer a triagem eficaz de problemas em qualquer solução criada na Salesforce Platform. Para permitir que as equipes façam a triagem eficaz de problemas em suas soluções do Salesforce: - **Garantir que as equipes de suporte tenham acesso a informações úteis**. - **Documente seu sistema e padrões de design**. Garantir a [legibilidade](/docs/architect/pt-br/well-architected/guide/intentional#legibilidade) e a consistência da sua solução é uma parte essencial para que a equipe de suporte entenda o sistema que é responsável por apoiar. Na sua documentação, considere como as equipes encontrarão informações sobre como priorizar problemas ou incidentes com diferentes partes do sistema. Além disso, garanta que as equipes possam rapidamente obter informações técnicas sobre táticas de recuperação com base na área de impacto. Forneça guias de solução de problemas relevantes para problemas comuns do Agentforce, como Classificação de tópico e Seleção de ação, que podem ajudar as equipes a solucionar rapidamente problemas relacionados a permissões ou configuração. - **Design com depuração em mente**. Equipes de suporte e administradores da organização precisarão habilitar a depuração e o diagnóstico para fazer a triagem correta de problemas do usuário em vários ambientes. Exemplos de padrões compatíveis com _a depuração_ incluem aqueles que incorporam registros e mensagens de erro personalizadas em caminhos de execução em todo o sistema. Habilite equipes de suporte em abordagens comuns de depuração do Agentforce com ferramentas como logs de eventos e a visualização de raciocínio do Agent Builder. - **Identificar PME e partes interessadas incidentes**. Crie uma lista de PME ou partes interessadas relevantes que devem estar disponíveis para dar suporte à recuperação de um incidente e que devem estar envolvidas na análise pós-incidente. - **Tratar transgressões com cuidado**. Garanta a qualidade de cada transferência de solução para equipes de suporte ou operações como parte da ativação. Forneça treinamento para a equipe de suporte para percorrer a arquitetura do sistema relevante e simulando os exercícios de resposta a incidentes. Pense em transferências pós-incidente, incluindo como as equipes devem documentar informações que não são capturadas por registros ou notas de caso, bem como como os responsáveis ao incidente podem contribuir para investigações de causa raiz ou realizar testes de aceitação do usuário para quaisquer remédios. - **Se você for consultado, mantenha todos focados na recuperação como a principal preocupação**. - **Responda rápido.** Responda rapidamente a todas as solicitações de suporte ao usuário, notificações de monitoramento e alertas que você receber. - **Ajuda a distinguir sintomas de problemas.** Trabalhe para determinar se há um incidente real do sistema que precisa ser resolvido. Tente identificar os componentes com os problemas reais. Ajude a garantir que as [tácticas de recuperação](/docs/architect/pt-br/well-architected/guide/resilient#tempo-para-recuperar) acordadas sejam seguidas para remover o sistema do status de incidente rapidamente. - Para agentes da Agentforce que oferecem suporte a casos de uso críticos, garanta que existam soluções alternativas viáveis e relevantes que possam ser ativadas com um breve aviso como uma medida de redundância. Os exemplos incluem alternar para manipulação manual ou redirecionar para documentações relevantes para revisão manual. Os [padrões e antipadrões para resposta a incidentes](/docs/architect/pt-br/well-architected/guide/resilient#padrões-de-resposta-a-incidentes-e-antipadrões) mostram como é a arquitetura para triagem eficaz em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar áreas do seu sistema que precisam ser refatoradas. Para saber mais sobre ferramentas do Salesforce para ajudar na triagem, consulte [Salesforce Tools for Resilience](/docs/architect/pt-br/well-architected/guide/resilient#ferramentas-do-salesforce-para-resiliência). ### Monitoramento e alerta _Monitoramento_ e _alerta_ são termos amplamente usados na engenharia de confiabilidade do local. No contexto da resiliência do sistema, o monitoramento avalia continuamente o estado atual de um sistema e o alerta automatiza notificações às partes interessadas sobre possíveis preocupações sobre o estado do sistema. O monitoramento e o alerta eficazes são uma parte essencial para desconectar a escala e o crescimento do seu sistema da escala e do crescimento da equipe de suporte. O Salesforce oferece uma variedade de recursos integrados para monitorar comportamentos em seu sistema. O Salesforce também oferece o [monitoramento de evento em tempo real](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/real_time_event_monitoring_overview.htm) como um complemento ou como parte do [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/). Em qualquer solução do Salesforce, os designs criados para monitoramento e alerta fornecem: - Recursos para resposta de incidente automatizada - Informações relevantes para os usuários certos, na hora certa - Informações claras para visualizações históricas e análise de tendências Para arquitetar o monitoramento e o alerta efetivos em suas soluções do Salesforce: - **Faça da automação uma prioridade**. Embora a notificação dos usuários sobre alterações de estado críticas seja uma parte crucial para manter seus sistemas estáveis e operacionais, em uma arquitetura ideal, o sistema corrige automaticamente os problemas quando possível e envia alertas apenas para problemas urgentes e não recuperáveis. Mesmo sem recursos de auto-correção, a automação pode tornar seu alerta e relatório mais úteis. - **Comece com o que o Salesforce já fornece**. A Salesforce Platform fornece logs e APIs relevantes para que você monitore as operações da sua solução em relação aos limites do regulador. Além disso, a plataforma envia alertas para violações de limite do controlador e problemas semelhantes. Use esses registros e alertas como a base para explorar maneiras de automatizar totalmente a auto-recuperação do sistema, os relatórios de incidentes e os alertas. Por exemplo, você pode implementar automação que monitora o registro e, em seguida, executa uma ação de recuperação quando um determinado tipo de evento é registrado. - **Classifique as alterações no estado do sistema de maneiras previsíveis**. Crie categorias específicas e relevantes para os principais estados que você deseja monitorar e relatar. Alinhe essas categorias com as categorias que você define para gerenciar o estado em seus [componentes de aplicativo](/docs/architect/pt-br/well-architected/guide/composable#gerenciamento-de-estado). Adote uma mentalidade orientada [à API](/docs/architect/pt-br/well-architected/guide/composable#gerenciamento-de-api) para como você lida com as informações de alteração de estado. Formatos de mensagem consistentes e categorias de estado simplificam a automação, os relatórios e os alertas. - **Alinhe sua lógica de automação com as outras partes do sistema**. Se você tiver criado o [tratamento de erros](/docs/architect/pt-br/well-architected/guide/automated#manipulação-de-erros) de automação adequado, poderá estender esses padrões para como classificar alterações de estado e responder com automação. Para alterações de estado consideradas recuperáveis, você pode automatizar os novos comportamentos de tentativa. Para alterações de estado consideradas críticas ou fatais, automatize alertas aos usuários. - **Evite criar barulho**. Quando os usuários recebem muitos alertas, especialmente alertas que não exigem nenhuma ação, eles tendem a começar a desabilitar ou ignorar todos os alertas. Esse cenário prejudica todos os esforços para criar alertas [útiles](/docs/architect/pt-br/well-architected/guide/engaging#útil). Para definir melhor o escopo de quem recebe alertas, o que os aciona e quando eles são acionados, considere fazer estes itens. - **Criar mapas das partes interessadas**. Para garantir que seu sistema forneça os alertas certos às partes interessadas certas no momento certo, primeiro identifique e classifique seus grupos de partes interessadas. - **Rotear mensagens com base nos privilégios do usuário**. Envie alertas apenas a destinatários que tenham capacidade e autoridade para responder. Os usuários de negócios podem se beneficiar de alertas sobre problemas que podem corrigir corrigindo problemas em registros aos quais têm acesso. Se um problema exigir uma resposta técnica mais envolvente, os alertas deverão ser direcionados para a equipe de suporte. - **Deixe a resposta esperada clara**. Envie alertas apenas em cenários que exigem intervenção humana. Estruture mensagens para indicar claramente a ação esperada do destinatário. Se você enviar um alerta para a visibilidade de uma parte interessada e nenhuma ação for necessária, deixe isso claro na versão da mensagem que ela receberá. - **Faça alertas oportunos e relevantes**. Alertas que são entregues em resposta a falhas que ocorreram e ainda precisam ser remediados) não são tão úteis quanto alertas sobre uma falha potencial. Idealmente, a equipe de suporte é alertada assim que ocorrem condições problemáticas no sistema, proporcionando uma oportunidade para [classificar](/docs/architect/pt-br/well-architected/guide/resilient#capacidade-de-triagem) problemas antes que eles possam ter impactos negativos nas operações de negócios. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/resilient#padrões-de-resposta-a-incidentes-e-antipadrões) mostra como é a arquitetura para monitoramento e alerta eficaz em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar áreas do seu sistema que precisam ser refatoradas. Para aprender mais sobre ferramentas do Salesforce para monitoramento e alerta, consulte [Salesforce Tools for Resilience](/docs/architect/pt-br/well-architected/guide/resilient#ferramentas-do-salesforce-para-resiliência). ### Padrões de resposta a incidentes e antipadrões Esta tabela 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 resposta a incidentes no [Padrão e Explorador antipadrão](/docs/architect/pt-br/well-architected-tools/guide/adaptable-incident-response).

	Padrões	Antipadrões
Hora de recuperar	No seu negócio: - Os protocolos de recuperação são praticados a intervalos regulares. - As equipes sabem quais serviços em produção são de sua propriedade e são responsáveis por elas. - As equipes entendem as ferramentas relevantes para dar suporte ao diagnóstico de problemas.	No seu negócio: - Os protocolos de recuperação não existem ou não são praticados a intervalos regulares. - Não está claro quais equipes são responsáveis pelos diferentes serviços na produção. - As equipes não têm orientação nem padrões sobre ferramentas para dar suporte ao diagnóstico de problemas.
	Na sua documentação: - As táticas de recuperação são definidas e classificadas por tipo de incidente e acionador. - Os critérios de saída para respostas de incidentes estão incluídos nos SLOs e são claros. - Os critérios de ativação e a lógica de atribuição para permissões elevadas durante incidentes estão claros. - Conjuntos de permissões e autorizações de resposta a incidentes são listados claramente. - Existe um guia de solução de problemas para ajudar a identificar e diagnosticar problemas comuns.	Na sua documentação: - A resposta de incidente é realizada ad hoc. - Não há critérios de saída para respostas de incidentes. - Permissões elevadas não são atribuídas ou, se estiverem, são atribuídas ad hoc. - Conjuntos de permissões e autorizações de resposta a incidentes não são listados.
	Em sua organização: - Existem conjuntos de permissões baseados em sessão para resposta a incidentes e podem ser atribuídos à equipe de suporte durante a recuperação. - A Trilha de auditoria de configuração mostra que os testadores de recuperação designados fizeram login no ambiente de teste no horário acordado e seguiram os scripts de teste de recuperação.	Em sua organização: - Os conjuntos de permissões baseados em sessão não existem para resposta a incidentes ou, caso existam, a equipe de suporte não está autorizada a usá-los. - A Trilha de auditoria de configuração mostra que os testadores de recuperação designados não fizeram login no ambiente de teste ou não seguiram scripts de teste de recuperação
	Em seus planos de teste: - Existem scripts de teste para testes de recuperação e são repetíveis. - Os ambientes para simulações de incidentes são listados claramente.	Em seus planos de teste: - Scripts de teste para testes de recuperação não existem. - Os ambientes para simulações de incidentes não são estabelecidos.
Habilidade de triagem	No seu negócio: - As PME ou partes interessadas que devem ser alertadas para dar suporte a problemas complexos são identificadas antes de um incidente ocorrer. - A transferência entre equipes de entrega e suporte faz parte da ativação. - Se consultado, os arquitetos do Salesforce respondem rapidamente e ajudam a equipe a se manter focada na recuperação.	No seu negócio: - As PME ou partes interessadas que devem ser alertadas não são identificadas até que um incidente ocorra. - A transferência entre equipes de entrega e equipes de suporte não faz parte do processo de liberação. - Os arquitetos do Salesforce consideram a resposta a incidentes como fora do escopo de trabalho.
	Na sua documentação: - Os padrões de sistema e design usados em uma determinada solução podem ser descobertos e lidos pela equipe de suporte.	Na sua documentação: - Os padrões de sistema e design usados em uma determinada solução não estão prontamente disponíveis para a equipe de suporte.
	Em sua organização: - Mensagens de erro personalizadas e de registro são incorporadas a caminhos de execução em todo o sistema.	Na sua organização: - Não são usados registros e mensagens de erro personalizadas.
Monitoramento e alerta	Em sua organização: - Os alertas são usados apenas para informar os usuários sobre cenários que exigem intervenção humana; outras falhas são registradas e relatáveis. - Os alertas são enviados aos usuários que são capazes de respondê-los. - Quando possível, os alertas são entregues antes de uma possível falha.	Em sua organização: - Os alertas são enviados quando ocorre qualquer tipo de falha, independentemente de ações de acompanhamento serem ou não necessárias. - Alertas sobre problemas que exigem soluções técnicas são entregues aos usuários de negócios. - Os alertas são entregues apenas em resposta a falhas que já ocorreram.
Monitoramento e alerta	Na sua documentação: - Os critérios de entrada para alertas de ajuste de prompt são definidos com base nas métricas de feedback de IA generativa direta e indireta.	Na sua documentação: - Não há critérios definidos para acionar alertas de ajuste de prompt para aplicativos de IA generativa.

## Planejamento de continuidade Uma chave para a resiliência dos negócios é o planejamento de continuidade, que se concentra em como permitir que pessoas e sistemas funcionem por meio de problemas causados por um evento não planejado. Os planos de continuidade de negócios (BCPs) têm uma visão orientada a pessoas de como manter os processos avançando durante a crise. Os aspectos técnicos do planejamento de continuidade estão contidos nas partes de recuperação de desastres de um CCO. Consulte [Continuidade da tecnologia](/docs/architect/pt-br/well-architected/guide/resilient#continuidade-da-tecnologia). Sem planos de continuidade adequados, sua organização agora pode saber como agir e, portanto, não agir de modo algum durante uma crise ou falha do sistema. O planejamento de continuidade ineficaz pode ter um impacto catastrófico sobre clientes, partes interessadas e negócios. Após um evento adverso, cada momento que passa sem manter ou recuperar processos críticos corre o risco de prejuízo financeiro, prejuízo à reputação, segurança dos funcionários e até mesmo conformidade regulatória. Você pode integrar um melhor planejamento de continuidade em seus sistemas focando seus esforços em três áreas: [definir a continuidade de negócios para o Salesforce](/docs/architect/pt-br/well-architected/guide/resilient#continuidade-dos-negócios), [planejar a continuidade da tecnologia](/docs/architect/pt-br/well-architected/guide/resilient#continuidade-da-tecnologia) e [criar recursos de backup e restauração](/docs/architect/pt-br/well-architected/guide/resilient#criar-funcionalidades-de-backup-e-restauração). ### Continuidade dos negócios Sua empresa já pode ter um CCO em vigor. Se tiver, certifique-se de que o Salesforce esteja incluído nele. Se sua empresa não tiver um BCP, trabalhe com suas partes interessadas para criar um que abranja suas organizações do Salesforce. O Salesforce costuma ser confiável como fonte da verdade para dados do cliente e processos comerciais essenciais em muitas divisões de negócios. Assim, o papel que o Salesforce desempenha em um BCP pode ser diferente dos papéis que outros sistemas desempenham. É provável que a Salesforce esteja envolvida em muitas áreas de alta prioridade para recuperação. Para criar um plano de continuidade de negócios relevante para sistemas do Salesforce: - **Esclareça as prioridades para recuperação**. Como acontece com a abordagem geral para a [resposta a incidentes](/docs/architect/pt-br/well-architected/guide/resilient#resposta-de-incidente), a recuperação deve ser a primeira prioridade dos sistemas em momentos de crise. Muitos serviços essenciais para os negócios são executados com o Salesforce. Você deve ajudar as partes interessadas a identificar a prioridade correta para recuperar várias funções e recursos de negócios. Uma estrutura geral pode ser: - Estabilize a infraestrutura de negócios essencial. - Estabilizar os serviços ao cliente. - Estabilizar serviços de funcionários e parceiros. - **Considere seu ecossistema em seus BCPs**. O Salesforce não é o único sistema em seu panorama. Identifique lacunas em seu CCO em torno de sistemas que se integram ao Salesforce, soluções instaladas de fornecedores do AppExchange e quaisquer outros sistemas que se conectem a dados ou processos no Salesforce. Se sua capacidade de entrega depender dos fornecedores, pergunte a esses fornecedores sobre seus planos de continuidade. Avalie seus recursos e planeje como manter seus sistemas disponíveis. - **Integrar preocupações do BCP em sua estratégia de teste**. Crie planos de teste para seu CCO e realize-os. É especialmente importante testar as áreas do seu CCO relacionadas a processos ou pessoas, que costumam ser ignoradas. Incorpore itens relevantes do seu CCO em sua [estratégia de teste](/docs/architect/pt-br/well-architected/guide/resilient#estratégia-de-teste) geral do ALM. Crie e siga uma agenda de manutenção para revisar os testes e garantir que seu plano fique atualizado. Os [padrões e antipadrões para o planejamento de continuidade](/docs/architect/pt-br/well-architected/guide/resilient#padrões-de-planejamento-de-continuidade-e-antipadrões) mostram como é o planejamento de continuidade adequado e ruim em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar locais em seu sistema que precisam ser refatorados. Para aprender mais sobre ferramentas do Salesforce para definir a continuidade dos negócios, consulte [Salesforce Tools for Resilience](/docs/architect/pt-br/well-architected/guide/resilient#ferramentas-do-salesforce-para-resiliência). ### Continuidade da tecnologia A meta da continuidade da tecnologia é garantir que problemas com componentes em um sistema não impeçam a empresa de manter operações essenciais. A Salesforce prioriza manter nossos serviços nos níveis mais altos de disponibilidade e fornecer informações transparentes sobre quaisquer problemas. Você pode ver informações em tempo real sobre o desempenho do sistema Salesforce e problemas em [trust.salesforce.com](https://trust.salesforce.com/). Como um arquiteto criando no Salesforce, suas soluções se beneficiam das funcionalidades de confiabilidade, segurança e desempenho do site que o Salesforce fornece em toda a plataforma. No entanto, a continuidade geral de suas soluções do Salesforce vai além dos serviços integrados que o Salesforce fornece. De uma perspectiva arquitetônica, o planejamento de continuidade de tecnologia do Salesforce precisa começar fazendo e respondendo perguntas sobre como o Salesforce se encaixa em seu panorama corporativo maior. Quais tipos de sistemas se integram ao Salesforce? Como os sistemas externos dependem de processos ou informações no Salesforce? Em suas organizações do Salesforce, quais processos ou funcionalidades dependem das soluções do AppExchange? Seus usuários acessam o Salesforce por meio de serviços de identidade ou SSO de terceiros? Para criar uma melhor continuidade de tecnologia em seus sistemas do Salesforce: - **Avaliar sua infraestrutura.** A estratégia de remediação mais comum para falhas ou problemas de tecnologia é criar serviços ou sistemas redundantes aos quais você pode voltar durante um incidente. No Salesforce, temos uma arquitetura intencionalmente redundante, o que significa que mantemos cópias dos sistemas e serviços de nossos clientes em diferentes locais físicos. Usamos várias técnicas de recuperação de desastres, incluindo a alternância do site, que nos permite direcionar o tráfego do usuário de um data center para outro, se necessário. Para identificar onde você pode precisar criar redundância intencional, faça estas perguntas a você mesmo. - O que acontece durante uma interrupção de serviço para o serviço \[X]? Podemos mudar desse serviço para outro? - Quanto tempo leva para recuperar \[X]? Qual é o impacto para nossos clientes? Qual é o impacto para nossos parceiros? Qual é o impacto para as equipes internas? - E quanto a [backups](/docs/architect/pt-br/well-architected/guide/resilient#criar-funcionalidades-de-backup-e-restauração) e sua frequência? Os backups podem fornecer os dados necessários para dar suporte aos negócios? - Nós dependemos de fornecedores? Quais são os planos de CCO? - **Fornecer apoio operacional.** O suporte operacional é fazer as equipes voltarem a funcionar o mais rápido possível. Pense em como seu sistema pode lidar com aumentos significativos nos requisitos de capacidade e demanda de alterações inesperadas, incluindo alterações do setor, da região ou globais. Certifique-se de que seu CCO considere os recursos adicionais ou os procedimentos de vidro quebrado de que a Engenharia de confiabilidade do site (SRE) ou as equipes de suporte podem precisar para responder a incidentes de modo eficaz. As perguntas sobre suporte operacional incluem: - Em uma interrupção, nossas equipes técnicas teriam as ferramentas necessárias para continuarem trabalhando? Simulamos uma interrupção para validar planos ou identificar lacunas? - Se um desastre ocorrer em uma área específica, temos planos de cobertura para essa área? - Nossos clientes são globais? Eles operam 24 horas por dia, 7 dias por semana? - Temos um [monitoramento e alerta](/docs/architect/pt-br/well-architected/guide/resilient#monitoramento-e-alerta) adequados para notificar as pessoas apropriadas quando há falhas? - **Automate e teste suas táticas de recuperação.** Depois que um problema for remediado, identifique onde ele ocorreu e como ele foi corrigido. Se possível, com base na remediação, automatize suas táticas de recuperação e ajuste quaisquer problemas do processo. Muitas empresas agendam simulações de incidentes para um subconjunto de serviços para testar a resiliência do sistema. Um exemplo poderia ser simular uma conta de administrador do sistema sendo bloqueada ou comprometida, ou simular uma interrupção ou problema com um provedor do AppExchange. Consulte [Resposta a incidentes](/docs/architect/pt-br/well-architected/guide/resilient#resposta-de-incidente).)As perguntas sobre como o teste e a automação podem ajudá-lo a restaurar serviços mais rapidamente incluem: - Com que frequência agendamos e executamos simulações de incidentes? - Sabemos quanto tempo leva para restaurar os serviços a um estado estável? - Temos processos de entrega estáveis em vigor? - Sabemos onde automatizar o failover e a recuperação? Trate qualquer item que venha de suas análises pós-incidente como seus outros itens de desenvolvimento. Adicione-os aos seus sistemas de planejamento para que você possa priorizá-los e trabalhar com eles. Os [padrões e antipadrões para planejamento de continuidade](/docs/architect/pt-br/well-architected/guide/resilient#padrões-de-planejamento-de-continuidade-e-antipadrões) mostram como é o planejamento de continuidade de tecnologia adequado e ruim em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar locais em seu sistema que precisam ser refatorados. Para aprender mais sobre ferramentas do Salesforce para planejamento de continuidade de tecnologia, consulte [Salesforce Tools for Resilience](/docs/architect/pt-br/well-architected/guide/resilient#ferramentas-do-salesforce-para-resiliência). ### Criar funcionalidades de backup e restauração A restauração de cópias de backup de dados ou metadados pode ajudar a retornar sua organização ao último estado estável conhecido. Ele também pode fornecer um sistema de failover durante uma falha catastrófica do sistema ou interrupção de serviço. Fazer backup regular de seus dados e metadados e armazenar suas cópias criptografadas em backup em um local seguro adiciona uma camada adicional de resiliência à sua arquitetura. Sem estratégias de backup e restauração, não é possível restaurar versões limpas de seus metadados e dados de produção quando eles forem corrompidos de modo mal-intencionado, quando defeitos entrarem inadvertidamente em produção ou quando uma falha durante um grande carregamento de dados corromper os dados de produção. Qualquer um desses cenários pode resultar em seus dados de produção críticos para os negócios serem corrompidos ou até mesmo perdidos permanentemente. A configuração da tecnologia de backup e restauração oferece várias vantagens além do planejamento de continuidade, incluindo ajudar com estratégias para mitigar grandes volumes de dados e cumprir políticas de retenção relacionadas à conformidade. Para ajudar a garantir a continuidade com estratégias de backup e restauração em suas soluções do Salesforce: - **Comece.** A primeira etapa para ter uma boa estratégia de backup e restauração é ter uma estratégia em primeiro lugar. Mesmo algo tão simples como fazer backups noturnos de todos os dados e metadados da sua organização pode evitar que sua empresa perca informações ou funcionalidades essenciais durante um desastre. - **Restrinja o acesso a backups.** Os administradores do sistema são os únicos usuários que devem ter acesso a cópias de segurança dos seus dados. Essa restrição de acesso impede que um usuário comercial possa visualizar registros em uma cópia de backup que não teria autorização para visualizar na sua organização. - **Teste seu processo de restauração regularmente.** Independentemente da estratégia de backup e restauração implementada, [teste](/docs/architect/pt-br/well-architected/guide/resilient#estratégia-de-teste) seu processo de restauração em um sandbox de Cópia total ou parcial regularmente para ter certeza de que ele funcionará corretamente quando você precisar. - **Alinhe sua estratégia de backup e restauração com sua estratégia de arquivamento de dados.** Determine o que deve acontecer em seus backups ou arquivos quando os registros são arquivados ou removidos do seu sistema. Consulte [Volume de dados](/docs/architect/pt-br/well-architected/guide/reliable#volume-de-dados)). Talvez você precise de uma estratégia de backup mais granular se seus volumes de dados forem tão grandes que um backup completo não tenha tempo para ser concluído antes da execução do próximo backup. Talvez você também precise de uma estratégia de backup mais granular se os dados da sua organização mudarem com tanta frequência que as atualizações sejam essenciais para a sua organização. Para tornar sua estratégia de backup mais granular: - **Especifique seus backups para objetos específicos**. Essa estratégia envolve fazer backup de registros de diferentes objetos em intervalos de tempo diferentes. Lembre-se de que os objetos filho devem fazer backup nos mesmos intervalos que seus pais para manter a consistência dos dados. - **Backups parciais** **de caixa de** tempo. Essa estratégia envolve a diferenciação entre backups completos (de todos os dados e metadados) e backups parciais (de apenas metadados e registros que foram adicionados ou alterados desde o último backup). **\*Nunca pare de realizar backups completos**. É importante observar que você nunca deve eliminar backups completos completamente, mesmo que os volumes de dados resultem em tempos de execução longos. Para grandes volumes de dados, planeje backups completos regulares, mas infrequentes (por exemplo, backups semanais). Planeje também backups parciais ou específicos de objeto mais frequentes (por exemplo, backups noturnos ou backups a cada X horas). Essa abordagem oferece flexibilidade para reconstruir o conjunto de dados mais completo e preciso para usar em seus processos de restauração.\* Os [padrões e antipadrões para planejamento de continuidade](/docs/architect/pt-br/well-architected/guide/resilient#padrões-de-planejamento-de-continuidade-e-antipadrões) mostram a aparência dos recursos de backup e restauração adequados e ruins em uma solução do Salesforce. Use-os para validar seus designs antes de criar ou para identificar locais em seu sistema que precisam ser refatorados. ### Backup e recuperação do Salesforce O Backup e recuperação do Salesforce, uma solução integrada do Salesforce que inclui a Recuperação própria da aquisição própria, protege dados importantes contra perda ou corrupção. Nossa solução altamente segura, fácil de configurar e sempre disponível garante a continuidade dos negócios e a resiliência dos dados e simplifica a conformidade. Use o Backup e recuperação do Salesforce para evitar perda de dados, recuperar de incidentes de dados rapidamente e simplificar sua estratégia geral de gerenciamento de dados. Você pode criar políticas de backup para dados de alto valor e regulados e restaurar esses dados com apenas alguns cliques. #### Implementar backups automatizados Os backups diários automatizados protegem todos os dados cruciais da sua organização, incluindo metadados, sandboxes, dados de pacote gerenciado, anexos de arquivo e muito mais. Execute backups com a frequência necessária para atender às metas do seu objetivo de ponto de recuperação (RPO) e proteger suas implantações. Os backups sempre estão acessíveis e armazenados de forma segura e em conformidade. A Proteção de dados contínua também está disponível para dados ainda mais confidenciais ou transacionais, permitindo uma recuperação mais rápida de informações críticas que mudam rapidamente. #### Monitorar dados proativamente Detecte atividades de dados incomuns, perda de dados e corrupção com alertas proativos enviados diretamente para seu email. Receba alertas em tempo real para identificar desvios estatísticos ou criar regras que o notificam sobre atividades de dados incomuns, ajudando você a detectar incidentes com mais rapidez do que nunca. #### Restaurar com precisão e rapidez O Backup e recuperação do Salesforce acelera a recuperação fornecendo visibilidade granular das alterações, permitindo a rápida identificação e restauração dos dados afetados. Ferramentas como gráficos visuais destacam alterações indesejadas, enquanto recursos de recuperação fáceis de usar restauram objetos, campos e registros afetados com precisão. #### Estender o uso de seus backups Nossas ferramentas permitem que você use backups para análise, auditorias e conformidade, oferecendo dados históricos pesquisáveis, funcionalidade de pesquisa aberta para a visibilidade de dados anteriores e recursos de exportação para análise externa ou armazenamento. Isso reutilizará os backups sem precisar de APIs adicionais do Salesforce. #### Gerenciamento de dados de backup unificado O Backup e Recuperação oferece um único console para consolidar todos os backups, gerenciamento, operações e conformidade. Esse console permite que você acesse, gerencie, personalize e monitore backups para todas as suas organizações de produção e sandboxes. Com ele, você também pode executar solicitações de sujeito de dados para garantir a conformidade dos dados de backup e ter controle total para personalizar agendas de backup, frequência e políticas de retenção. #### Principais casos de uso para Backup e recuperação do Salesforce - **Minimizar o impacto de incidentes de dados**. O Backup e recuperação do Salesforce ajuda a mitigar incidentes de dados, como ataques cibernéticos ou atividades internas ou externas mal-intencionadas, permitindo que os usuários revertirem os registros afetados para o estado anterior ao incidente. A funcionalidade de exportação do Backup e Recover garante o acesso contínuo e a usabilidade dos dados críticos dos usuários. - **Prevenir perda permanente de dados**. O erro humano continua sendo a principal causa de perda de dados. O Backup and& Recover oferece uma solução precisa e rápida para esses erros. - **Satisfazer mais facilmente os requisitos legais e de conformidade de dados**. O Backup e recuperação do Salesforce dão suporte ao modelo de responsabilidade compartilhada, habilitando a funcionalidade de autoatendimento para o esquecimento em massa ou a correção de dados em seus dados de backup. Para aprender mais sobre ferramentas do Salesforce para backup e restauração, consulte [Salesforce Tools for Resiliency](/docs/architect/pt-br/well-architected/guide/resilient#ferramentas-do-salesforce-para-resiliência). ### Padrões de planejamento de continuidade e antipadrões Esta tabela 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 planejamento de continuidade no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/adaptable-continuity-planning).

	Padrões	Antipadrões
Continuidade dos negócios	No seu negócio: - Uma mentalidade "recuperação em primeiro lugar" é adotada com foco em remover os recursos e as funções de negócios de prioridade mais alta do impacto assim que possível. - Há uma agenda de manutenção para revisão de planos de teste do BCP.	No seu negócio: - Uma mentalidade de "corrigir o problema" é a única abordagem para o gerenciamento de incidentes. - Os planos de teste BCP não são atualizados a intervalos regulares.
	Na sua documentação: - Existe um CCO contendo etapas para continuar processando ou classificando dados se o Salesforce ficar indisponível, uma lista de eventos que acionam o uso do CCO e etapas e intervalos para testes do CCO. - O CCO inclui sistemas e dependências a montante e a jusante.	Na sua documentação: - Um BCP não existe, não está completo ou inclui apenas o Salesforce.
	Em seus planos de teste: - As áreas do seu CCO relacionadas a processos e pessoas são consideradas.	Em seus planos de teste: - As áreas do seu CCO relacionadas a processos e pessoas não são consideradas.
Continuidade da tecnologia	No seu negócio: - Você avaliou se precisa criar sistemas intencionais de redundância ou failover - As táticas de recuperação de incidentes são automatizadas sempre que possível.	No seu negócio: - Você não avaliou a necessidade de redundância intencional ou sistemas de fall-over - As táticas de recuperação de incidentes são todas manuais.
Continuidade da tecnologia	Na sua documentação: - O CCO considera recursos adicionais ou procedimentos de vidro quebrado que as equipes podem precisar para responder a incidentes de modo eficaz.	Na sua documentação: - O CCO não inclui necessidades de suporte operacional.
Backup e restauração	Na sua documentação: - Há uma estratégia de backup e restauração para dados e metadados.	Na sua documentação: - Uma estratégia de backup e restauração não existe ou, se existir, está incompleta, aplicando-se apenas a dados ou apenas a metadados, não a ambos.
Backup e restauração	Na sua empresa: - Os backups são armazenados em um local seguro que somente usuários autorizados podem acessar. - Os planos de teste e os registros de teste mostram que as restaurações de dados são testadas em um sandbox de Cópia total ou parcial pelo menos duas vezes por ano.	Na sua empresa: - Os backups não são legíveis por humanos. - Os backups são armazenados em locais que usuários comerciais não autorizados podem acessar. - Não há um processo de restauração de dados ou o processo de restauração de dados não foi testado.

## Ferramentas do Salesforce para resiliência

Ferramenta	Descrição	Gerenciamento de ciclo de vida do aplicativo	Resposta de incidente	Planejamento de continuidade
Testes do Apex Hammer	Saiba mais sobre testes do Apex do Salesforce em versões atuais e novas.	X
Apex Stub API	Crie uma estrutura de simulação para simplificar os testes.	X
Backup e recuperação	Gere backups automaticamente para evitar perda de dados.			X
Objetos grandes	Armazene e gerencie grandes volumes de dados na plataforma.			X
Rastreamento de histórico de campo	Rastreie e exiba o histórico do campo.		X
Obter Insights de adoção e segurança para sua organizaçãoObrir link em nova janela	Monitore a adoção e o uso do Lightning Experience em sua organização.		X
Gerenciar trabalhos de carregamento de dados em massa	Crie atualizações ou exclua grandes volumes de registros com a API em massa.		X
Gerenciar eventos de monitoramento de evento em tempo real	Gerencie as configurações de armazenamento e streaming de monitoramento de evento.		X
Recursos de dados e armazenamento	Visualize os limites de armazenamento e o uso da sua organização do Salesforce.		X
Logs de depuração do monitor	Monitore registros e defina sinalizadores para acionar o registro.		X
Monitore a atividade de login com análise forense de login	Identifique o comportamento que pode indicar fraude de identidade.		X
Monitor alterações de configuração com a Trilha de auditoria de configuração	Acompanhe alterações de configuração recentes feitas por administradores.		X
Histórico de treinamento do monitor	Visualize as aulas de treinamento do Salesforce que seus usuários realizaram.		X
Trabalhos de monitoramento de fundo	Monitore trabalhos em segundo plano na sua organização.		X
Monitorando trabalhos agendados	Visualize instantâneos de relatórios, trabalhos do Apex agendados e atualizações de painel.		X
Teste de escala	Teste o desempenho do sistema e interprete os resultados.	X
Monitoramento proativo	Minimize interrupções usando os serviços de monitoramento do Salesforce.		X
Salesforce Data Mask	Mascarar automaticamente os dados em um sandbox.	X
Página de visão geral do sistema	Visualize os dados de uso e os limites da sua organização.		X
Use force:lightning:lint	Analise e valide o código por meio do Salesforce CLI.	X

## Recursos relevantes para resilientes

Recurso	Descrição	Gerenciamento de ciclo de vida do aplicativo	Resposta de incidente	Planejamento de continuidade
7 antipadrões em testes de desempenho e escala	Evite antipadrões comuns em testes de desempenho e escala.	X
Analisar hotspots de desempenho e escala em aplicativos Salesforce complexos	Aprenda uma abordagem para lidar com problemas de desempenho e escalabilidade em sua organização.	X
Criar um plano de recuperação de desastres (Trailhead)	Crie um plano de recuperação de desastres.			X
A continuidade dos negócios é mais do que backup e restauração	Obtenha uma visualização abrangente do BCP.			X
Modelo de padrões de design	Crie padrões de design para sua organização.	X
Estruturas de diagnóstico e monitoramento no Salesforce	Saiba como melhorar a qualidade e o desempenho de suas implementações.		X
Princípios Diretores para o Planejamento de Continuidade dos Negócios	Revise os princípios básicos subjacentes a um BCP eficaz.			X
Como fazer Teste de escala no Salesforce	Aprenda as cinco fases do ciclo de vida de teste de escala.	X
Introdução ao Teste de Desempenho	Saiba como desenvolver um método de teste de desempenho.	X
Monitore sua organização	Saiba mais sobre as opções de monitoramento de autoatendimento.		X
Modelo de estratégia de teste	Crie e personalize planos de teste de escala e desempenho.	X
Modelo de estratégia de teste	Garanta que sua estratégia de teste esteja concluída.	X
Entender Desenvolvimento orientado por origem (Trailhead)	Aprenda mais sobre desenvolvimento de pacote e organizações teste.	X

## Diga-nos o que você pensa Ajude-nos a manter o Salesforce Well-Architected relevante para você; faça nossa [pesquisa](https://sfdc.co/bxNtvh) 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](/docs/architect/pt-br/well-architected/guide/contributors). ## Introdução Um sistema seguro protege as partes interessadas e os dados de uma organização. As arquiteturas seguras verificam a identidade do usuário, restringem o acesso aos dados apenas às informações necessárias e impedem o comprometimento dos dados. A Salesforce prioriza o Trust do cliente e a segurança dos dados. A Salesforce Platform garante privacidade e segurança. Informações de desempenho e segurança do sistema em tempo real estão disponíveis no [Salesforce Trust](https://trust.salesforce.com/). A proteção dos dados da sua organização e do cliente é a base para criar soluções seguras do Salesforce. Como arquiteto do Salesforce, você é responsável por proteger os dados da sua organização e do cliente usando os recursos de segurança integrados do Salesforce. Considere a distribuição geográfica, o setor, os procedimentos operacionais da empresa e os tipos de dados do cliente ao tomar essas decisões. Você pode tornar suas soluções mais seguras focando em três áreas: segurança organizacional, segurança da sessão e segurança de dados. ## Segurança organizacional A segurança organizacional protege os sistemas contra acesso não autorizado garantindo que apenas usuários validados e autorizados possam acessar um sistema e apenas os recursos e dados necessários. Os sinais de que você tem problemas de segurança organizacional incluem: - Processos ad hoc para ativar ou desativar usuários - Etapas pouco claras para atualizar a autorização para alterações de papel do usuário ou do sistema - Dependência do Knowledge institucional de indivíduos para atribuições corretas de segurança do usuário - Falha de alinhamento com estruturas de segurança estabelecidas ou práticas recomendadas do setor - Ausência de uma estrutura de governança de dados estruturada e políticas de suporte Você pode criar melhores controles de segurança organizacionais para suas organizações do Salesforce focando a autenticação e a autorização. ### Autenticação A autenticação é crucial para segurança e gerenciamento de acesso, verificando a identidade dos usuários que tentam acessar seu sistema. Isso se aplica a usuários humanos (funcionários, clientes) e usuários automatizados (sistemas externos, integrações), sendo que cada tipo de usuário requer esquemas de autenticação específicos. Para garantir acesso seguro em todos os pontos de entrada do Salesforce em sua organização, você precisará configurar vários métodos de autenticação. Para criar fluxos de autenticação seguros no Salesforce: - **Crie usuários do Salesforce com base em indivíduos, não em personas**. Os recursos de auditoria integrados do Salesforce são mais eficazes quando cada conta de usuário corresponde a um único indivíduo que acessa a plataforma. O uso de contas de usuário compartilhadas compromete a eficácia dessas auditorias, introduz vulnerabilidades de segurança adicionais, escala o potencial impacto de violações de conta e complica sua capacidade de criar esquemas de autorização eficazes. Isso inclui contas de usuário para usuários de integração. - Cenários de acesso **seguro baseados em UI**. A maioria dos usuários humanos requer algum tipo de acesso baseado em IU (geralmente chamado de acesso de login) para uma organização do Salesforce. O Salesforce oferece várias camadas de proteção para esses cenários de login, incluindo: - **Políticas de senha.** Os cibercriminosos costumam ter como alvo nomes de usuário e senhas para obter acesso não autorizado aos aplicativos. Embora a configuração das [políticas de senha](https://help.salesforce.com/s/articleView?id=sf.admin_password.htm&type=5) seja um passo fundamental para proteger o acesso de login, é importante notar que isso sozinho não é suficiente, pois o Salesforce permite substituições por usuário dessas políticas. - **Autenticação multifator (MFA)**. O Salesforce [requer MFA](https://help.salesforce.com/s/articleView?id=000352937&type=1) para todos os logins de usuário baseados em IU. A MFA fornece uma defesa essencial contra vazamentos de credenciais e ataques de força bruta exigindo que os usuários forneçam uma forma adicional de identificação, ou fator, depois de inserir com sucesso seu nome de usuário e senha. Esse fator adicional geralmente assume uma forma física, como um dispositivo móvel, uma chave de segurança ou um marcador biométrico. - **Sinal único ativado (SSO)**. Em cenários de SSO, os usuários usam apenas um conjunto de credenciais nos aplicativos de uma organização. O acesso aos sistemas é provisionado e gerenciado de um local central, o que melhora a segurança. O Salesforce pode atuar como um provedor de serviços ou um provedor de identidade em [cenários de SSO](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5). Certifique-se de permitir que alguns ou todos os administradores façam login diretamente no Salesforce para que possam resolver interrupções ou problemas com sua implementação de SSO. - **Etapas após o login.** Para alguns casos de uso, você pode exigir que os usuários concluam etapas adicionais antes de acessar seu sistema. Fluxos de login personalizados podem ser implementados para orientar os usuários por essas etapas extras do processo. Os exemplos incluem: - Aceitando termos e condições - Trabalhando com [descoberta de login e cenários de login sem senha](https://help.salesforce.com/s/articleView?id=sf.external_identity_passwordless_login_use_cases.htm&type=5) - Limitar o número de sessões simultâneas do Salesforce por usuário para reduzir a probabilidade de ataques baseados em sessão (consulte [segurança da sessão](/docs/architect/pt-br/well-architected/guide/secure#segurança-da-sessão)). - Conectar-se a serviços de cerca geográfica - Cenários de acesso **seguro baseados em API**. Qualquer usuário pode solicitar acesso baseado em API para uma organização do Salesforce. O Salesforce oferece várias camadas de proteção para cenários baseados em API, incluindo: - **API Access Control**. Sem o [controle de acesso à API](https://help.salesforce.com/s/articleView?id=sf.security_api_access_control_about.htm&type=5), qualquer pessoa com um conjunto válido de credenciais pode utilizar qualquer aplicativo para se conectar à sua organização, mesmo que o aplicativo conectado não esteja implantado na organização. Os controles de acesso a dados ainda serão aplicados, mas os usuários poderão acessar informações de maneiras não controladas. Por exemplo, um aplicativo pode ser usado para fazer download de grandes volumes de dados ou até mesmo carregar informações corrompidas sem a aprovação de um administrador do sistema. - **Permissões somente API**. Você pode configurar as permissões de usuário apenas de API no Salesforce. Atribua isso como parte de um conjunto de permissões a qualquer personalidade de usuário automatizada ou de [integração](https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm) para bloquear totalmente o acesso baseado em interface do usuário. - **Certificados e chaves**. Os [certificados e chaves](https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5) permitem que o Salesforce valide se as solicitações se originam de empresas ou empresas autorizadas. Você precisará configurar certificados e chaves se quiser usar o [SSO com o Salesforce](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5). - **Aplicativos conectados**. Configurar [aplicativos conectados](https://help.salesforce.com/s/articleView?id=sf.connected_app_overview.htm&type=5) no Salesforce permite controlar o acesso do sistema externo ao Salesforce, incluindo protocolos de autenticação obrigatórios, escopo de autorização e comportamento da sessão em uma única definição. - **Credenciais nomeadas**. As [credenciais nomeadas](https://help.salesforce.com/s/articleView?id=sf.named_credentials_define.htm&type=5) permitem controlar pontos de acesso externos e protocolos de autenticação em uma única definição no Salesforce. Use-os para definir e gerenciar com segurança a autenticação para chamadas do Apex, serviços externos e fontes de dados do Salesforce Connect. - Autenticação de usuários agentes **Agentforce**. Os agentes do Agentforce, criados com base no Salesforce, usam objetos de agente-usuário com permissões gerenciáveis como os de usuários reais. Ao configurar um agente, alinhe o acesso com cuidado ao papel desempenhado pelo agente, limitando o acesso aos dados apenas ao que é necessário para atender aos usuários finais. Assim como é importante, os agentes podem ser configurados com ações públicas e privadas. Para ações privadas, valide e autentique os usuários finais, mapeando-os para o contexto do agente. Isso permite que o Agente se imite e opere dentro dos controles de acesso do usuário final, mantendo a segurança e Trust. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/secure#padrões-de-segurança-organizacionais-e-antipadrões) abaixo mostra a aparência da arquitetura de autenticação adequada (e ruim) em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais. Para saber mais sobre as ferramentas de autenticação disponíveis no Salesforce, consulte [Ferramentas relevantes para segurança](/docs/architect/pt-br/well-architected/guide/secure#ferramentas-relevantes-para-proteger). ### Autorização A autorização define quais recursos, funcionalidades e dados um usuário pode acessar, bem como as ações que ele pode executar com esses recursos depois de terem sido [autenticados](/docs/architect/pt-br/well-architected/guide/secure#autenticação). Os controles de autorização não são apenas para usuários humanos, eles também precisam ser personalizados para Usuários Agentes do Agentforce, especialmente Agentes que fornecem serviços a usuários finais não autenticados. Embora restringir quem pode se autenticar em sua organização seja uma primeira etapa crucial, é igualmente vital combinar autenticação forte com autorização robusta. Sem controles de autorização adequados, os usuários podem criar, editar e excluir registros ou acessar a funcionalidade do sistema de maneiras que são prejudiciais para sua empresa e suas partes interessadas. O controle de autorização inadequado também pode dificultar o uso dos sistemas. Ao controlar o que os usuários podem fazer no sistema, você promove níveis mais elevados de Trust, salvaguardando seu sistema e seus usuários. Para criar esquemas de autorização seguros para o Salesforce: - **Siga o princípio do privilégio mínimo**. Adote o princípio de privilégio mínimo (PoLP) atribuindo aos usuários apenas as permissões necessárias para suas tarefas. Para seguir esse princípio, crie conjuntos de permissões granulares e modulares. Isso permite controles de acesso sofisticados por meio de grupos de conjuntos de permissões, permitindo o gerenciamento preciso de permissões, incluindo a capacidade de [mutir](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_muting.htm&type=5), [de definir datas de expiração](https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238) e muito mais. Alinhe suas [unidades funcionais](/docs/architect/pt-br/well-architected/guide/composable#unidades-funcionais) de sistemas com funcionalidades de negócios para definir permissões granulares e grupos de conjuntos de permissões eficazes. Lembre-se de que as permissões se aplicam ao acesso a _metadados_ no Salesforce. Para obter detalhes sobre como configurar o PoLP para acesso a _dados do_ Salesforce, consulte [Compartilhamento e visibilidade](/docs/architect/pt-br/well-architected/guide/secure#compartilhamento-e-visibilidade). - **Pense sobre o acesso do usuário em termos de personas, não indivíduos**. Pensar em autorização (ou segurança em geral) em termos de usuários individuais não configurará seu sistema em escala e evoluirá. Em vez disso, projete e gerencie personas que representam grupos de usuários. As soluções seguras do Salesforce usam indivíduos para autenticação e personas para autorização. Ao definir configurações de segurança para personas distintas, você obtém controle granular sobre o acesso e os privilégios em seu modelo de segurança, o que minimiza a necessidade de refatoramento no longo prazo. Inclua as personalidades de segurança que você define em suas [normas de design e documentação](/docs/architect/pt-br/well-architected/guide/intentional#legibilidade). - **Controle o acesso do usuário aos metadados usando conjuntos de permissões e grupos de conjuntos de permissões**. Conjuntos de permissões e grupos de conjuntos de permissões controlam o que os usuários de metadados podem acessar e o que eles podem fazer com esses metadados. Para aprender mais sobre metadados do Salesforce, consulte [Metadados versus dados](/docs/architect/pt-br/fundamentals/guide/architecture-basics#metadados-versus-dados). Configure atribuições de aplicativo, ativações de licença de recurso, acesso a pacotes gerenciados, permissões do sistema, acesso [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm) e acesso em nível de campo por meio de conjuntos de permissões e grupos de conjuntos de permissões. Inclua esse acesso em suas [normas de design e documentação](/docs/architect/pt-br/well-architected/guide/intentional#legibilidade). - **Use padrões organizacionais (OWDs) e compartilhamento para controlar o acesso aos dados dos usuários**. Os [dados e metadados](/docs/architect/pt-br/fundamentals/guide/architecture-basics#metadados-versus-dados) são entidades distintas no Salesforce, exigindo controles de acesso separados para cada uma. Use OWDs e ferramentas de compartilhamento integradas para configurar o acesso a dados do Salesforce (registros, arquivos e documentos individuais). Para obter mais detalhes, consulte [Segurança de dados](/docs/architect/pt-br/well-architected/guide/secure#segurança-de-dados). - **Use escopos do OAuth para controlar o acesso para aplicativos conectados**. Ao configurar um aplicativo conectado, você define o [escopo](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US) ou as permissões de acesso que os usuários do aplicativo terão para os recursos do Salesforce. Para obter mais informações sobre o gerenciamento de tokens OAuth, consulte [Gerenciamento de sessão](/docs/architect/pt-br/well-architected/guide/secure#gerenciamento-de-sessão). - **Crie um usuário do Salesforce para cada integração**. Para cumprir o princípio de privilégio mínimo, crie um único [usuário de integração do](https://help.salesforce.com/s/articleView?id=sf.integration_user.htm) Salesforce para cada integração. Isso permite que você atribua acesso a dados específicos, melhorando o controle sobre as operações, garantindo o rastreamento da transação e minimizando o impacto de possíveis violações de segurança. - **Implemente contas únicas com o PoLP para todos os usuários Agentes**. Cada Usuário Agente do Agentforce deve ser único e não reutilizado entre vários Agentes. As permissões para essas contas devem cumprir estritamente o princípio de privilégio mínimo. Lembre-se de que as ações executadas por um usuário agente podem operar em um contexto de segurança elevado no Salesforce ou em sistemas externos que não respeitam os controles de acesso do Salesforce. Isso pode levar a Ações acessarem ou revelarem informações confidenciais aos usuários. - **Minimize o uso de perfis e migre quaisquer controles de acesso dos perfis**. Os perfis permitem limitar o acesso a intervalos de [IP de login](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm&type=5), [horas de login](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) e recursos específicos da interface de usuário legada do Salesforce Classic (especificamente tipos de registro padrão e atribuições de layout de página). Qualquer outra funcionalidade atualmente em perfis deve ser migrada para funcionalidades equivalentes em [conjuntos de permissões e grupos de conjuntos de](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_create_with_perm_sets.htm) permissões. A funcionalidade em seus perfis vinculados aos recursos da interface do usuário do Salesforce Classic deve ser direcionada para correção. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/secure#padrões-de-segurança-organizacionais-e-antipadrões) abaixo mostra a aparência das práticas de autorização adequadas (e ruins) em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais. Para saber mais sobre as ferramentas de autorização disponíveis no Salesforce, consulte [Ferramentas relevantes para segurança](/docs/architect/pt-br/well-architected/guide/secure#ferramentas-relevantes-para-proteger). ### Padrões de segurança organizacionais e antipadrões Esta tabela 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 segurança organizacional no [Explorador de padrões e antipadrões](/docs/architect/pt-br/well-architected-tools/guide/trusted-organizational-security).

	Padrões	Antipadrões
Autenticação	Em suas normas de design e documentação: - Personalidades de segurança aprovadas são definidas e listadas claramente - O mapeamento entre personalidades de segurança e esquemas de autenticação permitidos (UI, API) existe em uma matriz de segurança	Se existem normas e documentação de projeto, elas: - Não incluir personalidades de segurança - Não inclua uma matriz de segurança com mapeamentos claros para personalidades de segurança e esquemas de autenticação permitidos
	Em sua organização: - Configurações de login alinhadas à Verificação de MFA do Salesforce - O relacionamento entre usuários e entidades que fazem login no Salesforce é de 1:1 (nenhum usuário compartilhado) - O controle de acesso à API impede que os usuários se autentiquem por meio de um aplicativo conectado não autorizado - Se o SSO estiver habilitado, os usuários administradores aprovados terão acesso de login direto	Em sua organização: - As configurações de login não estão alinhadas à Verificação de MFA do Salesforce - O relacionamento entre usuários e entidades que fazem login no Salesforce não é 1:1 (há contas de usuário compartilhadas) - Se os usuários acessarem o Salesforce de trás de um firewall, o firewall usará endereços IP embutidos em código para proteger as comunicações de/para o Salesforce - O controle de acesso à API não está habilitado - Se o SSO estiver habilitado, nenhum usuário administrador aprovado terá acesso de login direto
	In LWC, Apex, Aura: - Métodos que executam autenticação usam credenciais nomeadas para lidar com fluxos de nome de usuário/senha - Nenhum nome de usuário ou senha aparece em código em formatos legíveis (nenhum valor ou string embutido em código) - Se existem fluxos de login personalizados, todo o código personalizado relacionado usa métodos apropriados `SessionManagement`	In LWC, Apex, Aura: - A autenticação é tratada ad hoc - Nomes de usuário e senhas aparecem em código
Autorização	Em suas normas de design e documentação: - Cada usuário e sistema com acesso ao Salesforce é mapeado para uma ou mais personas em uma matriz de segurança - A matriz de segurança lista claramente permissões de metadados e personas de usuário atribuídas - Os casos de uso para conceder privilégios elevados estão claramente listados, incluindo: -- Modificar todas as permissões de dados -- Visualizar todas as permissões de dados	Se existem normas e documentação de projeto, elas: - Não incluir uma matriz de segurança - Não listar permissões claramente - Não liste claramente casos de uso para conceder privilégios elevados
	Em sua organização: - Conjuntos de permissões e grupos de conjuntos de permissões são usados para controlar o acesso a metadados - Conjuntos de permissões e grupos de conjuntos de permissões alinhados a funcionalidades de negócios - Permissões atribuídas aos usuários seguem definições de matriz de segurança - Os perfis são usados de forma mínima e apenas para controlar intervalos de IP de login e horas de login - Um usuário de integração somente de API exclusivo é configurado para cada integração	Em sua organização: - Os grupos de conjuntos de permissões não estão configurados para permitir acesso com base em funcionalidades de negócios - Os conjuntos de permissões são configurados ad hoc - Os conjuntos de permissões são redundantes ou são altamente duplicados; é difícil entender a lógica funcional clara e as diferenças entre os conjuntos - Permissões atribuídas a usuários não seguem definições de matriz de segurança - Os perfis contêm controles de acesso para metadados - Os usuários apenas de API não estão configurados ou são compartilhados em mais de uma integração
	No Apex: - As operações de banco de dados realizam verificações de acesso em nível de campo e objeto adequadamente, incluindo: -- As instruções DML e Database DML declaram o modo do usuário ou do sistema para operações de dados AND/OR -- As instruções DML e Database DML usam métodos `stripInaccessible` antes de operações de dados -- As instruções SOQL e SOSL usam `COM USER_MODE` e `COM SYSTEM_MODE` palavras-chave E/OU -- Os métodos `stripInaccessible` são usados para filtrar resultados de consulta e subconsulta -- os métodos de resultado de descrição sObject (ou seja, `isAccessible`, `isCreateable`, `isUpdateable` e/ou `isDeletable`) são usados com moderação	No Apex: - Métodos DML, Classe do banco de dados, SOQL e SOSL são executados no modo do sistema padrão - As operações de banco de dados não realizam verificações de acesso adequadamente, incluindo: -- Os métodos DML ou Database Class usam exclusivamente as verificações `isAccessible`, `isCreateable`, `isUpdateable` e/ou `isDeletable` para acesso em nível de campo e sObject -- Consultas SOQL usam exclusivamente palavras-chave `COM SECURITY_ENFORCED` para restrições de acesso
	Em fluxos(considerações de segurança para design de fluxo): - Os fluxos usam o Contexto de execução mais restritivo possível, idealmente o Modo de usuário - O acesso a dados confidenciais ou privilegiados é realizado por Subfluxos para minimizar o contexto da execução - Limitar lógica realizada em fluxos acionados por registro - As entradas de fluxo são validadas para garantir que somente as cargas úteis permitidas sejam passadas como entrada	Em fluxos: - Fluxos são executados no Modo do sistema ou no Modo do sistema sem compartilhamento, independentemente das ações que o fluxo executa - Toda a lógica de fluxo é realizada em um único fluxo grande - Entradas de fluxo não são validadas e são passadas para os consumidores sem verificação

## Segurança da sessão Uma sessão é a série de solicitações e respostas associadas a um usuário ao longo de um período de tempo. Uma sessão é iniciada quando um usuário se autentica com sucesso no Salesforce. A [segurança de sessão](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_overview_sessions.htm) é a prática de configurar seu sistema para evitar acesso não autorizado e violações de dados, evitando interferência de sessão ou sequestro. Todas as atividades do usuário no seu sistema ocorrem no contexto de uma sessão, portanto, é essencial considerar como as sessões são iniciadas, o que pode ocorrer durante uma sessão, quais dispositivos os usuários usarão (e devem) e como detectar e responder a comportamentos de sessão suspeitos ou anômalos. Você pode criar a segurança da sessão no Salesforce focando três chaves: gerenciamento de sessão, acesso ao dispositivo e detecção e resposta de ameaças. ### Gerenciamento de sessão As sessões são iniciadas quando um usuário se autentica com sucesso e obtém acesso ao Salesforce. Essas sessões permitem que a plataforma associe solicitações e respostas específicas a esse usuário específico. O protocolo HTTPS facilita a comunicação entre um cliente de front-end e a Salesforce Platform. Os clientes podem incluir navegadores, aplicativos móveis, aplicativos locais etc. HTTPS é um protocolo sem estado, o que significa que cada comunicação é discreta e não está relacionada a nenhuma comunicação anterior ou futura. Essa abordagem sem estado acelera as comunicações de rede e elimina erros causados por links quebrados entre pacotes. No entanto, os aplicativos da Web ainda precisam de um modo de acompanhar a identidade de cada usuário e outras informações relacionadas em várias interações de resposta e solicitação. O Salesforce, como a maioria dos aplicativos da Web, realiza isso usando sessões e [tokens](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_tokens_scopes.htm&type=5). - As **sessões** permitem que o Salesforce associe solicitações e respostas aos usuários. Depois que um usuário é autenticado, a plataforma envia um ID de sessão de volta ao aplicativo cliente, que inclui esse ID com qualquer solicitação do usuário (como navegar, pesquisar e enviar dados). - Os **tokens** permitem que usuários e aplicativos conectados confirmem sua identidade uma vez e usem um token de acesso exclusivo a partir de então. Os tokens têm uma vida útil limitada e fornecem acesso apenas a recursos específicos (consulte [Autorização](/docs/architect/pt-br/well-architected/guide/secure#autorização) para obter mais informações sobre a configuração dos níveis de acesso). Os tokens permitem acesso a recursos autorizados sem exigir que os usuários façam login. Se as sessões e os tokens não forem protegidos adequadamente, os agentes ruins poderão interferir neles e personificar usuários ou executar código mal-intencionado no seu sistema. Para criar gerenciamento de sessão seguro para o Salesforce: - **Entenda como o Salesforce classifica tipos de sessão**. Identifique e mapeie [tipos de sessão](https://help.salesforce.com/s/articleView?id=sf.security_session_types.htm&type=5) aprovados para personas de usuário de segurança e registre-os na sua documentação. - **Controle como as sessões podem se originar e para onde o tráfego da sessão pode ir**. Depois de identificar os tipos de sessões que várias personalidades de usuário têm permissão para iniciar, configure controles para bloquear sessões originadas de origens ou contextos não aprovados. O Salesforce oferece várias maneiras de controlar as origens e o tráfego da sessão, incluindo: - **Proteção de sessão integrada**. O Salesforce habilita automaticamente proteções organizacionais para atividades mal-intencionadas baseadas em sessão, incluindo script entre sites, falsificação de solicitações entre sites, [sniffing de conteúdo](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing), [clickjacking](https://owasp.org/www-community/attacks/Clickjacking) e muito mais. Essas proteções nunca devem ser desabilitadas; algumas não podem ser desabilitadas. - **Domínios e intervalos de IP**. Todas as organizações do Salesforce têm [Meu domínio](https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5) habilitado por padrão, o que cria um subdomínio específico da empresa para acesso ao Salesforce. Você pode personalizar ou alterar o nome associado a uma organização por meio do Meu domínio. Além disso, o Salesforce oferece suporte a outras [configurações de domínio](https://help.salesforce.com/s/articleView?id=sf.domain_mgmt_overview.htm&type=5) para sites do Experience Cloud e outras páginas de aplicativos. Nota: Se os usuários precisarem acessar o Salesforce de trás de um firewall da empresa, adicione os [domínios obrigatórios](https://help.salesforce.com/s/articleView?id=sf.setup_domains.htm&type=5) às listas de permissões do firewall. Você pode configurar [intervalos de IP de login](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/users_profiles_epui_login_ip_ranges_edit.htm) e [intervalos de IP confiáveis](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm) para controlar solicitações de login e sessão de entrada para o Salesforce. - **Horas de login**. Se determinadas personalidades de usuário tiverem horários de funcionamento definidos, você poderá restringir a capacidade delas de acessar o Salesforce fora dos [horários de login](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) definidos. - **Controle atividades que exigem segurança em nível de sessão** adicional. Por padrão, as sessões podem ter dois tipos de [níveis de segurança](https://help.salesforce.com/s/articleView?id=sf.security_overview_sessions.htm&type=5): padrão e de alta garantia. Use esses níveis de segurança para controlar como os usuários podem e não podem realizar atividades, como acessar relatórios e painéis ou gerenciar as configurações de segurança em uma organização do Salesforce. As políticas de segurança em nível de sessão podem exigir que os usuários criem [sessões de alta garantia](https://help.salesforce.com/s/articleView?id=sf.security_auth_require_ha_session.htm&type=5) para realizar operações ou impedir que os usuários realizem operações confidenciais. - **Controle atividades que exigem permissões baseadas em sessão adicionais**. O Salesforce oferece suporte a ativações de permissão baseadas em [sessão](https://help.salesforce.com/s/articleView?id=sf.perm_sets_session_use.htm&type=5) para permitir temporariamente aos usuários autorização maior ou acesso a permissões durante uma determinada sessão. Você pode ativar e desativar permissões baseadas em sessão por meio de APIs do Salesforce ou Fluxo. - **Gerencie sessões de usuário inativas por meio de tempos limite**. Encerrar sessões inativas é uma parte importante do gerenciamento da segurança da sessão. Isso ajuda a proteger seu sistema quando, por exemplo, um usuário deixa uma sessão do Salesforce aberta em uma guia do navegador, mas está ativamente trabalhando em outro aplicativo, ou quando o dispositivo móvel de um usuário está conectado ao Salesforce, mas está sem assistência. O Salesforce tem um tempo limite de inatividade da sessão padrão de duas horas. Você pode aumentar ou diminuir os níveis de tempo limite de inatividade da sessão, mas aumentar os tempos limite deve ser feito apenas com uma justificativa convincente e bem documentada. - **Gerencie sessões de aplicativo conectado por meio da configuração de token.** Ao configurar um aplicativo conectado, você também define o escopo, ou nível de autorização, que será concedido aos usuários que acessam o Salesforce por meio do aplicativo conectado. Esse escopo é aplicado no nível da sessão por meio de [tokens OAuth](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US), que são emitidos depois que um usuário de um aplicativo conectado autentica com sucesso. Você pode controlar por quanto tempo um token deve durar por meio das [políticas de atualização de token](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US). Os administradores da organização podem revogar os tokens manualmente por usuário e por organização, se necessário. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/secure#padrões-de-segurança-da-sessão-e-antipadrões) abaixo mostra como é o gerenciamento de sessão adequado (e ruim) em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais. Para saber mais sobre as ferramentas de gerenciamento de sessão disponíveis no Salesforce, consulte [Ferramentas relevantes para segurança](/docs/architect/pt-br/well-architected/guide/secure#ferramentas-relevantes-para-proteger). ### Acesso ao dispositivo No contexto atual, um _dispositivo_ é qualquer peça de equipamento eletrônico que uma pessoa usará para acessar o Salesforce, como uma estação de trabalho de desktop, laptop, tablet ou telefone celular. Dispositivos portáteis oferecem aos usuários a flexibilidade de acessar o Salesforce de qualquer lugar. No entanto, essa conveniência pode introduzir vetores de ataque adicionais para atores mal-intencionados. Esses vetores de ameaça variam de táticas simples, como surf em um local público para roubar credenciais, a métodos mais sofisticados, como instalar malware em um dispositivo ou criar uma rede Wi-Fi pública falsa para interceptar transmissões de dados. Por isso, proteger dispositivos, especialmente dispositivos portáteis, é essencial para a segurança geral do sistema. Para proteger o acesso ao dispositivo para o Salesforce: - **Use as soluções de aplicativo móvel fornecidas pela Salesforce**. Faça com que os usuários em dispositivos móveis que precisam acessar o Salesforce usem os [aplicativos Salesforce disponíveis para iOS e Android](https://help.salesforce.com/s/articleView?id=sf.mobile_security.htm&type=5). Se as necessidades de negócios exigirem uma solução móvel personalizada, você deve usar o [Salesforce Mobile SDK](https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm), que fornece métodos para autenticação e autorização seguras. - **Projete o uso de dispositivos móveis no gerenciamento de sessão**. Níveis de segurança da sessão, tempos limite da sessão e outros controles de contexto da sessão devem levar em conta qualquer acesso previsto dos usuários em dispositivos móveis. Considere quais dispositivos devem e não devem ter permissão para acessar o Salesforce e quais tipos de usuários devem ter acesso a sessões móveis. Inclua padrões de acesso móvel na sua documentação de personalidade de segurança. Para obter mais informações sobre este tópico, consulte [Gerenciamento de sessão](/docs/architect/pt-br/well-architected/guide/secure#gerenciamento-de-sessão). - **Aumentar a segurança em nível de dispositivo com a tecnologia Gerenciamento de dispositivos móveis (MDM).** Os aplicativos Salesforce para iOS e Android são [compatíveis com muitos pacotes de MDM populares](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mdm.htm&type=5). Você pode configurar controles de acesso adicionais para o aplicativo Salesforce em dispositivos de usuário por meio da sua solução de MDM preferida. - **Aumentar a segurança em nível de aplicativo com a tecnologia Gerenciamento de aplicativo móvel (MAM)**. A tecnologia MAM oferece suporte a controles no nível do aplicativo em dispositivos móveis. O Salesforce oferece um complemento pago [MAM](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mam_overview.htm&type=5) para aplicativos móveis do Salesforce. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/secure#padrões-de-segurança-da-sessão-e-antipadrões) abaixo mostra como é o gerenciamento de dispositivos adequado (e ruim) em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais. Para saber mais sobre as ferramentas de gerenciamento de dispositivos disponíveis na Salesforce, consulte [Ferramentas relevantes para segurança](/docs/architect/pt-br/well-architected/guide/secure#ferramentas-relevantes-para-proteger). ### Detecção e resposta a ameaças A detecção de ameaças é o processo de identificar padrões de comportamento em seu sistema que podem indicar atividade mal-intencionada. Isso pode incluir volumes maiores que a média de dados sendo baixados ou um usuário modificando campos contendo dados confidenciais em vários registros em um período menor que a média. As respostas a ameaças podem incluir expiração da sessão automatizada, alerta e outras notificações. A meta da detecção de ameaças é identificar e responder a possíveis problemas o mais rapidamente possível. Realizar ações com base na detecção de ameaças em tempo real pode impedir o comportamento mal-intencionado em seu caminho. O Salesforce oferece o [monitoramento de evento em tempo real](https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5) como um complemento ou como parte do [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/). Use uma dessas soluções se você tiver aplicativos altamente confidenciais ou precisar de recursos robustos de detecção e resposta de ameaças em tempo real. Para criar uma estratégia eficaz de detecção e resposta de ameaças para suas soluções do Salesforce: - **Use recursos de auditoria integrados**. O Salesforce oferece uma variedade de [ferramentas integradas](https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5) para ajudar a rastrear e auditar alterações na sua organização. Por exemplo, a [Trilha de auditoria de configuração](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5) permite visualizar o histórico de auditoria de ações administrativas. O Salesforce rastreia alterações no nível do campo por um período de tempo limitado por padrão, mas você pode ativar o [Rastreamento de histórico de campo](https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5) para exibir alterações de campo por até 18 meses na IU e até 24 meses por meio da API. Além disso, você pode ativar a [Trilha de auditoria de campo](https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5) para reter um histórico de auditoria para alterações no nível de campo indefinidamente (até que você exclua os dados manualmente). - **Estabelecer revisões periódicas de auditoria**. A auditoria é crucial para identificar alterações anômalas que a detecção de ameaças em tempo real pode perder. Considere um cenário em que um usuário com acesso legítimo exclui consistentemente um pequeno número de registros diariamente durante um período prolongado. Como esse usuário tem credenciais de login válidas, autorização adequada para excluir registros e não está excluindo um grande volume de registros de uma só vez, é improvável que a atividade seja detectada como uma ameaça em tempo real. No entanto, uma equipe de auditoria revisando relatórios de atividades do usuário identificaria claramente essa tendência de exclusão excessiva de registro por um único usuário ao longo do tempo, facilitando a solução. Como parte de suas [políticas de governança](/docs/architect/pt-br/well-architected/guide/intentional#governança), estabeleça intervalos regulares para auditar o histórico de login, a atividade da sessão do usuário e o uso do aplicativo conectado. - **Desenvolva uma estratégia de resposta a ameaças e inclua-a em suas políticas de segurança**. Crie uma estratégia de resposta à ameaça que abranja: - Definições de tipo de resposta às ameaças (por exemplo, alertas e automações) e quaisquer [grupos de](/docs/architect/pt-br/well-architected/guide/resilient#resposta-de-incidente) partes interessadas. Para obter mais informações sobre a criação de mensagens ou alertas, consulte [Erros e notificações](/docs/architect/pt-br/well-architected/guide/engaging#notificações-e-mensagens). - Categorias específicas para alterações em tempo real ou atividades que podem ser consideradas ameaças e o tipo de resposta associado para cada uma - Uma lista clara de todas as respostas a ameaças automatizadas (como revogar tokens, encerrar sessões, desativar contas de usuário ou bloquear o acesso a recursos) e acionadores de automação O Monitoramento de evento fornece os dados necessários para aplicar esse princípio habilitando a detecção e resposta a ameaças em tempo real. A Segurança da transação aplica as ações conduzidas pela política da sua empresa, e os tipos de evento dão suporte ao monitoramento do acesso do usuário e do aplicativo ao longo do tempo. O serviço nativo de Detecção de ameaças do Salesforce usa modelos estatísticos e de aprendizado de máquina para identificar comportamento suspeito. Esse serviço gera eventos específicos que protegem contra ataques cibernéticos e acesso a dados suspeitos. A Segurança da transação leva a segurança um passo adiante, pois fornece uma estrutura que intercepta os principais eventos que ocorrem na sua organização e aplica as ações conduzidas pela política da sua empresa. Isso transforma o Monitoramento de evento de uma ferramenta de registro em um componente importante de uma defesa de segurança automatizada. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/secure#padrões-de-segurança-da-sessão-e-antipadrões) abaixo mostra como é a detecção e resposta adequadas (e ruins) de ameaças em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais. Para saber mais sobre as ferramentas de automação de detecção, alerta e resposta de ameaças disponíveis no Salesforce, consulte [Ferramentas relevantes para segurança](/docs/architect/pt-br/well-architected/guide/secure#ferramentas-relevantes-para-proteger). ### Padrões de segurança da sessão e antipadrões Esta tabela 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 segurança da sessão no [explorador de padrões e antipadrões](/docs/architect/pt-br/well-architected-tools/guide/trusted-session-security).

	Padrões	Antipadrões
Gerenciamento de sessão	Em suas normas de design e documentação: - Personalidades de segurança listam claramente os tipos de sessão aprovados e as configurações de tempo limite/duração para cada personalidade - As horas de login foram especificadas (ou identificadas como não necessárias) - Operações que exigem segurança ou permissões em nível de sessão são claras e descobríveis - O escopo do aplicativo conectado e as políticas de gerenciamento de token são claros e descobríveis	Em suas normas de design e documentação: - Personalidades de segurança não existem ou faltam informações sobre tipos de sessão e configurações de tempo limite/duração - As políticas de segurança não contêm informações sobre escopos de aplicativo conectado ou gerenciamento de token
	Em sua organização: - As auditorias de sessão mostram que os usuários acessam o Salesforce apenas por meio de tipos de sessão esperados - Há um conjunto de permissões claro e ativo para acesso "Único usuário da API" (com o conjunto de permissões "Único da API" definido como TRUE) e todos os usuários de integração e automatizados são atribuídos - Se os usuários acessarem o Salesforce de trás de um firewall, o firewall usará uma lista de permissões de domínios obrigatórios em vez de endereços IP para proteger as comunicações de/para o Salesforce - Intervalos de tempo limite de sessão inativos não ultrapassam o padrão (2 horas) - Todas as configurações a seguir estão habilitadas: -- Proteção contra clickjack para páginas de Configuração -- Proteção contra clickjack para páginas do Salesforce não de configuração -- Proteção contra falsificação de solicitação entre sites (CSRF) -- Proteção de script entre sites (XSS) -- Habilitar proteção de detecção de conteúdo -- Proteção de URL do referenciador -- Avisar os usuários antes que eles sejam redirecionados para fora do Salesforce	Em sua organização: - Não há auditoria de sessão regular - Não há definições de quais tipos de sessão os usuários devem ter - As permissões "apenas API" não estão claras ou estão ausentes da integração e dos usuários automatizados - Se os usuários acessarem o Salesforce de trás de um firewall, o firewall usará endereços IP embutidos em código para proteger as comunicações de/para o Salesforce - Intervalos de tempo limite de sessão inativos excedem o padrão (2 horas) - Qualquer uma das seguintes configurações está desabilitada: -- Proteção contra clickjack para páginas de Configuração -- Proteção contra clickjack para páginas do Salesforce não de configuração -- Proteção contra falsificação de solicitação entre sites (CSRF) -- Proteção de script entre sites (XSS) -- Habilitar proteção de detecção de conteúdo -- Proteção de URL do referenciador -- Avisar os usuários antes que eles sejam redirecionados para fora do Salesforce
	In LWC, Apex, Aura: - Se existem fluxos de login personalizados, todo o código personalizado relacionado usa métodos apropriados `SessionManagement` para atribuir segurança em nível de sessão	In LWC, Apex, Aura: - Se houver fluxos de login personalizados, não haverá lógica para atribuir segurança no nível da sessão
Acesso ao dispositivo	Em suas normas de design e documentação: - As políticas do dispositivo são claras e descobríveis - Personalidades de segurança são mapeadas claramente para usos e políticas de dispositivo adequados	Em suas normas de design e documentação: - As políticas de segurança não existem ou não contêm informações sobre o acesso ao dispositivo
Acesso ao dispositivo	Em sua organização: - A configuração do aplicativo móvel conectado do Salesforce exige desbloqueio de PIN/senha após a inatividade - Se as necessidades de negócio exigirem um controle rígido dos usuários que podem acessar o Salesforce móvel, o Controle de acesso à API será habilitado e os conjuntos de permissões serão atribuídos a todos os usuários dos aplicativos Salesforce móvel	Em sua organização: - O aplicativo móvel conectado do Salesforce não está configurado para exigir desbloqueio de PIN/senha para inatividade – As necessidades de negócios exigem um controle rígido dos usuários que podem acessar o Salesforce móvel, mas o Controle de acesso à API não está habilitado ou os conjuntos de permissões não são usados para controlar o acesso a aplicativos Salesforce móvel
Detecção e resposta a ameaças	Em suas normas de design e documentação: - As políticas de segurança contêm uma lista de eventos que devem acionar uma resposta junto com o tipo de resposta apropriado - Os níveis de auditoria foram especificados para todos os objetos no modelo de dados - As etapas para revisar os registros disponíveis no Salesforce são documentadas - Todas as respostas automatizadas são documentadas claramente	Em suas normas de design e documentação: - As políticas de segurança não existem ou não incluem informações sobre detecção e alerta de ameaças - A documentação para respostas automatizadas não existe ou não está clara
	Dentro da sua empresa: - Os dados de auditoria estão disponíveis em relatórios que as partes interessadas da empresa podem entender e acessar - Revisões regulares do histórico de auditoria e relatórios ocorrem	Dentro da sua empresa: - Os dados de auditoria estão disponíveis apenas por meio de arquivos de registro que exigem conhecimento sobre o assunto para acessar e interpretar - Não há processos para revisar informações de auditoria
	Em sua organização: - Automações estão em vigor para responder a ameaças desativando contas de usuário ou bloqueando o acesso a recursos em tempo real se uso anormal for detectado - Notificações e alertas são configurados para notificar os usuários apropriados sobre atividade anômala - O rastreamento de histórico de campo está habilitado para todos os campos que contêm dados privados ou confidenciais	Em sua organização: - Não há automações em vigor para responder a ameaças - As notificações e alertas não estão configuradas para notificar os usuários apropriados sobre atividades anômalas ou algumas notificações e alertas relacionados a atividades anômalas existem, mas são ad hoc - O rastreamento de histórico de campo não está habilitado de modo consistente para campos contendo dados privados ou confidenciais

## Segurança de dados A segurança de dados é a prática de proteger seus dados contra acesso não autorizado, corrupção ou exclusão acidental. A segurança de dados envolve proteger dados em trânsito e em repouso. Uma forte segurança de dados minimiza os riscos e possíveis danos decorrentes de acesso não autorizado ao seu sistema. A segurança de dados inadequada torna os sistemas vulneráveis a violações de dados, o que pode afetar seriamente os clientes e sua empresa. Portanto, proteger seus dados é fundamental para criar arquiteturas seguras. Melhorar a segurança de dados começa com uma compreensão clara do que é considerado como dados no Salesforce, junto com sua classificação. Os registros individuais, arquivos e documentos armazenados em uma organização do Salesforce são seus dados. Para obter mais informações sobre a distinção entre metadados e dados, consulte [Bases da Arquitetura do Salesforce](/docs/architect/pt-br/fundamentals/guide/architecture-basics#metadados-versus-dados). Você pode criar segurança de dados mais forte em suas soluções do Salesforce focando o compartilhamento e a visibilidade, bem como o uso de criptografia. > Nota: Ao projetar para segurança de dados, lembre-se de levar em conta a [privacidade dos dados](/docs/architect/pt-br/well-architected/guide/compliant#privacidade-de-dados), bem como o [arquivo e a limpeza](/docs/architect/pt-br/well-architected/guide/resilient#planejamento-de-continuidade), pois ambos os conceitos afetarão a segurança geral dos dados das suas soluções. ### Classificação de dados Identifique e classifique todos os dados armazenados na Salesforce Platform com base em sua confidencialidade (por exemplo, público, interno, confidencial, restrito). Defina uma clara **política de classificação de dados** que descreva como cada tipo de dados deve ser tratado e protegido. Implemente controles de segurança adequados, como segurança em nível de campo, criptografia e mascaramento de dados, para aplicar a política e proteger dados confidenciais contra acesso ou exposição não autorizados. Revise e audite essas classificações e controles regularmente para garantir que eles permaneçam alinhados aos requisitos de negócios e conformidade. ### Compartilhamento e visibilidade O compartilhamento e a visibilidade envolvem configurar seu sistema para controlar como os usuários acessam dados no Salesforce. É importante notar que o compartilhamento e a visibilidade controlam quais registros individuais um usuário pode acessar, mas essas configurações sozinhas não controlam, por fim, o que um usuário pode fazer com um registro específico ou quais campos específicos nesse registro estão visíveis. As permissões para realizar operações de dados (como [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm)) são atribuídas aos usuários por meio de controles de acesso a metadados, que podem ser configurados para um usuário no nível de objeto e campo individual. Para obter mais informações sobre isso, consulte [Autorização](/docs/architect/pt-br/well-architected/guide/secure#autorização). Ações do Agentforce podem expor dados a usuários autenticados e anônimos que normalmente não têm acesso direto. Ao criar Agentes do Agentforce, considere cuidadosamente e documente todas as Ações atribuídas ao agente. Para cada Ação, você deve entender: - Quais dados as Ações podem acessar. - Em qual contexto de segurança as Ações são executadas. - Se as Ações têm recuperação do Knowledge ou outros recursos que podem incorporar dados confidenciais ou restritos na sessão do agente. Para configurar o compartilhamento e a visibilidade efetivos no Salesforce: - **Projete acesso em torno de funções de trabalho significativas**. Crie uma matriz de segurança que mapeie suas [personas de usuário](/docs/architect/pt-br/well-architected/guide/secure#autenticação) para as funções de negócios que eles devem executar. Use esse [modelo](/docs/architect/pt-br/resources/guide/security-policy-template) como base para projetar seu compartilhamento e visibilidade. Para obter mais informações sobre a identificação de funções de negócios significativas, consulte [Unidades funcionais](/docs/architect/pt-br/well-architected/guide/composable#unidades-funcionais). - **Escolha o caminho mais simples para aplicar o princípio do privilégio mínimo**. Ao aplicar o [princípio do privilégio mínimo](/docs/architect/pt-br/well-architected/guide/secure#autorização) ao projetar esquemas de compartilhamento e visibilidade, faça-o da maneira mais simples possível. Evite restrições de dados e esquemas de compartilhamento excessivamente projetados, que podem causar problemas a jusante na capacidade de manutenção, escalabilidade e adaptabilidade do sistema. Em vez disso, aproveite o compartilhamento de dados em camadas [flexível no Salesforce](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf) para configurar regras detalhadas para acesso do usuário no nível de dados. - **Definir padrões _internos_ para toda a organização (OWDs) como Somente leitura pública, a menos que sua empresa trate de dados confidenciais, use Privado**. Os OWDs controlam o nível de privilégio "menos" que os usuários terão no nível de dados. Não é possível restringir o acesso abaixo do nível da OWD. Embora OWDs privados possam parecer ideais em todos os casos de uso, os usuários de negócios muitas vezes podem replicar inadvertidamente um OWD mais permissivo por meio de esquemas de compartilhamento complexos. Além disso, OWDs privados podem fazer com que os usuários criem dados duplicados. Cálculos de compartilhamento (e recálculos recalculatórios) podem levar um tempo significativo para serem concluídos, dependendo do volume de dados e da discrepância entre pai e filho ou propriedade – OWDs privadas exacerbam isso. É importante observar que os OWDs não controlam as permissões CRUD e a visibilidade em nível de campo. Escolha apenas um OWD de Privado quando for justificado por necessidades de negócios — na maioria das vezes, essas justificativas estarão relacionadas à [conformidade](/docs/architect/pt-br/well-architected/guide/compliant). - **Definir padrões de toda a organização (OWDs) _externos_ como Privados, a menos que você tenha um motivo comercial convincente para permitir maior acesso**. Os [OWDs externos](https://help.salesforce.com/s/articleView?id=sf.security_owd_external.htm&type=5) se aplicam a usuários que acessam dados do Salesforce de sites, portais e assim por diante do Experience Cloud. Isso permite que você configure linhas de base de OWD separadas para usuários internos e externos, para permitir diferentes tipos de privilégio "menos". Sempre defina o OWD para usuários externos como Privado. As exceções para um nível mais aberto devem ser claramente justificadas pelas necessidades de negócios. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/secure#padrões-e-antipadrões-de-segurança-de-dados) abaixo mostra o compartilhamento e a visibilidade adequados (e ruins) em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais. Para saber mais sobre ferramentas de compartilhamento e visibilidade do Salesforce, consulte [Ferramentas relevantes para segurança](/docs/architect/pt-br/well-architected/guide/secure#ferramentas-relevantes-para-proteger). ### Uso da criptografia A criptografia converte dados legíveis em um formato codificado indeciferível. Os dados criptografados podem ser descriptografados ou traduzidos de volta para sua forma original por meio de uma chave. Como resultado, a criptografia está entre os métodos mais eficazes para proteger dados em repouso e em trânsito, garantindo que, mesmo que partes não autorizadas acessem os dados, eles não serão legíveis. Para projetar o uso adequado da criptografia em suas soluções do Salesforce: - **Sempre criptografe adequadamente os dados em trânsito**. O Salesforce [utiliza a Segurança de camada de transporte (TLS)](https://help.salesforce.com/s/articleView?id=sf.security_overview_infrastructure.htm&type=5) para todas as sessões que ocorrem em um [navegador compatível com o Salesforce](https://help.salesforce.com/s/articleView?id=sf.getstart_browser_overview.htm&type=5) e exige que as chamadas de saída usando HTTPS atendam a padrões de segurança específicos. As APIs da plataforma também usam HTTPS por padrão. Além disso, os dados enviados entre um site do Salesforce Experience Cloud ou um portal e sua organização do Salesforce relacionada são criptografados em trânsito [por padrão](https://help.salesforce.com/s/articleView?id=xcloud.security_pe_platform_encryption_faq.htm&type=5). Se você usa os [serviços de email integrados](https://help.salesforce.com/s/articleView?id=sf.emailadmin_send_email_from_salesforce_overview.htm&type=5) do Salesforce, há níveis padrão para a Segurança de camada de transporte (TLS) que o Salesforce usa para [enviar e tentar entregar emails](https://help.salesforce.com/s/articleView?id=sf.emailadmin_deliverability.htm&type=5). Você deve, no mínimo, garantir que as configurações da organização não sejam inferiores às configurações padrão, a menos que tenha uma justificativa comercial clara. Com base na classificação e na confidencialidade dos seus dados, considere aproveitar uma conexão de rede privada com o Salesforce por meio do AWS Direct Connect ou do Salesforce Private Connect. Isso garante que seus dados não passem pela Internet pública, mas fluam com segurança por uma conexão de rede privada para acesso de usuário e integrações. - **Se a empresa o exigir, criptografe dados em repouso**. O Salesforce oferece diferentes maneiras de criptografar dados em repouso. - **Hyperforce**. Os dados são criptografados em repouso em organizações que usam o [Hyperforce](/docs/architect/pt-br/fundamentals/guide/platform-multitenant-architecture#hyperforce). A criptografia é gerenciada para a sua organização pelo Salesforce. Você não pode criar (ou destruir) suas próprias chaves de criptografia. - **Salesforce Shield**. O [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) permite criptografar dados em repouso em uma organização do Salesforce em camadas adicionais, incluindo as camadas de aplicativo e banco de dados. Com o Shield, você tem recursos de gerenciamento completos para as chaves de criptografia do seu locatário, incluindo opções robustas de "Traga sua própria chave" (BYOK). Você também pode criptografar dados não estruturados (incluindo arquivos, anexos, índices de pesquisa e eventos). As instâncias baseadas no Hyperforce oferecem a opção de usar um gerenciador de chaves externo, permitindo que você traga seu próprio AWS KMS. Com esse recurso, você mantém o controle total sobre as chaves de criptografia no KMS que são usadas para criptografar e descriptografar os dados armazenados no Salesforce, reforçando a segurança e alinhando-as aos requisitos de conformidade da sua organização. A lista de [padrões e antipadrões](/docs/architect/pt-br/well-architected/guide/secure#padrões-e-antipadrões-de-segurança-de-dados) abaixo mostra o uso adequado (e ruim) da criptografia em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais. Para saber mais sobre as ferramentas de criptografia disponíveis no Salesforce, consulte [Ferramentas relevantes para segurança](/docs/architect/pt-br/well-architected/guide/secure#ferramentas-relevantes-para-proteger). ### Padrões e antipadrões de segurança de dados Esta tabela 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 segurança de dados no [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/trusted-data-security).

	Padrões	Antipadrões
Compartilhamento e visibilidade	Em suas normas de design e documentação: - Uma matriz de segurança descreve os dados que cada persona do usuário tem permissão para acessar - Diferentes padrões de acesso a dados são usados para usuários externos e usuários internos, se aplicável	Em suas normas de design e documentação: - Os padrões de design e a documentação não existem ou não contêm uma matriz de segurança - Se houver uma matriz de segurança, ela não descreverá o acesso a dados para personalidades do usuário
	Em sua organização: - Os padrões para toda a organização (OWDs) para usuários internos são Leitura pública ou OWDs para usuários internos são Privados, devido aos requisitos de conformidade - OWDs para usuários externos são privados - A IA generativa opera apenas no modo de usuário ou os usos selecionados para acesso ao sistema têm uma justificativa comercial clara	Em sua organização: - OWDs para usuários internos são definidos como Privados sem justificação comercial ou OWDs para usuários internos são definidos como Leitura/Gravação pública - OWDs para usuários externos são definidos como qualquer coisa diferente de Privado sem justificativa comercial - A IA generativa opera no modo do sistema sem justificativa de negócios
	No Apex: - Todos os códigos que acessam dados (SOQL/SOSL) ou executam operações de dados (métodos DML/Classe de banco de dados) usam palavras-chave `compartilhadas`	No Apex: - `com compartilhamento` palavras-chave são usadas inconsistentemente
Uso da criptografia	Em suas normas de design e documentação: - Casos de uso para criptografia de dados em trânsito e (se necessário) em repouso são claros e descobríveis - Os protocolos de criptografia aprovados são listados claramente - A documentação de código indica claramente onde a criptografia é usada e quais protocolos são usados	Em suas normas de design e documentação: - Os protocolos de criptografia aprovados não estão claros ou não estão listados - O código não está documentado ou a documentação não está clara sobre onde e como a criptografia é usada no código
	Em sua organização: - Se forem identificados riscos de segurança que exijam maior proteção de dados em repouso, o Hyperforce ou o Salesforce Shield fornecerão criptografia em repouso	Em sua organização: - As necessidades de negócios exigem maior proteção de dados em repouso, mas nem o Hyperforce nem o Salesforce Shield são usados
	No Apex: - Se as necessidades de negócios exigem maior proteção de dados em trânsito, todo o código envolvido na integração executa lógica usando métodos Crypto Class para criptografar dados antes da transmissão ou descriptografar dados após o recebimento	No Apex: - As necessidades de negócios exigem maior proteção de dados em trânsito, mas o código envolvido na integração executa a lógica sem criptografar dados antes da transmissão ou no recebimento, ou os métodos Classe Crypto são usados ad hoc

## Ferramentas relevantes para proteger

Ferramenta	Descrição	Segurança organizacional	Segurança da sessão	Segurança de dados
Classe Apex Crypto	Criptografar e descriptografar dados no Apex			X
Controle de acesso à API	Gerenciar o acesso às APIs e aos aplicativos conectados do Salesforce	X	X	X
Eventos de anomalia de API	Rastrear anomalias na forma como os usuários fazem chamadas à API		X
Configurações de segurança do navegador	Proteger dados confidenciais e monitorar certificados SSL		X
Autenticação baseada em certificado	Autenticar indivíduos com certificados digitais exclusivos	X	X
Certificados e chaves	Verificar solicitações para sites externos do Salesforce		X	X
Scanner de código	Verificar o Apex code quanto a vulnerabilidades de segurança		X	X
Aplicativos conectados	Integrar por meio de APIs e protocolos padrão	X	X
Eventos de preenchimento de credenciais	Rastreie tentativas de logins que usam credenciais de usuário roubadas		X
Sitio confiável da CSP	Previna ataques de injeção de código (por exemplo, script entre sites)		X
Fluxos de login personalizados	Controlar processos comerciais de login para usuários	X
Identidade do cliente	Controlar logins e verificação de aplicativo e site	X
Data Mask	Mascarar automaticamente dados confidenciais em sandboxes			X
Logs de depuração	Rastrear eventos que ocorrem em sua organização		X
Administração delegada	Atribuir privilégios de administrador limitados a usuários não administradores	X		X
Ativação do dispositivo	Verificar logins de navegadores, dispositivos ou intervalos de IP não confiáveis		X
Segurança de transações aprimorada	Interceptar eventos, monitorar e controlar a atividade do usuário		X
Acesso ao campo	Controlar o acesso a dados no nível do campo			X
Pista de auditoria de campo	Definir uma política para reter dados de histórico de campo arquivados			X
Rastreamento de histórico de campo	Rastrear e exibir histórico de campo			X
Frontdoor.jsp	Permitir acesso com um ID de sessão e URL do servidor existente		X
Heroku Connect	Sincronização bidirecional entre o Heroku e o Salesforce			X
Heroku Shield	Criar aplicativos em conformidade com HIPAA ou PCI			X
Segurança de sessão de alta garantia	Exigir segurança adicional para operações sigilosas		X
Identity Connect	Mapear registros de usuário para contas do Active Directory	X
Histórico de verificação de identidade	Auditar tentativas de verificação de identidade do usuário	X
Licença de usuário de integração	Conceda acesso a dados e recursos apenas por meio da API.	X		X
Lightning Login	Impedir senhas fracas ou esquecidas e contas bloqueadas	X
Acesso de login	Permitir que usuários de suporte façam login como outro usuário	X
Análise forense de login	Identifique o comportamento que pode indicar fraude de identidade		X
Histórico de login	Monitorar tentativas de login da organização e do site do Experience Cloud	X
Rastreamento de dispositivo móvel	Rastreie e monitore o acesso de dispositivo móvel à sua organização		X
Mobile SDK	Conecte-se à Salesforce Platform em aplicativos móveis independentes	X	X	X
Permissões do usuário do monitor (shield)	Alterações de conjunto de permissões e grupo de conjuntos de permissões	X		X
Autenticação multifator	Exigir dois ou mais métodos de verificação para login	X	X
Autenticação mútua	Impor autenticação mútua SSL ou TLS
Meu domínio	Configurar páginas e políticas de login, logins SSO e sociais	X
Credenciais nomeadas	Especificar URLs de ponto de extremidade e parâmetros de autenticação		X
Autorização de OAuth	Autorizar o acesso ao aplicativo cliente por meio de troca de token	X
Políticas de senha	Definir histórico, comprimento e complexidade da senha	X
Expirations de atribuições de conjunto de permissões	Definir expirações para atribuições de conjunto de permissões e grupo de conjuntos de permissões	X		X
Eventos de conjunto de permissões	Monitore alterações feitas em conjuntos de permissões e grupos de conjuntos de permissões	X		X
Grupos de conjuntos de permissões	Empacotar conjuntos de permissões para dar suporte a requisitos de acesso complexos	X
Conjuntos de permissões	Controle como os usuários acessam metadados, recursos e aplicativos	X
Conexão privada	Proteger integrações entre o Salesforce e a Amazon Web Services			X
Perfis	Controlar intervalos de IP de login e horas de login	X
Monitoramento de evento em tempo real	Monitorar e detectar eventos padrão no Salesforce		X
Configurações do site remoto	Registrar sites externos para chamadas do Apex ou JavaScript		X
Eventos de anomalia de relatório	Rastrear anomalias na maneira como os usuários executam ou exportam relatórios		X
Regras de restrição	Impedir que usuários acessem registros desnecessários			X
Analisador de código do Salesforce	Ler código por meio de IDE, CLI ou CI/CD para garantir que ele cumpra as práticas recomendadas		X	X
Regras de delimitação	Controle os registros padrão que seus usuários podem ver			X
Centro de Segurança	Visualize as configurações de segurança em todas as suas organizações e configure alertas para alterações de postura	X		X
Verificação de integridade de segurança	Identifique vulnerabilidades em suas configurações de segurança			X
Eventos de sequestro de sessão	Identificar acesso não autorizado por meio de identificadores de sessão roubados		X
Classe de gerenciamento de sessão	Personalizar as configurações de segurança para uma sessão ativa		X
Configurações de segurança da sessão	Configure sessões para proteger contra ataques mal-intencionados		X
Configurar trilha de auditoria	Rastrear alterações de configuração recentes feitas por administradores			X
Configurações de compartilhamento	Controlar o acesso a dados no nível do registro			X
Shield Platform Encryption	Criptografe dados confidenciais em repouso e em trânsito			X
Login único	Fornecer acesso a vários aplicativos por meio de um único login	X	X
Sistema de gerenciamento de identidade entre domínios (SCIM)	Gerenciar identidades entre sistemas por meio de APIs REST		X
Detecção de ameaças	Usar estatísticas e aprendizado de máquina para detectar ameaças		X
Intervalos de IP confiáveis	Defina endereços IP que não exigem verificação adicional		X
Relatório de acesso do usuário	Obtenha uma visualização unificada do acesso a objetos, registros e permissões de seus usuários	X		X

## Recursos relevantes para proteger

Recurso	Descrição	Segurança organizacional	Segurança da sessão	Segurança de dados
Um guia para arquitetura de compartilhamento	Saiba mais sobre ferramentas de acesso, modelos de compartilhamento e casos de uso			X
Modelo de padrões de design	Criar padrões de design para sua organização	X	X	X
Como criar um modelo de segurança do usuário	Obtenha uma compreensão melhor dos modelos de segurança do usuário	X		X
Como implementar o princípio de privilégio mínimo no Salesforce	Aprenda a aplicar controles de acesso a dados PoLP no Salesforce	X		X
Monitore sessões do usuário	Revisar sessões ativas e encerrar sessões suspeitas		X
Autenticação multifator	Acessar recursos oficiais de MFA do Salesforce	X
Grupos de conjuntos de permissões (Trailhead)	Obtenha práticas com grupos de conjuntos de permissões	X		X
Arquitetura da API REST	Entender os termos e conceitos da API REST	X	X	X
Segurança e a API SOAP	Entender os termos e conceitos da API SOAP	X	X	X
Práticas recomendadas de segurança para usuários internos da API e do sistema	Proteger o acesso ao Salesforce por usuários da API e usuários do sistema interno seguros	X
Guia de implementação de segurança	Dê uma olhada abrangente na Segurança do Salesforce	X	X	X
Modelo de política de segurança	Definir políticas de segurança para sua organização	X	X	X
Tipo de sessão	Identifique os tipos de sessões usadas para acessar sua organização		X
Fundamentos da modelagem de ameaças (Trailhead)	Aprenda sobre ameaças à segurança e como evitá-las.		X

## Diga-nos o que você pensa Ajude-nos a manter o Salesforce Well-Architected relevante para você; faça nossa [pesquisa](https://sfdc.co/bxNtvh) para fornecer feedback sobre esse conteúdo e diga-nos o que você gostaria de ver em seguida. ## Introdução Diagram showing Salesforce Well-Architected core capabilities are Trusted, Easy, Adaptable

Diagram showing Salesforce Well-Architected core capabilities are Trusted, Easy, Adaptable

O Salesforce Well-Archived Framework mostra como é o estado de saúde e onde você pode passar seu tempo criando roteiro e projetando soluções com a Salesforce Customer 360 Platform. Ele compartilha orientações prescritivas e exemplos de padrões e antipadrões para procurar em sua paisagem, com base no Knowledge das equipes de produto e especialistas em implementação em todo o Salesforce e nosso ecossistema. O Salesforce Well-Architected é organizado para ajudá-lo a criar soluções confiáveis, fáceis e adaptáveis. Soluções **confiáveis** protegem as partes interessadas.
Soluções **fáciles** proporcionam valor rapidamente.
Soluções **adaptáveis** evoluem com o negócio.
O Salesforce Well-Architected foi projetado para ajudá-lo a avançar no pensamento arquitetônico necessário para criar soluções saudáveis na Plataforma Customer 360. Um desafio exclusivo para os arquitetos criando soluções com o Salesforce é a flexibilidade fundamental da plataforma. Uma solução pode estender uma solução pré-criada oferecida pelo Salesforce (por exemplo, Sales Cloud, Service Cloud, diferentes verticais do Industries Cloud). Outra solução pode ser um aplicativo totalmente personalizado. O que você pode fazer com o Salesforce é amplo e profundo, e as escolhas de tecnologia específicas mais adequadas à sua implementação dependem das necessidades de negócios. Pode ser extremamente difícil saber o que vai criar a melhor chance de saúde de longo prazo para cada solução do Salesforce possível. O Salesforce Well-Architected oferece percepções e orientações de arquitetos altamente experientes conforme você precisa. Você pode usar as visualizações e recomendações com opinião para validar (ou desafiar) seu pensamento e obter percepções sobre áreas de consideração ou tecnologia que podem ser novas para você. Também pode ser difícil entender se há referências arquitetônicas comuns a todas as soluções saudáveis, considerando a grande variedade entre implementações. No Salesforce, tudo o que fazemos como empresa e como pessoas é guiado por nossos valores centrais. Acreditamos que isso também pode se aplicar à arquitetura. É por isso que o Salesforce Well-Architected é criado com base em um núcleo de Confiável, Fácil e Adaptável. À medida que você avalia detalhes arquitetônicos complexos e compensações, pode voltar a esses recursos centrais e usá-los como pontos de bússola para orientar sua tomada de decisão. Abaixo, você encontrará detalhes sobre tópicos individuais para explorar em nossa estrutura confiável, fácil e adaptável. ## Como os tópicos são organizados Usamos dois níveis para organizar informações em todo o Salesforce bem arquivado. O nível superior é o que as soluções bem criadas devem ser: Confiável, fácil e adaptável. O segundo nível vai para mais detalhes sobre considerações, padrões a serem criados (ou antipadrões a serem evitados) e orientação prescritiva relacionada a aspectos específicos de soluções confiáveis, fáceis e adaptáveis. Alinhar seus designs com as orientações fornecidas em toda essa estrutura deve promover maior qualidade e maior integridade em seus aplicativos Salesforce Customer 360. 💡 Quer começar a usar padrões e antipadrões rapidamente? Visite o [Padrão & Anti-Padrão Explorador](/docs/architect/pt-br/well-architected-tools/guide/patterns). Abaixo, você pode ver uma visão geral de como os tópicos são organizados:

Confiável
Uma solução confiável protege sua empresa e as partes interessadas.
Seguro	Conformidade	Confiável
Segurança organizacional Segurança da sessão Segurança de dados	Adesão legal Padrões éticos Acessibilidade	Disponibilidade Desempenho Escalabilidade
Fácil
Uma solução fácil gera valor comercial rapidamente.
Intencional	Automatizado	Engajamento
Estratégia Capacidade de manutenção Legibilidade	Eficiência Integridade de dados	Simplificado Útil
Adaptable
Uma solução adaptável evolui com seus negócios.
Resistente		Composto
Gerenciamento de ciclo de vida do aplicativo Resposta de incidente Planejamento de continuidade		Separação de preocupações Interoperabilidade Capacidade de empacotamento