Cada propuesta de consultoría en los últimos cinco años ha usado la expresión "Single Source of Truth" como si designara una tecnología concreta. No lo es. Es una decisión organizativa que, después, se implementa con tecnología. Confundir esas dos capas es el error que hace que la mayoría de proyectos que empiezan como "vamos a hacer Salesforce nuestro SSoT" terminen, año y medio después, siendo otra fuente más de dato incoherente.
Qué NO es un Single Source of Truth
Aclaremos primero lo que no es, porque casi todo lo que se etiqueta así en presentaciones no lo es:
- No es un data warehouse. Un warehouse guarda copias históricas del dato para analítica; el SSoT es la fuente contra la que el negocio opera en vivo. Son cosas complementarias, no equivalentes.
- No es la aplicación que más gente usa. Salesforce puede ser el CRM más usado de la empresa y no ser el SSoT del cliente si el dato canónico realmente vive en el ERP o en una plataforma propietaria.
- No es un dashboard. Un dashboard consume el SSoT; no lo es.
- No es una promesa de "todo en un sitio". Los datos siguen viviendo en muchos sistemas. El SSoT es el sitio que dice cuál de las versiones cuenta cuando dos discrepan.
Qué es realmente: un contrato de dato
Un SSoT es, sin adornos, un acuerdo explícito de la organización sobre qué sistema tiene la palabra final para cada entidad del negocio. Cliente, pedido, factura, contrato, punto de venta, empleado. Para cada uno de esos, hay un sistema que manda; los demás lo consultan y lo alimentan, pero no discuten con él.
Ese acuerdo es primero organizativo y luego técnico. Antes de comprar una plataforma, alguien en la empresa tiene que poder decir en voz alta: "el dato del cliente lo mantiene el CRM; el dato del pedido lo mantiene el ERP; el dato del abonado lo mantiene la plataforma X". Sin esa decisión, ningún proyecto de integración termina en un SSoT — termina en más copias.
El SSoT es una decisión organizativa que después se implementa con tecnología, no al revés.
Por qué Salesforce como SSoT (y cuándo no)
Salesforce es un candidato natural a SSoT cuando la entidad canónica es el cliente, entendido en toda su relación con la empresa: interacción comercial, servicio, facturación, marketing, incidencias, contratos, campañas. Eso es exactamente lo que Salesforce está diseñado para modelar y donde su modelo de datos escala sin sorpresas.
Salesforce es un mal candidato cuando la entidad canónica es operacional: producción, inventario físico, activos, logística fina, contabilidad interna. Esos datos suelen vivir mejor en el ERP o en sistemas verticales especializados, con Salesforce consultándolos cuando el negocio los necesita.
Traducido a decisión práctica: si tu pregunta como CTO es "¿quién tiene la última palabra sobre este cliente?", la respuesta suele ser Salesforce. Si es "¿quién tiene la última palabra sobre esta unidad de inventario en el almacén?", suele no serlo — y forzarlo produce un modelo de datos artificial que envejece mal.
Data Cloud vs sincronización tradicional: cuándo cada uno
Cuando la decisión organizativa es "Salesforce como SSoT del cliente", aparecen dos caminos que a menudo se confunden:
Sincronización tradicional (MuleSoft + Sales/Service Cloud)
Los sistemas externos alimentan Salesforce con eventos, batches o APIs a través de MuleSoft, y Salesforce funciona como el registro operativo del cliente. Es el camino más maduro, funciona sobre cualquier stack, y es el adecuado cuando la volumetría es la de un CRM operacional — miles a cientos de miles de registros por entidad — y el objetivo es que el equipo comercial, de servicio y de marketing trabajen contra una foto única del cliente.
Salesforce Data Cloud
Está diseñado específicamente para agregar dato del cliente desde múltiples fuentes a escala masiva (millones de perfiles, dato de comportamiento, eventos en volumen), unificarlos con un motor de resolución de identidad, y proyectar segmentos hacia herramientas de activación. Encaja cuando el problema es tratar al cliente como un perfil enriquecido con dato de comportamiento — para personalización, para segmentación avanzada, para activación cross-canal — no solo como registro comercial.
En muchas empresas se combinan: MuleSoft alimenta a Salesforce (operativo) y Data Cloud a la vez (analítico + activación). Data Cloud no sustituye la sincronización operativa — la complementa. Cambiar una por otra por moda es uno de los errores más caros que hemos visto en presupuestos B2B.
Las tres decisiones que hay que tomar antes de arrancar
Cualquier iniciativa de SSoT que no haya cerrado estas tres antes de firmar un proyecto termina en reingeniería seis meses después:
- Qué entidades son canónicas y en qué sistema. No genérico — específico. "El cliente vive en Salesforce; el pedido en el ERP; el activo físico en el sistema X." Esta lista, escrita en una pizarra, es el primer entregable del proyecto.
- Cómo se resuelve un conflicto entre dos sistemas. Alguien tiene que decidir la regla: gana el más reciente; gana el sistema fuente; gana el humano que interviene. Sin regla explícita, cada integración inventa la suya en silencio, y a los seis meses no hay dos que se comporten igual.
- Quién es dueño del dato en la organización. No "el sistema" — la persona. El data owner es quien decide cuando dos áreas discrepan. Sin nombre y apellido, el proyecto se atasca en la primera excepción y no vuelve a moverse hasta la siguiente reorganización.
El error más caro: convertir el SSoT en un proyecto "todo o nada"
El error clásico es planificar el SSoT como una entrega única de 18 meses en la que un día se apaga el mundo antiguo y se enciende el nuevo. Nunca funciona: las integraciones legacy sobreviven, aparecen datos que nadie había mapeado, y el cambio organizativo no viaja al ritmo del cambio técnico.
El patrón que sí funciona es entidad a entidad: se empieza por la más obvia y la que más duele — casi siempre el cliente — se conecta un sistema, se demuestra que la nueva foto es más fiable que la antigua, y se avanza. En seis a doce meses hay una capa funcionando; el cambio organizativo llega detrás, pero llega apoyado en algo que ya está entregando valor visible al negocio.
Un SSoT bien construido no es un proyecto: es una infraestructura. Y las infraestructuras se construyen por partes, con presupuesto renovable, con cortes claros de valor cada pocos meses. Cualquier propuesta que te venda lo contrario merece una segunda opinión antes de firmar.
¿Estás valorando Salesforce como SSoT en tu organización? — En Eme Integrations diseñamos la arquitectura y la implementamos con MuleSoft. Hablemos.