AI workers for Typeform

What is an AI worker for Typeform?

An AI worker for Typeform is an AI agent scoped to one job around your forms, such as summarizing last week's responses, drafting a new form from a brief, auditing which forms and automations are actually live, or keeping the Contacts database in order. It works through your own Typeform sign-in and inherits your Typeform permissions, and it can publish a form, send through an automation or delete anything only where you bind the tools that do that.

What these workers do

Summarize last week's responses

Reads the response data for a form on a schedule and writes what people actually said, so a team gets the themes on Monday instead of a link to a dashboard nobody opens.

Audit what is live

Lists every form and automation with its published state and its trigger, so you can see which forms are collecting, which automations are sending, and who they reach.

Draft a form from a brief

Builds a new form's questions and logic as a draft from a plain description of what you want to ask, and stops there, leaving the decision to publish to a person.

Keep the Contacts database in order

Reads the contact schema and segments on a cadence, reports fields nothing writes to and segments nothing sends to, and applies the tidying you approve.

Turn respondents into an audience

Checks that a form's answers are mapped into contact fields, imports the responses that predate the mapping, and reports how many people the target segment now holds.

How an AI worker runs in Typeform

The form is the easy part

Reading is most of the value and changes nothing

Two tools cross a line the others do not

Responses are text strangers wrote

Deleting is wider than it sounds

Automations are a paid add-on

Typeform questions, answered.

Can a worker email our contacts?

Only if you bind the tool that publishes an automation, and that is the one tool here worth deciding about deliberately. Publishing makes an automation live, and from then on it runs by itself whenever its trigger fires, sending its email steps to real contacts with no further confirmation. A worker that only builds automations as drafts holds no ability to send, however it is prompted, and neither does one that only reads. If you do grant publishing, grant the pause tool alongside it, because that is what lets a worker stop an automation that is sending in error. Note that adding or importing contacts can also start email indirectly, by putting someone into a segment an already-published automation targets.

Can a worker put a form on the internet?

Only with the publish tool bound. Creating a form and editing its questions produce a draft that is not live, so a worker built to draft forms cannot make one public. Publishing replaces what is served at the form's public link, which means it can also change a form that is already collecting responses. Editing is deliberately split into a validate step and an apply step, so a malformed change fails harmlessly before anything is saved.

What data can a worker reach?

Whatever your Typeform user can reach, and no more. The connection is made with your own Typeform sign-in and inherits that account's permissions, so a worker cannot see forms, responses or contacts that are already closed to you. On top of that it can call only the tools you bind to it. One limit to know before connecting: on Enterprise plans only Owner and Admin users can see Contacts at all unless your CSM has opened it to the team, so a worker connected by anyone else will find the contact tools empty.

Can a worker delete our forms or contacts?

Only with the delete tools bound, and they are the ones to think hardest about. Deleting a form takes the responses collected through it out of reach with it. Deleting a custom contact property removes that field's values from every contact in the database, and there is a bulk version that does it to several fields at once. These have real uses, including honoring an erasure request, so they ship available rather than withheld, but a reporting or drafting worker has no business holding them.

Is it safe for a worker to read form responses?

It is the main reason to connect Typeform, and it is worth knowing what it means. Response data is free text typed by whoever filled in your form, so a worker reading it is processing input from people outside your organization. Treat what it reads as material to summarize rather than instructions to act on, and be deliberate about which workers hold the response tools and who sees what they write. Every call is logged with the worker, the tool and the time, so what a worker read is answerable after the fact.

Why would a worker report no responses, or fail on automations?

Two account-level reasons, both invisible from our side. Automations require the Contacts and Automations add-on, included on the Growth Flow plan and purchased separately on Plus and above; without it the automation tools return errors even though they are bound. And if your account uses a response data center that this integration does not support, forms, contacts and automations all work normally but response data comes back empty rather than erroring, which is the more confusing of the two because a worker will report that there is nothing to summarize.

What AI workers can do in Typeform

The tools a worker can be granted in Typeform once you connect it. A kit grants only the ones its job needs, and you can narrow them further on the worker.

List accounts

Lists the Typeform accounts the connected user belongs to, with the identifiers the other tools need to address one. Usually the first call in a run, because a user who works across several accounts has to say which one is meant.

Add a delay step

Adds a wait of a set duration between two steps of an automation draft, so a follow-up lands hours or days after the step before it rather than immediately.

Add an email step

Adds an email step to an automation draft, setting the sender, subject and body that recipients will get. The step sends nothing while the automation is unpublished, but it defines what will be sent once it is.

Add an integration step

Adds a step that pushes contact or response data out to a connected third-party integration when the automation runs. Data leaves Typeform for another vendor's system every time that step fires.

Add a webhook step

Adds a step that posts automation data to a URL you supply. Whoever controls that address receives contact and response data on every run, so the URL is the security boundary here.

Create an automation

Creates a new automation in the account as an unpublished draft. Nothing is sent until the automation is published, so this is the safe half of building one.

Get authorized email domains

Returns the sending domains this account has verified with Typeform. An email step can only send from a domain on this list, so this is the check that explains a rejected sender address.

Get an automation

Returns one automation's full working state: the trigger that starts it and the ordered steps it runs. The working state is the draft, so what this returns can differ from what is currently live.

Get an email template

Returns the draft content of one email template used by an automation step: subject, body and the contact fields it merges in. The way to review what would be sent before anything goes live.

Get an automation trigger

Returns the conditions that start an automation, such as a form submission or a change to a contact, as currently drafted. Reading the trigger is how a worker tells who an automation will actually fire for.

List automations

Lists every automation in the account with its name, status and identifier, so a worker can find the one it was asked about instead of being handed an ID.

List referenceable fields

Lists the contact and form fields an automation may reference in its emails and trigger conditions. Worth calling before editing a step, because a field name absent from this list will not merge.

Edit an automation trigger

Applies JSON Patch operations to an automation's trigger, changing which event starts it and which contacts qualify. Widening a condition enlarges the audience the automation reaches on its next run.

Pause an automation

Stops an automation by disabling its trigger, and optionally halting runs already in flight. This is the stop button for an automation that is sending in error.

Publish an automation

Makes the automation's draft live. From this call on it runs on its own whenever its trigger fires, sending its email steps to real contacts with no further confirmation. This is the tool that turns a draft into outbound mail.

Remove automation steps

Deletes one or more steps from an automation draft. The steps and their content are removed rather than disabled, so an email deleted this way has to be written again from scratch.

Reorder an automation step

Moves a step to a different position in the automation, changing the order recipients experience. A delay moved after an email turns an immediate send into a scheduled one.

Update a delay step

Changes how long an existing delay step waits, retiming everything that follows it in the automation.

Update an email step

Rewrites an existing email step's sender, subject or body in the automation's working draft. What recipients receive changes when that draft is published.

Update a webhook step

Changes an existing webhook step's destination or configuration. Repointing it sends the automation's contact and response data to a different address from then on.

Create contact lists in bulk

Creates several segments at once from their filter rules, for setting up a whole audience structure in a single call.

Create contact properties in bulk

Adds several custom fields to the Contacts database schema in one call. Account-wide structure, so a careless batch leaves clutter everyone in the account then has to look at.

Create or update contacts in bulk

Creates or updates many contacts in one call, matching existing people on their identifier. The highest-volume write here: it can overwrite properties on people already in the database, and everyone it adds becomes eligible for whatever automations their segment triggers.

Create a contact

Adds one person to the Contacts database. A new contact can immediately match a segment and qualify for a published automation, so adding someone can be what starts email reaching them.

Create a contact property

Adds a custom field to the Contacts database schema, which is an account-wide structural change rather than an edit to one person.

Create a contact list

Creates a segment: a saved list defined by filter and sort rules over the Contacts database. Segments are what automations send to, so the rule written here is what decides an audience.

Create a contact mapping

Connects a form's questions to contact fields, so every future submission writes into the Contacts database. From this call on, respondents become contacts automatically.

Delete a contact

Removes a person from the Contacts database along with the property values held on them. Sometimes exactly what a deletion request calls for, and irreversible either way.

Delete contact properties in bulk

Removes several custom fields from the Contacts database schema in one call, deleting their stored values on every contact. After deleting a form, the widest data loss available in this app.

Delete a contact property

Removes a custom field from the Contacts database schema. The values held in that field on every contact go with it, which is a far wider loss than the singular wording suggests.

Delete a contact list

Deletes a segment. The contacts in it stay in the database, but anything that targeted the segment loses its audience definition.

Delete a contact mapping

Removes a form's mapping, so its submissions stop writing into the Contacts database. Contacts already created are untouched; what stops is the flow of new ones.

Enable standard contact properties

Turns on built-in contact fields that this account had switched off, making them available to write to and to filter on again. Additive: it restores fields rather than creating them.

Get a contact

Returns one person's full contact record: every property set on them, with the metadata saying where each value came from.

Get contact properties by ID

Returns specific contact fields by their identifiers, including type and configuration. The targeted version of listing the whole schema.

Get a contact list

Returns one segment's definition: its name and the filter and sort rules that decide which contacts fall into it. Reading the rule is how a worker tells who an automation aimed at that segment would reach.

Check field compatibility

Reports which of a form's questions and variables can legally write into which contact fields, given their types. The check that stops a mapping being built that silently drops answers.

Get a form's contact mapping

Returns the mapping configuration for one form: which of its questions write into which contact fields when someone submits it.

Get a contact mapping by ID

Returns one mapping configuration by its own identifier, for when a worker holds the mapping ID rather than the form it belongs to.

Import form responses into contacts

Schedules a bulk import of a form's existing responses into the Contacts database using its mapping. It can add a large number of people at once, and each of them then qualifies for whatever automations their segment triggers.

List contacts

Lists people in the account's Contacts database with filtering and pagination, returning names, email addresses and whatever custom properties are set on them. This is bulk personal data about real people, and it is the tool that hands the most of it to a worker at once.

List contact properties

Lists the fields the Contacts database is built from, the standard ones and any custom ones this account added, so a worker knows what it can filter or write on before it tries.

List contact lists

Lists the saved contact lists, or segments, in the account with their names and identifiers. Segments are how automations choose an audience, so this is usually the step before asking who is in one.

List contact mappings

Lists the configurations that copy form answers into contact fields across the account, showing which forms feed the Contacts database at all.

Update a contact

Changes the property values on one existing contact. Editing a field that a segment filters on can move that person into or out of an automation's audience.

Rename a contact property

Renames a custom field in the Contacts database schema. The stored values are kept, but anything that referred to the old name, including mappings and segment rules, has to be checked.

Update a contact list

Changes a segment's name or its filter and sort rules. Loosening a rule enlarges the audience of every automation that sends to that segment, without touching the automation itself.

Replace a contact mapping

Replaces a form's mapping wholesale. Every field pairing is rewritten rather than merged, so a partial update sent here silently drops the pairings it leaves out.

Create a form

Creates a new, empty form in a workspace and returns the identifier the editing tools need. The form has no questions and is not public until it has been built and published.

Delete a form

Permanently removes a form from the account, taking the responses collected through it out of reach with it. Destructive, and nothing a reporting worker ever needs.

Get form editor capabilities

Returns the field types, block operations and logic operators this account's form editor supports. Worth calling before building or editing a form, because it is what tells a worker which question types it may use.

Get a form

Returns a form's current definition: its questions, logic, settings and theme. It can be asked for the whole thing, just the fields, or a bare structural skeleton, which matters because a long form's full definition is large.

List forms

Lists the forms the connected user owns, with search and pagination, returning each form's title and identifier. The way a worker finds a form by name instead of being handed an ID.

Apply form edits

Commits validated edits to a form's draft, adding, changing or removing questions, logic and settings. Changes are saved but not live, and the token from the validation tool is required, so an unvalidated edit cannot land.

Publish a form

Makes the current draft the live version at the form's public URL. Anyone with the link then sees the new version, so this is where a form edit stops being internal.

Validate form edits

Dry-runs a batch of form edits and reports whether they would be accepted, saving nothing. It returns a token that the apply-edits tool requires, so it is the mandatory first half of editing a form and the place mistakes surface harmlessly.

Discover available analytics

Returns what analytics are available for a form or audience: which fields can be queried and which measures exist. The schema call a worker makes before asking for data, because the answer differs form by form.

Read response data

Returns response data a row at a time for one field of a form. That means the answers people actually submitted, free text included, so a worker reading this is reading text written by members of the public.

List workspaces

Lists the workspaces the connected user can see, with each one's name, identifier and how many forms it holds. Forms are created into a workspace, so this is the lookup that precedes building one.