Make

Make conecta AppBO con otros sistemas mediante un lienzo visual de escenarios, en lugar de una lista lineal de pasos. Del lado de AppBO escucha eventos y ejecuta acciones de forma muy parecida a cualquier plataforma de automatización. Lo que lo distingue es lo que pasa en medio: enrutadores (routers) que dividen el flujo en varios caminos condicionales, iteradores que expanden un arreglo en elementos individuales, agregadores que vuelven a juntar muchos elementos en uno solo, y manejadores de errores asociados a módulos específicos. El lienzo es un grafo de flujo de datos, no una lista de verificación.

Eliges Make en lugar de una herramienta más simple cuando la lógica tiene forma. Repartir un solo evento de AppBO hacia tres sistemas con reglas distintas para cada uno. Tomar los datos de un pedido que contiene un arreglo de partidas, recorrerlo, buscar cada producto y escribir una sola nota resumida de vuelta en el contacto. Reintentar solo la llamada frágil a un tercero mientras el resto del escenario sigue adelante. Ramificar según cinco tipos de servicio donde una herramienta lineal necesitaría cinco automatizaciones separadas, sincronizadas a duras penas.

Ocupa un punto intermedio a propósito. Comparado con una integración basada en código, es más rápido de construir, visible para quienes no son desarrolladores y se documenta solo en el lienzo. Comparado con una automatización lineal más simple, exige más cuidado: el mismo poder que te permite recorrer mil elementos también te permite consumir una cantidad enorme de operaciones sin querer, y un escenario con doce módulos y tres enrutadores necesita la misma disciplina de revisión que el código.

1. Haz un boceto del escenario antes de construirlo: el disparador, cada condición de ramificación, qué módulos necesita cada rama y qué pasa cuando falla cada llamada externa. Construir sobre la marcha un escenario lleno de enrutadores produce algo que nadie puede mantener.
2. Crea un escenario nuevo y agrega el módulo de AppBO como primer módulo, eligiendo un tipo de disparador. Un disparador instantáneo (basado en webhook) donde esté disponible, y uno por consulta (polling) en los demás casos. Los disparadores instantáneos son más rápidos y además mucho más baratos en operaciones.
3. Crea la conexión con la cuenta de AppBO. Completa el flujo de autorización eligiendo la subcuenta específica, y ponle a la conexión el nombre de esa subcuenta para que los módulos posteriores no se presten a confusión.
4. Corre el escenario una vez en modo manual para traer un paquete (bundle) de datos real. Revisa el paquete de salida completo; la estructura de campos que Make aprende aquí es a la que hace referencia cada mapeo posterior.
5. Agrega un filtro en la conexión que sale del disparador, para que los paquetes que no te interesan se detengan de inmediato en lugar de recorrer todo el escenario.
6. Agrega un enrutador donde la lógica se divide, y ponle a cada ruta un filtro explícito, incluida una ruta de respaldo para los paquetes que no coinciden con nada. Un paquete sin manejar que desaparece sin avisar es un error que vas a encontrar semanas después.
7. Donde los datos traigan un arreglo, agrega un iterador para expandirlo, y recuerda que todo lo que viene después del iterador se ejecuta una vez por elemento. Agrega un agregador después si el siguiente paso necesita un solo valor combinado en lugar de muchos.
8. Agrega un módulo de búsqueda antes de cualquier módulo de creación. Busca el registro por una clave estable y manda los casos de encontrado y no encontrado por rutas separadas, en lugar de dejar que una creación corra sin condiciones.
9. Mapea los campos de forma explícita y usa las funciones de Make para normalizar mientras mapeas: da formato a las fechas, quita el formato de los teléfonos y convierte texto a número donde el destino sea estricto.
10. Asocia un manejador de errores a cada módulo que llama a un servicio externo. Elige la directiva a propósito: reintenta los errores pasajeros, continúa con un valor por defecto donde un valor faltante sea tolerable y manda a una rama de notificación donde tenga que intervenir una persona.
11. Activa el procesamiento secuencial y define a propósito el máximo de ciclos si el orden importa o si un sistema posterior no aguanta escrituras en paralelo.
12. Prueba cada rama con ejecuciones manuales, forzando paquetes por cada ruta, una por una. Lee el inspector de ejecución de cada módulo, no solo el del último.
13. Verifica que la conexión esté activa disparando un evento real y viendo cómo aparece en el historial de ejecuciones del escenario, con la ruta esperada y los registros esperados escritos.
14. Provoca una falla a propósito (apunta un módulo a una credencial incorrecta) y confirma que el manejador de errores hace lo que diseñaste en lugar de detener el escenario.
15. Programa o activa el escenario, configura las notificaciones de operaciones y de errores, y revisa el historial de ejecuciones todos los días durante la primera semana.

De la plataforma a Make

• Paquetes de disparo para los eventos que exponen los módulos de AppBO en Make: contactos nuevos y actualizados, cambios en oportunidades y pipelines, envíos de formularios, citas y mensajes entrantes. Confirma los disparadores disponibles en la lista de módulos de la app.
• Registros completos que traen los módulos de búsqueda y de consulta, incluidos los valores de campos personalizados.
• Arreglos que un iterador puede expandir: respuestas de formularios, partidas, listas de etiquetas, conjuntos de resultados de búsqueda.

De Make a la plataforma

• Creación y actualización de contactos, con campos estándar y personalizados, etiquetas y responsable.
• Creación de oportunidades y cambios de etapa.
• Notas, tareas y registros de citas.
• Entrada de un contacto a un flujo de trabajo.
• Llamadas arbitrarias a la API mediante el módulo HTTP genérico de Make, para todo lo que no cubren los módulos dedicados, usando el token de la conexión.

Entre Make y terceros

• Lo que expongan los módulos de la app conectada, en ambas direcciones, con Make guardando una conexión y una credencial separadas para cada app.

Lo que no se mueve

• Las operaciones y el estado de las ejecuciones son de Make; la plataforma no tiene forma de ver si un escenario se ejecutó.
• Los elementos de los editores: páginas de funnels, diseño de plantillas de email, estructura de los sitios.
• Las cargas históricas masivas. Se puede hacer que un escenario recorra miles de registros, pero por el costo en operaciones una importación directa es mejor herramienta.
• Las garantías transaccionales. Un escenario que falla en el módulo siete no deshace los módulos uno a seis.

Escenario: el envío de un formulario en AppBO tiene que mandarse a uno de tres sistemas de destino según el tipo de servicio, y el arreglo de respuestas del envío se tiene que resumir en el contacto como una sola nota.

1. El primer módulo del escenario es el disparador instantáneo de AppBO para envíos de formularios, conectado a la subcuenta de la clínica y filtrado al formulario de admisión.
2. Un paciente envía el formulario de admisión. El disparador se activa en segundos y emite un paquete con los datos del contacto y un arreglo de pares de pregunta y respuesta.
3. El filtro de la primera conexión revisa que el campo de email no esté vacío. Los envíos en blanco se detienen aquí, con un costo de una operación.
4. Un iterador expande el arreglo de respuestas en paquetes individuales: once respuestas, once paquetes.
5. Un agregador los vuelve a juntar de inmediato en un solo valor de texto, una línea por respuesta, con formato para que se lea fácil. Este par de iterar y luego agregar es la forma de convertir un arreglo en algo que cabe en un campo de nota.
6. Un módulo de AppBO escribe ese texto como nota en el contacto, para que el equipo clínico vea el envío completo en contexto.
7. Un enrutador divide según la respuesta de tipo de servicio en tres rutas, cada una con un filtro explícito, más una cuarta ruta de respaldo.
8. La ruta uno pasa al paciente al sistema de agenda externo mediante su propio módulo. La ruta dos crea un registro en el portal del laboratorio con el módulo HTTP genérico, porque no existe un módulo dedicado. La ruta tres crea una tarea en la herramienta de gestión de la clínica. La ruta de respaldo publica en un canal interno de notificaciones un aviso de que un envío no coincidió con ningún tipo de servicio, con el identificador del contacto.
9. El portal del laboratorio es lento de vez en cuando, así que ese módulo HTTP tiene un manejador de errores configurado para reintentar con espera progresiva. El primer intento se agota por tiempo; el segundo funciona, y el resto del escenario no se ve afectado.
10. Una semana después, el portal del laboratorio rota su credencial. Ahora el módulo HTTP falla de forma permanente; su manejador de errores manda a la rama de notificación en lugar de reintentar para siempre, y a un operador se le avisa qué envío hay que volver a procesar.
11. Actualizas la credencial y vuelves a correr las dos ejecuciones incompletas guardadas desde el historial del escenario, lo que repite solo la parte que falló, sin volver a enviar la nota ni volver a mandar los datos a los otros sistemas.

Operaciones y límites de uso

Make cobra por operaciones, y una operación es, más o menos, un módulo que procesa un paquete. Un iterador sobre un arreglo grande multiplica cada módulo posterior por la cantidad de elementos, y así es como un escenario que parecía barato en las pruebas consume el saldo de un mes en una tarde. Filtra antes de iterar, agrega tan pronto como la lógica lo permita y define un máximo de ciclos. Aparte de eso, cada llamada de un módulo de AppBO cuenta contra el presupuesto de uso de la API de la cuenta, así que un escenario que recorre miles de contactos puede provocar respuestas 429 sin importar tu saldo de operaciones.

Reintentos e idempotencia

Los manejadores de errores te dan control real, y con él una responsabilidad real. Una directiva de reintento en un módulo de creación va a crear sin problema un segundo registro si el primer intento en realidad funcionó antes de agotarse por tiempo. Pon un módulo de búsqueda antes de cada creación y prefiere la lógica de actualizar o crear. El almacén de ejecuciones incompletas de Make es de verdad útil aquí, pero repetir una ejecución guardada vuelve a correr los módulos desde el punto de la falla, así que esos módulos tienen que tolerar haberse ejecutado a medias.

Trampas al mapear campos

Los mapeos quedan atados a la estructura que Make aprendió del paquete de muestra; un campo que no venía en esa muestra no está disponible en el selector del mapeo, y un campo que cambia de forma más arriba termina mapeado a nada sin avisar. Make es estricto con los tipos en algunos lugares (un valor de texto donde se espera un número da error en lugar de convertirse), así que usa las funciones de formato a propósito. Después de un iterador, los mapeos que hacen referencia al paquete anterior al iterador siguen funcionando, pero significan algo distinto de los valores por elemento; mezclar los dos es una fuente común de resultados incorrectos.

Creación de duplicados

Los enrutadores empeoran esto respecto a una herramienta lineal: dos rutas cuyos filtros pasan las dos se van a ejecutar las dos, y si ambas terminan en una creación, obtienes dos registros. Haz que los filtros de las rutas sean mutuamente excluyentes, y prueba forzando un paquete que podría coincidir con más de una.

Pruebas contra producción

Las ejecuciones manuales escriben datos reales. Usa una subcuenta de prueba y credenciales de prueba para los sistemas conectados, y recuerda que una ejecución manual de un escenario con un módulo de mensajería envía un mensaje real. Clona el escenario para experimentar en lugar de editar uno que está activo.

Vencimiento de la autorización

Las conexiones guardan tokens que vencen o se revocan. Make va a mostrar un error de autenticación y, después de varias fallas seguidas, va a desactivar el escenario. Las conexiones creadas con el usuario de una persona mueren con ese usuario, así que créalas con una identidad compartida del equipo y manda las notificaciones de error a un buzón compartido.

Lo que se rompe con más frecuencia

• Un enrutador sin ruta de respaldo, que descarta sin avisar los paquetes que no coinciden con nada.
• Un iterador que se quedó en su lugar después de que los datos de origen dejaron de ser un arreglo.
• Operaciones agotadas a mitad de mes, que desactivan todos los escenarios a la vez.
• Un escenario activo editado directamente mientras hay ejecuciones en curso.
• Procesamiento en paralelo que escribe en un destino que necesita actualizaciones en orden.
• Manejadores de errores agregados a los módulos fáciles y olvidados en el frágil.