# architect Diagramas de referência (reference-diagrams) - Full Documentation
# Arquitetura da organização única
## Descrição
Um diagrama detalhando uma única estratégia da organização que dá suporte a várias unidades de negócios.
A caixa inferior pode conter a lista de produtos em uso (como descrito acima) ou pode listar os recursos necessários para as unidades de negócios, como Carrinho de compras, Gerenciamento de lead ou Gerenciamento de caso.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/92edbe8d-18b8-4998-a851-7d1e815ea7d5)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/single-org-architecture.webp)
# Arquitetura de implementação do Data 360 Customer Zero
## Descrição
Um diagrama de ponta a ponta que mostra o Salesforce Data 360 como implementado no Salesforce como nosso programa Customer Zero. O Salesforce Data 360 serve como a camada central de inteligência e governança, unificando dados empresariais por meio da federação do Zero Copy com sistemas externos Snowflake e AWS, preservando a Trust e a semântica. Essa base de dados unificada e pronta para IA ativa a ativação do Agentforce 360, possibilitando agentes ricos em raciocínio, aprimoramento de CRM e automação entre nuvens com fluxos de dados seguros e sensíveis às políticas em todas as funções de negócios, transformando a organização em uma empresa agente.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNew/af215946-127b-4b47-95b9-a7c158be351b)
- [Imagem](https://architect.salesforce.com/ns-assets/data360_ref_arch/sfdc_customer_zero_implementation.png)
# Arquitetura de integração de dados de cópia zero com o Data 360
## Descrição
Um diagrama que mostra o Salesforce Data 360 usando conectores prontos para uso para integração com vários serviços de dados da AWS, junto com a poderosa interoperabilidade do Zero Copy com o AWS Redshift e S3\. Essa arquitetura permite que as organizações integram e unificem dados perfeitamente entre plataformas federadas, fornecendo uma Camada de unificação e ativação central que é essencial para transformar-se em uma verdadeira Enterprise do agente. Inclui produtos do Salesforce como Agentforce 360, Tableau Next, Marketing Cloud, Data 360 e Agentforce Sales.
## Links para download:
**Backend: Serviços da Web da Amazon**
- [Lucid](https://lucid.app/lucidchart/editNew/04991364-85c0-45e6-b5de-553367fbb473)
- [Imagem](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-aws.webp)
**Backend: Plataforma do Google Cloud**
- [Lucid](https://lucid.app/lucidchart/editNew/4661f0e4-e86a-409b-9a98-8301cbbca74f)
- [Imagem](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-gcp.webp)
**Backend: Databricks**
- [Lucid](https://lucid.app/lucidchart/editNew/e74f6e22-ce6d-4b6d-a258-76ddb8f73f4e)
- [Imagem](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-databricks.webp)
**Backend: Floco de neve**
- [Lucid](https://lucid.app/lucidchart/editNew/b02236c2-f3f4-4de8-b13b-35f67fd5390d)
- [Imagem](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-snf.webp)
# Arquitetura de soluções
Os diagramas de arquitetura de soluções ilustram os detalhes técnicos de design e implementação de soluções específicas, mostrando como componentes, serviços e integrações funcionam juntos para atender aos requisitos de negócios. Esses diagramas fornecem aos arquitetos e desenvolvedores uma visualização detalhada das interações do sistema, dos fluxos de dados e dos padrões arquitetônicos. Eles servem como esquemas para implementação, ajudando as equipes a entender relacionamentos de componente, pontos de integração e dependências técnicas em uma solução.
Esta seção contém quatro diagramas de referência relacionados à arquitetura de soluções:
| Nome do diagrama | Descrição |
| -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| [Arquitetura de integração de dados de cópia zero com o Data 360](/docs/architect/pt-br/reference-diagrams/guide/aws-data-360) | Diagramas que mostram o Salesforce Data 360 usando conectores prontos para uso para integração a vários serviços de dados de back-end. |
| [Arquitetura de implementação do Data 360 Customer Zero](/docs/architect/pt-br/reference-diagrams/guide/sfdc-customer-zero-implementation) | Um diagrama de ponta a ponta que mostra o Salesforce Data 360 como implementado no Salesforce como nosso programa Customer Zero. |
| [Arquitetura de ação conduzida por evento e ativação em lote do Data 360](/docs/architect/pt-br/reference-diagrams/guide/data360-actions-activations) | Um diagrama que representa o Salesforce Data 360 em uma solução completa para ativações de marketing. |
| [Arquitetura de soluções de gerenciamento de fidelidade](/docs/architect/pt-br/reference-diagrams/guide/loyalty-management-solution-architecture) | Um diagrama de arquitetura que representa os produtos e recursos diretamente envolvidos em uma solução de gerenciamento de fidelidade. |
# Arquitetura de soluções do Gerenciamento de fidelidade
## Descrição
Um diagrama de arquitetura que representa os produtos e recursos diretamente envolvidos em uma solução de gerenciamento de fidelidade. Isso inclui Agentforce Commerce, Agentforce Sales, Agentforce Service, Marketing Cloud Engagement, MuleSoft, Data 360 e Tableau para análise.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/217c76c7-b8c4-44ed-aade-a7ae3fb8df0a)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/loyalty-management-solution-architecture.webp)
# Ativação em lote do Data 360 e arquitetura de ação conduzida por evento
## Descrição
Este é um diagrama que representa o Salesforce Data 360 em uma solução completa para ativações de marketing. Ele mostra como criar uma solução completa com produtos como Organizações iniciais, Organizações parceiras, Data Cloud One, Agentforce 360, Agentforce Sales, Marketing Cloud e Tableau Next.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNew/620837ec-bb08-4f1e-af26-1164fc5f789c)
- [Imagem](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-actions-activations.webp)
# Centro de excelência
## Descrição
Um diagrama mostrando como um Centro de excelência (CoE) une partes interessadas executivas e TI.
Ele destaca como os recursos de liderança funcional e técnica são essenciais para um CoE.
Os Centros de excelência fornecem conhecimento e orientação em toda a empresa.
Eles fornecem valor com atividades como:
- Estabelecimento de práticas recomendadas para a implementação das soluções
- Aplicar a adesão a padrões corporativos e práticas padrão do setor
- Como especialistas em produto, instrua e treine as equipes de projeto nos produtos
- Resolva problemas graves que surgem durante a implementação
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/59956c3b-3c73-469b-87a4-44c6dad948e5)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/center-of-excellence.webp)
## Introdução
Os diagramas são uma ferramenta essencial e uma parte importante do trabalho arquitetônico. Eles nos permitem comunicar muitas ideias diferentes a muitos tipos diferentes de partes interessadas.
Os gráficos ajudam as equipes de entrega a se manterem alinhadas, servindo como uma única fonte de verdade sobre as realidades de implementações e produtos. Os gráficos também são uma maneira crítica de capacitar as partes interessadas dos negócios a tomar as decisões de compra e tecnologia certas.
**Diagramas devem sempre:**
- Ler da esquerda para a direita e de cima para baixo o mais de perto possível
- Transmita uma mensagem de forma concisa, com um escopo adequado de informações para legibilidade
- Use [componentes padrão do Salesforce Diagrams](/docs/architect/pt-br/reference-diagrams/guide/kit-of-parts), incluindo cartões e um cabeçalho com uma descrição clara descrevendo o conteúdo, o escopo e o propósito do diagrama
## Escopo do diagrama
O escopo de um diagrama deve ser limitado apenas às informações críticas a serem transmitidas para um tópico específico. Qualquer coisa que não seja necessária para capturar a mensagem que você pretende comunicar deve ser excluída. Vários diagramas podem (e devem) ser criados para capturar conceitos variados, a fim de comunicar com mais clareza e limitar o foco do conteúdo do diagrama.
- Defina as informações/mensagem essenciais que você precisa transmitir ao seu público
- Classifique escopos lógicos para focar as informações para capturar a mensagem
- Identifique os tipos de diagrama mais adequados para usar como modelos
## Tipos de diagrama
O Salesforce Diagrams definiu nossos tipos de diagramas mais úteis/populares para ajudá-lo a utilizar facilmente modelos e entender convenções de diagramação. Nossos recursos atuais são classificados como:
### Mapas de capacidade
- Capture a combinação de propriedades e os principais recursos relevantes incluídos em uma solução
- Foco em funcionalidade, valores e fatores de negócios
✨ Encontre Mapas de capacidade na [Galeria de arquitetura de referência](/docs/architect/pt-br/reference-diagrams/guide/section-capability-map)
### Paisagens do sistema
- Capture os produtos e/ou sistemas técnicos envolvidos em uma determinada implementação
- Concentre-se nas propriedades, nos aspectos de propriedade específicos e nas conexões entre as propriedades
✨ Encontre exemplos e modelos de Paisagem do Sistema na [Galeria de Arquitetura de Referência](/docs/architect/pt-br/reference-diagrams/guide/section-system-landscape)
### Arquiteturas de soluções
- Inclua produtos ou tecnologias com integração, comportamento e/ou funcionalidade
- Concentre-se nas conexões detalhadas e/ou nos aspectos de comunicação entre as propriedades
✨ Encontre exemplos e modelos de Arquitetura de soluções na [Galeria de Arquitetura de Referência](/docs/architect/pt-br/reference-diagrams/guide/section-solution-architecture)
### Roteiro
- Ajude as organizações a planejar e visualizar a implementação estratégica de recursos, componentes, recursos e sistemas ao longo do tempo
- Forneça uma visão clara da ordem de implementação, das dependências e das prioridades
✨ Encontre exemplos e modelos de roteiro na [Galeria de Arquitetura de Referência](/docs/architect/pt-br/reference-diagrams/guide/section-roadmap)
### Interação/Processo/Fluxos
- Capture etapas baseadas em tempo, fluxos de dados ou interações necessárias para dar suporte a um processo
- Concentre e esclareça (com numeração sequencial) a ordem dos aspectos/propriedades
✨ Encontre exemplos e modelos de diagramas de Interação, Processo e Fluxo na [Galeria de Arquitetura de Referência](/docs/architect/pt-br/reference-diagrams/guide/section-interaction-process-flow)
### Modelos de dados/ERDs
- Capture entidades (objetos), relacionamentos e conceitos para implementações de metadados
✨ Encontre exemplos e modelos de Modelo de dados na [Galeria de modelos de dados](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html)
Veja exemplos dos Tipos de diagrama na [Galeria de Arquitetura de Referência](/diagrams) ou na nossa [Galeria de modelos de dados](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html) dedicada. Use um modelo para criar rapidamente ou facilmente um diagrama para seu caso de uso.
## Etapas para criar um diagrama:
- Defina o **escopo** da mensagem que você precisa transmitir:
- _Pense no seu público, quais propriedades/aspectos você precisa representar, quais informações são necessárias para capturar a mensagem e o que pode ser excluído._
- Certifique-se de que haja um **Cabeçalho** com um **Título** claro e uma **Descrição** concisa e bem formulada que capture o propósito, o escopo e a mensagem do seu diagrama
- Use **Cartões** para capturar as propriedades (sistemas, conceitos, entidades, etc.)
- Capture detalhes da propriedade ou os principais aspectos / recursos conforme necessário em **Atributos do cartão**
- Exibir relacionamentos conforme necessário com **Conectores** entre as propriedades do cartão
- Incorporar **Ícones de cartão** quando útil, disponível e/ou apropriado
- Use **Ícones de rodapé** e **Ícone de rodapé** para capturar qualquer outro aspecto essencial da propriedade
**Aviso:** devido a uma limitação atual com o Lucidchart, os ícones de rodapé em diagramas criados a partir de um modelo são desbloqueados do cartão. Você precisará reencaixar os ícones arrastando-os para o centro do rodapé.
Consulte a [página Componentes padrão](/docs/architect/pt-br/reference-diagrams/guide/kit-of-parts) para obter mais detalhes e práticas recomendadas.
**Tem informações ou perguntas sobre o Salesforce Diagrams?** Por favor, informe-nos seus pensamentos [aqui](https://docs.google.com/forms/d/e/1FAIpQLSe5RmVA2ZtpfGlR2u436FA4QN6QmJGdAWxtZ_AcRLMAH_US9Q/viewform?usp=sf_link).
## Componentes padrão
Componentes padrão facilitam a criação, a personalização e a reutilização de diagramas consistentes de alta qualidade.
A Salesforce recomenda Lucid para diagramas de arquitetura.
O estilo profissional é utilizado por todos os modelos e formas de diagrama do Salesforce.
Biblioteca de formas e modelos do Salesforce no Lucidchart
Encontre exemplos de como usar componentes na [Galeria de arquitetura de referência](https://architect.salesforce.com/diagrams#reference-architecture-gallery)
## Melhores práticas
As seções a seguir apresentam as melhores práticas detalhadas para o [Cabeçalho](#cabeçalho), [Cartões](#cartões), [Ícones](#ícones) e [Conectores](#conectores) incluídos nos Componentes padrão.
## Cabeçalho
O Cabeçalho deve estar presente em todos os diagramas e incluir:
- Um título que pode ser rapidamente compreendido pelo seu público
- Uma descrição clara do que o diagrama abrange, seu propósito e intenção
- (opcional) seu logotipo ou nome da empresa para transmitir o autor
- (opcional) uma chave para esclarecer ícones, designs ou símbolos usados como classificações
O tamanho deve ocupar pelo menos 10% da altura do diagrama e 100% da largura.
O tamanho da fonte da descrição deve ser pelo menos metade do tamanho do título.
Uma chave deve ser incluída quando Ícones, conectores, cores etc. são usados que não são especificados com títulos no diagrama em si. A chave deve ser agrupada em linhas iguais quando possível.
## Cartões
Todas as propriedades do seu diagrama devem ser representadas com um cartão. Os cartões podem ser redimensionados e ter preenchimentos transparentes ou coloridos. Há várias seções do cartão que fornecem variações que você pode usar para representar diferentes conceitos no seu diagrama.
### **Anatomia do cartão**
Um cartão de exemplo está abaixo, com as diferentes seções descritas. O único conteúdo necessário do Cartão é o Título. As outras seções estão disponíveis para uso conforme necessário para casos de uso específicos.
**Ícone de cartão**
Ícones de cartão são ativos visuais que representam a propriedade do cartão
**Título do cartão**
O título do cartão é um nome para o cartão que pode ser rapidamente compreendido, capturando qual propriedade, área ou conceito o cartão representa
**Atributos do cartão**
Atributos de cartão são detalhes baseados em texto sobre a propriedade, representados como uma lista e usados quando você precisa capturar e transmitir vários pontos de dados
Rodapé **de cartão**
O rodapé do cartão fornece características adicionais da propriedade. Os exemplos incluem: Nomes de API/Objeto/Pacote, Propriedade, Recursos etc.
**Ícones de rodapé de cartão**
A seção de ícones de rodapé é para ativos visuais exibirem informações adicionais sobre a propriedade. Os exemplos incluem: canais, serviços compartilhados, recursos etc. Os ícones de rodapé devem ser incluídos/explicados na sua chave de diagrama.
Aviso: devido a uma limitação atual com o Lucidchart, os ícones de rodapé em diagramas criados a partir de um modelo são desbloqueados do cartão. Você precisará reencaixar os ícones arrastando-os para o centro do rodapé.
### **Variações de cartão**
A utilização de seções diferentes fornece variações de cartão diferentes para diferentes usos. Você pode combinar a anatomia do cartão conforme necessário para criar essas variações em seus diagramas. Veja exemplos abaixo:
Consulte a [Galeria de arquitetura de referência](https://architect.salesforce.com/diagrams#reference-architecture-gallery) para obter ideias sobre como usar essas variações.
Use a capacidade de ajustar o tamanho e a cor dos seus cartões conforme necessário para distinguir tipos e criar diagramas claros e compreensíveis.
## **Contêineres**
Os cartões também podem atuar como contêineres, ou seja, agrupamentos para várias propriedades. Você pode aninhar cartões dentro de outro cartão para representar relacionamentos hierárquicos ou classificar propriedades relacionadas conforme necessário.
## **Ícones**
Os Diagramas do Salesforce fornecem um conjunto básico de Logotipos de produto do Salesforce, bem como ícones adicionais para representar propriedades e outras áreas no seu diagrama.
Você pode encontrar exemplos de como usar Ícones na [Galeria de Arquitetura de Referência](https://architect.salesforce.com/diagrams#reference-architecture-gallery)
_Para mais ícones, consulte os ícones do [Lightning Design System.](https://www.lightningdesignsystem.com/icons/)_
## Conectores
Os conectores devem sempre usar linhas de conexão de cotovelo e ser retos sempre que possível para maior legibilidade.
Os **conectores** representam uma relação, integração ou etapa de processo entre dois cartões. Os estilos de linha indicam um tipo diferente de conexão e devem ser representados em sua chave de diagrama. Os pontos de extremidade indicam a direção de um conector de processo ou integração. Os pontos de extremidade também indicam a cardinalidade e a ordinalidade em um conector de relacionamento.
As **pílulas** são usadas para fornecer detalhes sobre as conexões. Consulte os diagramas [Arquitetura de soluções](/docs/architect/pt-br/reference-diagrams/guide/section-solution-architecture) e Fluxo de [processo de interação](/docs/architect/pt-br/reference-diagrams/guide/section-interaction-process-flow), por exemplo, usos de pílulas.
## Acessibilidade
Em todo o mundo, cerca de [1,3 bilhões](https://www.salesforce.com/company/legal/508_accessibility/#:~:text=Product%20Accessibility%20Status&text=Around%20the%20world%2C%20approximately%201.3,global%20economy%20that%20includes%20everyone.) de pessoas vivem com alguma forma de deficiência, o que representa 15% da população mundial. Acessibilidade significa tornar seu diagrama compreensível para todos os seus visualizadores. Há duas áreas de foco específicas que podem ajudar seus diagramas a ficarem mais acessíveis: otimização para leitores de tela e uso de contraste de cores adequado.
Você pode encontrar mais recursos sobre design para acessibilidade no [blog Salesforce Design](https://medium.com/salesforce-ux/tagged/accessibility).
**Leitor de tela**
Um leitor de tela é um aplicativo de software que lê em voz alta as palavras em um arquivo, aplicativo ou site. Um leitor de tela pode ler diagramas para indivíduos que não conseguem vê-los claramente. O melhor formato para compatibilidade com o leitor de tela é PDF (Formato de documento portátil). Diferentemente de imagens e aplicativos inacessíveis, os PDFs podem ser acessados por leitores de tela para ler palavras, formas e cores. Exportar seus diagramas para o formato PDF ao compartilhar com outras pessoas pode aumentar a acessibilidade.
Contraste de **cor**
Aumentar o contraste de cores é outra maneira de ajudar seu diagrama a ficar mais acessível.
As pessoas poderão reconhecer e ler melhor seus diagramas quando cumprirem o [contraste de cores mínimo das Diretrizes de acessibilidade de conteúdo da Web (WCAG)](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html) de ter uma proporção de 4,5:1 entre a cor de segundo plano atrás do texto e a cor do próprio texto.
Cada cor no [sistema de cores do Salesforce](https://medium.com/salesforce-ux/the-salesforce-color-system-c7c6b5b9c577) tem um número, entre 0 e 100, associado a ela. Ao escolher cores para seus diagramas, certifique-se de que a cor de segundo plano atrás do texto seja pelo menos 50 pontos maior ou menor que a cor do texto. Por exemplo, se a cor do segundo plano for 80, a cor do texto não deve ser maior que 30\. Considere usar a regra de 50 pontos conforme necessário para bordas e contorno também.
**Tem informações ou perguntas sobre o Salesforce Diagrams?** Por favor, informe-nos seus pensamentos [aqui](https://docs.google.com/forms/d/e/1FAIpQLSe5RmVA2ZtpfGlR2u436FA4QN6QmJGdAWxtZ_AcRLMAH_US9Q/viewform?usp=sf_link).
# Fila
## Descrição
Mostra um exemplo do padrão de enfileiramento que mostra um evento sendo publicado e gravado em uma fila quando um registro é modificado. Os assinantes recebem cópias do evento de suas filas associadas e fazem as atualizações adequadas em seus próprios registros.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/0cef151e-5b48-4237-bbe4-a774eee152ab)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/queuing.webp)
# Fluxo de personalização do cliente
## Descrição
Este diagrama mostra interações baseadas em tempo envolvidas no fluxo de informações de ponta a ponta das interações com o cliente no site do Experience Cloud até a automação de back-end no Marketing Cloud e no Slack. O MuleSoft orquestra integrações a sistemas de back-end, o Slack conecta todos na equipe e o Marketing Cloud fecha o loop com a jornada do cliente. Essa arquitetura também usa os produtos Headless 360 e Data 360.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/b13e3166-d3a1-4621-b275-242638f3f9af)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/customer-personalization-flow.webp)
# Fluxo do processo de interação
Os diagramas de fluxo de processo de interação ilustram a sequência de interações, fluxos de dados e etapas de processo entre componentes do sistema, serviços e usuários. Esses diagramas ajudam arquitetos e desenvolvedores a entender como diferentes partes de um sistema se comunicam, como eventos se propagam pela arquitetura e como processos assíncronos e síncronos são orquestrados. Eles fornecem documentação essencial para entender o comportamento do sistema, identificar gargalos e otimizar fluxos de processo.
Esta seção contém seis diagramas de referência relacionados ao fluxo do processo de interação:
| Nome do diagrama | Descrição |
| ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [Eventos de processamento assíncrono via plataforma](/docs/architect/pt-br/reference-diagrams/guide/asynchronous-processing-via-platform-events) | Mostra como o processamento assíncrono funciona com eventos de plataforma. Os eventos publicados no barramento são consumidos pelos assinantes para processamento. |
| [Verificação de reivindicação](/docs/architect/pt-br/reference-diagrams/guide/claim-check) | Mostra um evento sendo publicado quando um registro é modificado. O corpo da mensagem do evento é armazenado em um banco de dados e apenas uma referência é passada pelo barramento de mensagens. |
| [Fluxo de Personalização do Cliente](/docs/architect/pt-br/reference-diagrams/guide/customer-personalization-flow) | Mostra interações baseadas em tempo envolvidas no fluxo de informações de ponta a ponta de interações com o cliente por meio de mecanismos de personalização para sistemas de entrega. |
| [Integrações externas via Http](/docs/architect/pt-br/reference-diagrams/guide/external-integrations-via-http) | Um exemplo de diagrama de arquitetura de soluções do Guia de decisão de criação de formulários que mostra integrações externas usando protocolos HTTP. |
| [Processo de gerenciamento de fidelidade de hotelaria](/docs/architect/pt-br/reference-diagrams/guide/hospitality-loyalty-management-process) | Mostra interações baseadas em tempo de sistemas em um processo de gerenciamento de fidelidade de hotelaria. |
| [Fila](/docs/architect/pt-br/reference-diagrams/guide/queuing) | Mostra um exemplo do padrão de enfileiramento que mostra um evento sendo publicado e gravado em uma fila, com assinantes processando eventos em ordem. |
# Hierarquia de papéis do Salesforce
## Descrição
Um diagrama que representa um exemplo de hierarquia da organização, capturando um subconjunto de papéis para esclarecer a estrutura de negócios, as personas e as permissões para um caso de uso específico.
Esse não é um diagrama de paisagem típico, mas é semelhante porque mostra um plano conceitual para como os papéis são relacionados e modelam o domínio de negócios.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/4fe3cd5e-0ccf-4ffd-9f7c-a418ce615c67)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/salesforce-role-hierarchy.webp)
# Integrações externas via Http
## Descrição
Este é um diagrama de arquitetura de solução de exemplo do Guia de decisão de criação de formulários que mostra uma conexão com uma origem de dados externa por meio de uma chamada HTTP no Fluxo e uma ação HTTP no OmniStudio. Ele mostra o padrão de resposta e solicitação familiar de HTTP.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/161cc130-341d-4c6d-84dc-00ca6aa00462)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/external-integrations-via-http.webp)
# Mapa de capacidade
Os mapas de capacidade fornecem uma representação visual dos recursos de negócios e técnicos, ilustrando como diferentes produtos e serviços dão suporte a objetivos organizacionais. Esses diagramas ajudam os arquitetos e as partes interessadas a entender o relacionamento entre acionadores de negócios, funcionalidades e pilha de tecnologia subjacente. Eles servem como ferramentas de planejamento estratégico que permitem um melhor alinhamento entre metas de negócios e implementação técnica.
Esta seção contém quatro diagramas de referência relacionados a mapas de funcionalidade:
| Nome do diagrama | Descrição |
| --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| [Mapa de capacidade comercial](/docs/architect/pt-br/reference-diagrams/guide/business-capability-map) | Um mapa de funcionalidades do modelo para descrever os fatores de negócios e os recursos com um posicionamento de produto de alto nível. |
| [Mapa de funcionalidades técnicas do Data 360](/docs/architect/pt-br/reference-diagrams/guide/data-360-technical-capability-map) | Um mapa de funcionalidades que mostra os recursos técnicos do Data 360 e a combinação de produtos envolvida em dar suporte a eles. |
| [Mapa de capacidade de gerenciamento de fidelidade](/docs/architect/pt-br/reference-diagrams/guide/loyalty-management-capability-map) | Um mapa de funcionalidade que mostra serviços de gerenciamento de fidelidade com posicionamento de produto de alto nível. |
| [Centro de Excelência](/docs/architect/pt-br/reference-diagrams/guide/center-of-excellence) | Um diagrama detalhando como um Centro de excelência (CoE) une partes interessadas executivas e TI. |
# Mapa de capacidade de negócios
## Descrição
Um mapa de funcionalidades do modelo para descrever os fatores de negócios e os recursos com um posicionamento de produto de alto nível.
Os fatores de negócio são as metas estratégicas de alto nível ou pressões externas que levam uma organização a mudar a maneira como ela opera.
Exemplos de condutores de negócios incluem:
- Crescimento de receita
- Redução do custo operacional
- Retenção de clientes
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/fe6ccc24-6a13-4e0f-8076-1e5af8b08466)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/business-capability-map.webp)
# Mapa de funcionalidades do Gerenciamento de fidelidade
## Descrição
Esse diagrama de mapa de funcionalidade mostra serviços de gerenciamento de fidelidade com posicionamento de produto de alto nível. Inclui recursos como Administração de fidelidade, Processamento e Análise. Essa solução usa produtos Salesforce, como Marketing Cloud Engagement, Agentforce Service e MuleSoft.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/d41ccba2-71ea-449a-8497-ea95396102b4)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/loyalty-management-capability-map.webp)
# Mapa de funcionalidades técnicas do Data 360
## Descrição
Um mapa de funcionalidades que mostra os recursos técnicos do Data 360 e a combinação de produtos envolvida em dar suporte a eles. Inclui recursos como Data Lakehouse, Processamento de big data, Conectores de dados, Transformações, Modelos e Fonte única da verdade. Este diagrama também mostra como o Tableau e o MuleSoft se encaixam em uma solução completa.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/9b36e287-525d-472c-92ec-729bca136540)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/data-360-technical-capability-map.webp)
## Introdução
Este documento apresenta uma visão geral da notação e das convenções do diagrama de relacionamento de entidade (ERD) do Salesforce para ajudá-lo a interpretar claramente os modelos de dados de produto disponíveis na [galeria de modelos de dados](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html).
Um ERD, também conhecido como modelo de dados, é uma representação gráfica de um sistema de informações. Ele mostra os relacionamentos entre pessoas, objetos, locais, conceitos e eventos nesse sistema. É um modelo lógico que transmite a estrutura funcional dos dados. Em ERDs do Salesforce, as entidades geralmente são mapeadas para um objeto no banco de dados do Salesforce.
## Entidades
Uma entidade é uma coisa ou objeto de significância, seja real ou conceitual, sobre as quais as informações precisam ser conhecidas ou mantidas.
As entidades são representadas nos diagramas como caixas com cantos arredondados. Cada caixa de entidade geralmente fornece dois rótulos (quando aplicável):
- O nome lógico da entidade (por exemplo, "Entidade do Salesforce" no exemplo mostrado aqui). Isso pode corresponder ao rótulo singular do objeto do Salesforce representado, mas nem sempre.
- O Nome da API "físico" ou o Nome do desenvolvedor do objeto na sua organização do Salesforce (por exemplo, "_Nome da API_" no exemplo). Para objetos de pacote gerenciado, o nome da API listado no diagrama normalmente não inclui o namespace do pacote gerenciado ("vlocity_ins\*\*", por exemplo), a menos que o Salesforce ou o Salesforce Cloud usem vários pacotes gerenciados. O fim do nome da API para objetos de pacote gerenciado denota o tipo de objeto personalizado usado: "\*\*c" para objetos personalizados e configurações personalizadas normais, "\*\*mdt" para metadados personalizados, "\*\*x" para objetos externos.
As caixas de entidade também podem listar um ou mais atributos que representam os atributos dessa entidade. Um atributo é precedido por um caractere "#" ou "-".
- Um "#" indica um atributo que faz parte da chave exclusiva lógica da entidade. No diagrama de exemplo, "Atributo de chave de usuário" é considerado a chave primária do usuário da entidade.
- Um "•" indica um atributo não-chave.
### Formatação de entidade
Cada diagrama de relacionamento de entidade ilustra o modelo de dados do Salesforce da perspectiva de uma nuvem especificada, como Sales Cloud, Service Cloud ou Marketing Cloud. O esquema de cores do diagrama reflete a nuvem em foco. Todas as nuvens do setor, como Financial Service Cloud, Health Cloud e Media Cloud, usam o mesmo esquema de cores do setor.
A cor de uma determinada entidade no diagrama também tem um significado específico. A cor da nuvem de foco é indicada usando a cor da marca do Salesforce, incluindo alguns exemplos abaixo.
A seção a seguir revisará a formatação de entidade diferente referente à legenda de exemplo do Sales Cloud abaixo:
### Entidade de nuvem
Uma entidade com as cores da nuvem de foco representa um objeto que vem com a licença para essa nuvem.
### Entidade relacionada
Uma entidade com preenchimento branco e borda preta representa um objeto que vem com uma licença diferente da nuvem de foco e que não é estendida pela licença de nuvem de foco. As entidades Conta e Contato mostradas em um ERD do Sales ou do Service Cloud, por exemplo, serão exibidas como brancas com uma borda negra, pois esses objetos estão disponíveis com uma licença de plataforma.
### Entidade relacionada estendida
Uma entidade com um preenchimento cinza claro e borda negra representa um objeto que vem com uma licença diferente da nuvem de foco, mas a nuvem de foco estende esse objeto. Por exemplo, o Commerce Cloud estende o objeto de base Product2 com campos adicionais. As extensões incluem campos adicionais, relacionamentos e tipos de registro.
### Entidade externa
Entidades sem fronteiras são virtuais. Quando usadas em um diagrama, essas caixas reconhecem a existência de uma entidade no modelo lógico do domínio, mas a entidade não é implementada como um objeto físico no Salesforce. Os dados dessa entidade devem ser acessados por meio de chamadas à API externas ou Salesforce Connect na solução implantada.
### Entidade de tipo de registro
Entidades com uma borda tracejada são modeladas como tipos de registro no Salesforce. No exemplo mostrado aqui, os subtipos Conta comercial, Conta de cobrança, Conta de consumidor e Conta de serviço têm uma borda tracejada porque são mapeados para tipos de registro entregues com o pacote gerenciado do Communications Cloud.
### Entidade conceitual
Entidades com borda pontilhada são virtuais. Nenhum tipo de registro ou objeto separado é usado para diferenciar esses subtipos na solução do Salesforce. Esses subtipos representam de modo lógico um conceito do domínio que ajuda a ilustrar a funcionalidade do modelo de dados.
### Entidades de supertipo e subtipo
Um subtipo de uma entidade é a definição de um subconjunto de suas ocorrências. Quando um conjunto de subtipos é adicionado em uma entidade de supertype, a entidade de supertype descreve os atributos e relacionamentos comuns, enquanto as entidades de subtipo mostram atributos e relacionamentos específicos do subtipo. Na notação de diagrama, os subtipos são mutuamente exclusivos, o que significa que qualquer registro único deve ser de um único subtipo.
Os subtipos podem ter subtipos aninhados que diferenciam ainda mais as ocorrências. Os subtipos nos diagramas são lógicos, mas podem ser mapeados para uma representação física de uma de três maneiras. A solidez da borda da entidade do subtipo define como o subtipo é implementado no modelo de dados do Salesforce.
As entidades de subtipo com uma borda contínua têm um objeto real que rastreia as ocorrências desse subtipo. No exemplo mostrado aqui, o subtipo Usuário externo de Contato tem uma borda sólida porque os Contatos registrados como Usuários externos são rastreados com um registro no objeto Usuário.
## Relacionamentos
Um relacionamento é uma associação nomeada e significativa entre duas entidades.
As marcações e o texto nas linhas ou ao redor delas descrevem a cardinalidade, a opcionalidade e o significado do relacionamento.
### Cardinalidade do relacionamento
A cardinalidade indica o número relativo de ocorrências em cada lado do relacionamento. Na notação, os extremos de uma linha de relacionamento indicam a cardinalidade do relacionamento naquela extremidade. O rodapé de um corno em uma extremidade indica que muitas ocorrências de entidade nessa extremidade podem se relacionar a cada ocorrência na extremidade oposta. A ausência de um rodapé em uma extremidade indica que, no máximo, uma ocorrência de entidade nessa extremidade pode se relacionar a uma determinada ocorrência na outra extremidade.
### Relacionamentos pai-filho
O Salesforce oferece suporte a dois tipos de [campos de relacionamento](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/field_types.htm#i1435823): campos de pesquisa e campos pai-filho (aka mestre-detalhes). Os campos Pai e Filho são como pesquisas obrigatórias, mas aplicam acoplamento adicional entre as entidades relacionadas. Os registros no muitos lados do relacionamento são excluídos em cascata quando o registro pai é excluído. Além disso, a visibilidade dos registros de detalhes é controlada pela visibilidade do registro pai.
Para ilustrar a diferença entre um relacionamento de filho e pai e um relacionamento de pesquisa, os ERDs do Salesforce emprestam a notação de diamante da UML. Um diamante no lado singular de um relacionamento significa que a entidade nesse lado desempenha o papel mestre no relacionamento. A entidade no lado múltiplo de um relacionamento desse tipo é a entidade de detalhe ou filha e pode ser considerada como contida na entidade pai.
### Opcionalidade de relacionamento
A opcionalidade indica se o relacionamento é obrigatório ou não para uma ocorrência em cada extremidade. Como um conceito, a opcionalidade está intimamente relacionada à cardinalidade e a notação reflete essa proximidade. A opcionalidade é indicada em cada fim de um relacionamento por meio de um círculo ou de uma barra na linha no outro fim do relacionamento. Por que no outro lado do relacionamento? Para incluir a marcação de opcionalidade no mesmo lado da linha que a cardinalidade.
No lado de muitos (ou seja, o pé do corvo) do relacionamento, há quase sempre um círculo na linha. Isso significa que pode haver ocorrências de zero para muitos no lado de muitos do relacionamento para cada ocorrência no lado singular do relacionamento.
No lado singular do relacionamento, um círculo e uma barra indicam um relacionamento opcional para a entidade no lado do rodapé do relacionamento. O círculo e a barra significam que pode haver zero ou uma ocorrência no lado singular do relacionamento para cada ocorrência no lado de muitos.
Como alternativa, no lado singular do relacionamento, as barras duplas indicam um relacionamento obrigatório para a entidade no lado múltiplo do relacionamento. As barras duplas significam que deve haver uma e apenas uma ocorrência no lado singular do relacionamento para cada ocorrência no lado de muitos.
A opcionalidade de um relacionamento pode ser mostrada conforme necessário, embora o relacionamento físico subjacente no Salesforce seja opcional. Por exemplo, o campo AccountId em Contato é fisicamente um relacionamento opcional, mas, se você ignorar Contatos privados, o relacionamento direto de um Contato com uma Conta será lógicamente obrigatório. O indicador de opcionalidade é usado com moderação. Na maioria dos casos, a opcionalidade mostrada no ERD reflete a opcionalidade subjacente do relacionamento.
### Significado do relacionamento
Além da cardinalidade e da opcionalidade, cada relacionamento entre duas entidades expressa um certo significado que distingue esse relacionamento de outros relacionamentos entre as mesmas duas entidades. Nomes de término de relacionamento, como "parte de" e "composta de" no diagrama acima, definem a natureza do relacionamento.
Quando você combina a cardinalidade, a opcionalidade e os nomes de término de um relacionamento, eles podem ser usados para formar uma frase que descreve o relacionamento.
Da esquerda para a direita: Cada (pode/deve) é (um e apenas um / um ou mais) .
Da direita para a esquerda: Cada (pode/deve) é (um e apenas um / um ou mais) .
Por exemplo,
Da esquerda para a direita: "Cada contato deve ser principalmente um contato para apenas uma conta." Da direita para a esquerda: "Cada conta pode ser representada principalmente por um ou mais Contatos."
### Codificação de cores de relacionamento
As linhas de relacionamento são codificadas por cores. Os relacionamentos adicionados pela nuvem em foco para o diagrama são desenhados em uma cor. As linhas pretas representam um relacionamento que vem com uma licença diferente da nuvem de foco.
### Relacionamentos recursivos
Os relacionamentos podem ser entre duas ocorrências da mesma entidade. Isso é chamado de relacionamento recursivo. Uma linha de relacionamento curva é usada para indicar relacionamentos recursivos.
### Relacionamentos mutuamente exclusivos
Os ERDs do Salesforce normalmente excluem a maioria das regras de negócios para se concentrar na estrutura do modelo de dados, mas um relacionamento mutuamente exclusivo é uma regra de negócios que é informativa para a estrutura, portanto, é observado. Um relacionamento mutuamente exclusivo indica que apenas um dos vários relacionamentos incluídos no arco será usado para qualquer ocorrência específica. Observe que dois, três ou mais relacionamentos podem participar do mesmo relacionamento mutuamente exclusivo. Uma frase que descreve o relacionamento mutuamente exclusivo mostrado aqui pode ser: "Cada entidade pode ser uma instância de uma e apenas uma Primeira outra entidade ou uma e apenas uma Segunda outra entidade."
Observe que, nos ERDs do Salesforce, uma linha de relacionamento quebrada que passa pelo arco não faz parte do relacionamento mutuamente exclusivo.
## Convenções de layout
Os ERDs de produto oficial do Salesforce seguem convenções de layout para melhorar a legibilidade. Essas convenções de layout incluem o seguinte:
- As linhas de relacionamento sempre devem ser diretas.
- As linhas de relacionamento devem ser desenhadas verticalmente ou horizontalmente. Em raras ocasiões em que isso não é possível, use uma linha reta em uma diagonal.
- Para manter as linhas de relacionamento diretas, as caixas de entidade podem ser redimensionadas (mais altas ou mais largas) para fornecer um ponto de aterrissagem para os relacionamentos entre as duas entidades. As entidades mais importantes (que têm mais relacionamentos disponíveis) são mostradas maiores no diagrama, reforçando sua importância.
- Ao longo de um único ERD, os pés do corno em relacionamentos devem estar consistentemente no lado esquerdo e/ou superior da linha de relacionamento (layout de cima para baixo) ou consistentemente no lado direito e/ou inferior da linha de relacionamento (layout de direita para cima). Essa convenção fornece clareza, pois resulta em entidades semelhantes reunidas na mesma área do diagrama, o que é útil para entender as entidades. Usar o layout de cima para baixo faz com que os diagramas apareçam de cima para baixo com entidades filho caindo acima ou à esquerda das entidades pai. No entanto, isso garante que as entidades mais específicas no diagrama fiquem no canto superior esquerdo do diagrama, o que torna os diagramas mais distinguíveis entre si e reconhecíveis. Usar a convenção de layout no lado direito para cima resulta em que as mesmas entidades comuns estejam no canto superior esquerdo de cada diagrama, mas as entidades filhas estarão abaixo ou à direita das entidades pai.
A estreita adesão a essas convenções de layout resulta em um diagrama limpo e fácil de ler.
Certifique-se de verificar a [galeria de modelos de dados](https://developer.salesforce.com/docs/platform/data-models/guide) para os Modelos de dados do Salesforce mais recentes que seguem esse padrão.
# Paisagem do sistema
Os diagramas de paisagem do sistema apresentam uma visão abrangente do ecossistema tecnológico de uma organização, ilustrando os relacionamentos entre produtos do Salesforce, sistemas externos e pontos de integração. Essas representações visuais ajudam os arquitetos a entender a topologia completa do sistema, identificar dependências e planejar implementações estratégicas. Eles servem como documentação essencial para as partes interessadas visualizarem como diferentes componentes interagem dentro de uma arquitetura Customer 360 e suportam objetivos de negócios.
Esta seção contém cinco diagramas de referência relacionados ao panorama do sistema:
| Nome do diagrama | Descrição |
| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [Customer 360 Marketing System Paisagem](/docs/architect/pt-br/reference-diagrams/guide/data-360-marketing) | Um panorama do sistema para uma implementação do Customer 360 Architecture. |
| [Paisagem do Sistema Agentforce](/docs/architect/pt-br/reference-diagrams/guide/einstein-system-landscape) | Uma paisagem do sistema capturando a combinação de produtos Salesforce e outros sistemas de tecnologia disponíveis com Agentforce. |
| [Sistema de varejo](/docs/architect/pt-br/reference-diagrams/guide/retail-system-landscape) | Um panorama do sistema mostrando uma solução do B2C Commerce e Marketing, indicando a combinação de produtos do Salesforce e outras tecnologias envolvidas na implementação. |
| [Hierarquia de papéis do Salesforce](/docs/architect/pt-br/reference-diagrams/guide/salesforce-role-hierarchy) | Um exemplo de hierarquia da organização, capturando um subconjunto de papéis para esclarecer a estrutura de negócios, os relacionamentos de pessoal e os padrões de acesso. |
| [Arquitetura da organização única](/docs/architect/pt-br/reference-diagrams/guide/single-org-architecture) | Um diagrama detalhando uma única estratégia da organização que dá suporte a várias unidades de negócios. |
# Paisagem do sistema Agentforce
## Descrição
Uma paisagem do sistema capturando a combinação de produtos Salesforce e outros sistemas de tecnologia disponíveis com Agentforce. Ele mostra como a camada do Trust do Einstein e a pilha de IA generativa (modelos de prompt, gateway de LLM, modelos externos, BYOM) se combinam com o Data 360 para fornecer uma base poderosa sobre a qual criar aplicativos agentes poderosos.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/28e332b9-b4d5-4780-8220-12e097f0dc58)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/einstein-system-landscape.webp)
# Paisagem do Sistema de Marketing do Customer 360
## Descrição
Este é um diagrama de paisagem do sistema para uma implementação do Customer 360, incluindo Agentforce Sales, Agentforce Service, Agentforce Commerce, Tableau e Data 360\. Ele mostra como diferentes componentes em uma solução do Salesforce integrada se comunicam entre si usando conectores nativos e conectores personalizados. Inclui recursos como entrada de dados, resolução de identidade, segmentação e ativação.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/e83190b9-5d7d-4468-aff9-882c9086e73f)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/data-360-marketing.webp)
# Paisagem do sistema de varejo
## Descrição
Um panorama do sistema que mostra uma solução B2C Commerce e Marketing, indicando a combinação de produtos Salesforce e outras tecnologias envolvidas na implementação, como MuleSoft, Data 360, Agentforce Sales, Agentforce Marketing, Agentforce Commerce e Agentforce Service. Inclui recursos como Automação de marketing, Gerenciamento de interação, Catálogo de produtos e Segmentação.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/4d6b109a-ea3e-46c2-bab6-84a07efd9ac5)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/retail-system-landscape.webp)
# Plano de liberação do Agentforce
## Descrição
Um roteiro detalhando os resultados para uma versão inicial do projeto Agentforce. Inclui estágios como Definição de projeto, Configurar e testar, Versão piloto e Versão beta.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/241905d5-9a36-451d-952a-e43390349502)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/generative-ai-release-plan.webp)
# Processamento assíncrono por meio de eventos de plataforma
## Descrição
O diagrama ilustra um fluxo de processo de interação para processamento assíncrono usando eventos de plataforma, mostrando como os eventos são publicados no barramento de eventos como parte de um padrão de arquitetura mais amplo. Esse padrão é projetado para cenários em que um processo precisa acionar o trabalho a jusante sem bloquear a transação principal, permitindo que o Salesforce lide com o trabalho pesado de modo assíncrono.
## Links para download:
- [Lucid](https://lucid.app/lucidchart/editNew/73e12d46-2c45-4d7c-bcf4-a2ca7596ed4c)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/asynchronous-processing-via-platform-events.webp)
# Processo de gerenciamento de fidelidade de hotelaria
## Descrição
As interações baseadas em tempo dos sistemas em um processo de gerenciamento de fidelidade de hotelaria. Esse fluxo rastreia o processo por meio do Agentforce Commerce, Agentforce Sales, Agentforce Platform, Data 360, Marketing Cloud Engagement, MuleSoft e fontes de dados externas.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/899f5366-4dea-4da7-81af-dc3939aece42)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/hospitality-loyalty-management-process.webp)
# Roteiro
Os diagramas do roteiro ajudam as organizações a planejar e visualizar a implementação estratégica de recursos, componentes, recursos e sistemas ao longo do tempo. Esses diagramas permitem que arquitetos e gerentes de projeto simplifiquem o planejamento de recursos, otimizem o orçamento e aprimorem a colaboração entre equipes de negócios e técnicas. Eles fornecem uma visão clara da ordem de implementação, das dependências e das prioridades, ajudando as partes interessadas a entender a abordagem em fases para entregar soluções complexas do Salesforce.
Esta seção contém seis diagramas de referência relacionados a roteiros:
| Nome do diagrama | Descrição |
| ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [Roteiro de capacidade](/docs/architect/pt-br/reference-diagrams/guide/capability-roadmap) | Um roteiro visual que simplifica o planejamento e o orçamento de recursos agrupando recursos e identificando a ordem de implementação, as dependências e o valor. |
| [Roadmap do componente](/docs/architect/pt-br/reference-diagrams/guide/component-roadmap) | Um roteiro visual que otimiza o planejamento e o orçamento de recursos identificando funcionalidades do sistema, recursos relevantes, ordem de implementação, períodos e dependências da parte interessada. |
| [Roadmap do recurso](/docs/architect/pt-br/reference-diagrams/guide/feature-roadmap) | Um roteiro visual que aprimora a colaboração entre equipes de negócios e técnicas identificando a ordem de implementação de recursos, as dependências e as funcionalidades adicionais para fins de planejamento. |
| [Agenforce Release Plan](/docs/architect/pt-br/reference-diagrams/guide/generative-ai-release-plan) | Um diagrama detalhando as entregas para uma versão inicial do projeto de IA generativa. |
| [Agentforce Roadmap](/docs/architect/pt-br/reference-diagrams/guide/generative-ai-roadmap) | Um roteiro de exemplo mostrando componentes para distribuir a IA em uma implementação do Salesforce Customer 360. |
| [Roadmap do sistema](/docs/architect/pt-br/reference-diagrams/guide/system-roadmap) | Simplifique o planejamento e o orçamento de recursos identificando a ordem de implementação do sistema, as dependências e as prioridades de recursos. |
# Roteiro de capacidade
## Descrição
Um roteiro visual que simplifica o planejamento e o orçamento de recursos agrupando recursos e identificando a ordem de implementação, as dependências e o valor.
Para cada funcionalidade neste diagrama, é comum ter um [Roadmap do componente](/docs/architect/pt-br/reference-diagrams/guide/component-roadmap) dedicado para detalhar os detalhes da entrega.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/12103374-8b95-49bb-b7ad-b0f8154ccec6)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/capability-roadmap.webp)
# Roteiro de recursos
## Descrição
Um diagrama de roteiro visual que aprimora a colaboração entre equipes de negócios e técnicas identificando a ordem de implementação do recurso, as dependências e as funcionalidades adicionais para fins de planejamento.
Esse diagrama geralmente é usado como uma exibição de detalhes de uma caixa em um [Roadmap do componente](/docs/architect/pt-br/reference-diagrams/guide/component-roadmap).
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/8e43258e-b21b-4525-87bf-8e5ba96f4032)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/feature-roadmap.webp)
# Roteiro do Agentforce
## Descrição
Um diagrama de roteiro mostrando os estágios para distribuir recursos do Agentforce em uma implementação do Salesforce Customer 360. Isso inclui estágios como _Criar padrões, Governança de modelo, Preparar dados, Estabelecer equipe_ e _Liberação e monitoramento_. Os nadadores incluem Centro de excelência, Vendas, Serviço e Desenvolvedores.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/1d9723f0-0835-4dc2-9cbb-01b2e97c91e8)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/generative-ai-roadmap.webp)
# Roteiro do componente
## Descrição
Esse diagrama contém um roteiro visual que otimiza o planejamento e o orçamento de recursos identificando funcionalidades do sistema, recursos relevantes, ordem de implementação, períodos e dependências da parte interessada.
Esse diagrama geralmente é usado como uma exibição de detalhes de uma caixa em um [Roteiro de capacidade](/docs/architect/pt-br/reference-diagrams/guide/capability-roadmap).
Para cada componente neste diagrama, é comum ter um [Roteiro de recursos](/docs/architect/pt-br/reference-diagrams/guide/feature-roadmap) dedicado para analisar os detalhes da entrega do recurso.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/2ca75fbd-af2e-45fd-a636-01255f1fb0cf)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/component-roadmap.webp)
# Roteiro do sistema
## Descrição
Um diagrama do roteiro que simplifica o planejamento e o orçamento de recursos identificando a ordem de implementação do sistema, as dependências, as áreas funcionais e os recursos relevantes para as partes interessadas.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/ead3af9a-ddc2-492a-a8c9-7ab3943fabd7)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/system-roadmap.webp)
# Verificação de reivindicação
## Descrição
Este diagrama mostra o padrão de verificação da declaração. Esse padrão publica e compromete um barramento de evento quando um registro é modificado. O corpo da mensagem do evento é armazenado em um repositório de dados separado enquanto o cabeçalho, que contém uma verificação de declaração, é passado para um assinante. O assinante então usa a verificação de declaração para recuperar o corpo da mensagem quando ela está pronta para processar as informações.
## Links para download
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/0699a470-11ca-4291-88d6-a6399142a1ca)
- [Imagem](https://architect.salesforce.com/ns-assets/reference-architectures/claim-check.webp)