Arquitectura CRM
Arquitectura CRM y Salesforce que sostiene
a la organización también dentro de dos años.
Planificación completa de arquitectura — solución, datos, seguridad, automatización, integración y entornos — para que el sistema funcione hoy y pueda seguir creciendo.
Para quién es
Cuándo tiene sentido incorporar un arquitecto de Salesforce
- Organizaciones que planifican su primera implementación de Salesforce.
- Sistemas existentes que han perdido orden y una arquitectura clara.
- Organizaciones que planifican integraciones profundas con ERP, finanzas o BI.
- Equipos de CRM que buscan reducir deuda técnica antes de una nueva fase.
Problemas que resuelve este servicio
Las señales de que un sistema ha perdido su arquitectura
Campos acumulados sin un modelo
Tras 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 responsables, reglas de alta y un ciclo de vida para cada campo.
Automatizaciones que se contradicen entre sí
Flow, Process Builder y triggers ejecutándose en paralelo sobre el mismo evento. Consolidamos en una única capa de automatización con un orden de ejecución predecible.
Permisos convertidos en un agujero de seguridad
Perfiles abiertos 'temporalmente' hace dos años y nunca cerrados. Construimos un modelo basado en permission sets y roles reales.
Integraciones sin responsable
Cuando alguien se marcha, nadie sabe cómo funcionan. La arquitectura incluye documentación, registros y responsabilidad clara para cada conexión.
Capas
Las capas de arquitectura que diseñamos
Arquitectura de solución
Alineación de los procesos de negocio clave con los productos de Salesforce, incluida la priorización de lo que entra en la primera versión frente a fases posteriores.
Arquitectura de datos
Modelo de objetos y relaciones, fuentes de verdad, reglas de calidad de datos y un plan de limpieza y consolidación de registros existentes.
Seguridad y sharing
Perfiles, roles, grupos públicos, modelo de sharing, campos protegidos y política de acceso a información sensible.
Arquitectura de automatización
Elección deliberada entre Flow, Apex y automatización asíncrona, evitando automatizaciones paralelas que se disparan sobre el mismo evento.
Arquitectura de integración
Direcciones de flujo, técnicas (REST, eventos, middleware), manejo de errores y registro para integraciones críticas de negocio.
Entornos y releases
Estructura de sandboxes, una metodología de despliegue, copias de seguridad, gestión de versiones y operaciones de mantenimiento continuo.
Principios de trabajo
Principios que guían cada decisión
- Configuración antes que código: desarrollo a medida solo cuando no hay una vía más sencilla.
- Todo cambio arquitectónico queda documentado y aprobado.
- Un modelo de permisos simple y claro, incluso a costa de algo de flexibilidad.
- Nunca dos automatizaciones se ejecutan en paralelo sobre el mismo evento.
- Toda integración incluye registro, manejo de errores y un área de responsabilidad clara.
- Todo nuevo despliegue pasa por sandbox antes de producción.
Entornos
Estructura de entornos recomendada
Developer
Para el desarrollo diario, sin datos reales.
Integration / QA
Para pruebas de sistema e integración entre componentes.
UAT
Una copia similar a producción para pruebas de aceptación con usuarios.
Staging / Pre-Prod
Un entorno de ensayo para el Go Live y las correcciones urgentes.
Producción
El entorno en vivo, con un proceso de despliegue únicamente controlado.
Punto de decisión
Revise su arquitectura
Una llamada breve ayuda a aclarar si necesita nueva planificación de arquitectura o una refactorización específica de componentes críticos.
Factores de decisión
Cuatro decisiones que determinan la estabilidad del sistema
Multi-org frente a org único
Cuándo es preferible separar en un org distinto frente al uso inteligente de record types y sharing. Una decisión con consecuencias a largo plazo.
Gestión de datos maestros (MDM)
¿Es Salesforce la fuente de verdad de los clientes, o reside la verdad en el ERP? La respuesta determina la dirección del flujo de cada integración.
Estrategia de automatización
Cuándo Flow, cuándo Apex, cuándo Platform Events. Una elección equivocada 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 esa política, cualquier sistema se llena de campos innecesarios en un año.
Qué obtiene
Posibles entregables del servicio
Documento de arquitectura
Solución + datos + seguridad + integraciones, con el detalle suficiente para habilitar el desarrollo.
Mapa de integraciones
Dirección del flujo, técnica, tipo de evento y escenarios de fallo para cada conexión crítica.
Modelo de datos
Objetos, relaciones, campos clave y reglas de calidad iniciales.
Modelo de permisos
Perfiles, roles y una política de sharing acorde a la estructura de la organización.
Errores habituales
Patrones que conviene evitar
- Permitir que cada departamento tenga su propio modelo de datos sin una visión transversal.
- Construir automatizaciones en Flow y en código en paralelo sobre el mismo evento.
- Desplegar directamente a producción sin pasar por sandbox.
- Dejar perfiles 'temporales' con All Modify Data sin revisarlos nunca.
- Construir una integración puntual sin documentarla; se convierte en una caja negra en pocos meses.
Guías y servicios relacionados
Profundice en el centro de conocimiento
Preguntas frecuentes
Arquitectura CRM — preguntas habituales
¿Qué incluye una buena arquitectura CRM?
¿Cuándo se necesita un arquitecto de Salesforce dedicado?
¿Se puede mejorar la arquitectura de un sistema existente?
¿Cuánto se tarda en planificar la arquitectura CRM?
¿La arquitectura CRM se limita a Salesforce?
Siguiente paso
Valide su arquitectura antes de construir
Revisaremos juntos su modelo de datos, permisos e integraciones, y señalaremos las decisiones que conviene fijar cuanto antes.
Siguiente paso