¿Cómo automatiza sobre campos del CRM que pertenecen a otro sistema?

01El problema de negocio

Para la mayoría de las organizaciones de cierto tamaño, el CRM no es el sistema de registro de los datos que más importan comercialmente. Si una suscripción se está pagando, cuándo termina el contrato, cuántas licencias hay contratadas, cuánto ha gastado el cliente hasta la fecha, si su acceso está suspendido en este momento: todo eso pertenece a la facturación, al aprovisionamiento, a un ERP. Llega al CRM por replicación.

Y, sin embargo, casi todas las automatizaciones que de verdad le importan al negocio se ramifican exactamente sobre esos campos. El recordatorio de renovación, la alerta de abandono, la escalada de «esta cuenta se ha quedado callada», el informe de ingresos, la previsión de renovaciones: todas se condicionan a datos que el CRM no ha producido y no puede verificar.

Así que el negocio pide al CRM que sea autoritativo sobre cosas que solo está repitiendo. Es una arquitectura perfectamente razonable, y es la habitual. La pregunta es qué tiene que hacer de forma distinta por ello.

El planteamiento honesto: su automatización del CRM tiene una dependencia que no puede ver, no puede probar y de la que nadie le avisará cuando se rompa.

02Por qué falla el enfoque obvio

El enfoque obvio es sincronizar el campo y luego usarlo exactamente como usaría un campo que ha escrito una persona. Cuatro cosas salen mal, en orden creciente de gravedad.

El campo es editable, así que alguien lo edita

Un agente de soporte ve una fecha de fin de suscripción que parece incorrecta y la corrige. Queda correcta durante un día, más o menos. El siguiente ciclo de replicación la sobrescribe, en silencio, y ahora el historial de auditoría registra a una persona haciendo un cambio que una máquina revirtió por motivos que nadie documentó. Peor aún: en el intervalo entre ambos, la automatización se disparó con el valor corregido.

Un campo reflejado que cualquiera puede editar no es un reflejo. Es una segunda fuente de verdad sin conciliación.

La automatización se ramifica directamente sobre el vocabulario de origen

Lo natural es escribir el proceso como «cuando el estado de origen pase a Cancelled, haga el trabajo de cancelación». Haga eso en veinte sitios y la enumeración del sistema de origen se habrá convertido en la API pública de su CRM.

Hemos visto un único campo de estado replicado leído por más de una docena de procesos distintos. Cuando el origen añade un valor (y lo hará, porque es un sistema vivo con su propia hoja de ruta), cada uno de esos procesos envía en silencio el nuevo valor a la rama por defecto que tenga. Normalmente esa rama es «no hacer nada», lo que no produce ningún error ni ningún registro de que se haya perdido algo.

Que un campo cambie no es lo mismo que el evento ocurra

Cuando un campo replicado cambia, lo que usted ha averiguado es que la sincronización se ha ejecutado. La marca de tiempo del cambio es la hora de la replicación, no la hora del evento de negocio. Si su proceso responde escribiendo Date lost = today, ha registrado la fecha en que el CRM se enteró, no la fecha en que el cliente se fue.

Con una sincronización diaria sana, esa discrepancia es de un día y nadie la nota. Tras una interrupción es de lo que haya durado la interrupción, aplicada a todos los registros afectados a la vez, y acaba en los informes de abandono.

Que un campo no cambie no es lo mismo que no pase nada

Este es el que causa daños reales, y de él trata el §6. La automatización activada por cambios no tiene el concepto de «debería haber cambiado». Cuando el origen deja de enviar, la capa de automatización del CRM no se degrada, no da error ni avisa. Se queda en silencio, lo que no se distingue de una semana tranquila.

03Modelo de datos — tres capas, no una

La solución es dejar de tratar «el campo» como una sola cosa. Divídalo en tres capas con propietarios distintos y reglas distintas.

Capa 1 — campos reflejados (propiedad de la integración)

Una copia literal del valor de origen. De solo lectura para todos los roles, incluidos los administradores, en el funcionamiento normal. Marcada con una convención de nombres para que cualquiera que lea un proceso, un formulario o un informe sepa de un vistazo que ese valor viene de fuera: basta con un sufijo o un prefijo coherente en la etiqueta, y vale más que una documentación que nadie abre.

Estos campos existen para leerse. Nada en el CRM debería escribirlos nunca.

Capa 2 — estado derivado (propiedad del CRM)

Un conjunto deliberadamente pequeño de campos que expresan lo que el CRM cree sobre la cuenta, en el vocabulario propio del CRM: un estado del ciclo de vida, la fecha en que terminó la relación, las fechas de renovación con las que planifica el negocio. Qué datos merecen siquiera un campo de capa 2 es la pregunta que desarrolla el Blueprint 003.

Esta es la capa sobre la que se ramifica su automatización. Todos los procesos posteriores (el recordatorio, el informe, la escalada, el filtro del panel) leen la capa 2. Solo un puñado de procesos de mapeo leen la capa 1.

La ventaja es exactamente la de cualquier adaptador: cuando cambia el vocabulario de origen, usted edita los procesos de mapeo y nada más. El coste es que la capa 2 puede desviarse de la capa 1, y por eso el §7 trata en gran parte de la conciliación.

Capa 3 — campos de salud de la sincronización

Dos campos que tratan de la replicación en sí y no del cliente:

• Una marca de tiempo de última sincronización en el registro, para que cualquier proceso pueda preguntar cómo de recientes son sus entradas.
• Un indicador de replicación completada que el origen activa cuando ha terminado de escribir la carga de un registro.

El segundo es el más interesante, y resuelve un problema real de orden: vea el §5.

Alternativas descartadas

• Ramificar directamente sobre la capa 1 en todas partes. Descartada más arriba. Acopla todo su conjunto de automatizaciones a la enumeración de otro.
• Hacer editables los campos reflejados «para que soporte pueda corregirlos». Ya pueden corregirlos, en el sistema que es su propietario. Editar el reflejo produce una corrección que sobrevive hasta la siguiente sincronización y un historial de auditoría que miente.
• Sincronizar en sentido inverso para que el CRM pase a ser autoritativo. Una arquitectura legítima, y un proyecto mucho mayor con su propio diseño de resolución de conflictos. No es un rodeo para este problema; es un problema distinto. Si hoy no tiene escritura de vuelta, no deje que este blueprint le convenza de inventarla.
• Recalcular el estado derivado al leer, en un campo de fórmula. Atractivo, y elimina por completo el problema de la desviación. También elimina su capacidad de registrar cuándo se entró en un estado, que es lo que necesita la mayor parte de los informes, y no puede ser el disparador de nada.

04Configuración a nivel de campo

Dos notas sobre los tipos. Mantenga la copia reflejada en el mismo tipo que el valor de origen en lugar de convertirlo a la entrada: un estado reflejado como texto y mapeado a un dropdown en la capa 2 falla de forma visible cuando aparece un valor nuevo, mientras que un dropdown reflejado puede descartar sin ningún error un valor que no figure en su lista de opciones. No hemos probado qué hace la sincronización en ese caso, así que no construya sobre ninguno de los dos resultados. Y haga que los marcadores de idempotencia sean campos o etiquetas, no un estado inferido: «¿ya hemos enviado esto?» debe poder responderse con un filtro, no razonando sobre fechas.

05Automatización y lógica

Primero derivar, después ramificar

Un proceso de mapeo por cada campo de origen. Su única tarea es traducir la capa 1 a la capa 2. Cada proceso de mapeo termina con una rama de valor no mapeado: una condición final que coincide con todo lo que no cubrieron las ramas anteriores, y cuya acción es notificar a un administrador que ha aparecido un valor no reconocido.

Esa última rama es el seguro más barato de todo este blueprint. Convierte un enrutamiento erróneo silencioso (el resultado por defecto cuando un sistema de origen añade un valor de enumeración) en un mensaje.

Active el proceso con el indicador de finalización, no con la carga

Cuando la replicación escribe los campos de un registro, no llegan todos en el mismo instante. Una lógica de proceso que se activa con un campo y lee otros cinco puede dispararse sobre un registro escrito a medias y ramificarse sobre una mezcla de valores nuevos y antiguos.

El patrón que lo resuelve: haga que el origen active un indicador de replicación completada como última escritura del lote de un registro, y active el proceso con ese indicador, leyendo los campos de la carga como condiciones y no como disparador. El proceso se ejecuta entonces una vez, cuando el registro ya es coherente.

Merece la pena construirlo incluso donde hoy la sincronización parezca atómica, porque cuesta un campo y marca la diferencia entre «funciona» y «funciona bajo carga».

Fuente. Centro de ayuda de Coevera, Automatizer — creating and running processes, para los tipos de disparador sobre los que se puede construir un proceso. Lo que no cubre, y este blueprint sí, es cuál de ellos es seguro apuntar a un campo que escribe otro sistema.

Detecte las contradicciones y envíelas a una persona

Un sistema de origen emite combinaciones no válidas. No porque esté mal construido, sino porque dos sistemas con relojes independientes y vías de edición independientes producirán estados que no concuerdan, y algunos de esos estados son de los que sus reglas de negocio dicen que no pueden existir:

• Hay una fecha de fin rellenada mientras el estado sigue indicando activo.
• El estado indica cancelado, pero no llegó ninguna fecha de fin.
• Cambia la fecha de inicio de una suscripción que lleva un año vigente.
• Un registro está marcado como suspendido y como pagado al mismo tiempo.

Construya un proceso para cada caso. Su acción no es corregir los datos: el CRM no es su propietario y cualquier corrección se sobrescribe en el siguiente ciclo. Su acción es notificar a un rol concreto la contradicción específica y el lugar específico del origen donde debe corregirse.

Tratar la detección de contradicciones como una funcionalidad y no como un gestor de errores marca la diferencia entre una integración en la que usted confía y una de la que solo espera que funcione.

Escriba las condiciones como rangos, siempre, con una condición de idempotencia

Esta es la regla más importante de este blueprint, y es la que se extrae más directamente del incidente del §6.

La versión con igualdad es correcta todos los días en que la sincronización está sana e incorrecta para siempre los días en que no lo está, porque la condición solo es verdadera para un valor y nada la vuelve a examinar después. La versión con rango más un marcador de idempotencia es idempotente y tolerante a huecos: hace el trabajo tarde en lugar de no hacerlo, y lo hace una sola vez.

Las condiciones de igualdad sobre un campo replicado son, en la práctica, una apuesta a que ninguna sincronización se interrumpirá jamás. No es una apuesta que merezca la pena por los dos minutos que cuesta la versión con rango.

Condicione por frescura, pero falle de forma visible

Los procesos que actúan sobre datos replicados deberían comprobar la marca de tiempo de última sincronización antes de actuar. La implementación obvia («ejecutar solo si la última sincronización es reciente») esconde una trampa que describe el §6, así que acompañe la condición de un registro o un aviso explícito en la rama de rechazo. Un proceso que se abstiene de ejecutarse debe decirlo.

06Límites y compromisos

La automatización activada por cambios queda en silencio, no falla

Ningún proceso onChange que escuchaba un campo replicado se disparó, sencillamente porque los campos no cambiaron. No existe un estado de error para «se esperaba un evento que nunca llegó». Una semana sin cambios de suscripción y una semana con una integración caída producen registros idénticos.

No existe una solución para esto en la plataforma. El monitor del §7 no es un extra; es lo único que se lo puede indicar.

La automatización programada sigue ejecutándose, con total confianza, sobre datos obsoletos

Esto es peor que no ejecutarse. Los procesos diarios se dispararon según su calendario cada día de la interrupción y trabajaron sobre una instantánea cada vez menos fiel: omitieron cuentas que cumplían los requisitos y procesaron cuentas que ya no los cumplían. Los correos de cuenta atrás para la renovación que se envían a clientes salieron calculados a partir de recuentos de días obsoletos, de modo que algunos clientes recibieron un correo que indicaba un número de días erróneo, y otros no recibieron nada al llegar a su hito.

La puesta al día lo dispara todo a la vez, con el día de referencia equivocado

Cuando se reanudó la replicación, los cambios acumulados durante días llegaron juntos y todos los procesos activados por cambios se dispararon en ráfaga. Los valores de los campos eran correctos. El día de referencia no lo era: cualquier proceso cuya acción fuera set date = today estampó la fecha de recuperación en un evento que había ocurrido días antes. Las fechas de pérdida, las fechas de cancelación y las fechas de cierre de los registros de pérdida creados a partir de ellas tuvieron que corregirse a mano después.

Las condiciones de coincidencia exacta se omiten para siempre y sin dejar rastro

La categoría más dañina, porque no deja ninguna evidencia:

• Un proceso diario que busca End Date = yesterday no volverá a coincidir nunca con esas cuentas. Se quedan sin sello de fin de vida, y los paneles las siguen contando como activas indefinidamente.
• Un proceso de hito que busca tenure = 13 months ve cómo el contador salta de 12 a 14 en una sola escritura de puesta al día. Nunca se dispara para esas cuentas, jamás.
• Los procesos de revisión de renovaciones que buscan un valor exacto de días hasta la renovación omiten las cuentas cuyo día exacto cayó dentro de la ventana.

Ninguno de ellos produce un error, un reintento ni una entrada en una cola. Producen un informe al que discretamente le faltan registros, que se descubre semanas después, si es que se descubre.

Una condición de frescura puede desactivar precisamente la comprobación que protege

Un proceso estaba condicionado a «ejecutar solo si la marca de tiempo de última sincronización está en el periodo actual», una protección de aspecto sensato contra actuar sobre datos obsoletos. La marca de tiempo de última sincronización es a su vez un campo replicado. Durante la interrupción dejó de avanzar, así que la condición se evaluó como falsa para todas las cuentas y el proceso no hizo nada en absoluto, para nadie, incluidas las cuentas cuyos umbrales debía vigilar.

Una condición sobre un campo replicado no puede distinguir entre «los datos están obsoletos» y «los datos están bien y el indicador de obsolescencia está obsoleto». Condicione por frescura, desde luego, pero ponga el aviso en la rama de rechazo, o la protección se convierte en la interrupción.

Las diferencias con el valor anterior también se replican

Las alertas de cambio del tipo «el número de licencias pasó de X a Y» suelen leer una instantánea del valor anterior que también se sincroniza. Después de un hueco, la instantánea y el valor actual pueden estar separados por varios cambios, de modo que la diferencia que se comunica a una persona es aritméticamente correcta y engañosa en los hechos. Verifique las diferencias después de cualquier interrupción en lugar de fiarse del texto de la alerta.

No hay garantía de orden ni transaccional, y no puede hacer esperar al CRM

La automatización de procesos en esta plataforma no es transaccional y no ofrece ninguna garantía de orden entre registros. No se puede expresar «retener este proceso hasta que termine la sincronización», y por eso el disparador por indicador de finalización del §5 es un patrón y no un ajuste. Tampoco se puede volver a reproducir un proceso activado por cambios para un periodo en el que no se disparó; la recuperación consiste en una consulta y una reejecución manual o masiva, y por eso el §7 insiste en que escriba esas consultas antes de necesitarlas.

El compromiso que usted acepta

El modelo de tres capas le compra desacoplamiento y lo paga con duplicación. La capa 2 puede desviarse de la capa 1, y lo hará: por interrupciones, por errores de mapeo, por ediciones manuales hechas durante una recuperación. Usted acepta una obligación de conciliación a cambio de un conjunto de automatizaciones que no se hace añicos cuando cambia una enumeración de origen.

Ese intercambio merece la pena con una condición: que la derivación se pueda volver a ejecutar. Un proceso que recalcula toda la capa 2 a partir del contenido actual de la capa 1, a demanda, para un conjunto filtrado de registros, es lo más valioso que se puede construir aquí. Es su herramienta de recuperación, su herramienta de migración y su banco de pruebas. Constrúyalo junto con el mapeo, no después del primer incidente.

07Verificación

Lo que hay que verificar aquí no es «funciona la automatización»: funcionó, durante toda la interrupción, y ese era el problema. Es «puede el CRM darse cuenta de cuándo sus entradas dejaron de ser ciertas».

• Construya primero el monitor de frescura de la sincronización. Un proceso programado, con una cadencia más corta que su tolerancia al hueco, que lee la marca de tiempo máxima de última sincronización entre los registros y avisa si es más antigua que un umbral. No debe depender a su vez de ningún campo replicado aparte de la marca de tiempo. Sin esto, el único detector de interrupciones del CRM es una persona que nota que un informe tiene un aspecto raro, que es lo que ocurrió.
• Escriba las consultas de conciliación antes de necesitarlas. Para cada campo derivado, una consulta guardada que encuentre los registros en los que la capa 2 no coincide con lo que implica la capa 1: registros con estado activo que llevan una fecha de fin; suscripciones terminadas sin sello de fin de vida; estados del ciclo de vida que ninguna combinación actual de campos reflejados produciría. Ejecútelas de forma programada, y después de cada interrupción conocida. Un estado derivado que ninguna consulta de conciliación puede explicar es la señal de regresión.
• Pruebe el hueco, no el camino feliz. En un espacio de pruebas, pause la alimentación, deje que los procesos programados pasen por varios ciclos, reanude con una puesta al día por lotes y compruebe después tres cosas: qué se disparó, qué debería haberse disparado y no lo hizo, y qué fechas se estamparon. Todos los hallazgos del §6 se pueden reproducir así, y es la única forma de saber si su propio conjunto de automatizaciones los tiene.
• Registre los rechazos. Cuando una condición de frescura rechace, déjelo registrado. «No hizo nada porque los datos estaban obsoletos» y «no hizo nada porque no había nada que hacer» deben poder distinguirse después, y por defecto no se distinguen.
• Audite el día de referencia después de cualquier recuperación. Busque los registros cuyas fechas de evento coincidan con la fecha de recuperación y compruebe cada uno contra el origen. Un grupo de eventos de negocio fechados todos el mismo día es la huella de una ráfaga de puesta al día, no una coincidencia.
• Vuelva a ejecutar la derivación y compare. El proceso de rederivación del §6 sirve también como comprobación: ejecútelo sobre una muestra, compare el antes y el después, y confirme que nada se mueve. Todo lo que se mueva es una desviación que no sabía que tenía.

Qué indicaría una regresión: cualquier condición de igualdad sobre un campo replicado que aparezca en un proceso nuevo; un contador de hitos o de notificaciones que se mantiene plano durante un periodo en el que el volumen no cambió; cualquier campo de fecha en el que un número significativo de registros comparta el mismo valor; un proceso de mapeo sin una rama final de valor no mapeado.

Blueprints relacionados

• Blueprint 003 — ¿Cómo modela algo para lo que su CRM no tiene un objeto? La pregunta previa. Decidir qué debe ser propiedad del CRM es lo que determina cuánto de su conjunto de automatizaciones acaba en la capa 1.
• Blueprint 008 — ¿Cómo prevé renovaciones que todavía no existen como registros? Las fechas de renovación son los campos replicados más habituales que existen, y los mecanismos de previsión descritos allí se sitúan directamente a continuación de este patrón.
• Blueprint 005 — ¿Cómo migra contactos desde otro sistema sin perder datos sin darse cuenta? La versión puntual de la misma disciplina: conciliar lo que llegó con lo que se envió, en lugar de fiarse del informe de carga.