La respuesta breve
La "Source of Truth" (Fuente Única de Verdad) no es una cuestión técnica, sino de autoridad: ¿quién en la organización está facultado para determinar que un valor específico es correcto? Cuando esta decisión no se toma explícitamente, se hace en silencio, por quien escribió la última integración.
La regla central: la propiedad se define a nivel de campo, no a nivel de sistema. El intento de declarar "el ERP es la fuente de verdad para el cliente" se rompe en el momento en que el departamento de servicio actualiza un número de teléfono en Salesforce y la sincronización nocturna borra la actualización.
Tres preguntas que definen la propiedad
Para cada entidad, y luego para cada grupo de campos, se pregunta: ¿dónde se creó el dato por primera vez, quién está autorizado a nivel de negocio para modificarlo, y quién asume la responsabilidad cuando este es erróneo? En los tres casos, la respuesta debe ser el nombre de un rol, no el nombre de un sistema. El sistema se deriva del rol.
Cuando las respuestas apuntan a dos roles distintos, es casi siempre una señal de que dos campos diferentes se han fusionado en uno.
Matriz de propiedad de ejemplo
| Entidad / Campo | Fuente de Verdad | Salesforce | Dirección de Sincronización |
|---|---|---|---|
| Razón social, NIF, Condiciones de pago | ERP | Solo lectura | ERP → Salesforce |
| Contacto, Cargo, Preferencias | Salesforce | Edición | Salesforce → Sistemas de Marketing |
| Catálogo de productos y lista de precios base | ERP / PIM | Solo lectura | ERP → Salesforce |
| Oferta y descuento aprobado | Salesforce | Edición | Salesforce → ERP |
| Pedido aprobado y estado de entrega | ERP | Solo lectura | ERP → Salesforce |
| Saldo deudor y estado de cobro | Sistema financiero | Solo lectura | Financiero → Salesforce |
| Actividad, Casos y Comunicación | Salesforce | Edición | Sin sincronización externa |
Esta tabla es el producto final. Es concisa, reside en un único documento, y cada nueva integración se verifica contra ella antes de su desarrollo.
Separación entre presentación y autoridad
Gran parte de la tensión entre sistemas desaparece cuando se comprende que presentar un dato no requiere copiarlo. Un saldo deudor que se muestra a un vendedor no tiene por qué ser un campo en Salesforce que se actualiza cada noche; puede ser una vista remota o una capa de federación.
Cada campo que se copia implica un compromiso operativo: sincronización, fallos, discrepancias y tiempo. Antes de copiar, pregunte si se requiere automatización o informes históricos sobre él. Si no, es preferible mostrarlo y no copiarlo. Una ampliación sobre este enfoque se encuentra en Zero Copy y Federation en Data 360.
Conflictos: decidir de antemano, no en tiempo real
Incluso cuando la propiedad está clara, surgen situaciones de actualización concurrente. Tres reglas posibles son: prioridad del sistema (el propietario siempre prevalece), marca de tiempo más reciente, o marcaje para gestión manual. La tercera regla es la más segura para campos sensibles, siempre que exista una cola de tratamiento con un responsable, y no un registro de log que se pierda.
Escenario: una organización con dos verdades para una misma dirección
Una empresa de servicios de infraestructura gestionaba la dirección de un cliente en dos sistemas: el ERP para fines de facturación y un sistema de servicio de campo para la llegada de técnicos. Ambos se sincronizaban bidireccionalmente con Salesforce. El resultado: una dirección que oscilaba entre versiones, y técnicos que llegaban a la dirección de facturación.
La solución no consistió en corregir la sincronización, sino en desglosar la entidad. Se definieron dos campos separados: dirección de facturación bajo la propiedad del ERP, y dirección de servicio bajo la propiedad del sistema de campo; ambos en modo de solo lectura en Salesforce, con un enlace para solicitar cambios que se dirigía al propietario correcto. El número de solicitudes de servicio cerradas por "dirección incorrecta" disminuyó significativamente en el siguiente trimestre.
La lección: cuando los sistemas "luchan" por un campo, generalmente se trata de dos datos de negocio distintos que recibieron el mismo nombre.
Implentación: del documento a la realidad
Una matriz de propiedad solo es efectiva si se implementa en tres puntos: Seguridad a nivel de campo (Field-Level Security) que impide la edición por parte de quien no es el propietario, un usuario de integración con permisos restringidos solo a los campos de su propiedad, y un informe mensual que muestre los campos actualizados en contra de la política. El tercer informe es el que revela integraciones antiguas que nadie recuerda.
La documentación del significado de cada campo se conecta directamente con el Mapeo de Datos para Migración.
Riesgos comunes y acciones preventivas
| Riesgo | Cómo se manifiesta en la práctica | Acción preventiva |
|---|---|---|
| Propiedad a nivel de sistema | Contradicciones dentro de la misma entidad | Decisión a nivel de campo o grupo de campos |
| Sincronización bidireccional por defecto | Valores que se alternan intermitentemente | Dirección única + lectura en el otro lado |
| Copia innecesaria | Decenas de campos sincronizados sin consumidor | Mostrar en lugar de copiar |
| Documento sin implementación | La política se debilita en meses | Permisos de campo + monitoreo de anomalías |
| Sin cola de conflictos | Las contradicciones se acumulan en silencio | Cola de tratamiento con responsable y SLA |
Cómo medir el éxito
| Área | Qué se mide | Frecuencia de verificación |
|---|---|---|
| Coherencia | Tasa de inconsistencia en campos clave entre sistemas | Mensual |
| Anomalías políticas | Escrituras en campos fuera del propietario definido | Mensual |
| Conflictos | Número y tiempo de cierre de ítems en la cola | Semanal |
| Impacto operativo | Incidencias causadas por datos erróneos | Trimestral |
La construcción y aplicación de una matriz de propiedad se realiza dentro del servicio de Integraciones y Datos.
Lista de verificación para determinar la Source of Truth
- ☐ Lista de las entidades centrales de la organización
- ☐ Para cada entidad: dónde se creó, quién está autorizado, quién es responsable del error
- ☐ Propiedad definida a nivel de campo o grupo de campos
- ☐ Dirección de sincronización explícita para cada grupo
- ☐ Cada campo copiado pasa la prueba de "tiene un consumidor"
- ☐ Se selecciona y documenta una regla de resolución de conflictos
- ☐ Existe una cola de tratamiento manual con un responsable y un SLA
- ☐ La Seguridad a nivel de campo (Field-Level Security) es coherente con la matriz
- ☐ El usuario de integración está limitado a los campos de su propiedad
- ☐ Informe mensual de anomalías políticas
Recursos profesionales
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data