La respuesta breve
La conexión entre Salesforce y un sistema ERP a menudo falla, no por un problema técnico en la integración misma, sino por una pregunta no formulada de antemano: ¿qué sistema es el origen de la verdad para cada entidad, y qué sucede cuando el mensaje entre los sistemas se pierde, llega duplicado o en un orden incorrecto? Esta guía estructura la decisión en torno a tres capas: origen de la verdad, patrón de sincronización y manejo de fallos, y muestra cómo elegir entre ellas según un escenario de negocio real, no según lo que permite la API.
El enfoque recomendado es comenzar por las entidades (cliente, producto, pedido, factura) y no por la herramienta. Para cada entidad, se define un único propietario, una frecuencia de actualización razonable y quién está autorizado a realizar cambios. A partir de ahí, se derivan el patrón de sincronización, el manejo de errores y el nivel de monitoreo requerido.
Una continuación natural a la discusión sobre la conexión entre Salesforce y un ERP se encuentra en la Arquitectura de Salesforce.
Origen de la verdad para cada entidad: la pregunta que precede a cualquier API
Antes de elegir un protocolo o herramienta de integración, es fundamental responder a una pregunta para cada entidad: ¿cuál es el sistema que decide qué es correcto en caso de conflicto? Generalmente, el ERP es el origen de la verdad para el inventario, la lista de precios, las facturas y los movimientos financieros, mientras que Salesforce es el origen de la verdad para las relaciones con los clientes, las oportunidades y la actividad de ventas. El problema surge cuando se asume tácitamente que ambas direcciones "se resolverán solas", lo que puede llevar a situaciones donde un representante de ventas cambia una dirección de envío en Salesforce mientras el ERP ya ha despachado el envío a la dirección antigua.
La solución práctica es un documento de mapeo de entidades: para cada entidad (Account, Product, Order, Invoice), se especifica el origen de la verdad, la dirección de sincronización (unidireccional o bidireccional) y la frecuencia de actualización requerida. Cuando hay una necesidad real de sincronización bidireccional, por ejemplo, la actualización del estado de pago que regresa del ERP al registro de oportunidad, se establece una regla explícita para la resolución de conflictos, como "la última actualización según la marca de tiempo (Timestamp) prevalece" o "el campo monetario siempre se rige por el ERP".
| Entidad | Origen de la verdad | Dirección de sincronización | Frecuencia típica |
|---|---|---|---|
| Cliente (Account) | Salesforce | Bidireccional con regla de conflicto | Casi instantánea |
| Producto y lista de precios | ERP | Unidireccional a Salesforce | Diaria o según cambios |
| Pedido (Order) | Creado en Salesforce, gestionado en ERP | Bidireccional, fases separadas | Inmediata en fase de creación |
| Factura y pago | ERP | Unidireccional a Salesforce | Diaria o casi en tiempo real (Near Real-Time) |
| Inventario disponible | ERP | Unidireccional a Salesforce | Cada pocos minutos hasta horaria |
Patrones de sincronización: Request-Reply, Batch y Event-Driven
Tres patrones cubren la mayoría de los escenarios prácticos. Request-Reply (síncrono) es adecuado cuando un usuario en Salesforce espera una respuesta inmediata, por ejemplo, la verificación de disponibilidad de inventario antes de confirmar un pedido. La ventaja es la simplicidad y la respuesta inmediata; la desventaja es la dependencia total de la disponibilidad del ERP en ese momento y el impacto en la experiencia del usuario si la respuesta es lenta.
Batch (por lotes) es adecuado para actualizaciones de gran volumen que no son urgentes, como la sincronización nocturna de la lista de precios o la importación de facturas del día anterior. Este patrón es más resistente a fallos temporales, pero implica una latencia de horas a un día entre los sistemas, un retraso que debe ser aceptable para el negocio, no solo para el equipo técnico.
Event-Driven (mediante Platform Events, Change Data Capture o una cola de mensajes externa) es adecuado cuando se necesita una respuesta casi inmediata sin requerir una dependencia síncrona. Un cambio de estado de pedido en el ERP emite un evento, y Salesforce se actualiza cuando está listo, incluyendo reintentos automáticos si estuvo temporalmente no disponible. Este es el patrón más flexible, pero también el más complejo de configurar y monitorear.
Tabla de selección de patrones por escenario
| Escenario | Patrón recomendado | Latencia típica | Riesgo principal |
|---|---|---|---|
| Verificación de inventario antes de confirmar pedido | Request-Reply | Pocos segundos | Dependencia total de la disponibilidad del ERP; el tiempo de espera (Timeout) afecta la experiencia del usuario |
| Sincronización de lista de precios y productos | Batch nocturno | Horas a 24 horas | Datos desactualizados entre ejecuciones; requiere coordinación con campañas y promociones |
| Actualización de estado de pago | Event-Driven | Segundos a minutos | Complejidad operativa; requiere monitoreo de cola de mensajes y Dead Letter Queue |
| Creación de nuevo pedido en ERP | Request-Reply con Retry | Segundos a un minuto | Fallo parcial: el pedido se creó en el ERP pero la respuesta se perdió, arriesgado a duplicidades |
| Actualización de inventario disponible para venta | Batch frecuente (cada 15-60 minutos) | Minutos | Vende basándose en inventario que ya se agotó entre ejecuciones |
| Alerta por exceder límite de crédito | Event-Driven | Casi inmediato | Un evento perdido provoca la aprobación de una transacción que no debería haber ocurrido |
En este contexto, la decisión sobre el tipo de sincronización también se relaciona con el modelo de permisos y la propiedad de los datos; una extensión sobre esto se encuentra en Salesforce Sharing and Visibility.
Middleware versus Point-to-Point
Cuando hay una sola conexión entre Salesforce y un ERP, una conexión directa (Point-to-Point) utilizando REST API o Named Credentials puede ser la solución más rápida y económica. El problema surge cuando se incorpora un tercer sistema (un almacén de datos, un sistema de envío o una plataforma de procesamiento de pagos), ya que cada nuevo sistema requiere la construcción de su propia lógica de transformación y manejo de errores, duplicando lo que ya existe en la conexión anterior.
Una capa de Middleware (como MuleSoft, Boomi o Workato) resuelve esto centralizando la lógica: cada sistema se conecta una sola vez al Middleware, y este se encarga de la transformación, los reintentos (Retry), la cola de mensajes y el monitoreo centralizado. El precio es un componente de infraestructura adicional que requiere licencia, mantenimiento y experiencia especializada.
Una regla general práctica: hasta dos o tres conexiones estables y sin lógica compleja, Point-to-Point es razonable. Con tres o más sistemas, o cuando hay un requisito de gobernanza centralizada (como monitoreo uniforme para todas las integraciones en la organización), el costo del Middleware se justifica casi siempre en uno o dos años.
Manejo de errores y Idempotency
El escenario más peligroso en la integración no es un fallo total, sino un fallo parcial: el mensaje fue enviado, el ERP creó un pedido, pero la respuesta a Salesforce se perdió debido a un tiempo de espera (Timeout). Si el sistema emisor intenta nuevamente de forma ingenua, se crea un pedido duplicado.
La solución es una Clave de Idempotencia (Idempotency Key): un identificador único creado en el lado emisor y adjunto a cada solicitud. El lado receptor mantiene un registro de los identificadores ya procesados y rechaza (o devuelve el resultado existente) si el identificador ya existe. Otros principios prácticos:
- Cada integración crítica recibe un mecanismo de reintento (Retry) con retroceso exponencial gradual, no un intento inmediato y repetido.
- Los mensajes que fallaron repetidamente se mueven a una cola de mensajes no entregados (Dead Letter Queue) para revisión manual, y no desaparecen en silencio.
- El registro de errores (Error Log) incluye la carga útil completa (Payload) del mensaje fallido para permitir la recuperación manual.
- Un proceso de reconciliación diario o semanal compara los sistemas e identifica las discrepancias que la sincronización "perdió".
Sin una Clave de Idempotencia y un proceso de reconciliación ordenado, cualquier problema de red transitorio se convierte en un problema de datos persistente que es difícil de localizar semanas después.
Limitaciones de API, seguridad y monitoreo
Salesforce impone límites diarios en el número de llamadas a la API (dependiendo de la licencia y la edición), y límites en el tamaño de la respuesta y el tiempo de ejecución. Una organización que sincroniza decenas de miles de registros al día a través de REST regular, llamada por llamada, alcanzará el límite rápidamente. La solución es Bulk API 2.0 para actualizaciones de volumen, y Composite API para reducir el número de llamadas en procesos síncronos de múltiples pasos.
En cuanto a la seguridad, tres principios se repiten en cada proyecto exitoso:
- El uso de Named Credentials y Connected Apps con OAuth, no nombres de usuario y contraseñas fijas en el código.
- Los permisos del "usuario técnico" de la integración están restringidos exactamente a los objetos y campos que necesita, no un perfil de administrador del sistema.
- El tráfico sensible (números de tarjeta de crédito, detalles de cuentas bancarias) se gestiona a través de una capa de Middleware o Tokenización, no se almacena como texto plano en Salesforce.
Para el monitoreo, se debe establecer un panel (Dashboard) que muestre al menos tres datos: la tasa de mensajes exitosos frente a fallidos, el tiempo de respuesta promedio y mediano, y el número de registros en la Dead Letter Queue. Una alerta automática cuando la tasa de fallos cruza un umbral definido (por ejemplo, más del 2% de los mensajes en un día) evita una situación en la que un problema acumulativo se detecta solo cuando un cliente se queja.
Estas decisiones a menudo se basan en un trabajo fundamental previo en el área de información y permisos, descrito en Deuda técnica de Salesforce.
Proceso de trabajo recomendado
1. Mapear entidades y definir el origen de la verdad
Para cada entidad (cliente, producto, pedido, factura), se define cuál es el sistema que decide en caso de conflicto. Sin esta decisión, cualquier conversación sobre "cuál es la forma correcta de sincronizar" se lleva a cabo en la ambigüedad.
2. Elegir el patrón de sincronización según la latencia requerida en la práctica
No todos los procesos necesitan una respuesta inmediata. La verificación de inventario antes de la venta sí; la actualización nocturna de la lista de precios no. Ajustar el patrón a la necesidad real ahorra costos de infraestructura innecesarios.
3. Decidir entre Middleware y Point-to-Point
La decisión depende del número de sistemas conectados y de la necesidad de gobernanza centralizada, no de una mera preferencia tecnológica.
4. Planificar Idempotency, Retry y Reconciliación desde el principio
Estos no son "mejoras futuras", sino parte de la definición de "listo" (Definition of Done) para cualquier integración que involucre dinero, inventario o pedidos.
5. Definir permisos mínimos para el usuario técnico
Un perfil dedicado, no un permiso de administrador del sistema generalizado. Cualquier cambio en el permiso requiere una aprobación separada del cambio funcional.
6. Probar escenarios de fallo, no solo el "Happy Path"
Realizar una prueba en la que el ERP "cae" en medio de un proceso, y medir el tiempo de recuperación y si se generan duplicados, revela problemas que no se ven en un entorno de desarrollo tranquilo.
7. Establecer un Dashboard y un proceso de Reconciliación permanente
El monitoreo técnico (el servidor está vivo) no es suficiente; se necesita monitoreo de negocio (el número de pedidos es igual en ambos sistemas).
Escenario empresarial de ejemplo
Una empresa comercial con aproximadamente 40,000 pedidos al mes conectó Salesforce a su ERP mediante llamadas REST síncronas directas, sin Middleware. Durante un pico de ventas, la tasa de fallos en las llamadas a la API aumentó drásticamente debido al límite diario de llamadas, y los pedidos que no pudieron registrarse en el ERP simplemente "desaparecieron", porque no había una Dead Letter Queue ni una alerta.
Después de la revisión, se descubrieron tres elementos faltantes: no se había definido una Clave de Idempotencia, por lo que los intentos repetidos a veces creaban pedidos duplicados; no se había utilizado Bulk API para actualizaciones de volumen; y no existía un proceso de reconciliación que comparara el número de pedidos en ambos sistemas. La solución incluyó la transición a una capa de Middleware con una cola de mensajes, el reemplazo de algunas de las llamadas síncronas por un Batch frecuente y la adición de un Dashboard diario para mostrar las discrepancias.
El resultado no fue "cero fallos" (un objetivo poco realista), sino que el tiempo de detección de fallos se redujo de semanas a horas, y un proceso que permite corregir una brecha el mismo día y no después de que un cliente se queje.
Riesgos comunes y acciones preventivas
| Riesgo | Cómo se manifiesta en la práctica | Acción preventiva |
|---|---|---|
| Origen de la verdad no definido | Dos partes "correctas" simultáneamente, y nadie sabe en quién confiar | Documento de mapeo de entidades con propietario definido para cada campo crítico |
| Falta de Idempotency | Pedidos duplicados después de cada fallo de red temporal | Clave de Idempotencia y verificación de duplicidad en el lado receptor |
| Point-to-Point sin gobernanza | Cada cambio en un sistema rompe silenciosamente otras conexiones | Capa de Middleware, contratos documentados y propiedad clara |
| Ignorar las limitaciones de la API | Llamadas fallidas en el pico de carga, sin alerta temprana | Transición a Bulk API, monitoreo del consumo de cuota diaria |
| Permisos amplios para el usuario técnico | Exposición de información sensible más allá de la necesidad de integración | Perfil restringido y revisión periódica de permisos |
Quienes se encuentren en una etapa más temprana que la planificación de la conexión pueden encontrar información complementaria en Salesforce Flow o Apex, especialmente en la decisión sobre dónde implementar la lógica de transformación.
Cómo medir el éxito
| Área | Qué se mide | Frecuencia de revisión |
|---|---|---|
| Fiabilidad | Tasa de mensajes completados versus fallidos | Continua, con alerta sobre umbral excedido |
| Latencia | Tiempo de extremo a extremo para cada escenario por separado | Continua |
| Consistencia de datos | Número de discrepancias en la revisión de reconciliación | Diaria o semanal |
| Costo operativo | Horas de soporte dedicadas a problemas de integración | Mensual |
Es aconsejable seleccionar solo tres o cuatro métricas para la primera versión, y medirlas también antes del lanzamiento para tener una línea de base (Baseline) real para comparar, no una estimación de memoria.
Lista de verificación antes de la puesta en producción
- ☐ Para cada entidad se define un origen de la verdad y una regla para la resolución de conflictos.
- ☐ Se ha seleccionado un patrón de sincronización (Request-Reply, Batch o Event-Driven) para cada proceso por separado.
- ☐ Se ha decidido si se requiere Middleware o si una conexión directa es suficiente.
- ☐ Existe una Clave de Idempotencia para cada operación que crea un registro financiero.
- ☐ Se ha configurado un mecanismo de reintento (Retry) con retroceso exponencial y una Dead Letter Queue para los mensajes fallidos.
- ☐ Se ha verificado el consumo de la cuota diaria de API frente al volumen esperado.
- ☐ El permiso del usuario técnico está limitado solo a los objetos y campos necesarios.
- ☐ Se ha realizado una prueba de fallo parcial, no solo del "Happy Path".
- ☐ Existe un Dashboard para monitoreo empresarial, no solo técnico.
- ☐ Se ha definido un proceso de reconciliación periódico y un responsable.
Notas profundas para la implementación y el mantenimiento
Nota del arquitecto: Cuándo cambiar un patrón existente
Si un patrón Batch nocturno fue elegido inicialmente por simplicidad, pero el negocio comienza a demandar una actualización de inventario casi inmediata, no es necesario "reventar" toda la arquitectura. Se puede aumentar la frecuencia a cada 15 minutos como una etapa intermedia, y transicionar a Event-Driven solo cuando se demuestre que eso tampoco es suficiente. Un cambio gradual, acompañado de la medición de la latencia real, es preferible a una decisión generalizada y prematura.
Desde un punto de vista gerencial, la verdadera prueba de la conexión entre Salesforce y un ERP no es solo que "funcione hoy", sino que se pueda explicar en cinco minutos por qué se eligió cada patrón y quién es responsable de arreglarlo cuando algo falla. Una solución que requiere una investigación prolongada en cada fallo genera un costo operativo oculto que aumenta con el tiempo.
Cuando la capacidad interna para planificar o implementar una conexión de este tipo es limitada, el servicio de arquitectura de CRM es el camino práctico a seguir.
Fuentes profesionales
- Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
- Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
- HPI Pro – Arquitectura de CRM — https://hpi.pro/crm-architecture
- HPI Pro – Integraciones y Datos — https://hpi.pro/integrations-data