low-code

1 publicación con la etiqueta “low-code”

Cómo crear tu primer workflow en Corteza: guía práctica paso a paso

6 de agosto de 2026

Equipo de Abera CRM

Abera CRM · Colombia

Un workflow convierte una regla de negocio en una secuencia que Corteza puede ejecutar por ti. Por ejemplo: cuando entra un lead, comprobar su prioridad, asignar una tarea y avisar a la persona responsable.

La idea puede sonar técnica, pero un workflow de Corteza se construye visualmente. La plataforma lo representa como un diagrama de flujo: eliges qué evento lo inicia, conectas los pasos, defines las condiciones y guardas el resultado. No necesitas empezar escribiendo JavaScript ni saber BPMN.

En esta guía vas a crear un flujo sencillo para dar seguimiento a nuevos leads. Al terminar tendrás una base que puedes adaptar a cotizaciones, soporte, aprobaciones, renovaciones o cualquier proceso repetitivo.

Nota sobre la interfaz: esta guía se basa en la documentación oficial de Corteza 2024.9. Los nombres de algunos recursos o funciones pueden cambiar según la versión y la configuración de tu instancia; usa siempre las opciones que aparecen en tu editor.

Quickstart: tu primer workflow en 10 minutos

Si quieres probar la idea antes de leer todos los detalles, construye esta versión mínima en un namespace de prueba:

Nombre: Seguimiento de nuevos leads
Recurso: Compose Record
Evento: afterCreate
Namespace: CRM
Módulo: Leads
Condición: prioridad == "Alta"
Acción: crear una tarea de seguimiento

Prueba primero con un lead de ejemplo y confirma que la tarea se cree. Después añade la notificación, el segundo camino y las integraciones. Separar el primer resultado de las mejoras evita que una configuración grande sea difícil de depurar.

Regla práctica: un workflow debe resolver una repetición concreta. Si no puedes describirlo en una frase que empiece por “cuando…”, todavía no está listo para automatizarse.

Figura 1. La aplicación de workflows reúne en un solo lugar los flujos existentes y el botón para crear uno nuevo.

La idea en una frase

Un workflow responde a esta pregunta:

Cuando ocurre X, si se cumple Y, ejecuta Z.

Parte	Qué significa	Ejemplo para ventas
Trigger (disparador)	El evento que inicia el flujo	Se crea un registro en el módulo Leads
Restricciones	Filtros que evitan ejecuciones innecesarias	Sólo en el namespace CRM y módulo Leads
Condición o gateway	Decide por qué camino continúa el flujo	Prioridad es “Alta”
Acción o función	El trabajo que realiza Corteza	Crear una tarea y enviar una notificación
Scope	Datos disponibles durante la ejecución	El lead actual, el módulo y el namespace
Terminación	El punto donde termina la ejecución	Flujo completado

La documentación de Corteza describe los workflows como diagramas BPMN simplificados. Cada workflow debe comenzar con un trigger; el paso de terminación es opcional porque el flujo también termina cuando ya no hay pasos conectados. Consulta la documentación oficial de workflows.

El ejemplo: seguimiento automático de un nuevo lead

Vamos a construir este proceso:

1. Se crea un lead en el módulo Leads.
2. Corteza comprueba si la prioridad es alta.
3. Si es alta, crea una tarea para contactar hoy y envía una alerta.
4. Si no es alta, crea una tarea para contactar en los próximos dos días.
5. El flujo termina y deja el resultado registrado.

Este ejemplo no intenta reemplazar el criterio comercial. Sólo evita que un registro nuevo quede sin responsable o sin siguiente acción.

Cómo sabrás que funcionó

Al terminar, un lead con prioridad alta debería producir algo parecido a esto:

Entrada	Resultado esperado
Nombre: Empresa Demo	Se crea una actividad relacionada con el lead
Origen: WhatsApp	El origen queda disponible para el seguimiento
Prioridad: Alta	La tarea vence hoy y genera una alerta
Responsable: Ana	La tarea queda asignada a Ana

Si una de esas cuatro cosas no ocurre, no añadas más pasos todavía. Corrige primero el trigger, la condición o la función que corresponde.

Antes de comenzar: define los datos

Un workflow es tan confiable como los datos que recibe. Para este ejemplo, prepara un módulo Leads con campos parecidos a estos:

• nombre: nombre del contacto o empresa.
• origen: WhatsApp, formulario, referido, llamada u otro canal.
• prioridad: Alta, Media o Baja.
• responsable: usuario encargado del seguimiento.
• proximaAccion: fecha o descripción del siguiente paso.

No tienes que copiar estos nombres literalmente. Lo importante es que puedas responder quién es el lead, de dónde llegó, quién lo atiende y qué debe ocurrir después.

Para hacer una prueba controlada, crea estos dos registros. Puedes copiarlos a una hoja de cálculo y cargarlos manualmente si tu instancia permite importar datos:

nombre,origen,prioridad,responsable,proximaAccion
Empresa Demo,WhatsApp,Alta,Ana,Contactar hoy
Comercial Ejemplo,Formulario,Media,Carlos,Contactar en 48 horas

El primer registro debe seguir la rama prioritaria y el segundo la rama normal. Tener un caso que cumple la condición y otro que no la cumple es más útil que probar sólo el camino “feliz”.

También escribe el resultado esperado antes de abrir el editor:

“Cada lead nuevo debe tener una tarea de seguimiento y, si es prioritario, una alerta inmediata”.

Paso 1: crea el workflow

1. Entra a tu instancia de Corteza.
2. Abre la aplicación Workflows.
3. Pulsa New Workflow.
4. Completa los metadatos:
   • Label: Seguimiento de nuevos leads.
   • Handle: seguimiento-nuevos-leads.
   • Description: Crea una tarea de seguimiento según la prioridad del lead.
   • Run as: comienza con el usuario que invoca el flujo, salvo que tengas una razón clara para usar otro contexto de seguridad.

El handle debe ser único, comenzar por un carácter, tener como máximo 64 caracteres y utilizar letras, números, guion, guion bajo o punto. Usar handles hace que tus workflows sean más fáciles de leer y mover entre ambientes.

Figura 2. Antes de añadir pasos, define el nombre, el handle, la descripción y si el workflow estará activado.

Paso 2: añade el trigger

El trigger define qué recurso, qué evento y qué condiciones ponen en marcha el workflow.

1. Desde la barra de herramientas, arrastra un paso Trigger al lienzo.
2. Abre su configuración.
3. Selecciona el recurso relacionado con los registros de Compose, o el nombre equivalente que muestre tu instancia.
4. Elige el evento de creación posterior, normalmente afterCreate, para reaccionar cuando el lead ya fue guardado.
5. Añade restricciones:
   • Namespace: tu namespace de CRM.
   • Module: Leads.
6. Comprueba que el trigger esté habilitado.

Las restricciones son importantes. Un trigger demasiado amplio puede ejecutar el workflow para registros de otros módulos o namespaces. La documentación oficial recomienda limitarlo tanto como sea posible.

Para esta prueba, tu configuración debería poder resumirse así:

Resource: Compose Record
Event: afterCreate
Constraint 1: Namespace = CRM
Constraint 2: Module = Leads
Enabled: true

Si tu instalación muestra etiquetas diferentes, conserva la misma lógica: registro creado, dentro del namespace correcto y sólo en el módulo que quieres automatizar.

Figura 3. El trigger combina recurso, evento y estado habilitado. El nombre visible de la etiqueta se actualiza automáticamente.

Figura 4. Las restricciones limitan el alcance del trigger; debajo aparece el scope inicial disponible para las expresiones.

Al trabajar con registros, el scope inicial suele incluir el registro actual, su versión anterior cuando aplica, el módulo relacionado, el namespace y posibles errores de validación. Revisa el panel de scope de tu versión para confirmar los nombres exactos de las variables.

Paso 3: crea la condición

Para separar los leads prioritarios de los demás, arrastra un gateway exclusivo después del trigger y conecta ambos pasos.

Un gateway exclusivo evalúa sus conectores en orden y continúa sólo por el primer camino cuya condición sea verdadera. En el primer conector escribe una expresión equivalente a:

lead.values.prioridad == "Alta"

lead y prioridad son nombres de ejemplo. En tu instancia debes utilizar la variable y el nombre de campo que aparecen en el scope. Corteza utiliza un lenguaje de expresiones basado en Gval; expresiones como total > 1000000, estado == "Ganado" o record.recordID != "0" son patrones habituales en la documentación.

Si el scope de tu trigger llama record al registro actual, la misma condición quedaría así:

record.values.prioridad == "Alta"

No copies ambas expresiones. Usa sólo la que corresponda al nombre visible en tu editor. Si el campo es una selección, escribe exactamente el valor guardado —por ejemplo Alta— y no necesariamente el texto que aparece en otro idioma en la interfaz.

Nombra los conectores para que el diagrama se entienda sin abrir cada configuración:

• Prioridad alta.
• Prioridad normal.

Figura 5. La pasarela exclusiva muestra dos caminos: una rama prioritaria y una salida alternativa. Haz clic en la etiqueta de cada camino para nombrarla y revisar su configuración.

En algunas instalaciones la salida alternativa aparece como Else (if) y la ventana del camino sólo muestra su etiqueta. Si tu versión no presenta un campo de expresión en ese panel, conserva la rama Else como salida por defecto y coloca la evaluación en un paso Expresiones o sigue la configuración de gateways de tu versión. No asumas que una etiqueta por sí sola está evaluando una condición.

El segundo camino puede quedar como salida por defecto si no tiene una condición específica. Si necesitas que varias acciones se ejecuten al mismo tiempo, usa un gateway fork. Si más de una condición puede cumplirse y quieres ejecutar cada camino válido, usa un gateway inclusivo. Revisa los tipos de gateway.

Paso 4: añade las acciones

Camino de prioridad alta

Después del conector Prioridad alta añade un paso Function.

En la lista de funciones, busca la operación para crear un registro en el módulo de tareas o actividades. Configura:

• El namespace y módulo donde se guardará la tarea.
• El nombre del lead como referencia.
• El responsable del lead como asignado.
• Una fecha de seguimiento para hoy.
• Una descripción como Contactar lead prioritario: {{nombre}}.

Después puedes añadir otra función para enviar una notificación o correo interno. Usa valores constantes para textos fijos y expresiones para los datos que cambian en cada ejecución. Corteza documenta las funciones como operaciones configurables: crear registros, enviar notificaciones, registrar información y otras acciones dependen de los recursos habilitados en tu instancia.

Una forma sencilla de revisar la acción antes de guardarla es completar esta matriz:

Argumento de la función	Valor de prueba
Módulo destino	Actividades o Tareas
Referencia del lead	El identificador del registro actual
Responsable	El usuario del campo responsable
Fecha límite	La fecha de hoy
Descripción	Contactar lead prioritario: Empresa Demo

Si el responsable está vacío, decide qué debe ocurrir: crear una tarea para un usuario de respaldo, detener el flujo con un error claro o enviar una alerta al administrador. Automatizar un dato incompleto sin una regla de respaldo sólo mueve el problema a otro lugar.

Figura 6. Una función define la operación que se ejecutará y muestra los argumentos obligatorios y el resultado que devuelve.

Camino de prioridad normal

Repite la acción de creación de tarea en el segundo camino, pero asigna una fecha posterior y un texto como Primer contacto en 48 horas.

Si varias ramas necesitan exactamente la misma acción, puedes reunirlas después del gateway o duplicar el paso cuando el diagrama sea más fácil de mantener así. La legibilidad es una parte importante de la automatización: otra persona debe poder entender el flujo sin reconstruirlo mentalmente.

Paso 5: guarda y activa el workflow

En Corteza no basta con configurar visualmente los pasos:

1. Guarda el workflow con el botón de guardado o Ctrl + S.
2. Verifica que el trigger esté marcado como habilitado.
3. Comprueba que todas las conexiones tengan origen y destino.
4. Revisa que cada función tenga sus argumentos obligatorios.
5. Crea un lead de prueba en el módulo correcto.

La configuración de los pasos puede guardarse localmente en el editor, pero el workflow debe guardarse para que los cambios tengan efecto. “Activar” en la práctica significa que el workflow está guardado y sus triggers están habilitados; no lo confundas con publicar un artículo o desplegar una aplicación.

Figura 7. La lista permite comprobar que el workflow existe, está activo y cuántos pasos tiene. Esta comprobación no sustituye la prueba con un registro real.

Paso 6: prueba con datos controlados

Haz dos pruebas y cambia una variable cada vez:

Prueba A: prioridad alta

• Crea un lead con prioridad = Alta.
• Confirma que se cree una tarea para hoy.
• Confirma que llegue la alerta esperada.
• Revisa que el responsable y la referencia al lead sean correctos.

Prueba B: prioridad normal

• Crea otro lead con prioridad = Media.
• Confirma que siga el segundo camino.
• Comprueba que no se envíe la alerta de prioridad alta.

Resultado mínimo que debes observar

Considera la prueba aprobada sólo si puedes responder “sí” a estas preguntas:

• ¿El workflow se ejecutó una sola vez por cada registro?
• ¿La prioridad alta tomó el camino correcto?
• ¿La tarea quedó relacionada con el lead?
• ¿El responsable puede ver y completar la tarea?
• ¿Un lead sin responsable produjo un resultado controlado?

Guarda una captura o anota el resultado de estas pruebas. Esa pequeña evidencia te ayudará cuando cambies un campo, migres el workflow o tengas que explicar el proceso a otra persona.

Si el resultado no coincide, revisa primero el trigger y sus restricciones; después revisa la expresión del gateway; por último, valida los argumentos de las funciones. Esta secuencia evita buscar el problema en todo el diagrama a la vez.

Para probar un workflow manualmente, crea un trigger System / onManual y utiliza el icono de ejecución del trigger. Es una forma útil de probar expresiones y funciones antes de conectarlas a datos reales. La documentación oficial también recomienda revisar las sesiones de ejecución para encontrar errores.

Qué hacer cuando una ejecución falla

Añade un error handler alrededor de las acciones que dependen de datos dinámicos o servicios externos. Ese bloque funciona como un try/catch: si una operación falla, puedes registrar el error, avisar a un administrador o crear una tarea de revisión.

Ten presentes estas tres precauciones:

1. Evita ciclos infinitos. Si el trigger se activa al actualizar un registro y el mismo workflow vuelve a actualizarlo, puedes provocar ejecuciones repetidas. Usa una condición, un campo de control o un evento más específico.
2. Revisa permisos. Por defecto, el workflow utiliza los permisos del usuario que originó la acción. Si ese usuario no puede leer o modificar un recurso, la automatización puede fallar.
3. Distingue síncrono de asíncrono. Un paso de espera (delay) o de interacción (prompt) vuelve asíncrono el workflow. En ese caso ya no puedes usarlo para invalidar la operación original de creación, edición o eliminación.

La documentación de automatización de Corteza explica estos límites y también cómo usar scripts cuando un workflow visual no cubre una lógica suficientemente compleja. Consulta automatización, permisos y ejecución.

Diagnóstico rápido

Síntoma	Revisa primero	Corrección habitual
No se ejecuta	Trigger y estado habilitado	Guardar el workflow y confirmar el evento
Se ejecuta para demasiados registros	Restricciones de namespace y módulo	Añadir todas las restricciones posibles
La condición nunca coincide	Nombre de variable o valor guardado	Revisar el scope y usar el valor exacto
La tarea no aparece	Permisos y argumentos de la función	Probar con el mismo usuario que invoca el flujo
Se repite varias veces	El workflow actualiza el registro que lo activa	Añadir un campo de control o cambiar el evento
Se queda esperando	Gateway inclusivo o ramas sin resolución	Revisar las conexiones y terminar cada camino

No intentes solucionar todos los síntomas añadiendo más pasos. Cambia una sola configuración, ejecuta de nuevo las dos pruebas y registra qué cambió.

Acciones que puedes automatizar

Una vez que entiendas el patrón trigger → condición → acción, puedes construir flujos como estos:

• Crear una tarea cuando un lead lleva varios días sin actividad.
• Cambiar el estado de una oportunidad después de registrar una cotización.
• Enviar una notificación cuando una renovación se acerque.
• Crear un registro relacionado, como una actividad, caso o seguimiento.
• Ejecutar un proceso diariamente con un trigger de intervalo.
• Recibir un webhook desde un formulario o una aplicación externa mediante Integration Gateway.
• Procesar una lista de registros con un iterator.
• Llamar un script de Corredor cuando necesites una integración o lógica que no exista como función nativa.

Tres automatizaciones que una pyme puede probar después

1. Recuperar una cotización olvidada

Trigger: una oportunidad pasa a Cotizada. Condición: han transcurrido tres días sin actividad. Acción: crear una tarea para el responsable y mostrarla en un panel de seguimiento.

2. Recibir un formulario web

Trigger: una petición POST llega al Integration Gateway. Condición: el correo no está vacío y el consentimiento está marcado. Acción: crear el contacto, crear la oportunidad y asignarla según ciudad o producto.

3. Preparar renovaciones

Trigger: ejecución diaria por intervalo. Condición: la fecha de renovación está dentro de los próximos 30 días y el estado no es Renovado. Acción: crear una tarea, enviar una notificación y registrar la fecha del último aviso.

En los tres casos conviene empezar con un solo resultado medible. Por ejemplo: “ninguna cotización sin siguiente acción durante más de tres días”. Si no puedes medir el resultado, todavía no sabrás si la automatización mejoró el proceso.

Para calendarios, Corteza admite triggers por intervalo con expresiones cron y triggers con timestamp. Para integraciones externas, el Integration Gateway puede recibir peticiones HTTP y entregarlas a un workflow. Consulta los ejemplos oficiales.

De un workflow a una integración con API o IA

Un workflow no tiene que vivir aislado. La API puede conectar el proceso con un formulario, una herramienta de facturación, un calendario o un canal de mensajería. El orden recomendado es:

1. Diseña y prueba el workflow dentro de Corteza.
2. Expón sólo la operación necesaria mediante la API o un webhook.
3. Define autenticación, permisos, límites y registro de actividad.
4. Añade un agente de IA sólo para tareas concretas y reversibles, como resumir oportunidades vencidas o proponer el siguiente paso.
5. Exige confirmación humana antes de enviar mensajes, eliminar registros o cambiar estados sensibles.

Por ejemplo, un agente podría consultar “¿qué leads prioritarios no tienen actividad esta semana?” y devolver un resumen basado en los datos autorizados. No debería modificar oportunidades o enviar mensajes automáticamente sólo porque tiene acceso a la API.

La documentación de Corteza indica que un workflow puede ejecutar scripts cuando la lógica no está disponible como función nativa. Eso permite combinar una automatización visual con una integración más especializada sin esconder toda la lógica dentro de código. Ejecución de scripts desde workflows.

Checklist antes de usarlo en producción

• El nombre y el handle describen el objetivo.
• El trigger usa el recurso y evento correctos.
• El namespace y módulo están restringidos.
• Las condiciones usan los nombres reales del scope.
• Cada camino tiene una salida clara.
• Las funciones tienen permisos y argumentos válidos.
• Hay tratamiento para errores importantes.
• Se probó con un caso que cumple la condición y otro que no.
• Se revisó el riesgo de ejecutar el mismo workflow varias veces.
• El workflow está guardado y el trigger está habilitado.
• Existe una forma de revisar sesiones, logs o registros de auditoría.
• El equipo sabe qué hacer cuando una acción automática falla.
• Hay una persona responsable de revisar el workflow después de los primeros días.

Cierre: empieza con una sola regla

El mejor primer workflow no es el más grande. Es una regla pequeña que el equipo repite todas las semanas y que hoy depende de la memoria de alguien: asignar un lead, recordar una fecha, avisar de una renovación o registrar una actividad.

Empieza con un trigger, una condición y una acción. Mide el resultado. Después añade ramas, notificaciones e integraciones sólo cuando el proceso básico ya sea claro.

Si quieres aplicar este patrón a un proceso comercial real, solicita una revisión de tu proceso en Abera CRM. La conversación debe ayudarte a identificar qué automatizar primero, qué datos faltan y qué permisos necesitas; no tienes que comprar nada para empezar a ordenar el flujo.

Abera trabaja sobre Corteza para adaptar módulos, permisos, paneles, workflows e integraciones al contexto de cada negocio. También puedes revisar otros recursos prácticos de CRM o conocer el acceso anticipado.

Bloque para Medium: si esta guía te ayudó, compártela con la persona que hoy asigna seguimientos manualmente. Para probar el ejemplo en un proceso real, solicita una revisión de tu proceso con Abera CRM. Conserva los enlaces a la documentación oficial de Corteza para que el lector pueda verificar cada concepto.

Fuentes oficiales

• Workflows de Corteza 2024.9
• Expresiones de Corteza
• Buenas prácticas para workflows
• Ejemplos de workflows
• Ejecución de scripts desde un workflow

Etiquetas:

• Corteza
• workflows
• automatización
• CRM
• API
• low-code