Entradas del Workflow
- Qué son las entradas del workflow y qué variables expone cada tipo de trigger
- Cómo referenciar esas variables con expresiones CEL en los pasos
- Cómo definir entradas personalizadas para workflows manuales
Las entradas del workflow son los valores que transportan datos desde el evento trigger hacia los pasos de tu workflow. Los lees dentro de los pasos con expresiones CEL (Common Expression Language), de modo que cada paso se adapta a los datos específicos de cada ejecución en lugar de usar valores fijos.
Cómo funcionan los campos CEL
Cada campo habilitado para CEL en un paso (texto, URL, body, filtro, condición, etc.) recibe un valor en el formato de objeto {expr: "..."}. Cuando el workflow se ejecuta, la expresión dentro de expr se evalúa contra el contexto de ejecución actual y se reemplaza con el resultado.
Por ejemplo, el campo de texto de un paso de mensaje puede ser:
{"expr": "'Hello ' + contact.name + ', your appointment is confirmed for ' + format_datetime(occurrenceDate, 'YYYY-MM-DD')"}
Si contact.name es "Maria Silva" y occurrenceDate es el 15 de marzo de 2025, el paso envía:
"Hello Maria Silva, your appointment is confirmed for 2025-03-15."
Para campos con mucho texto también puedes usar la función tpl(), que rellena los placeholders de llave simple {key} desde un objeto de valores: tpl('Hello {name}', {name: contact.name}).
La sintaxis de llaves dobles {{ }} no aplica aquí — solo existe en las plantillas de mensaje de WhatsApp.
Variables por tipo de trigger
Las variables disponibles para un workflow dependen de su tipo de trigger. Estas siempre están presentes:
| Variable | Descripción |
|---|---|
company | El objeto de la empresa (companyName, _id, options, planId) |
step(N) | La salida del paso N (indexado desde 0), ej.: step(0).data |
Un trigger hook (se dispara al crear/actualizar/eliminar un documento) también expone:
| Variable | Descripción |
|---|---|
doc | El documento que se está creando, actualizando o eliminando |
prev | El estado anterior del documento (solo en actualizaciones) |
op | La operación del ciclo de vida que disparó el hook, ej.: afterCreate, afterUpdate o afterDelete (uno de beforeSave/afterSave/beforeCreate/afterCreate/beforeUpdate/afterUpdate/beforeDelete/afterDelete) |
model | El modelo dynadata que disparó el hook (ej.: contacts, ct:events) |
Un trigger temporal (se ejecuta según una programación) expone:
| Variable | Descripción |
|---|---|
occurrenceDate | La fecha/hora programada para esta ocurrencia |
Cuando un workflow se ejecuta desde una conversación con un agente, las variables del contexto del agente también quedan accesibles, incluyendo contact (contact.name, contact.contactIdentification para el identificador del canal, como un número de teléfono o nombre de usuario, y contact.channelType para el canal) y contactMessage (contactMessage.body.text para el texto de un mensaje recibido).
Usar entradas en los pasos
Al configurar un paso en la sección Pasos, define cada campo CEL con un valor {expr: "..."} que referencie las variables anteriores. Puedes combinar texto estático con varias variables en una sola expresión:
{"expr": "'Dear ' + contact.name + ', you have an upcoming appointment on ' + format_datetime(occurrenceDate, 'DD/MM/YYYY') + '.'"}
Entradas personalizadas para workflows manuales
Cuando un workflow usa un trigger manual, puedes definir campos de entrada personalizados en la sección Parámetros. El profesional los completa antes de ejecutar el workflow — útil cuando el workflow necesita información que ningún evento automático proporciona.
Cada parámetro tiene un nombre, un tipo y una descripción opcional. El nombre se convierte en una variable CEL de nivel superior: un parámetro llamado report_date se referencia como report_date (no parameters.report_date).
Tipos de parámetro
| Tipo | Qué introduce el profesional |
|---|---|
string | Texto libre — o una lista fija, ver Valores permitidos más abajo |
number | Un valor numérico |
boolean | Una casilla de verificación |
datetime | Una fecha/hora |
ref | Un documento elegido de otro model — indica cuál con el selector Ref: events, conversations, messages, contacts, services, agents, webhooks, workflows, employees o notifications |
file | Un archivo del almacenamiento de tu workspace |
El valor de ejecución de un parámetro file es un objeto de referencia de almacenamiento -- {bucket, fullPath, name?} -- no una cadena con una ruta. La referencia se valida contra tu workspace al inicio de la ejecución, antes de crear ningún registro de ejecución: una referencia que apunta fuera de tu workspace, o a un archivo que no está, rechaza la ejecución con Workflow input '<name>' file was not found or is not accessible from this workspace. (el mismo mensaje en ambos casos, para que el error no sirva para sondear archivos de otros workspaces). Pasa el objeto de referencia completo a un paso que acepte archivos. El inputFiles de la acción de código recibe un array de referencias, así que un parámetro contract entra como {expr: "[contract]"} -- pasar {expr: "contract"} hace que el paso falle con inputFiles must evaluate to an array of storage refs.
Opciones por parámetro
- Requerido -- desactivado de forma predeterminada. El modal de ejecución no envía hasta que un parámetro requerido esté completo. Solo los parámetros
filese vuelven a comprobar en el servidor: unfilerequerido dejado vacío rechaza la ejecución antes de que se ejecute nada. Para los demás tipos el indicador no se vuelve a comprobar cuando la ejecución llega desde la API/v1, una acción de workflow o el MCP. - Valores permitidos (solo parámetros
string) -- activa Enable Enums y enumera los valores permitidos en Enum. El modal de ejecución pasa a mostrar una lista con esos valores en lugar de un campo de texto libre. Esto es metadato del modal de ejecución, no una regla de validación: nada comprueba el valor de la ejecución contra la lista, así que una ejecución iniciada a través de la API/v1, una acción de workflow o el MCP puede llevar cualquier string. Protege el valor dentro del propio workflow cuando un valor fuera de la lista pueda causar daño. - Ref (solo parámetros
ref) -- de qué model lee el selector, entre los diez listados arriba.
Por ejemplo, define un parámetro report_date; el profesional lo ingresa al hacer clic en Ejecutar, y tus pasos lo leen como:
{"expr": "report_date"}
El mismo workflow produce entonces resultados diferentes según lo que el profesional ingrese cada vez.