Arquitetura de CRM
Arquitetura Salesforce e CRM que suporta
a organização mesmo daqui a dois anos.
Planeamento arquitetónico completo — Solution, Data, Security, Automation, Integration e Environment — para que o sistema funcione hoje e possa continuar a crescer.
Para quem é o serviço
Quando é que é o momento certo para trazer um arquiteto Salesforce
- Organizações que planeiam a primeira implementação de Salesforce.
- Sistemas existentes que perderam a ordem e a arquitetura claras.
- Organizações que planeiam integrações profundas com ERP, finanças ou BI.
- Equipas de CRM que querem reduzir a dívida técnica antes de uma nova fase.
Problemas que o serviço resolve
Os sinais de que o sistema perdeu a sua arquitetura
Campos que se acumularam sem modelo
Após dois a três anos, cada departamento adicionou os seus próprios campos. O resultado: objetos com mais de 300 campos, relatórios não fiáveis e automações que falham. A arquitetura define a propriedade, as regras de adição e o ciclo de vida de cada campo.
Automações que se contradizem umas às outras
Flow, Process Builder e Trigger a correr em paralelo no mesmo evento. Unimos para uma camada de automação com uma ordem de execução previsível.
Permissões que se tornaram uma falha de segurança
Perfis que foram abertos 'temporariamente' há dois anos e permaneceram abertos. Construímos um modelo baseado em Permission Sets e funções reais.
Integrações sem proprietário
Quando alguém sai, ninguém sabe como funcionam. A arquitetura inclui documentação, registos e responsabilidade clara para cada conexão.
Camadas
As camadas de arquitetura que iremos planear
Solution Architecture
Alinhamento entre os processos centrais da organização e os produtos Salesforce, incluindo a priorização do que entra na primeira versão e o que fica para fases futuras.
Data Architecture
Modelo de objetos e relações, fontes da verdade, regras de qualidade de dados e um plano para limpar e unificar registos existentes.
Security & Sharing
Perfis, funções, grupos públicos, modelo de partilha, campos protegidos e política de acesso a informações sensíveis.
Automation Architecture
Escolha consciente entre Flow, Apex e automações assíncronas, evitando automações paralelas no mesmo evento.
Integration Architecture
Direções de fluxo, técnicas (REST, Events, Middleware), tratamento de erros e registos para integrações de negócios críticas.
Environment & Release
Estrutura de Sandboxes, método de trabalho para implementações, backups, gestão de versões e operações de manutenção contínuas.
Princípios de Trabalho
Princípios que guiam cada decisão
- Configuração antes do código — desenvolvimento personalizado apenas quando não há uma forma mais simples.
- Cada alteração arquitetónica é documentada e aprovada.
- Um modelo de permissões simples e claro, mesmo que à custa de alguma flexibilidade.
- Não há duas automações a decorrer em paralelo para o mesmo evento.
- Cada integração inclui um registo, tratamento de erros e um âmbito de responsabilidade claro.
- Uma nova implementação passa por Sandbox antes de Produção.
Environments
Estrutura de ambientes recomendada
Developer
Para o desenvolvimento diário, livre de dados reais.
Integration / QA
Para testes de sistema e testes de integração entre componentes.
UAT
Cópia com dados simulados de produção para testes de aceitação do utilizador.
Staging / Pre-Prod
Ambiente de ensaios para Go Live e correções de Hotfix.
Production
O ambiente de produção, apenas com um processo de implementação ordenado.
Ponto de decisão
Submeter a sua arquitetura para revisão
Uma breve conversa ajuda a entender se é necessário um novo design de arquitetura ou um Refactor específico para componentes críticos.
Considerações para a decisão
Quatro decisões que determinam a estabilidade do sistema
Multi-Org ou Single-Org
Quando é que uma separação para uma organização separada é preferível a uma utilização inteligente de Record Types e Sharing? Uma decisão com implicações a longo prazo.
Master Data Management
O Salesforce é a Fonte de Verdade para os 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 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 que processo. Sem essa política, qualquer sistema enche-se de campos desnecessários dentro de um ano.
O que vai receber
Resultados possíveis do serviço
Documento de Arquitetura
Solution + Data + Security + Integrations, com um nível de detalhe que permite o desenvolvimento.
Mapa de Integrações
Sentidos de fluxo, técnica, tipo de evento e cenários de falha para cada conexão essencial.
Modelo de Dados
Objetos, relações, campos chave e regras de qualidade iniciais.
Modelo de permissões
Perfis, funções e política de partilha que se adequam à estrutura da organização.
Erros comuns
Padrões a evitar
- Dar a cada departamento o seu próprio modelo de dados, sem uma visão organizacional abrangente.
- Construir automatizações em Flow e código simultaneamente no mesmo evento.
- Implementar diretamente para Produção sem passar por um Sandbox.
- Deixar perfis "temporários" com All Modify Data e não voltar a eles.
- Desenvolver uma integração pontual sem documentá-la - torna-se uma caixa preta em meses.
Guias e serviços relacionados
Aprofundar o centro de conhecimento
27. Perguntas frequentes