---
title: "Web Data Forms Integration"
description: "Web Data Forms is a no-code platform for embeddable, branded web forms with automation and reporting on top. Agents read and write submissions, move each one through status, priority, assignee and comments, and subscribe to webhooks to react the moment a form is filled in."
url: https://flowrunner.ai/integrations/web-data-forms
date_modified: 2026-09-04T19:22:58-07:00
---

# Web Data Forms

[Forms](https://flowrunner.ai/integrations/category/documents-forms)

Web Data Forms is a no-code platform for embeddable, branded web forms with automation and reporting on top. Agents read and write submissions, move each one through status, priority, assignee and comments, and subscribe to webhooks to react the moment a form is filled in.

2 triggers · 16 actions · API key · available

[Web Data Forms website](https://webdataforms.com/) · [Platform Documentation](https://documenter.getpostman.com/view/32580100/2sB3WtrJLA) · Capability data verified 2026-08-26

1.  On New Submission fires when a customer files an intake or inspection form
2.  Agent reads the field values and the metadata block that carries the submission number
3.  Search Submissions looks for an earlier record on the same email address or reference
4.  List Workflow Options and List Group Users resolve the status and assignee identifiers the write needs
5.  Update Submission Workflow sets status, priority and type and hands the record to an owner
6.  A summary posts to the team channel naming the form and the submission number
7.  The assigned owner reads the comment on the record and decides whether to escalate or close it

## What This Integration Enables

Web Data Forms is for teams who treat a submission as a ticket rather than a row. The forms themselves, which the platform calls Data Templates, are the easy part. What the API is actually shaped around is the state a submission accumulates afterward: a status, a priority, a type, an assignee and an internal comment thread, all addressed by identifier and all writable from outside. That is a service desk model wearing a form builder's clothes, and it is the reason a flow can do more here than copy answers somewhere else.

FlowRunner agents read and search submissions by business key rather than by counter, push records in from other systems so field staff see them in the same queue as hand filled forms, move each record through status, priority, type and ownership, and wake on both a new submission and a workflow change. Every one of those operations is built and verified against the vendor's own Automation API. The [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) part matters more here than on most form connectors, because the agent is writing into a queue that people are working out of, and a write into somebody's queue can quietly destroy their work.

### Without FlowRunner

**Submissions arrive as rows**: A form fills a table, and who owns each request gets settled in a side conversation

**State lives outside the record**: Whether anyone has acted on a submission depends on who last scrolled the queue

**Two systems disagree**: The CRM says a request is closed while the form queue still shows it open

### With FlowRunner

**The submission carries its state**: Status, priority, type, assignee and comments sit on the record itself, where the next person looks

**Assignment is a recorded step**: The agent resolves an administrator, hands the record over, and writes the reason as a comment

**One queue, both origins**: Records pushed in from other systems sit alongside the ones people filled in by hand

## Use Case Scenarios

### An intake form becomes owned work

A customer submits a service request. On New Submission delivers the field values and the initial workflow state before anyone has opened the queue. The agent classifies the request, calls Search Submissions on the customer's email to see whether this is a repeat, and resolves the right status and administrator with List Workflow Options and List Group Users. Update Submission Workflow then sets the status to In Progress, sets the priority the classification implies, assigns the record and attaches a comment explaining the reasoning. A message goes to [Slack](https://flowrunner.ai/integrations/slack) naming the form, the submission number and the owner. Nobody had to triage a queue to make that happen.

### Workflow changes mirrored where the rest of the business reads

On Workflow Change fires whenever a submission's status, priority, type, assignee or comments move. The agent branches on the new status: a change to Resolved appends a row to a [Google Sheets](https://flowrunner.ai/integrations/google-sheets) log with the resolution timestamp and reads the final field values back with Get Submission so the log carries the answers as well as the outcome. A change that pushes a record to high priority instead posts into the escalation channel with the comment that triggered it. Because the delivery already carries the submission in its state after the change, the flow branches without a second read.

### Pushing records in without overwriting anyone

Rows awaiting field collection sit in [Airtable](https://flowrunner.ai/integrations/airtable), and the crew works from the Web Data Forms queue on tablets. The agent reads the pending rows, calls Get Data Template Schema to learn the exact field keys and their allowed choices, and creates one submission per row so the crew sees them next to the forms they filled in themselves. Before it writes, it checks whether the target form is a Single Submit template, because on those the create replaces rather than appends. Where it is, the agent stops and asks. Every submitter also gets added to the notification list in [Brevo](https://flowrunner.ai/integrations/brevo), so the crew is told the queue has grown.

## Human-in-Loop Highlight

Create Submission on a Single Submit Data Template does not add a record. It replaces the one that is already there, which is the vendor's documented behavior and cannot be undone. That would be manageable if an agent could reliably tell whether the slot was occupied, but List Submissions defaults to returning one generated sample record when a form has no real submissions yet, so an empty form and a form holding a technician's completed inspection look the same from the outside unless mock data is explicitly turned off. So the sync agent reads with mock data off, and when the slot is occupied it does not guess. It posts: "Form Site Inspection is Single Submit and already holds submission 41, filed 6 September by dwalker@, with 12 of 14 fields completed. Creating the Airtable row here replaces it. Overwrite, update the existing record in place with Update Submission, or skip this row?" The agent has done the lookup, read the schema and staged the payload. What it will not do is overwrite a person's completed work because a source row said so.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

## Agent Capabilities

16 actions

### Group and Account

3

-   **Get Group Details** Reads the descriptive record of the connected group: name, email address, phone number, website and postal address. The vendor uses this as its own credential test, so it is the right call for confirming an API key and Group ID pair works before a flow does anything else.
-   **Get Group Info** Returns the account level options envelope in one call, optionally carrying the data template list, the status, priority, type and comment type option lists, and the administrator list. Useful when a flow needs several of those sets at once.
-   **List Group Users** Returns the group's administrators as identifier and label pairs, where the label is the email address. These identifiers are what Update Submission Workflow accepts as an assignee, so this is how a flow routes a record to a person chosen at run time.

### Forms and Schema

4

-   **List Data Templates** Returns the account's forms as identifier and label pairs, with the label showing the folder path and form name. Restrict to automation enabled forms, because a form without Automation switched on is refused by every other operation here.
-   **List Workflow Options** Returns the group's four workflow option lists, status, priority, type and comment type, as identifier and label pairs. This is what turns a readable state such as In Progress into the value the API expects.
-   **Get Data Template Schema** Returns a form's field definitions: key, display label, data type, required flag, help text, placeholder and, for choice fields, the allowed values. These keys are exactly what Create Submission and Update Submission expect, so this is the first call when a flow has to build a submission for a form it does not already know.
-   **Get Searchable Fields** Returns the fields a form will search on, as the tokens Search Submissions expects, marking any field the form treats as unique. Run it when a flow needs to find a record by a business value rather than by its number.

### Submissions

5

-   **List Submissions** Returns a page of recent submissions for one form with their field values, workflow state and metadata. Turn mock data off to be certain an empty form returns nothing, because the vendor otherwise answers with one generated sample record.
-   **Get Submission** Reads one submission by its per form submission number, returning field values, workflow state identifiers, assignee and metadata. Submission numbers count within a single form, so always pair one with the form it came from.
-   **Create Submission** Records a new submission exactly as if someone had filled the form in, which is how data from another system enters the same queue. On a Single Submit template it replaces the existing submission rather than adding one, which is the operation this page's human gate exists for.
-   **Update Submission** Rewrites the field values of an existing submission, identified by its submission number. This is the vendor's save operation rather than a partial patch, so send the complete set of values the record should end up with.
-   **Search Submissions** Finds submissions of a form whose searchable field matches a value, which is how a flow looks a record up by email address, reference or order number instead of by submission number. A field the form marks unique returns at most one match.

### Workflow

1

-   **Update Submission Workflow** Moves a submission through the group's internal workflow, setting status, priority and type, reassigning it and attaching a comment in one call. Every value is an identifier rather than a name. Leaving the assignee empty returns the record to the unassigned pool rather than leaving the current owner in place.

### Webhooks

2

-   **Attach Webhook** Registers a URL the platform posts to on a new submission or a workflow change, and returns the external hook identifier. The triggers manage their own webhooks, so use this only to feed something outside FlowRunner, and record the identifier because there is no route for listing them.
-   **Delete Webhook** Removes a webhook using the identifier Attach Webhook returned. An identifier that was never recorded cannot be recovered through the API, and the webhook has to be removed in the web app instead.

### Escape Hatch

1

-   **Make API Call** Sends an authorized request to any Web Data Forms route with the API key header and group context already applied, for routes this connector does not name as their own operation. Prefer a named operation where one exists, because this performs no validation of its own.

## Triggers

2 triggers

### Event Triggers

2

-   **On New Submission** Starts the flow the moment someone submits the watched form, delivering the field values, the initial workflow state and the metadata block carrying the submission number. The Data Template must have Automation enabled before the trigger can subscribe, which is the most common reason a trigger never fires.
-   **On Workflow Change** Starts the flow whenever a submission of the watched form has its workflow altered, covering a change of status, priority or type, a reassignment and a new comment. The delivery carries the submission in its state after the change, so a flow can branch on the new status without reading the record back.

## Frequently Asked Questions

### What can FlowRunner do with Web Data Forms?

FlowRunner agents can run Get Group Details, Get Group Info, and List Data Templates in Web Data Forms, plus 13 more actions.

### Does connecting Web Data Forms to FlowRunner require OAuth?

No. Web Data Forms connects to FlowRunner with an API key, no OAuth flow required.

### Can Web Data Forms trigger a FlowRunner workflow automatically?

Yes. Web Data Forms supports 2 triggers that can start a FlowRunner workflow automatically.

**Work at Web Data Forms?** This integration exposes Web Data Forms to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current.

---
Markdown version of https://flowrunner.ai/integrations/web-data-forms. Site index: https://flowrunner.ai/llms.txt
