Feishu Base

Feishu Base is the Bitable database inside Feishu. Agents create bases and tables, manage fields and views, search, create, update and delete records in bulk, and administer roles on bases with advanced permissions.

Verified 35 actions OAuth available

Feishu Base website Platform Documentation Capability data verified 2026-08-27

A quarterly access review opens on a Base that holds customer data

List Roles and List Role Members collect who currently holds which role and what each role reaches

Get Base confirms advanced permissions are switched on, because the role operations do not exist on a Base without them

The agent compares each role's per table permissions against the access matrix the team intended

The agent posts a per table before and after for every role it proposes to rewrite

The Base owner approves each rewrite, because Update Role replaces the whole permission set and any table left out of the payload silently drops

What This Integration Enables

Feishu Base is the Bitable database that lives inside the tool a mainland China organization already runs its day in, which is why it ends up holding the operational data that matters and the permissions that go with it. FlowRunner agents work the whole surface: create and copy Bases, add and remove tables and fields, read through a view so the view's own filters apply, search with a structured filter, and write records in batches of up to a thousand. Two Feishu specifics shape every workflow. Cell values are keyed by field name rather than by field id, so List Fields runs before any write. And roles only exist on a Base with advanced permissions switched on, which means the permission layer is a deliberate choice rather than a default.

That permission layer is where this connector stops being a database integration and starts being a governance one. Feishu's role write is a replace rather than a patch, so the agent that maintains access is one payload away from removing it. FlowRunner's answer is not to keep agents out of the permission layer. It is human-in-the-loop: the agent gathers, computes and proposes, and the change that alters who can see what is approved by the person accountable for it.

Without FlowRunner

Access drifts quietly Roles accumulate table by table, and nobody can say from memory who can read which table

Column renames break things later Records are addressed by field name, so a rename changes the shape of every read and the breakage shows up somewhere else

Structure rebuilt by hand Each new project starts with somebody copying tables, fields and views into a fresh Base

With FlowRunner

Access reviewed as a process Agents assemble the current role matrix on a schedule and put the changes in front of the owner as a diff

Names read before every write List Fields supplies the exact field names at run time, so a write follows the schema as it stands

Structure cloned deliberately Copy Base reproduces a proven Base without its records, so a new project starts from a template rather than a blank table

Use Case Scenarios

Bulk maintenance on a table people are still using

A pricing table in a Base needs several hundred rows corrected after an upstream change. The agent calls List Fields to get the exact field names, Search Records with a structured filter to find the affected rows, and Batch Update Records to write them in blocks rather than one call per row. Records that fall outside the filter are left alone. A summary posts to Slack naming how many rows changed and which fields were touched, and the source of truth stays in MySQL where the pricing actually lives.
A Base per project, cloned from a proven one

When a new engagement starts, the agent calls Copy Base against the reference Base with records excluded, so the copy carries the tables, fields and views and none of the previous client's data. Batch Create Tables adds the tables this engagement needs on top, Create View saves the filters the team works from, and the kickoff details land in a first batch of records. The structure is identical every time because nobody rebuilt it by hand.
The access review that ends with a person

On a schedule, the agent reads List Roles, List Role Members and each role's per table permissions, then compares them against the intended matrix. It finds a role that reaches two tables it should not and a former contractor still holding it. The agent computes the corrected permission set and the exact list of tables the rewrite would carry, posts both, and waits. It has the operations to fix this on its own. It does not use them until the Base owner says so.

Human-in-Loop Highlight

Update Role does not edit a role, it replaces one. The table permissions in the payload become the role's entire permission set, so a table that is simply absent from the request loses its entry, and the people holding that role lose that access without an error being raised anywhere. That is a quiet failure mode with a loud consequence, and it is why the access review agent stops here. It posts: "Role Regional Sales currently reaches 6 tables. The rewrite carries 5. Table Pipeline Q4 is not in the payload, so the 11 people holding this role will lose access to it. Apply, or add Pipeline Q4 back?" The Base owner answers. The agent then applies the set it was given, and Add Role Member or Delete Role run only against a list a person confirmed. The agent did the reading, the comparison and the arithmetic. The change to who can see customer data belonged to a human.

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

35 actions

Bases

Create Base Creates a Base and returns the app token every other operation is keyed on.
Get Base Reads a Base's name, revision and whether advanced permissions are on. The revision is how a workflow tells whether anything has changed since it last looked.
Update Base Renames a Base or switches its advanced permissions on or off. Switching them on is what makes the role operations work, and it changes how every other call is authorized.
Copy Base Duplicates a Base, optionally without its records, so the copy is a clean template of the same structure.
List Dashboards Lists the dashboards in a Base.

Tables

List Tables Lists the tables in a Base with the table id every record and field operation needs.
Create Table Adds a table to a Base, optionally with its initial fields and rows in the same call.
Batch Create Tables Adds several tables to a Base in one call. Used when provisioning a project structure from a template.
Update Table Renames a table.
Delete Table Permanently removes a table and every record in it.
Batch Delete Tables Permanently removes several tables and everything in them.

Fields

List Fields Lists a table's fields with their names, types and options. Record writes are keyed by field name in Feishu, so this is where the exact names come from.
Create Field Adds a field to a table. A type that carries options, such as a single select, also needs the object describing them.
Update Field Changes a field's name, type or settings. Feishu requires the full definition rather than a patch, so send the name and type even when only one is changing.
Delete Field Permanently removes a field and the data held in it across every record.

Records

List Records Reads records from a table, optionally through a view so the view's own filters and sorting apply.
Get Record Reads one record by its record id.
Search Records Finds records using a structured filter rather than an expression string. The read to prefer for anything beyond a view lookup.
Create Record Adds a record to a table. Cell values are keyed by field name, so read the exact names from List Fields first.
Update Record Changes the named cells on one record and leaves the rest untouched.
Delete Record Permanently removes one record.
Batch Get Records Reads several records by id in one call, which is far cheaper than one Get Record per id.
Batch Create Records Adds up to 1000 records in one call. The write behind any bulk import.
Batch Update Records Changes up to 1000 records in one call, each entry naming its own record id alongside the cells to write.
Batch Delete Records Permanently removes up to 500 records in one call.

Views

List Views Lists a table's views. A view id passed to a read applies that view's own filters and sorting.
Create View Adds a view to a table, so the filter a workflow uses is the same one people see.
Update View Changes a view's name or its filter, sort and field visibility settings.
Delete View Removes a view. The records it showed are unaffected, because a view is only a lens over the table.

Roles

List Roles Lists the custom roles defined on a Base. Every role operation requires the Base to have advanced permissions switched on.
Create Role Creates a custom role on a Base, with per table permissions.
Update Role Replaces a role's name and permissions. The table roles sent become the role's whole permission set, and any table not listed loses its entry.
Delete Role Removes a custom role. The people who held it lose the access it granted.
List Role Members Lists the people who hold a role. The read behind any access review.
Add Role Member Grants a role to one person.

Frequently Asked Questions

What can FlowRunner do with Feishu Base?

FlowRunner agents can run Create Base, Get Base, and Update Base in Feishu Base, plus 32 more actions.

Does connecting Feishu Base to FlowRunner require OAuth?

Yes. Feishu Base connects to FlowRunner with OAuth 2.0, so agents authenticate without handling raw credentials.

Can Feishu Base trigger a FlowRunner workflow automatically?

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

Start building with Feishu Base

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us