Fallos de sincronización Salesforce ERP: cómo resolverlos

Un pedido está confirmado en Salesforce, pero falta en el ERP. Antes de rehacer la integración, sigue ese registro: dónde se aceptó por última vez, qué respuesta recibió y quién puede recuperarlo.

Esta guía es un punto de partida para el diagnóstico. Los escenarios ilustran posibles fallos; no son casos de clientes ni resultados medidos.

Tres tipos de fallos que conviene investigar

Empieza por comprobar cuál de estos síntomas coincide con los registros afectados:

• Fallos silenciosos: Los datos dejan de sincronizarse, pero nadie lo nota hasta que un cliente llama por un pedido faltante
• Errores en cascada: Una transacción fallida bloquea todo lo que está detrás, creando un retraso de más de 100 sincronizaciones fallidas
• La actualización del proveedor: Tu proveedor de ERP lanza una actualización que cambia el nombre de un campo, y de repente nada funciona

Un parche puede restablecer el flujo sin explicar por qué falló. Conserva el error original y los identificadores de los registros para investigar la causa.

Tu equipo de operaciones se adapta construyendo "procesos de respaldo" — hojas de cálculo, verificaciones manuales, reuniones de conciliación semanales. La integración se convierte en el problema que se suponía debía resolver.

Por qué sucede esto (No son las herramientas)

El problema no es Salesforce. No es tu ERP. La plataforma de middleware que elegiste probablemente está bien.

Un área que conviene investigar es la arquitectura: tres suposiciones que parecen razonables durante el proceso de venta pero fallan bajo condiciones del mundo real:

Suposición 1: "La sincronización en tiempo real siempre es mejor"

La sincronización en tiempo real suena ideal. ¿Cotización creada en Salesforce? Aparece instantáneamente en el ERP. Perfecto, ¿verdad?

Hasta que tu ERP está caído durante 15 minutos durante una ventana de mantenimiento planificada. O un problema de red causa un timeout. O alguien guarda un registro incompleto. Sincronización en tiempo real significa fallos en tiempo real.

Escenario ilustrativo: el ERP deja de estar disponible durante una actualización. Sin almacenamiento persistente y un mecanismo de recuperación, un pedido puede seguir faltando cuando el ERP vuelva a funcionar.

Suposición 2: "La integración maneja todo automáticamente"

La mayoría de las integraciones están construidas para el camino feliz. ¿Cliente existe en ambos sistemas? Genial. ¿Producto estándar? Sin problema. ¿Lista de precios coincide? Perfecto.

Pero ¿qué pasa cuando:

• ¿Un nuevo cliente existe en Salesforce pero aún no en el ERP?
• ¿Un acuerdo de precios especiales aplica a esta cotización?
• ¿El producto está disponible pero necesita una configuración personalizada?

Sin manejo explícito de errores para casos límite, la integración falla silenciosamente o, peor, crea datos incorrectos. Descubres el problema cuando contabilidad concilia el mes y encuentra discrepancias.

Suposición 3: "Una vez que funciona, sigue funcionando"

Los proyectos de integración tienen una fase de pruebas. Todo pasa. Sales a producción. Éxito.

Luego tu proveedor de ERP actualiza a la versión 12.3. Un nombre de campo cambia. Un tipo de dato cambia de string a integer. Un endpoint de API queda obsoleto.

La integración se rompe. Y como nadie documentó qué campos, endpoints o transformaciones usa realmente la integración, arreglarlo toma días de investigación.

Salesforce Architecture: Integration Patterns

---

La arquitectura que realmente funciona

Estas decisiones de arquitectura pueden facilitar la recuperación:

Principio 1: Diseña para el fallo

Asume que los fallos sucederán. Construye explícitamente para ellos:

• Usa colas persistentes cuando el proceso permita trabajo asíncrono: Cuando un registro necesita sincronizarse, ponlo en una cola. Procesa la cola con lógica de reintentos. Si algo falla, no bloquea todo lo demás.
• Implementa backoff exponencial: Aumenta la espera entre reintentos, limita los intentos y respeta los límites de la API. Evita duplicados al repetir peticiones.
• Alerta sobre patrones, no fallos individuales: ¿Una sincronización fallida? Normal. ¿Diez fallos en una hora? Alertar a alguien.

Los reintentos ayudan ante interrupciones temporales. Un cliente inexistente, un valor inválido o un error de permisos requiere otra respuesta: corregir la causa antes de reenviar la petición.

Principio 2: Haz visibles los fallos

Los peores fallos son los silenciosos. Diseña para la visibilidad:

• Dashboards de errores: Muestra qué falló, por qué, y qué necesita atención
• Informes resumen semanales: Distingue registros correctos, reintentos y registros pendientes de revisión manual.
• Propiedad clara: Alguien necesita ser dueño de la salud de la integración (usualmente operaciones, no TI)

No puedes arreglar problemas que no sabes que existen. La visibilidad no es opcional.

Principio 3: Documenta las dependencias

Cuando tu integración se rompa (y lo hará), necesitas saber:

• Qué endpoints de API usa
• Qué campos son obligatorios vs opcionales
• Qué transformaciones de datos ocurren
• Qué sistema es la fuente de verdad para cada tipo de dato

Esta documentación no es para tu yo actual. Es para tu equipo en seis meses cuando algo se rompa a las 4 PM del viernes y necesites entender qué cambió.

Cómo investigar una integración Salesforce que falla

1. Elige un pedido afectado y anota su identificador en ambos sistemas. Compáralo con un pedido correcto.
2. Localiza el último paso completado. Revisa horas, códigos de respuesta y registros de la integración.
3. Comprueba autenticación, campos obligatorios, mapeos y cambios recientes en la API o la configuración.
4. Antes de reenviar, comprueba si el sistema de destino ya creó el pedido. Usa un identificador externo estable para evitar duplicados.
5. Prueba la corrección con una muestra controlada. Después concilia los registros afectados y documenta la recuperación.

Define qué sistema controla cada campo, qué retrasos son aceptables y quién atiende los errores que no se recuperan solos. La arquitectura adecuada depende del proceso.

Preguntas para hacerle a tu proveedor de integración

Antes de tu próximo proyecto de integración (o al evaluar el actual), pregunta:

1. ¿Qué pasa cuando el ERP está temporalmente no disponible? Si la respuesta es "la sincronización fallará", pregunta sobre mecanismos de reintento.
2. ¿Cómo sabemos cuando algo se rompe? Si la respuesta es "verás errores", pregunta por detalles de monitoreo y alertas.
3. ¿Quién es dueño de la documentación? Si la respuesta es confusa o "proporcionamos documentación", asegúrate de que realmente obtengas documentación usable, no solo especificaciones de API.
4. ¿Cuál es el proceso de recuperación ante desastres? Si algo se rompe a las 6 PM del viernes, ¿qué pasa? ¿Hay una cola que podamos reproducir? ¿O perdemos datos?
5. ¿Puede nuestro equipo modificar esto nosotros mismos? El vendor lock-in no se trata del software. Se trata del lock-in de conocimiento.