Baserow glossary: Key terms and concepts

This comprehensive glossary explains essential Baserow terminology across all modules: Database Builder, Application Builder, Dashboard Builder, and Automation Builder. Terms are organized by category to help you understand how concepts relate to each other.

Understanding Baserow terminology

Learning Baserow terminology accelerates your ability to use the platform effectively, troubleshoot issues, and collaborate with your team. This glossary covers terms from all Baserow modules, organized by category to show how concepts connect. Whether you’re building databases, creating applications, designing dashboards, or automating workflows, these definitions will help you navigate Baserow with confidence.

Baserow core concepts visualization

Core platform concepts

These foundational terms apply across all Baserow modules:

Term Definition
Workspace The top-level organizational container where teams collaborate. Workspaces hold databases, applications, dashboards, and automations.
Workspace admin A user role with full control over workspace management, including adding members, assigning permissions, creating databases and applications, and managing workspace settings. Different from an instance admin.
Workspace member A collaborator who has access to a workspace with specific permissions assigned by workspace admins.
Billable user Any user with access to a workspace who counts toward your subscription’s user limit.
Role-based permissions A system for controlling access by assigning roles that determine what users can view and modify.
Snapshot A complete point-in-time backup of your database that can be restored later.

Database Builder terms

Terms related to organizing and structuring data:

Term Definition
Database A container for related tables that organize data for specific projects or purposes. A workspace can contain multiple databases.
Table A structured collection of data organized into rows and columns within a database. Each table represents a specific type of information.
Table ID A unique numerical identifier assigned to each table, used for API access and linking tables together.
Field A column in a table that defines a specific type of data to be stored. Each field has a data type (text, number, date, file, etc.) that determines what information it can hold.
Row A single record in a table containing related information across multiple fields. Each row represents one item, person, task, or data point.
Row ID A unique numerical identifier automatically assigned to each row when created. Access using the row_id() formula.
Cell The intersection of a row and column where individual data values are stored. Each cell contains one piece of information for one record.
Link to table field A field type that creates relationships between tables, allowing you to connect related data. For example, linking “Customers” to “Orders” to see which customer placed each order.
Filter Criteria applied to show only relevant information, such as date ranges, categories, or specific conditions.
View A customized way of displaying and interacting with table data. The same table can have multiple views (Grid, Gallery, Form, Kanban, Calendar, Timeline) that show data differently without changing the underlying information.
Grid view The default spreadsheet-like view for tables, best for detailed data entry and manipulation.
Gallery view A visual view displaying records as cards with images, ideal for products, portfolios, or any visual content.
Kanban view A board view organizing records as cards in columns based on a single-select field, perfect for workflow management and project tracking.
Calendar view A calendar-based view displaying records with date fields as events, useful for scheduling and deadline tracking.
Form view An interactive form for collecting data from external users who don’t need database access.
Timeline view A Gantt-chart-style view showing records with start and end dates along a timeline, ideal for project planning.
Primary field The first field in every table that serves as the main identifier for each row.

Application Builder terms

Terms for creating custom applications:

Term Definition
Application A custom web interface built using the Application Builder, consisting of pages, elements, and data sources. Applications can be internal tools, customer portals, or public websites.
Page An individual screen or route within an application. Applications can have multiple pages with navigation between them.
Element A building block component added to pages (buttons, tables, forms, text, images, inputs, etc.). Elements are configured to display data and respond to user interactions.
Data source A connection between application elements and database tables that provides data to display or modify. Data sources can include filters, sorting, and search parameters.
Page parameter A variable passed in the URL that allows dynamic page content based on the parameter value (e.g., showing different customer details based on customer ID).
Event An action that occurs when users interact with elements (clicking buttons, submitting forms, etc.). Events trigger workflows like navigation, data updates, or notifications.
User source An authentication system that controls who can access an application and what data they can see based on their login credentials.
Published application An application that has been deployed and is accessible to users via a URL or custom domain.
Domain A custom web address (URL) assigned to a published application for professional branding.
Theme Visual styling settings (colors, fonts, spacing) applied across an entire application for consistent appearance.

Dashboard Builder terms

Terms for visualizing data and metrics:

Term Definition
Dashboard A visual analytics interface displaying data from databases through charts, tables, and metrics. Dashboards provide at-a-glance insights into key performance indicators.
Widget An individual visualization component on a dashboard (chart, table, metric, gauge, etc.). Each widget displays specific data from connected database sources.
Chart A visual representation of data using bars, lines, pies, or other graphical formats. Charts help identify trends, patterns, and comparisons.
Data summary Calculations performed on database data to create summaries (sum, average, count, min, max, etc) displayed in dashboard widgets.

Automation Builder terms

Terms for creating automated workflows:

Term Definition
Automation A container holding one or more workflows that run automatically based on triggers. Automations connect Baserow with other tools and automate repetitive tasks.
Workflow A sequence of nodes (trigger + actions) that execute in order when the workflow runs. Each workflow has exactly one trigger followed by one or more actions.
Node A single step in a workflow, either a trigger (the starting event) or an action (what happens next). Nodes execute sequentially from top to bottom.
Trigger The first node in every workflow that determines when the workflow runs.
Action A node that operates the trigger fires. Actions can create/update/delete rows, send notifications, call external APIs, or transform data.
Test run A single manual execution of a workflow to verify it works correctly. Use for development and debugging.
Publish Activating a workflow for production use. Published workflows run automatically whenever their trigger conditions are met, without manual intervention.
History A log of all workflow executions showing successful runs, failures, error messages, and execution details. Essential for troubleshooting and monitoring automation performance.
Conditional logic Rules that determine whether actions execute based on specific conditions (if/then statements). Allows workflows to make decisions based on data values.
Data mapping Assigning values from trigger data to action fields, allowing information to flow through the workflow.
Error handling How workflows respond when something goes wrong, including retry attempts, fallback actions, or notifications to admins.

Deployment and administration terms

Terms related to hosting and managing Baserow:

Term Definition
Baserow Cloud The hosted SaaS version of Baserow at baserow.io where infrastructure, updates, and maintenance are managed by Baserow. Also called “hosted” or “cloud” version.
Self-hosted Baserow installed on your own servers (on-premise or private cloud) where you manage infrastructure, updates, and maintenance. Also called “on-premises” hosting.
Instance A complete Baserow installation, whether Cloud or Self-hosted. Each instance has a unique identifier used for licensing.
Instance ID A unique identifier for your Baserow installation, required for premium license activation on Self-hosted deployments.
Instance admin A server-wide administrator role (Self-hosted only) with access to all workspaces, user management, license activation, and system settings. The first user account is automatically an instance admin. Different from workspace admin.
Admin panel The interface where instance admins manage users, workspaces, licenses, audit logs, and system settings.
License A purchased subscription that activates paid features on Self-hosted installations.
License key A unique string of characters used to register and activate a premium license on a Self-hosted instance.
Single Sign-On (SSO) An authentication system allowing users to log in to Baserow using credentials from another service (Google, Microsoft, Okta, etc.) without creating separate passwords.
Open source The freely available version of Baserow with core features, released under the MIT license. Can be used, modified, and distributed without licensing fees.
Paid features Advanced functionality (advanced permissions, increased limits, premium field types) available through paid subscriptions on both Cloud and Self-hosted.
Enterprise features High-end functionality (audit logs, SSO, admin panel, priority support) available on Enterprise plans.

API and integration terms

Terms for programmatic access and external connections:

Term Definition
API (Application Programming Interface) A programmatic interface for accessing and manipulating Baserow data from external applications. Baserow provides a REST API for each database.
Database token An authentication credential that grants API access to specific databases with defined permissions. Used instead of user passwords for secure API calls.
Webhook An automated HTTP notification sent from Baserow to external services when specific events occur (row created, updated, deleted). Enables real-time integrations.
REST API The architectural style of Baserow’s API, using standard HTTP methods (GET, POST, PATCH, DELETE) to interact with data.
Endpoint A specific URL in the API that performs a particular operation (e.g., /api/database/tables/{table_id}/rows/ to access table rows).
API Rate limit A restriction on how many API requests can be made within a time period.

Collaboration terminology

Term Definition
User The broadest term. A person with a Baserow account. (Example: “A user can be invited to multiple workspaces.”)
Workspace Member A user who has successfully joined a workspace. This is the standard term for anyone who is part of a workspace. (Example: “Admins can manage all workspace members.”)
Role (e.g., Admin, Editor) The specific permission level assigned to a workspace member. (Example: “A new workspace member is assigned the Editor role.”)
Member role A specific role that a workspace member can be assigned, which has fewer permissions than Admin. (Example: “The Member role has fewer permissions than Admin.”)
Collaborator A term used for the Collaborator field type, which is used to assign a workspace member to a specific row. (Example: “Assign a task using the Collaborator field.”)

Frequently asked questions

What’s the difference between a workspace admin and instance admin?

A workspace admin manages a specific workspace, adding members, creating databases, and controlling workspace-level permissions. An instance admin (Self-hosted only) manages the entire Baserow installation, all users, all workspaces, licenses, and system settings. One person can own both roles, but they serve different purposes.

How do views differ from applications?

Views are different ways to display a single table’s data within the Database Builder (Grid, Kanban, Calendar, etc.). Applications are standalone interfaces built with the Application Builder that can combine multiple tables, add custom layouts, and create experiences for users who never see the underlying database structure.

Do I need to understand all these terms before using Baserow?

No. Start with core concepts (workspace, database, table, field, row) in the Database Builder. Learn Application Builder, Dashboard Builder, and Automation Builder terminology only when you’re ready to use those modules. Most users begin with databases and gradually adopt other builders as their needs grow.

What’s the difference between a trigger and an action in automations?

A trigger is the starting event that causes a workflow to run (e.g., “when a row is created”). Every workflow has one trigger. Actions are the operations that happen after the trigger fires (e.g., “send an email”, “update a row”). Workflows can have multiple actions that execute in sequence.

What does “billable user” mean for my subscription?

Each billable user counts toward your plan’s user limit. Guest access through public view sharing doesn’t count toward your limit. Learn more about billable users.

Can I use automation without the Application Builder?

Yes. Automations work independently and can interact with database tables directly. You don’t need to build applications to use automation. Automations are useful for tasks like sending notifications, syncing data, generating reports, or connecting to external services, all without building custom apps.

What’s the relationship between databases, applications, and dashboards?

Databases store your structured data in tables. Applications present that data to users through custom interfaces. Dashboards visualize data through charts and metrics. All three can coexist in the same workspace, pulling from the same database tables. Think of databases as your data foundation, applications as user interfaces, and dashboards as analytics layers.

Related content

Still need help? If you’re looking for something else, please feel free to make recommendations or ask us questions; we’re ready to assist you.