O inventário real de ferramentas do Data Cloud (e por que ninguém usa todas de uma vez)
Data Streams, DMOs, Identity Resolution, Data Spaces, Calculated Insights: entenda o que cada peça faz e onde ela costuma quebrar em projeto
Data Cloud não é um produto que você liga, é uma pilha de ferramentas que precisa ser orquestrada com decisão de arquitetura. Um mapa prático de cada peça, do Setup Menu à Data Ingestion API, com a leitura de quem já bateu cabeça com identity resolution mal configurada.
Todo projeto de Data Cloud começa do mesmo jeito: alguém no cliente ouve falar de Customer 360, acha que é um botão de "unificar dados" e descobre, na segunda reunião de discovery, que na verdade está lidando com uma pilha de ferramentas que precisa de decisão de arquitetura antes de qualquer ingestão de dado. Não é crítica, é a natureza do produto. Data Cloud não é um conector, é uma plataforma de dados que mora dentro do ecossistema Salesforce, e tratar isso como um simples "habilitar feature" é o erro mais comum que vejo em projetos que depois viram retrabalho caro.
Vale abrir um parêntese: a Salesforce renomeou Data Cloud para Data 360 em outubro de 2025, dentro do pacote Agentforce 360. O nome novo importa principalmente para quem está pensando em RAG e grounding de agentes de IA na própria base de dados da empresa, mas no dia a dia de projeto o time ainda fala "Data Cloud", e é assim que vou tratar aqui.
O que cada peça faz (e quando você realmente usa)
- Data Cloud Setup Menu: é onde nascem as decisões estruturais, criação de Data Spaces, conexão de fontes, controle de permissão. É o primeiro lugar onde o time de implementação passa tempo de verdade, antes de qualquer mapeamento. Decisão tomada errado aqui vira dor de cabeça em produção.
- Data Cloud Console: o workspace unificado do dia a dia, onde você monitora streams, ajusta segmentos e revisa Calculated Insights sem ficar pulando entre telas. Na operação contínua, é aqui que a mão suja mesmo.
- Data Kits: pacotes pré-configurados com mapeamentos, insights e segmentos prontos para indústrias como varejo ou serviços financeiros. Ajudam a não reinventar a roda em casos de uso padrão, mas não espere que resolvam a complexidade real do seu negócio sem ajuste fino.
- Data Actions: disparam resposta em tempo real quando uma condição é atingida no dado unificado, tipo notificar o vendedor quando um lead de alto valor volta a interagir. É a diferença entre um dado que você só olha em dashboard e um dado que gera ação automática.
- Data Streams: o ponto de entrada de dado, conectando Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud e fontes externas como Snowflake, S3, Google Cloud Storage e APIs, em modo agendado ou quase real-time.
- Data Model Objects (DMOs): a camada de padronização. Se um sistema chama de "customer" e outro chama de "cliente", é o DMO que faz esse dado conversar sem retrabalho manual. É aqui que o Data 360 entrega o valor real de unificação, transformando ingestão bruta em modelo semântico consistente que toda a org consegue consumir, seja em um Flow Approval Process, seja em uma automação do Agentforce Revenue Management.
Cada peça dessas resolve um problema específico, e a armadilha comum é tratar Data Cloud como uma ferramenta única quando na verdade é um conjunto de capacidades que precisa ser orquestrado com intenção. Antes de sair criando Data Stream para tudo que existe, pergunte qual decisão de negócio aquele dado vai suportar. Sem essa pergunta, você acumula complexidade sem gerar valor.
Quem está avaliando ou já vendeu Data Cloud precisa entender que o produto não entrega valor por si só: ele entrega valor pela forma como Data Streams, DMOs, Identity Resolution e Data Spaces são combinados. Isso muda a conversa comercial, muda o escopo de discovery e muda quem deve estar na mesa desde o dia um (spoiler: precisa de arquiteto de dados, não só de admin).
Vale reforçar: Data Cloud não roda em sandbox tradicional, só em produção ou em trial edition. Isso muda a estratégia de teste e validação do projeto, e é um detalhe que muita proposta comercial esquece de mencionar até o cliente perguntar como vai testar antes de ir para produção.
Antes de tocar em Data Stream, sente com o cliente e mapeie: quantas fontes de dado existem, se há necessidade de Data Spaces (múltiplas marcas, unidades de negócio, regiões) e que regras de Identity Resolution fazem sentido para o negócio. Documente isso antes de configurar qualquer DMO, porque mapeamento errado nessa fase é caro de corrigir depois que o dado já está fluindo.
Use Data Kits como ponto de partida quando o caso de uso for padrão de mercado (varejo, serviços financeiros), mas trate como esqueleto, não como solução pronta. E treine o time de negócio em Trailhead e Salesforce Help antes do go-live, porque Data Cloud evolui rápido e ninguém quer descobrir uma feature nova via ticket de suporte.
O erro mais caro em Data Cloud não é técnico, é de sequenciamento: times que tentam configurar Identity Resolution ou Calculated Insights antes de fechar a modelagem de DMOs e a estratégia de Data Spaces. Corrigir identity resolution mal configurada depois que o dado já foi unificado é retrabalho sério, às vezes envolve reprocessar tudo.
Outro ponto de atenção: Data Cloud não roda em sandbox, então a estratégia de teste precisa ser pensada com trial edition ou ambiente de produção controlado, isso raramente está no radar de quem está estimando o projeto pela primeira vez.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.