Arquitetura CRM
Arquitetura CRM e Salesforce que suporta
a organização também daqui a dois anos.
Planejamento completo de arquitetura — solução, dados, segurança, automação, integração e ambientes — para que o sistema funcione hoje e possa continuar crescendo.
Para quem é
Quando faz sentido incorporar um arquiteto de Salesforce
- Organizações que planejam sua primeira implementação de Salesforce.
- Sistemas existentes que perderam ordem e uma arquitetura clara.
- Organizações que planejam integrações profundas com ERP, finanças ou BI.
- Equipes de CRM que buscam reduzir a dívida técnica antes de uma nova fase.
Problemas que este serviço resolve
Os sinais de que um sistema perdeu sua arquitetura
Campos acumulados sem um modelo
Após dois ou três anos, cada departamento adicionou seus próprios campos. O resultado: objetos com mais de 300 campos, relatórios pouco confiáveis e automações que falham. A arquitetura define responsáveis, regras de criação e um ciclo de vida para cada campo.
Automações que se contradizem
Flow, Process Builder e triggers executando em paralelo sobre o mesmo evento. Consolidamos em uma única camada de automação com uma ordem de execução previsível.
Permissões que se tornaram um buraco de segurança
Perfis abertos 'temporariamente' há dois anos e nunca fechados. Construímos um modelo baseado em permission sets e papéis reais.
Integrações sem responsável
Quando alguém sai, ninguém sabe como funcionam. A arquitetura inclui documentação, registros e responsabilidade clara para cada conexão.
Camadas
As camadas de arquitetura que projetamos
Arquitetura de solução
Alinhamento dos processos de negócio chave com os produtos Salesforce, incluindo a priorização do que entra na primeira versão versus fases posteriores.
Arquitetura de dados
Modelo de objetos e relacionamentos, fontes de verdade, regras de qualidade de dados e um plano de limpeza e consolidação de registros existentes.
Segurança e compartilhamento
Perfis, papéis, grupos públicos, modelo de compartilhamento, campos protegidos e política de acesso a informações sensíveis.
Arquitetura de automação
Escolha deliberada entre Flow, Apex e automação assíncrona, evitando automatizações paralelas que são disparadas pelo mesmo evento.
Arquitetura de integração
Direções de fluxo, técnicas (REST, eventos, middleware), tratamento de erros e registro para integrações críticas de negócio.
Ambientes e releases
Estrutura de sandboxes, uma metodologia de implantação, backups, gestão de versões e operações de manutenção contínua.
Princípios de trabalho
Princípios que guiam cada decisão
- Configuração antes do código: desenvolvimento sob medida apenas quando não há uma maneira mais simples.
- Toda alteração arquitetônica é documentada e aprovada.
- Um modelo de permissões simples e claro, mesmo à custa de alguma flexibilidade.
- Nunca duas automações são executadas em paralelo sobre o mesmo evento.
- Toda integração inclui registro, tratamento de erros e uma área de responsabilidade clara.
- Toda nova implantação passa por sandbox antes da produção.
Ambientes
Estrutura de ambientes recomendada
Developer
Para desenvolvimento diário, sem dados reais.
Integration / QA
Para testes de sistema e integração entre componentes.
UAT
Uma cópia similar à produção para testes de aceitação com usuários.
Staging / Pre-Prod
Um ambiente de ensaio para o Go Live e correções urgentes.
Produção
O ambiente em produção, com um processo de implantação unicamente controlado.
Ponto de decisão
Revise sua arquitetura
Uma breve chamada ajuda a esclarecer se você precisa de um novo planejamento de arquitetura ou de uma refatoração específica de componentes críticos.
Fatores de decisão
Quatro decisões que determinam a estabilidade do sistema
Multi-org vs. org único
Quando é preferível separar para um org distinto em vez do uso inteligente de record types e sharing. Uma decisão com consequências a longo prazo.
Gestão de dados mestres (MDM)
É o Salesforce a fonte da verdade dos clientes, ou a verdade reside no ERP? A resposta determina a direção do fluxo de cada integração.
Estratégia de automação
Quando usar Flow, quando Apex, quando Platform Events. Uma escolha errada cria um sistema difícil de manter.
Política de campos personalizados
Quem está autorizado a adicionar um campo e através de qual processo. Sem essa política, qualquer sistema se enche de campos desnecessários em um ano.
O que você obtém
Possíveis entregáveis do serviço
Documento de arquitetura
Solução + dados + segurança + integrações, com detalhes suficientes para habilitar o desenvolvimento.
Mapa de integrações
Direção do fluxo, técnica, tipo de evento e cenários de falha para cada conexão crítica.
Modelo de dados
Objetos, relacionamentos, campos chave e regras de qualidade iniciais.
Modelo de permissões
Perfis, papéis e uma política de compartilhamento de acordo com a estrutura da organização.
Erros comuns
Padrões que convém evitar
- Permitir que cada departamento tenha seu próprio modelo de dados sem uma visão transversal.
- Construir automações em Flow e em código em paralelo sobre o mesmo evento.
- Implantar diretamente na produção sem passar por sandbox.
- Deixar perfis 'temporários' com 'All Modify Data' sem nunca revisá-los.
- Construir uma integração pontual sem documentá-la; ela se torna uma caixa preta em poucos meses.
Guias e serviços relacionados
Aprofunde-se no centro de conhecimento
Perguntas frequentes
Arquitetura CRM — perguntas habituais
O que inclui uma boa arquitetura de CRM?
Quando é necessário um arquiteto de Salesforce dedicado?
É possível melhorar a arquitetura de um sistema existente?
Quanto tempo leva para planejar a arquitetura de CRM?
A arquitetura de CRM se limita ao Salesforce?
Próximo passo
Valide sua arquitetura antes de construir
Revisaremos juntos seu modelo de dados, permissões e integrações, e indicaremos as decisões que convém definir o quanto antes.
Próximo passo