Iniciar sesión

Envíos de formularios y flujos de trabajo de WordPress con Flow

En el modo Pro, Flow incluye una aplicación de administración integrada en el escritorio de WordPress. Abarca áreas como:

  • Ajustes generales
  • Ajustes de la API
  • Envíos
  • Plantillas
  • Flujos de trabajo

Esta es la capa operativa de los formularios respaldados por Flow. El editor de bloques del frontend define la experiencia del formulario, mientras que la aplicación de administración gobierna el almacenamiento, las plantillas, la ejecución de flujos de trabajo y la integración con el backend.

Ajustes de la API​

La pantalla de ajustes de la API controla cómo se comunica Flow con el backend. Entre los conceptos importantes se incluyen:

  • transporte del backend (gatey o fetch)
  • nombre de la API del backend
  • URL base del backend
  • modo de autenticación de AWS (COGNITO, IAM, NONE)

En la configuración Pro recomendada, primero registra la API del backend de Flow en Gatey y después la selecciona en los ajustes de API de Flow.

Envíos​

Con el backend Pro conectado, Flow puede ofrecer operaciones de envío como:

  • enumerar envíos,
  • filtrar y ordenar,
  • ver detalles,
  • editar notas y etiquetas,
  • cambiar el estado,
  • ver el historial de eventos,
  • invocar acciones manuales.

Las acciones manuales resultan útiles cuando un operador quiere devolver un envío a un flujo de automatización sin editar el formulario. Se pueden limitar por formulario y se emiten como eventos pertinentes para los flujos de trabajo.

Plantillas​

Flow Pro incluye plantillas de correo electrónico con cuerpos HTML y de texto, vista previa y varios motores de renderizado. Las plantillas suelen usarse en pasos de correo de los flujos de trabajo, pero el mismo modelo de variables también es importante cuando Flow consume eventos normalizados procedentes de canalizaciones de recepción de correo electrónico del backend de AI Kit.

Flujos de trabajo​

Los flujos de trabajo de Flow Pro están dirigidos por eventos. Reaccionan a eventos con nombre y después ejecutan uno o varios pasos de acción.

Los activadores actuales incluyen:

  • submission.created
  • submission.updated
  • submission.action-invoked
  • integration.webhook.requested
  • ai.agent.completed
  • ai.agent.failed

Los tipos de pasos actuales incluyen:

  • email.send
  • webhook.call
  • eventbridge.event
  • ai.agent
  • status.update
  • delay

Pasos de agente de IA en flujos de trabajo​

El paso ai.agent es distinto del bloque de Sugerencias de IA del frontend. Emite un evento ai.agent.requested hacia el backend de IA y después los flujos de trabajo posteriores continúan desde ai.agent.completed o ai.agent.failed.

Requisito operativo:

  • el backend de Flow se encarga de almacenar y distribuir el evento del flujo de trabajo
  • el backend de AI Kit es el componente que procesa realmente ai.agent.requested

En otras palabras, activar pasos de IA en flujos de trabajo no concierne únicamente al backend de Flow. Una implementación real también necesita el distribuidor del backend de AI Kit y su configuración de modelo. Para obtener un comportamiento de IA basado en fuentes, también necesita una Knowledge Base configurada.

Esta división proporciona una separación clara entre:

  • la asistencia en el frontend antes de que un usuario envíe,
  • la clasificación o el enrutamiento en el backend después de que la plataforma acepte un envío.

Los pasos de actualización de estado también pueden producir activadores submission.updated posteriores, lo que permite modelar transiciones de estado como parte de un mapa de procesos más amplio.

La interfaz del paso de IA presenta la configuración de:

  • Mode
  • Internal routing
  • Route Keys, Outcome Types y Signal Keys
  • Prompt Text
  • Platform System Block
  • Additional System Guidance
  • Response Constraint
  • Update Status on Dispatch

Interpretación recomendada:

  • use Mode para la intención de la tarea,
  • use Internal routing solo cuando quiera una ramificación posterior propiedad de Flow,
  • use las claves de ruta y resultado como identificadores canónicos estables,
  • use el esquema de respuesta como un verdadero contrato en tiempo de ejecución, no solo como documentación.

Advertencia relevante:

  • No internal routing elimina el bloque de protección de enrutamiento de Flow, pero no borra automáticamente ningún esquema de respuesta personalizado anterior que siga en el editor.

Para ver una explicación completa de cada campo, consulte Paso de agente de IA del flujo de trabajo.

EventBridge y sistemas externos​

eventbridge.event y webhook.call permiten que Flow participe en topologías de automatización más amplias. Resulta útil cuando Flow es una fuente de entrada entre muchas o cuando quiere distribuir un envío hacia canalizaciones de procesamiento nativas de AWS o de terceros.

Relación con la recepción de correo del backend de AI Kit​

Los flujos de trabajo de Flow no se limitan a los envíos de formularios desde el navegador. En las implementaciones actuales también pueden situarse detrás de canalizaciones de recepción de correo electrónico del backend de AI Kit como:

  • WorkMail -> ai-email-intake-proxy -> ai-email-intake-dispatcher -> Flow workflow -> email.send
  • WorkMail -> ai-email-intake-proxy -> ai-email-intake-dispatcher -> Flow workflow -> ai.agent -> ...

En estas configuraciones, las plantillas y los pasos de flujo de trabajo de Flow consumen un contrato de eventos normalizado en lugar de limitarse a los campos brutos del formulario. Esto permite que una sola capa de flujos de trabajo gestione tanto envíos procedentes del navegador como consultas recibidas por correo electrónico.

Las acciones manuales también pueden volver a activar un comportamiento similar al de un flujo de trabajo sin cambiar necesariamente el estado.