Mapeo de fuentes
Qué sistemas contienen qué entidades, y cuál es la autoridad.
Integraciones y migración de datos
Un sistema core no puede funcionar solo, ni sobre datos en los que nadie confía.
Conectamos Salesforce con los sistemas que la organización ya utiliza, definimos contratos de interfaz claros y migramos los datos históricos mediante un proceso controlado con reconciliación completa.
Topología del flujo de datos
Cómo entran, se gobiernan y se consumen los datos
Toda integración estable empieza decidiendo qué sistema es la autoridad de cada entidad. Todo lo demás —protocolo, frecuencia y herramientas— se deriva de esa decisión.
Topología del flujo de datos
Sistemas origen
De dónde vienen los datos
- ERP y sistemas financieros
- Sitio web, formularios y campañas
- Centro de contacto y canales de servicio
- Sistemas operativos
Capa de contrato y control
Qué se gobierna antes de la entrada
- Contrato de interfazcampos, formato, responsabilidad
- Clave de identidad e idempotencia
- Validación y calidad de datos
- Reintentos, registro y monitorización
Salesforce y consumo
Donde el dato se convierte en decisión
- Modelo de datos core
- Automatización y procesos
- Informes y dashboards
- Agentforce sobre datos gobernados
Tipos de sistemas
Qué se puede conectar
- ERP
- Sistemas financieros y contables
- Sitios web y formularios
- Marketing automation
- Telefonía y CTI
- WhatsApp y canales de mensajería
- Sistemas de servicio
- BI y data warehouse
- Sistemas operativos
- Sistemas de RR. HH.
- Sistemas de documentos y firma electrónica
- APIs internas
- Webhooks
La conexión en sí casi nunca es lo difícil. Lo difícil es decidir quién es responsable de cada campo, qué ocurre cuando dos sistemas actualizan el mismo valor y cómo se detecta un fallo antes de que lo detecten los usuarios.
Patrones de integración
Elegidos por tolerancia al fallo, no por comodidad
| Patrón | Cuándo encaja | Ejemplo típico | Qué vigilar |
|---|---|---|---|
| Request–Reply | Se necesita una respuesta inmediata antes de continuar el proceso | Comprobación de stock o crédito al crear un pedido | Dependencia directa de la disponibilidad del sistema destino |
| Fire and Forget | La actualización importa pero no bloquea el proceso | Enviar una actualización de estado a un sistema de reporting | Requiere reintentos y monitorización |
| Batch Sync | Alto volumen, baja sensibilidad a la actualidad del dato | Sincronización nocturna de catálogo o precios | Desfases de actualidad entre sistemas |
| Event-Driven | Varios consumidores para un mismo evento de negocio | Publicar 'pedido aprobado' a múltiples sistemas | Requiere gestión del esquema y del orden de eventos |
| Data Virtualization | Ver datos sin copiarlos | Mostrar el historial de facturación de un sistema externo | El rendimiento depende de la fuente externa |
Request–Reply
- Cuándo encaja
- Se necesita una respuesta inmediata antes de continuar el proceso
- Ejemplo típico
- Comprobación de stock o crédito al crear un pedido
- Qué vigilar
- Dependencia directa de la disponibilidad del sistema destino
Fire and Forget
- Cuándo encaja
- La actualización importa pero no bloquea el proceso
- Ejemplo típico
- Enviar una actualización de estado a un sistema de reporting
- Qué vigilar
- Requiere reintentos y monitorización
Batch Sync
- Cuándo encaja
- Alto volumen, baja sensibilidad a la actualidad del dato
- Ejemplo típico
- Sincronización nocturna de catálogo o precios
- Qué vigilar
- Desfases de actualidad entre sistemas
Event-Driven
- Cuándo encaja
- Varios consumidores para un mismo evento de negocio
- Ejemplo típico
- Publicar 'pedido aprobado' a múltiples sistemas
- Qué vigilar
- Requiere gestión del esquema y del orden de eventos
Data Virtualization
- Cuándo encaja
- Ver datos sin copiarlos
- Ejemplo típico
- Mostrar el historial de facturación de un sistema externo
- Qué vigilar
- El rendimiento depende de la fuente externa
Migración de datos
Diez pasos controlados
Profiling de datos
Medición de completitud, duplicación, formatos irregulares e historial ausente.
Reglas de limpieza
Qué se corrige de forma automática, qué requiere una decisión de negocio y qué no migra.
Mapeo
Campo a campo, incluidas transformaciones y valores por defecto.
Clave de identidad
Una clave de negocio única por entidad para evitar duplicados en cargas repetidas.
Carga de prueba
Una carga completa en un entorno de test con volúmenes reales.
Validación
Comprobaciones de conteo, suma y muestreo frente al origen.
Reconciliación
Una comparación formal y una lista de diferencias aprobada.
Carga definitiva
Una ventana de cutover planificada con un punto de rollback definido.
Control continuo
Métricas de calidad de datos que se mantienen tras el go-live.
La vida después del go-live
Una integración es un sistema que hay que operar
Ciclo operativo de integraciones
- 01
Monitorización
Medición de éxitos, fallos y tiempos de respuesta por interfaz.
- 02
Alertas
Un fallo que supera un umbral genera una alerta a un responsable de proceso identificado.
- 03
Gestión y corrección
Reintento controlado, corrección manual documentada y análisis de causa raíz.
- 04
Ajuste
Actualización del contrato de interfaz o de la regla de negocio, y registro del cambio.
↻ El ciclo se repite: cada iteración alimenta la priorización de la siguiente
Continúe desde aquí
Servicios y guías relacionados
- Arquitectura CRM
- Data Cloud y unificación de datos
- Desarrollo y automatización
- Implementación de Salesforce
- Guía: patrones de integración de Salesforce
- Guía: migración de datos en Salesforce
- Guía: conectar Salesforce con el ERP
- Guía: manejo de errores en integraciones
- Guía: definir una fuente de verdad
- Guía: evitar duplicados en Salesforce
Preguntas frecuentes
Integraciones y datos — preguntas habituales
¿Cuándo se elige integración en tiempo real y cuándo por lotes?
La pregunta decisiva es qué ocurre si el dato llega con una hora de retraso. Si la consecuencia es una decisión equivocada frente a un cliente, se requiere tiempo real. Si la consecuencia es un informe algo menos actualizado, el proceso por lotes es más barato, más estable y más fácil de mantener. Una combinación habitual es tiempo real para las entidades clave y por lotes para enriquecimiento y correcciones.
¿Qué es un contrato de interfaz y por qué es crítico?
Un contrato de interfaz define por escrito qué sistema es la fuente, qué campos se mueven, en qué formato, qué ocurre en caso de fallo, qué identifica de forma única a un registro y quién es responsable de los cambios. Sin él, cualquier actualización en un lado rompe el otro y nadie sabe por qué. Es el documento que evita la mayoría de los fallos reales de integración.
¿Cómo se evitan duplicados durante una migración?
Se define una clave de identidad de negocio para cada entidad antes de cargar los datos, se ejecuta un profiling de datos para conocer el alcance real de la duplicación, se decide una regla explícita de fusión y se realiza una carga de prueba en un entorno de test. Solo tras superar la reconciliación completa se ejecuta la carga definitiva.
¿Qué se hace cuando el sistema origen no es fiable?
No se oculta el problema detrás de una integración. Se define el rango de calidad aceptable, se filtran o marcan los registros que quedan fuera de ese rango y se define un proceso de corrección en el origen. Trasladar datos deficientes a Salesforce solo traslada la desconfianza al nuevo sistema.
¿Cuánto tarda una migración de datos?
La duración depende de la calidad del origen, no del volumen. Un millón de registros limpios con una clave clara es mucho más rápido que cien mil registros con duplicados e historial parcial. Por eso el profiling se realiza pronto, antes de comprometer cualquier plazo.
¿Se necesita una plataforma de integración dedicada?
No siempre. Para un puñado de interfaces estables, un enfoque basado en APIs y platform events es suficiente. Una plataforma dedicada se justifica cuando hay muchos sistemas, transformaciones complejas, requisitos de monitorización centralizada o necesidad de reutilizar lógica entre procesos.
Siguiente paso
Planificar una integración o migración
Mapearemos los sistemas, las fuentes de verdad y el nivel de calidad requerido, y construiremos un plan que realmente pueda ejecutarse.