Se connecter

Soumissions de formulaires WordPress et workflows avec Flow

En mode Pro, Flow inclut une application d’administration intégrée à l’admin WordPress. Elle couvre des domaines tels que :

  • Paramètres généraux
  • Paramètres d’API
  • Soumissions
  • Modèles
  • Flux de travail

C’est la couche opérationnelle des formulaires alimentés par Flow. L’éditeur de blocs frontend définit l’expérience du formulaire, tandis que l’application d’administration gouverne le stockage, les modèles, l’exécution des workflows et l’intégration backend.

Paramètres d’API​

L’écran des paramètres d’API contrôle la manière dont Flow communique avec le backend. Les concepts importants incluent :

  • le transport backend (gatey ou fetch)
  • le nom de l’API backend
  • l’URL de base du backend
  • le mode d’authentification AWS (COGNITO, IAM, NONE)

Dans la configuration Pro recommandée, vous enregistrez d’abord l’API du backend Flow dans Gatey, puis vous sélectionnez cette API dans les paramètres d’API de Flow.

Soumissions​

Avec le backend Pro connecté, Flow peut fournir des opérations sur les soumissions telles que :

  • l’affichage de la liste des soumissions,
  • le filtrage et le tri,
  • l’affichage des détails,
  • la modification des notes et des étiquettes,
  • le changement de statut,
  • l’affichage de l’historique des événements,
  • le déclenchement d’actions manuelles.

Les actions manuelles sont utiles lorsqu’un opérateur souhaite réinjecter une soumission dans un flux d’automatisation sans modifier le formulaire lui-même. Elles peuvent être limitées par formulaire et sont émises sous forme d’événements pertinents pour les workflows.

Modèles​

Flow Pro inclut des modèles d’e-mail avec corps HTML/texte, prise en charge de l’aperçu et plusieurs moteurs de rendu. Les modèles sont généralement utilisés par les étapes d’e-mail des workflows, mais le même modèle de variables est aussi important lorsque Flow consomme des événements normalisés provenant de pipelines d’ingestion d’e-mails du backend AI Kit.

Flux de travail​

Les workflows Flow Pro sont pilotés par événements. Ils réagissent à des événements nommés, puis exécutent une ou plusieurs étapes d’action.

Les surfaces de déclenchement actuelles incluent :

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

Les types d’étape actuels incluent :

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

Étapes de workflow d’agent IA​

L’étape ai.agent est différente du bloc de suggestions IA de l’interface publique. Elle émet un événement ai.agent.requested vers le backend IA, puis les workflows en aval continuent à partir de ai.agent.completed ou ai.agent.failed.

Prérequis opérationnel :

  • le backend Flow est responsable du stockage et de la diffusion de l’événement de workflow
  • le backend AI Kit est le composant qui traite effectivement ai.agent.requested

En d’autres termes, activer les étapes de workflow IA n’est pas seulement une affaire de backend Flow. Un vrai déploiement nécessite aussi le répartiteur du backend AI Kit et sa configuration de modèle. Si vous souhaitez un comportement IA fondé, il faut en plus une base de connaissances configurée.

Cette séparation vous donne une distinction nette entre :

  • l’assistance frontend avant qu’un utilisateur ne soumette,
  • la classification ou le routage backend après que la plateforme a accepté une soumission.

Les étapes de mise à jour de statut peuvent aussi produire des déclencheurs submission.updated en aval, ce qui vous permet de modéliser les transitions d’état comme partie d’un processus plus large.

L’UI de l’étape IA expose la configuration suivante :

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

Interprétation recommandée :

  • utilisez Mode pour l’intention de la tâche,
  • utilisez Internal routing uniquement lorsque vous voulez un branchement en aval détenu par Flow,
  • utilisez les clés de route et de résultat comme identifiants canoniques stables,
  • utilisez le schéma de réponse comme un vrai contrat d’exécution, et pas seulement comme une documentation.

Réserve importante :

  • No internal routing supprime le bloc de garde-fou de routage de Flow, mais ne supprime pas automatiquement un ancien schéma de réponse personnalisé déjà laissé dans l’éditeur.

Pour l’explication complète champ par champ, voir Étape de workflow d’agent IA.

EventBridge et systèmes externes​

eventbridge.event et webhook.call permettent à Flow de participer à des topologies d’automatisation plus larges. C’est utile lorsque Flow n’est qu’une source d’entrée parmi d’autres, ou lorsque vous voulez diffuser une soumission vers des pipelines de traitement natifs AWS ou tiers.

Relation avec l’ingestion d’e-mails du backend AI Kit​

Les workflows Flow ne se limitent pas aux soumissions de formulaires navigateur. Dans les déploiements actuels, ils peuvent aussi se placer derrière des pipelines d’ingestion d’e-mails du backend AI Kit tels que :

  • 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 -> ...

Dans ces configurations, les modèles Flow et les étapes de workflow consomment un contrat d’événements normalisé plutôt que de simples champs de formulaire bruts. C’est ce qui permet à une seule couche de workflow de traiter à la fois les soumissions provenant du web et les demandes reçues par e-mail.

Les actions manuelles peuvent aussi redéclencher un comportement de type workflow sans nécessairement modifier le statut.