Disparar workflows desde un botón de chat, de punta a punta

Un botón que dispara un workflow se ve simple — haces clic, el workflow corre — pero la regla de elegibilidad, el contrato del payload y el espacio de variables del que lee el workflow son lo suficientemente específicos como para que un solo detalle mal puesto (un workflow que no es api_trigger, un payload que es un arreglo en vez de un objeto) falle de forma ruidosa en lugar de silenciosa. Este es el contrato completo.

Elegibilidad: solo workflows api_trigger

Un workflow de Dailybot tiene un tipo de evento — schedule, envío de formulario, finalización de check-in, o api_trigger (“When triggered via API or button”). Solo los workflows api_trigger se pueden disparar desde afuera — vía la CLI, el endpoint REST, o el callback_workflow de un botón de chat. Cualquier otra cosa devuelve 400 workflow_not_triggerable.

Los workflows se crean y editan exclusivamente en la web app de Dailybot — no existe una ruta de CLI para crear o cambiar uno. Una vez que existe un workflow api_trigger, resuelve su UUID:

dailybot workflow list --filter api_trigger --json

--filter api_trigger es una conveniencia del lado del cliente sobre el workflow list estándar — devuelve solo los workflows que puedes disparar legítimamente. Inspecciona la configuración de uno con:

dailybot workflow get <workflow_uuid> --json

Trata el JSON devuelto como la fuente de verdad de lo que el workflow realmente hace — no adivines a partir de su nombre.

Dispararlo directamente (CLI / API)

# Fire it, no payload
dailybot workflow trigger <workflow_uuid> --json

# Fire it with a JSON payload the workflow can read
dailybot workflow trigger <workflow_uuid> \
  --payload '{"version": "v2.5", "environment": "production"}' --json

Equivalente HTTP:

curl -s -X POST \
  -H "Authorization: Bearer $DAILYBOT_BEARER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"payload": {"version": "v2.5"}}' \
  https://api.dailybot.com/v1/workflows/<workflow_uuid>/trigger/

Un disparo exitoso devuelve HTTP 202 — la ejecución queda en cola, no es síncrona, y la respuesta no lleva ningún output de la ejecución; el workflow corre en el servidor de forma asíncrona. --payload (o el payload del cuerpo del request) debe ser un objeto JSON — no un arreglo, no un escalar — y tiene un tope de 8 KiB; cualquier cosa más grande o malformada devuelve 400 workflow_trigger_payload_invalid. Un workflow congelado (deshabilitado) devuelve 403 workflow_frozen; quien llama sin permiso de ejecución recibe 403 workflow_execute_not_allowed; un UUID desconocido devuelve 404.

Confirma antes de disparar. workflow trigger tiene efectos secundarios — puede iniciar un despliegue o cualquier otra automatización. Repite el workflow objetivo (nombre + UUID) y el payload (o “sin payload”) y espera un sí explícito antes de dispararlo desde un contexto de agente.

Dispararlo desde un botón de chat

El mismo disparo del lado del servidor ocurre cuando se hace clic en el callback_workflow del botón de un mensaje:

curl -sS -X POST 'https://api.dailybot.com/v1/send-message/' \
  -H 'X-API-KEY: $DAILYBOT_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "message": "Ready to redeploy staging?",
    "target_channels": ["C0123456789"],
    "buttons": [
      {"label": "Redeploy staging", "button_type": "interactive", "value": "redeploy_staging",
       "callback_workflow": "$REDEPLOY_WORKFLOW_UUID"}
    ]
  }'

Atajo de CLI:

dailybot chat send -c C0123456789 -m "Ready to redeploy staging?" \
  --workflow-button "Redeploy staging=$REDEPLOY_WORKFLOW_UUID"

callback_workflow recibe solo el UUID del workflow — nombres y slugs se rechazan. UUIDs desconocidos, inactivos o de otra organización devuelven 400 button_callback_workflow_not_found. No ocurre ninguna llamada HTTP externa y no interviene ningún secreto de firma: el disparo es enteramente interno a Dailybot, atribuido al usuario que hizo clic.

Disparado por botón vs. disparado por API — mismo mecanismo, una variable los distingue

Ambos caminos pasan por el mismo mecanismo de disparo del lado del servidor. La única diferencia visible para los propios pasos del workflow es {{trigger.source}}, que resuelve a "api", "button_click" o "modal_submit" — así un mismo workflow puede ramificar su comportamiento (por ejemplo, saltarse un paso de confirmación cuando lo dispara un clic ya confirmado, pero preguntar de nuevo cuando lo dispara directamente la API).

Leer el contexto del clic dentro del workflow

Los pasos del workflow disparado referencian el contexto del disparo a través del espacio de nombres {{trigger.*}}:

Variable	Valor
{{trigger.source}}	"api" | "button_click" | "modal_submit"
{{trigger.button_value}}	El value del botón que se clicó
{{trigger.button_id}}	El $btn/<uuid4> generado por el servidor
{{trigger.fields.<name>}}	El valor enviado de un input de modal_body, si el botón abrió un modal primero
{{trigger.clicked_at}}	Timestamp del clic
{{trigger.body.*}}	El objeto crudo de --payload, cuando se dispara directamente vía API/CLI
{{trigger.user.*}}	uuid, full_name, first_name, email, role del usuario que hizo clic o disparó
{{trigger.triggered_by_user_uuid}}	Atajo al UUID del usuario que disparó

Un workflow, varios botones

En vez de crear workflows casi duplicados para variar una etiqueta, apunta varios botones al mismo UUID de callback_workflow con distintos value, y ramifica dentro del workflow según {{trigger.button_value}}:

{"message": "Choose a rollback target",
 "target_channels": ["C0123456789"],
 "buttons": [
   {"label": "Rollback to v2.3", "button_type": "interactive", "value": "v2.3", "callback_workflow": "$ROLLBACK_WORKFLOW_UUID"},
   {"label": "Rollback to v2.2", "button_type": "interactive", "value": "v2.2", "callback_workflow": "$ROLLBACK_WORKFLOW_UUID"}
 ]}

Modal → workflow: recolectar input antes del disparo

modal_body se combina con callback_workflow — el clic abre el modal, y al enviarlo los valores de los campos se entregan como {{trigger.fields.<input.name>}}, sin ningún servidor externo de por medio:

{"label": "Report", "button_type": "interactive", "value": "report",
 "callback_workflow": "$INCIDENT_WORKFLOW_UUID",
 "modal_body": {
   "title": "New incident",
   "blocks": [
     {"type": "input", "name": "summary", "label": "What happened?", "multiline": true, "required": true}
   ]
 }}

El workflow puede usar {{trigger.fields.summary}} en cualquier paso — prellenar una respuesta de formulario, componer un mensaje de seguimiento, o alimentar un prompt de IA.

Referencia de errores

Error	Cuándo ocurre
400 workflow_not_triggerable	El tipo de evento del workflow no es api_trigger
400 workflow_trigger_payload_invalid	El payload no es un objeto JSON, o excede 8 KiB
400 button_callback_workflow_not_found	callback_workflow no resuelve a un workflow activo en la organización de quien llama
403 workflow_execute_not_allowed	Quien llama no tiene permiso para ejecutar workflows
403 workflow_frozen	El workflow está deshabilitado
403 plan_upgrade_required	Los workflows no están incluidos en el plan de la organización
404	UUID de workflow desconocido

Referencias cruzadas

• La API send-message, de punta a punta para el contrato completo de botones dentro del cual vive callback_workflow.
• /es/developers/api/workflows para la referencia completa de {{trigger.*}}.
• /es/developers/cli para los flags de workflow list / get / trigger.

Explora el hub de Soluciones para el recorrido orientado a producto de disparar automatizaciones directamente desde el chat.