Pickaform

Pickaform, now AirProcess, is a French no-code platform for building business applications out of forms, data models and workflows. Agents browse workspaces, applications, models and views, then create, update, search and delete the records behind them.

Verified 2 triggers 23 actions Session available

Pickaform website Platform Documentation Capability data verified 2026-08-26

On New Record fires when a purchase request is created in the Requests model

Get Model Fields maps the record's field identifiers onto the labels the team actually uses

Find Records By ID resolves the supplier and cost center the request links to

Search Records confirms no open request already covers the same lines

Update Record Field writes the committed amount so the budget rollups recalculate

The agent posts the request with its new budget position to the approver

The department approver decides whether the budget can absorb the commitment

What This Integration Enables

Pickaform, now trading as AirProcess, is for departments that outgrew the spreadsheet without wanting an IT project: a workspace per department, applications inside it, and a model for each kind of record the team handles. That shape is the reason it is worth automating. Because workspaces, applications, models, views, and fields are all readable through the API, a FlowRunner agent can discover the data model at run time instead of being hardcoded against one, which matters on a platform where the people who own the process also change it.

Two pairs of operations define how a careful agent behaves here, and both are worth knowing before you build. Record payloads are keyed by field identifier rather than by label, so Get Model Fields is the call that turns a spreadsheet's worth of headings into something a flow can write to. And the record layer offers two removals: Send Record To Trash puts a record somewhere it can be brought back from, while Delete Record does not. FlowRunner agents take the reversible path by default and hand the other one to a person, because human-in-the-loop is not a feature you switch on at the end. It is which operation the agent is allowed to call on its own.

Without FlowRunner

Every team builds its own A department's process lives in a form nobody outside that team can read, query, or reconcile

Two deletes, one memory A record removed in a hurry is gone, and nobody recalls which of the two removal paths was used

Rollups drift quietly A value written straight into a field leaves the summaries and lookups that depend on it stale

With FlowRunner

Structure an agent can read Workspaces, applications, models, and views are all enumerable, so a flow adapts to the data model rather than assuming one

Reversible by default Agents trash records; permanent removal is a decision a person makes with the record in front of them

Consequences propagate Writes that feed a formula or a rollup take the cascading path, so connected records stay correct

Use Case Scenarios

Intake that arrives already resolved

A request submitted through Jotform or a message picked out of Gmail reaches the agent as unstructured text. It calls Get Models and Get Model Fields to learn the shape of the Requests model, extracts the fields it recognizes, and resolves the supplier and cost center with Find Records By ID rather than writing free text into a link field. Create Record inserts the request with an identifier the agent chose up front, so every later step in the flow has a key to reference. What lands in Pickaform is a request the reviewer can act on, not one they have to finish typing.
Reporting that reads what the team sees

Get View returns a view's columns, sort, filter, and grouping. The agent replays that same filter through Search Records, so the numbers it reports are the numbers on the screen the department uses, not a parallel query someone wrote once and forgot. Results append to a sheet in Google Sheets and a weekly digest posts to Slack. When a manager changes the view, the report follows, because the report was never a second definition of the truth.
Cleanup that stops at the point of no return

A retention sweep runs monthly. Search Records finds records past the retention window, Get Record pulls each one in full, and the agent calls Send Record To Trash. Trashed records leave reads and searches immediately, so the operational effect is complete, and the records themselves are still recoverable from the interface. Only where an erasure request names a specific record does the flow escalate, and only a person may authorize Delete Record on it.

Human-in-Loop Highlight

Pickaform hands the agent two ways to remove a record, and exactly one of them can be walked back. Send Record To Trash moves a record into the trash collection where the interface can restore it. Delete Record destroys it. Both are one call, both report success, and nothing in the response tells you afterward which one you chose. So the retention agent uses the reversible one on its own authority and stops at the other: "Record 4417 in the Contracts model is 39 months past its retention date and an erasure request names it. Trashing it removes it from every read now and it can still be restored. Delete Record cannot be undone. Which do you want?" The records manager answers. The reason this works is not that the agent detected the retention breach, which it did perfectly well. It is that the one call with no undo belongs to the person accountable for the erasure.

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

23 actions

Account and People

Get Account Returns the account the configured credentials belong to, with plan, allowances, status, and billing period. Used to check a limit before a flow creates more applications or invites more users.
Get Users Lists the members of the account currently signed in to, with names, email addresses, and active flags. Used to resolve a person before assigning a record to them.
Get Collaborators Lists external users invited to work with this account, and which accounts each can reach. The list to consult when a record has to be shared outside the team.
Get Groups Lists the permission groups defined on the account and their members. The fastest way for a flow to learn who can read or update a given workspace or field.

Structure

Get Workspaces Lists the workspaces the authenticated user can see, each with its name, icon, and read and update permissions. The top of the hierarchy and the natural first call when exploring an account.
Get Applications Lists every application the user can read, optionally narrowed to one workspace, including the layout naming the models and views each one presents.
Get Application Returns one application with its full layout: the ordered models it exposes and, for each, the views presented to the user.
Get Models Lists every data model on the account. A model defines one kind of record, and its identifier is what every record operation addresses.
Get Model Returns the complete definition of one model, with fields nested inside form panels. Used when a flow needs the form layout rather than just the field list.
Get Model Fields Flattens a model definition into identifier, label, type, read-only flag, and panel. This is the call that makes writing possible, because record payloads are keyed by identifier and never by label.
Get Views Lists views, optionally narrowed to one application or model. A view carries its own columns, sort, filter, grouping, and display type.
Get View Returns one view's full definition. Used to reproduce in a flow exactly what a user sees, or to read a filter that can then be replayed through Search Records.

Records

Get Records Retrieves every record of a model, keyed by field identifier and carrying the created and updated audit properties. There is no server-side filter or paging on this route, so prefer the search operations on a large model.
Get Record Retrieves one record by identifier. Link fields come back as arrays of identifiers rather than embedded objects.
Create Record Inserts a record from a map of field identifiers to values. Supplying a Record ID lets the flow choose the key up front, which makes the write repeatable and gives later steps something to reference.
Update Record Writes a partial set of field values and leaves everything else alone. The plain write path, and the right default for a status change or an enrichment pass.
Update Record Field Writes one field and lets the server propagate the consequences, recalculating computed fields on this record and on every connected record, including lookups and summaries. Used whenever the value feeds a formula, a rollup, or a relationship.
Send Record To Trash Soft deletes a record into the trash collection. It stops appearing in reads and searches but is not destroyed, which makes it the safe counterpart to Delete Record and the default an agent should reach for.
Delete Record Permanently deletes a record with no route back through the interface. The operation this page's human gate exists for.

Finding Records

Find Records By Field Searches a model on a single field condition with paging, using friendly comparison labels. The Is Empty and Is Not Empty comparisons take no value.
Search Records Searches with a full filter document and paging, in either the normalized tree syntax or a MongoDB style query. The operation to use when conditions have to combine with and and or.
Find Records By ID Retrieves several records of one model in a single call. The efficient way to resolve the identifiers stored in a link field without one request per identifier.

Advanced

Make An API Call Issues any request against the configured base URL with authentication and error handling applied. The published collection is smaller than the product, so this is the escape hatch for routes it does not list.

Triggers

2 triggers

Event Triggers

On New Record Fires when a record is created in the watched model, emitting it exactly as Get Record would return it. Records created through the interface, an email form, or another integration all fire it the same way. The first cycle records a baseline without firing, so existing records are never replayed.
On Record Updated Fires when a record of the watched model is modified, emitting its new state. Pickaform stamps the updated timestamp on creation as well, so a brand new record fires this too unless Ignore New Records is switched on.

Frequently Asked Questions

What can FlowRunner do with Pickaform?

FlowRunner agents can run Get Account, Get Users, and Get Collaborators in Pickaform, plus 20 more actions.

Does connecting Pickaform to FlowRunner require OAuth?

No. Pickaform connects to FlowRunner with session-based authentication, no OAuth flow required.

Can Pickaform trigger a FlowRunner workflow automatically?

Yes. Pickaform supports 2 triggers that can start a FlowRunner workflow automatically.

Start building with Pickaform

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us