KIS

Connect AI agents to KIS, a no-code platform for internal micro-apps built around datatables. Agents read and write the datatables a team already runs its process on.

7 actions API key available

Platform Documentation ↗ Capability data verified 2026-08-01

A supplier submits a compliance document through the intake form

Agent parses the document and pulls the supplier reference, expiry date and certificate type

Agent calls Get Records with a filter on the supplier reference to see whether a row already exists

Agent confirms every key it intends to write matches a field name in the datatable structure

Agent calls Update Record on the existing row, or Create Records when the supplier is new

Agent posts the refreshed compliance status into the procurement channel

When the parsed expiry date contradicts the row already on file, the agent stops and asks the process owner which one is right

What This Integration Enables

KIS is a no-code platform for building internal micro-apps around datatables, and the honest thing to say about micro-apps is that they become load-bearing without anyone deciding they should. Someone builds a supplier register or a shift log or an equipment checklist in an afternoon, three teams start relying on it, and eighteen months later it holds operational data with no owner, no integration and no backup discipline. This connector treats those datatables as what they have actually become: a system of record that agents can read, reconcile and write to on a schedule, so the micro-app stops being an island the moment it starts to matter.

Agents can read the structure of every datatable they can reach, query records with column filters, create records in batches, update single rows, delete a row, and wipe a datatable clean. Two behaviors are worth designing around. Field names are case and spelling sensitive, and the request is rejected outright if any key does not exist in the structure, so a datatable that someone renamed a column in will fail loudly rather than write a partial record, which is the better of the two failure modes. And authentication is handled for you: the connection signs in with the App Token and Secret, caches the bearer token, and re-authenticates transparently when it expires.

Without FlowRunner

Micro-app fed by hand Someone retypes form submissions into the datatable the team runs on

Data ages quietly Records drift out of step with the source system with nothing to catch it

Cleanups run blind A scheduled reset targets a table by name and nobody checks what is in it first

With FlowRunner

Fed by the flow Submissions, webhooks and email attachments land in the datatable directly

Reconciled on a schedule An agent compares rows against the source of record and corrects the differences

Destructive steps confirmed A wipe is preceded by a count and a sample, seen by the person who owns the app

Use Case Scenarios

Intake that lands in the app the team already uses

A supplier compliance micro-app sits in KIS: one datatable per certificate type, a form for uploads, a dashboard the procurement team checks. Documents still arrive by email. An agent reads the mailbox, extracts the supplier reference, certificate type and expiry date from each attachment, filters the datatable for an existing row, and either updates it or creates a new one. The team keeps the app they built and stop keying documents into it. Anything the agent cannot parse confidently is routed to a person rather than written as a guess.

Reconciling a micro-app against the system of record

The supplier register in KIS and the vendor master in NetSuite have quietly diverged. A nightly flow pulls the vendor list from the system of record, calls Get Records to pull the KIS rows, and compares them field by field. Differences that are clearly stale on the KIS side are corrected with Update Record. Differences that could go either way are collected into a summary and posted to Slack for the register's owner to arbitrate. Reconciliation stops being an annual project and becomes something that runs while everyone is asleep.

A staging table that gets reset properly

A team uses a KIS datatable as a staging area for an import that runs each month. Before the new load, the table has to be emptied. The flow calls List Datatables to resolve the identifier, calls Get Records to count and sample what is currently there, writes that snapshot to an archive, and only then calls Wipe Datatable. The reset is repeatable, the previous month's contents are recoverable from the archive, and the destructive step is the last thing that happens rather than the first.

Human-in-Loop Highlight

Wipe Datatable is the operation that deserves the gate, and the reason is a detail in how it is addressed. It permanently deletes every record in a datatable while keeping the structure intact, there is no confirmation step and no way to restore afterwards, and it takes the datatable identifier rather than its name. In a flow, that identifier is almost always resolved at runtime from List Datatables, which means the wipe is aimed by a lookup rather than by a person. Someone renames a table, someone duplicates a table to try something, someone builds a second micro-app that reuses a label, and the lookup returns a different identifier than it did last month. The call succeeds. The wrong team's live data is gone, and there is nothing to appeal to.

FlowRunner puts a person between the lookup and the call. The agent resolves the identifier, calls Get Records to count the rows and pull a handful of them, and stops. It sends the owner of the micro-app a message: "Monthly staging reset is about to wipe the datatable resolved as import_staging, identifier ending 4f1c. It currently holds 3 rows, and the last three resets held around 900. Sample rows attached. Confirm this is the staging table, or cancel." A count that has collapsed usually means the identifier moved, and that is exactly the signal a person can read in two seconds and a lookup cannot read at all. The agent does the resolving and the counting. The person confirms what is about to be destroyed.

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

Datatables

List Datatables Retrieves the structure of every datatable available to the API access credentials, including each table's name, identifier and field definitions. Used to discover the datatable name the record operations need, to resolve the identifier Wipe Datatable requires, and to let downstream steps map fields dynamically rather than hardcoding them.
Wipe Datatable Permanently deletes every record stored in a datatable while keeping the datatable and its structure intact. Used for scheduled cleanups and staging resets. The deletion is immediate and irreversible with no confirmation step, and it requires the datatable identifier rather than its name, so resolve the identifier and confirm what it points at before the call.

Records

Get Records Retrieves records from a datatable. Used to look up an existing row before writing, to drive conditional logic in a flow, and to snapshot a table before a destructive operation. Without filters the whole datatable is returned; supply filters to narrow by column, comparison operator and value, with an optional limit. Multiple filters are combined by the API, and the Contains operator performs a partial-value match.
Create Records Creates one or more records in a datatable in a single call. Used for intake: form submissions, parsed email attachments and batch imports. Each object represents one record, with keys matching the field names in the structure. Field names are case and spelling sensitive and the request is rejected outright if any key does not exist, so a structure change surfaces as a failure rather than a partial write. Omitted fields are simply left unset.
Update Record Updates a single existing record. Used in reconciliation and enrichment flows where only some fields change. Partial updates are supported because only the supplied fields are changed, but every key must match a field defined in the structure or the request is rejected.
Delete Record Permanently deletes a single record from a datatable. Used to remove an individual row that should not have been created, or that a downstream process has retired. The deletion is immediate and irreversible. To empty a table entirely, Wipe Datatable is the operation, not a loop over this one.

Session

Sign Out Ends the current API session and invalidates the bearer token held by this connection. Sign-in happens automatically on the next operation, so this is only needed when a session has to be released explicitly, for example at the end of a long-running flow or to satisfy a security policy.

Frequently Asked Questions

What can FlowRunner do with KIS?

FlowRunner agents can run List Datatables, Wipe Datatable, and Get Records in KIS, plus 4 more actions.

Does connecting KIS to FlowRunner require OAuth?

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

Can KIS trigger a FlowRunner workflow automatically?

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

Start building with KIS

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

Start Building Free Talk to us

KIS