Baserow Kanban or Busabase change review: what should your team test?

Updated 13 November 2026: added what Baserow's row change history records and which Baserow plans include Kanban, role-based permissions and audit logs, from Baserow's current docs. We also corrected how Busabase review works today: every edit is a Change Request, and waiting for review is optional, set by the key.

A self-hosted team can build a review board by adding Pending, Accepted, and Rejected options to a status field. The board is easy to understand. The harder question is what downstream readers see while a card is marked Pending.

If the agent has already changed the underlying business fields, a pending label may describe work awaiting a person while other tools are already reading the new values. That can be acceptable for collaborative progress tracking. It needs a different design when review must happen before a value becomes authoritative.

Baserow Kanban and Busabase Change Requests provide documented mechanisms for these jobs. Evaluate the object each mechanism controls and the moment the data takes effect.

What moving a Baserow card changes

Baserow's Kanban guide explains that the view "organizes records into vertical columns based on a Single select field." Each record appears as a card. When you move it, "the card's Single select field updates automatically to match the new column," and "this change syncs across all views."

That is useful for sales stages, recruitment, and content production. People see where work accumulates and can move it forward without duplicating records between separate stage tables. Cards can expose the fields that matter for coordination.

A Pending option is still a business field value. Its presence alone does not demonstrate that other proposed field edits remain on an isolated branch. If old values must stay available to consumers until acceptance, verify the write path that enforces that requirement.

Baserow does keep a trail after the fact. Its row change history "records every modification made to a row's data," with the author, the changed fields, and the old and new values. It is "read-only for auditing purposes": to undo a change you copy the old value back by hand, and the guide describes no review step before a change applies. On Baserow Cloud the history is kept for 14 days on Free, 90 on Premium, and 180 on Advanced.

What a Busabase Change Request controls

In Busabase, every edit — a record field, a Doc, a Skill file, a schema change — is a Change Request: a branch with immutable commits, a message, a field-level before-and-after diff, and the author plus the key or tool it came through. Merging fast-forwards the canonical record pointer, so nothing is overwritten, every record keeps its full history, and any change can be rolled back. Busabase Bases open as kanban boards too, alongside table, gallery, calendar, and Gantt views, so moving a card is an edit with the same diff and history.

This makes the proposed field difference an inspectable object. A reviewer can evaluate which values should change and why, which is useful when agents extract facts, enrich records, or update shared conclusions.

Whether a change waits is your choice, set per key. A writer with write access merges as soon as the Change Request is created, and the diff and history stay on the record. Give an agent a proposal-only changeRequest key, or pass autoMerge: false, and its changes wait in the Inbox while canonical records keep exposing the previous values. Because the rule lives on the key rather than in a status option, an agent cannot skip review by writing to a field directly.

Test one record through both reads

Take a real record in a safe test environment and prepare one evidence-backed field change. Record the original value, then verify it through a separate read path representing the downstream consumer.

For Baserow, move the card and inspect the Single select value in Grid. Then exercise the approval design you intend to use for other fields. Check whether the downstream consumer still receives the original value while review is pending. If this relies on a separate proposal table or automation, include its relationships, permissions, and read targets in the test, and look at what row change history shows afterwards.

For Busabase, submit the proposed update with a proposal-only key. Read the Change Request and the canonical record separately. Confirm the diff exists and the canonical value is unchanged while pending; after review, verify the merge state, reread the accepted value, and try rolling it back. This is a suggested evaluation procedure to run in your deployment.

Also test what happens if another actor changes the baseline first. Correct review judgment cannot make an obsolete baseline current. See parallel agent record updates for that separate problem.

When Baserow is a strong fit

Baserow's board directly supports teams that collaborate on tables, advance work through stages, and inspect the same records in several views. Immediate status updates are useful behavior for that job, and a team already running Baserow for people-driven tracking has little reason to move it.

Budget for the plan you need. Baserow's guide says "Kanban view requires paid plans"; its pricing plans list Kanban under Premium ($10–12 per user per month) and role-based permissions and audit logging under Advanced ($18–22). Self-hosting does not make every capability free.

When Busabase fits the control point

Busabase is built for teams where agents write shared facts and someone needs to see, and sometimes approve, exactly what changed. Business progress can remain a field on a record while Change Requests record every edit to that record.

A task might still be in progress after one factual correction has merged. Conversely, a task marked complete may have an associated data change that has not yet been accepted. Define both states so downstream consumers do not treat one as proof of the other.

Beyond the review path, the same workspace gives agents and people:

• A team knowledge base. Docs, files, and Bases in one tree, with roles for members and keys for agents.
• Grep across everything. One regex search over files, Doc bodies, Base records, and agent prompts, returning the matching line and its context.
• Shared Skills. Upload your team's Skills once; every connected agent reads the same version, and editing one is a Change Request.
• AirApps. Small apps on your data that run in the browser, on your machine, in a cloud sandbox, or as a website on your own domain.
• Any agent. MCP, a CLI, an OpenAPI REST API, webhooks, and a Python SDK, so Claude Code, Codex, Cursor, and ChatGPT write under the same rules.

Using both products requires a clear owner for each class of record, stable relationships, and an implemented synchronization direction. Two interfaces should not accidentally create two competing sources of truth.

Include self-hosting operations in acceptance

Installation is only the start. Check backup and restore, upgrades, identity and access, exposure to external networks, logs, and maintenance ownership. Data location, write permissions, merge authority, and downstream read paths are distinct decisions.

Busabase is MIT-licensed and self-hosting is free with no seat limit. It runs on a laptop, on your own servers, or fully offline, and a space exports to plain files: Markdown, Base definitions, and JSON records. If you prefer the cloud, Busabase Cloud is a flat price per seat with no metered overage. Use the Busabase self-hosting guide to examine deployment choices. Deployment control does not by itself prove review or security controls, so test those separately.

Choose the rule that must hold

If the essential rule is that people can see and advance progress, start with board and collaboration acceptance. If unaccepted field changes must stay out of authoritative reads, start with pending values, diffs, effective credentials, and post-merge reads.

Test those rules separately. The result is a clearer purchasing decision and a smaller set of custom controls to operate. For how Busabase compares with other tools on the same jobs, see all comparisons.