Lark Base
DatabaseUse Lark Base tables as agent-writable databases. Agents list and create tables, discover fields, and create, update, delete, and search records with structured filters, ideal for syncing form submissions and app data into ByteDance's Lark suite.
What This Integration Enables
Inside companies that run on Lark, Base tables are where operations actually happen: the launch tracker, the vendor list, the hiring pipeline, each one a typed database wearing a spreadsheet's face. FlowRunner treats them as exactly that. Agents discover tables and fields at runtime, write and update records with values shaped to the schema, and search with structured filters, so the tables the team plans from stop depending on someone remembering to update them. And because Base lives inside Lark, the notification loop stays short: the same flow that writes the record posts its summary into the chat where the table's owners already work. - Sync form submissions and app data into Base tables as structured records - Update rows from workflow events: mark done, flip a status, correct a field - Search with structured filters, sorting, and field selection to power reports and downstream steps - Discover tables with List Tables and field schemas with List Fields so flows adapt to the Base as built - Create new tables with typed fields when a workflow needs a home for its output
Without FlowRunner
With FlowRunner
Use Case Scenarios
The intake table that fills itself
Responses from [Typeform](/integrations/typeform) land as rows the moment they arrive. The flow reads the schema with List Fields, shapes each response to the table's field names and types, and calls Create Record per submission. Duplicates are checked first via Search Records on the email field, so the table stays one-row-per-person, and the summary posts to the team's channel with counts and the link to the Base.
The escalation sweep on a timer
Every morning, Search Records runs a structured filter: status not Done, due date before today, conjunction and. The matching rows post to [Slack](/integrations/slack) grouped by owner, and each row's record gets an Update Record stamping the escalation date so tomorrow's sweep knows what was already flagged. Nobody opens the Base to find out what slipped; the Base reports it. Owners who clear their list before the sweep see nothing at all, which is the point: the report spends attention only where attention is due.
The migration off the spreadsheet
A team graduates a tracking sheet into Base. The flow pulls rows from [Google Sheets](/integrations/google-sheets), calls Create Table with typed field definitions, text, number, single select, date, person, then walks the rows through Create Record with values shaped by List Fields. The result is not a pasted copy but a typed table that validates its data, and the old sheet gets a final row pointing at its successor.
Human-in-Loop Highlight
Delete Record permanently removes a row, and the dangerous case is not one deletion but a propagated one. A sync flow that mirrors an external source into Base has to decide what to do when rows vanish upstream, and the honest answer is: it depends on why they vanished. A botched export or a truncated API response looks identical to an intentional cleanup, and a sync that faithfully mirrors it will hollow out the table the whole team plans from, one permanent Delete Record at a time. So FlowRunner sync flows carry a deletion tripwire. Removing the odd stale row proceeds automatically, but when a run computes deletions beyond a small threshold, the agent stops, posts the would-be casualties with their field values, and waits. The ops owner looks at the list, recognizes the upstream export failure, and cancels; or confirms the cleanup and lets it run. Mirroring is machine work. Deciding that a mass disappearance upstream is real belongs to a person.
Agent Capabilities
9 actionsTables
2- List Tables Lists the data tables inside a Base app with ID, name, and revision, keyed by the Base app token. The entry point for every record operation.
- Create Table Creates a table with a name and optional typed field definitions, from text and number through single select, date, checkbox, person, phone, URL, and attachment. The step that gives a workflow's output a structured home.
Schema
1- List Fields Lists a table's fields with ID, name, numeric type code, and configuration. The discovery step that lets agents shape valid payloads against the table as it exists today.
Records
6- List Records Lists a table's rows with pagination, optionally applying a view's filters and sorting. The bulk read behind exports and mirrors.
- Get Record Retrieves a single record by ID with its full fields object. The context pull before an update decision.
- Create Record Creates a row from a fields object mapping field names to values matched to the schema. The write that turns events into records.
- Update Record Updates a record's supplied fields only, leaving the rest untouched. The status-flip and correction step.
- Delete Record Permanently removes a row by record ID. The operation this page's deletion tripwire exists for.
- Search Records Searches a table with a structured filter object supporting and/or conjunctions, sort criteria, and field selection, returning matches with pagination. The query engine behind sweeps, dedup checks, and reports.
Frequently Asked Questions
What can FlowRunner do with Lark Base?
FlowRunner agents can run List Tables, Create Table, and List Fields in Lark Base, plus 6 more actions.
Does connecting Lark Base to FlowRunner require OAuth?
Yes. Lark Base connects to FlowRunner with OAuth 2.0, so agents authenticate without handling raw credentials.
Can Lark Base trigger a FlowRunner workflow automatically?
Lark Base doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Lark Base
$100 in credits. No card required. Connect in minutes.