Arquitectura de CRM
Arquitectura de Salesforce y CRM que da soporte
a la organización incluso dentro de dos años.
Diseño completo de la arquitectura —Solución, Datos, Seguridad, Automatización, Integración y Entorno— para que el sistema funcione hoy y pueda seguir creciendo.
Para quién es este servicio
Cuándo es oportuno contratar a un arquitecto de Salesforce
- Organizaciones que planifican su primera implementación de Salesforce.
- Sistemas existentes que han perdido el orden y una arquitectura clara.
- Organizaciones que planean integraciones profundas con ERP, finanzas o BI.
- Equipos de CRM que desean reducir la deuda técnica antes de una nueva fase.
Problemas que resuelve el servicio
Señales de que el sistema ha perdido su arquitectura
Campos acumulados sin modelo
Después de dos o tres años, cada departamento ha añadido sus propios campos. El resultado: objetos con más de 300 campos, informes poco fiables y automatizaciones que fallan. La arquitectura define la propiedad, las reglas de adición y el ciclo de vida de cada campo.
Automatizaciones que se contradicen
Flow, Process Builder y Trigger ejecutándose en paralelo sobre el mismo evento. Unificamos a una sola capa de automatización con un orden de ejecución predecible.
Permisos que se convirtieron en una brecha de seguridad
Perfiles que se abrieron "temporalmente" hace dos años y se quedaron abiertos. Construimos un modelo basado en Permission Sets y roles reales.
Integraciones sin propietario
Cuando alguien se va, nadie sabe cómo funcionan. La arquitectura incluye documentación, registros y responsabilidad clara para cada conexión.
Capas
Capas de la arquitectura que diseñaremos
Solution Architecture
Coherencia entre los procesos centrales de la organización y los productos de Salesforce, incluyendo priorización de lo que entra en la primera versión y lo que queda para fases futuras.
Data Architecture
Modelo de objetos y relaciones, fuentes de verdad, reglas de calidad de datos y un plan para limpiar y unificar registros existentes.
Security & Sharing
Perfiles, roles, grupos públicos, modelo de compartición, campos protegidos y política de acceso a información sensible.
Automation Architecture
Elección consciente entre Flow, Apex y automatizaciones asíncronas, evitando automatizaciones paralelas sobre el mismo evento.
Integration Architecture
Direcciones de flujo, técnicas (REST, Events, Middleware), manejo de errores y registros para integraciones comerciales críticas.
Environment & Release
Estructura de Sandboxes, método de trabajo para despliegues, copias de seguridad, gestión de versiones y operaciones de mantenimiento rutinarias.
Principios de trabajo
Principios que guían cada decisión
- Configuración antes que código — Desarrollo personalizado solo cuando no hay una forma más sencilla.
- Todo cambio arquitectónico documentado y aprobado.
- Un modelo de permisos simple y claro, incluso a costa de un poco de flexibilidad.
- No hay dos automatizaciones ejecutándose simultáneamente sobre el mismo evento.
- Cada integración incluye un registro, gestión de errores y un ámbito de responsabilidad claro.
- Una nueva implementación pasa por Sandbox antes de Production.
Environments
Estructura de entornos recomendada
Developer
Para el desarrollo diario, limpio de datos reales.
Integration / QA
Para pruebas de sistema y pruebas de integración entre componentes.
UAT
Una copia con datos de simulación de producción para pruebas de aceptación con los usuarios.
Staging / Pre-Prod
Entorno de "ensayo" para el Go Live y correcciones de Hotfix.
Production
El entorno de producción, solo con un proceso de implementación ordenado.
Punto de decisión
Envíe su arquitectura para revisión
Una breve conversación ayuda a comprender si se necesita un nuevo diseño de arquitectura o una refactorización puntual de componentes críticos.
Consideraciones de decisión
Cuatro decisiones que determinan la estabilidad del sistema
Multi-Org o Single-Org
¿Cuándo es preferible una separación en una organización diferente a un uso inteligente de Record Types y Sharing? Una decisión con implicaciones a largo plazo.
Master Data Management
¿Es Salesforce la fuente de la verdad para los clientes, o la verdad reside en el ERP? La respuesta determina la dirección del flujo de cada integración.
Estrategia de automatización
Cuándo usar Flow, cuándo Apex, cuándo Platform Events. Una elección incorrecta crea un sistema difícil de mantener.
Política de campos personalizados
Quién está autorizado a añadir un campo y mediante qué proceso. Sin esta política, cualquier sistema se llena de campos innecesarios en un año.
Qué obtendrá
Posibles entregables del servicio
Documento de arquitectura
Solución + Datos + Seguridad + Integraciones, con un nivel de detalle que permite el desarrollo.
Mapa de integraciones
Direcciones de flujo, técnica, tipo de evento y escenarios de fallo para cada conexión significativa.
Modelo de datos
Objetos, relaciones, campos clave y reglas de calidad primarias.
Modelo de permisos
Perfiles, roles y política de compartición que se ajusten a la estructura de la organización.
Errores comunes
Patrones a evitar
- Dar a cada departamento su propio modelo de datos sin una visión interdepartamental.
- Construir automatizaciones en Flow y en código simultáneamente sobre el mismo evento.
- Desplegar directamente a Producción sin pasar por Sandbox.
- Dejar perfiles 'temporales' con 'All Modify Data' y no volver a ellos.
- Desarrollar una integración a medida sin documentarla, que se convierte en una caja negra en cuestión de meses.
Guías y servicios relacionados
Profundizar en el centro de conocimiento
Preguntas frecuentes
Arquitectura CRM — Preguntas frecuentes
El siguiente paso