Anmelden

WordPress-Formularübermittlungen und Workflows mit Flow

Im Pro-Modus enthält Flow eine in den WordPress-Admin eingebettete Admin-Anwendung. Sie umfasst Bereiche wie:

  • Allgemeine Einstellungen
  • API-Einstellungen
  • Übermittlungen
  • Vorlagen
  • Workflows

Dies ist die Betriebsebene für Flow-gestützte Formulare. Der Frontend-Blockeditor definiert das Formularerlebnis, während die Admin-Anwendung Speicherung, Vorlagen, Workflow-Ausführung und Backend-Integration steuert.

API-Einstellungen​

Die API-Einstellungen legen fest, wie Flow mit dem Backend kommuniziert. Wichtige Konzepte sind:

  • Backend-Transport (gatey oder fetch)
  • Backend-API-Name
  • Backend-Basis-URL
  • AWS-Authentifizierungsmodus (COGNITO, IAM, NONE)

In der empfohlenen Pro-Einrichtung registrieren Sie zuerst die Flow-Backend-API in Gatey und wählen sie anschließend in den API-Einstellungen von Flow aus.

Übermittlungen​

Bei verbundenem Pro-Backend bietet Flow unter anderem folgende Vorgänge für Übermittlungen:

  • Übermittlungen auflisten,
  • filtern und sortieren,
  • Details anzeigen,
  • Notizen und Schlagwörter bearbeiten,
  • Status ändern,
  • Ereignisverlauf anzeigen,
  • manuelle Aktionen auslösen.

Manuelle Aktionen sind hilfreich, wenn ein Betreiber eine Übermittlung erneut in einen Automatisierungsablauf geben möchte, ohne das Formular selbst zu bearbeiten. Sie können pro Formular begrenzt werden und werden als workflowrelevante Ereignisse ausgegeben.

Vorlagen​

Flow Pro enthält E-Mail-Vorlagen mit HTML- und Textinhalten, Vorschauunterstützung und mehreren Rendering-Engines. Vorlagen werden üblicherweise von E-Mail-Schritten in Workflows genutzt. Dasselbe Variablenmodell ist auch relevant, wenn Flow normalisierte Ereignisse aus E-Mail-Eingangspipelines des AI-Kit-Backends verarbeitet.

Workflows​

Flow-Pro-Workflows sind ereignisgesteuert. Sie reagieren auf benannte Ereignisse und führen anschließend einen oder mehrere Aktionsschritte aus.

Zu den aktuellen Auslösern gehören:

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

Zu den aktuellen Schritttypen gehören:

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

KI-Agent-Workflow-Schritte​

Der Schritt ai.agent unterscheidet sich vom Frontend-Block AI Suggestions. Er sendet ein Ereignis ai.agent.requested an das KI-Backend. Nachgelagerte Workflows werden anschließend durch ai.agent.completed oder ai.agent.failed fortgesetzt.

Betriebliche Voraussetzung:

  • Das Flow-Backend speichert und verteilt das Workflow-Ereignis.
  • Das AI-Kit-Backend verarbeitet ai.agent.requested tatsächlich.

Das Aktivieren von KI-Workflow-Schritten betrifft somit nicht nur das Flow-Backend. Eine reale Bereitstellung benötigt außerdem den Dispatcher und die Modellkonfiguration des AI-Kit-Backends. Für wissensgestütztes KI-Verhalten ist zusätzlich eine konfigurierte Knowledge Base erforderlich.

Diese Aufteilung trennt klar zwischen:

  • Frontend-Unterstützung vor der Übermittlung durch einen Benutzer,
  • Backend-Klassifizierung oder -Weiterleitung, nachdem die Plattform eine Übermittlung angenommen hat.

Statusaktualisierungsschritte können zudem nachgelagerte submission.updated-Auslöser erzeugen. So lassen sich Zustandsübergänge als Teil einer größeren Prozesskarte modellieren.

Die Oberfläche des KI-Schritts bietet Einstellungen für:

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

Empfohlene Auslegung:

  • Verwenden Sie Mode für die Aufgabenabsicht.
  • Verwenden Sie Internal routing nur für von Flow gesteuerte nachgelagerte Verzweigungen.
  • Nutzen Sie Routen- und Ergebnisschlüssel als stabile kanonische Bezeichner.
  • Behandle das Antwortschema als echten Laufzeitvertrag und nicht nur als Dokumentation.

Wichtige Einschränkung:

  • No internal routing entfernt den Routing-Schutzblock von Flow, löscht aber kein älteres benutzerdefiniertes Antwortschema, das bereits im Editor steht.

Eine vollständige Erklärung aller Felder finden Sie unter KI-Agent-Workflow-Schritt.

EventBridge und externe Systeme​

Mit eventbridge.event und webhook.call kann Flow an größeren Automatisierungstopologien teilnehmen. Das ist hilfreich, wenn Flow eine von mehreren Eingangsquellen ist oder eine Übermittlung an AWS-native oder externe Verarbeitungspipelines verteilt werden soll.

Beziehung zum E-Mail-Eingang des AI-Kit-Backends​

Flow-Workflows sind nicht auf Formularübermittlungen aus dem Browser beschränkt. In aktuellen Bereitstellungen können sie auch hinter E-Mail-Eingangspipelines des AI-Kit-Backends liegen, zum Beispiel:

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

In diesen Einrichtungen verarbeiten Flow-Vorlagen und Workflow-Schritte einen normalisierten Ereignisvertrag statt nur roher Formularfelder. Dadurch kann eine gemeinsame Workflow-Ebene sowohl browserbasierte Übermittlungen als auch eingehende E-Mail-Anfragen verarbeiten.

Manuelle Aktionen können workflowähnliches Verhalten erneut auslösen, ohne zwangsläufig den Status zu ändern.