Cognito Forms

Work with Cognito Forms submissions from your flows. Agents list forms, inspect field schemas, and create, update, filter, and delete entries with OData-style paging and queries.

7 actions API key available

Cognito Forms website ↗ Platform Documentation ↗ Capability data verified 2026-07-28

The intake sweep runs List Entries on the client application form with an OData filter for entries since the last checkpoint

Get Form Schema confirms the field map so the workflow reads each submission's fields by their real names, not guesses

Each new application syncs to the CRM and appends to the intake tracking sheet with its entry number

The agent validates required documents and flags applications with missing or contradictory information

Complete applications route to the reviewer queue; incomplete ones generate a follow-up request to the applicant

The intake reviewer decides each flagged application: accept with conditions, request corrections, or decline

Update Entry writes the review status and corrected values back onto the entry, keeping the form as the working record

The weekly digest reports intake volume, completion rate, and the fields applicants most often get wrong

What This Integration Enables

Cognito Forms is built for forms that are really processes: multi-page intake, registrations, applications, the kind where the submission starts a case rather than ends a conversation. Its API matches that seriousness, full entry CRUD with OData paging and filtering, and this connector puts FlowRunner agents in charge of the case work. Agents list forms, read field schemas before mapping a single value, pull entries in filtered pages, create submissions programmatically, and update or delete entries under review. - Sync new submissions into CRMs, spreadsheets, and databases on a reliable sweep - Read the field schema first, so integrations survive form edits instead of silently mis-mapping - Page through large entry sets with OData filters, ordering, and field selection - Create entries from checkout, registration, and intake flows in other systems - Update entries to carry status and corrections as the case progresses - Execute retention and GDPR deletions deliberately, with review The schema-first habit is the practical difference between integrations that survive and integrations that rot: because Get Form Schema is a step, not a suggestion, workflows notice when the form changes instead of mapping the wrong field for a month. The entry lifecycle runs on FlowRunner's [human-in-the-loop](/concepts/human-in-the-loop) discipline at both ends: judgment calls on flagged submissions, and confirmation on the deletes that cannot be undone.

Without FlowRunner

Submissions checked by inbox New entries announce themselves by notification email, and processing depends on who noticed

The form and the tracker diverge Data gets copied to a sheet once, then corrections happen in one place but not the other

Cleanup is unaccountable Old entries get deleted ad hoc, and nobody can say afterward what was removed or why

With FlowRunner

Entries processed on a sweep OData-filtered pulls guarantee every submission is read, validated, and routed

The entry is the working record Status and corrections write back to the entry itself, so form and tracker cannot disagree

Deletion is a logged decision Erasure and retention deletes are confirmed by a person, entry by entry

Use Case Scenarios

Intake that never loses an application

List Entries sweeps the application form every fifteen minutes with a filter on submission time. Each entry lands in [HubSpot](/integrations/hubspot) as a contact with the application attached, and the tracking row appends to [Google Sheets](/integrations/google-sheets) with the entry number as the join key. Validation runs against the schema from Get Form Schema, so when the team adds a field next quarter, the workflow flags the change instead of dropping the data.

Two systems, one submission

Lead details arrive through [Typeform](/integrations/typeform) at events, but internal processing runs on Cognito Forms. Create Entry mirrors each external submission into the intake form, nested fields and all, so the operations team works one queue with one field vocabulary. The mirrored entry carries the source reference, and Get Entry serves the full record whenever a downstream step needs the original values.

The retention workflow that can face an audit

Quarterly, List Entries filters each form for entries past the retention window. The agent bundles candidates with their entry numbers, timestamps, and a summary of contents, and posts the list for review. Approved entries export to the archive first, then Delete Entry removes each confirmed ID, and the deletion log records who approved what. Individual erasure requests run the same path at any time: locate with an OData filter on email, confirm with Get Entry, delete on approval.

Human-in-Loop Highlight

Delete Entry permanently destroys a submission, and in an intake process the entry is not a copy of the record, it is the record: the application as the applicant actually submitted it, timestamped, with its entry number in the sequence. Delete the wrong one and no CRM sync can reconstruct what the person originally wrote. So deletion on this page is always a confirmed, singular act: "Erasure request from m.osei@ example matches entry 1847 on the Volunteer Application form, submitted 2025-11-02, synced to CRM contact 30291. Archive copy verified. Delete the entry?" The privacy owner confirms, the delete runs against that one ID, and the log keeps the accounting. Update Entry sits behind a related caution for a different reason: editing a submitted entry rewrites what the record says was submitted, so agents write status and corrections into fields designated for them and stop for review before touching anything the applicant filled in.

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

7 actions

Forms

List Forms Lists the organization's forms accessible to the API key, with numeric ID, name, and internal name. The reference step for every entry operation.
Get Form Schema Retrieves a form's field schema: every field's name, data type, and configuration. The map read before creating or updating entries, and the early-warning system when forms change.

Entries

List Entries Lists a form's entries with OData-style paging, filtering, ordering, and field selection, each with field values and metadata including Id and entry number. The sweep behind every sync.
Get Entry Retrieves a single entry with all field values and metadata. The confirmation step before updates, deletions, and downstream handoffs.
Create Entry Creates a submission with data keyed by the form's field names, nested objects included, returning the assigned ID and metadata. The mirroring step for external intake sources.
Update Entry Updates an entry's field values with the supplied object, setting only the included fields. Used for status and corrections, with human review before submitted data changes.
Delete Entry Permanently deletes an entry. Cannot be undone, which is why it runs one confirmed ID at a time behind this page's gate.

Frequently Asked Questions

What can FlowRunner do with Cognito Forms?

FlowRunner agents can run List Forms, Get Form Schema, and List Entries in Cognito Forms, plus 4 more actions.

Does connecting Cognito Forms to FlowRunner require OAuth?

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

Can Cognito Forms trigger a FlowRunner workflow automatically?

Cognito Forms doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Cognito Forms

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us