Airtable Dashboard: KPIs, Setup and Reporting

What should an Airtable dashboard help you decide?

Start with a recurring decision rather than a chart type. An agency's operations lead might ask: which projects need attention this week, which approvals are blocking delivery, and where could costs exceed the agreed internal budget?

Those questions give the dashboard a purpose. A large total of completed tasks may be accurate while saying little about delivery risk.

Airtable provides a Dashboard layout in Interface Designer, with numbers, charts, lists and access to underlying records when configured. Our Airtable Interfaces guide covers the wider workspace design. This article focuses on choosing reliable metrics and turning them into a useful reporting view.

Define your KPIs before building the interface

A key performance indicator, or KPI, needs a clear definition. Specify the population, calculation, reference date and person responsible for the next action.

For the example below, an active project excludes completed and canceled projects. A missing deadline is a data issue to resolve; it should not silently classify a project as on schedule.

The five-day approval window is a teaching assumption, not a universal service standard. Set thresholds with the team and make them visible to the people using the dashboard.

Keep cost consumption separate from progress. Spending 80% of a budget does not establish that 80% of the work is complete. Each measure needs its own definition and supporting data.

Give each metric a reliable data source

A small agency can start with three connected tables:

• Projects: one record per project, with client, owner, status, due date and planned cost budget.

• Deliverables: one record per deliverable linked to its project, with approval status and submission date.

• Actual costs: one record per cost assigned to a project, with amount, date and a reference that allows someone to verify it.

Add a separate Clients table when client information is already maintained there. Reuse those relationships instead of copying the same client details into every project.

If actual costs come from time entries, decide how time is valued and how missing entries are flagged. Applying today's hourly rate to every historical entry can change old reports when that rate changes. Preserve the relevant recorded cost when a stable history is required.

Our Airtable project management guide explains the delivery model behind projects and deliverables. The dashboard should use that operational model as its source.

Calculate at the right level

A Rollup field on Projects can total the amounts of linked cost records with SUM(values). Airtable's rollup documentation explains how linked records support these aggregations.

Count projects in Projects and deliverables in Deliverables. Copying a project's budget into ten cost records and summing that column would count the same budget ten times.

A conditional count or rollup can include only related records that meet defined criteria. Filtering a table view does not, by itself, change the records included in a rollup.

A worked example: three agency projects

The figures below are fictional teaching data, not a client result. All amounts represent planned or recorded production costs over the projects' lifetimes, using the same currency.

The individual consumption ratios are 80%, 90% and 20%. Across this portfolio, the ratio is $13,500 / $20,000 = 67.5%.

A simple average of the three percentages would be 63.3%. That gives equal weight to projects with different budgets. To show the portfolio's overall budget consumption, divide total actual costs by total planned cost budgets.

Keep this calculation distinct from the review decision. Atlas needs its overdue commitment examined. Boreal needs the approval unblocked and the remaining cost assessed. A single portfolio percentage cannot explain either problem.

The ratio measures neither gross margin, revenue nor completion. When time entries are missing, recorded costs are incomplete; make that uncertainty visible before presenting the figure as decision-ready.

How to create the dashboard in Airtable

In the interface editor, add a page, select the Dashboard layout and choose its source table. Airtable's official dashboard walkthrough covers the starting steps.

Begin with a group sourced from Projects. Add a separate group for metrics sourced from Deliverables; each dashboard group uses a single table from the underlying base.

Use the current Dashboard layout documentation for the detailed controls. A practical first page needs only a few elements:

1. Headline metrics showing the situations that need review.

2. A chart by owner or status to explain the distribution.

3. An exception list with project, owner, deadline and next action.

4. A route to the records that explain the numbers.

Check how group filters, visualization filters and user controls interact. Label the population clearly: “Active projects at review date” communicates more than “Projects.”

Be careful with neighboring elements that use different scopes. A cost summary filtered to one owner should not be visually presented as the numerator of a budget total that includes every owner.

Make the exceptions actionable

If a number says two projects are overdue, the reviewer should be able to identify them and understand the next step. Provide the corresponding list and enable access to underlying records where it helps the workflow.

An executive page may emphasize the portfolio. A project lead needs the relevant details and follow-up actions. Trying to serve every role with one dense page usually makes the review harder.

Choose charts that answer a question. A status distribution can reveal a queue of approvals; a list explains which approvals to handle. There is little value in adding a second visualization that tells the same story.

Build monthly reporting separately from the live view

A live dashboard answers “What is happening now?” A month-end report needs to preserve what was true at that cutoff.

Filtering today's data to projects created in September does not reveal how many were overdue on September 30. Statuses, due dates and budgets may have changed since then.

When that history matters, define what must be retained. A dated snapshot table can store the agreed metrics, their scope and the reporting cutoff. An event history supports more detailed reconstruction, with additional design and maintenance effort.

Decide how late corrections are handled. If a time entry arrives after closing, should the old report remain unchanged, be revised with a new version, or be recalculated? Readers need to understand that policy.

For an occasional report, a checked and dated export may be enough. Copying records into another base does not automatically create a historical snapshot. Our Airtable Sync guide explains the responsibilities and limits of synchronization.

Validate calculations, filters and permissions

Before sharing the dashboard, reconcile a small selection of records manually. Include cases that could produce a misleading result:

• a project with no due date;

• a project completed after its deadline;

• a submitted deliverable that was reopened;

• a project with a missing or zero budget;

• a cost assigned to the wrong project;

• a user who should see only part of the data.

A zero budget should not cause an invalid division or silently become a 100% consumption rate. Missing information is not the same as zero. Show an explicit data issue instead of hiding it inside an apparently healthy total.

Review Interface Designer permissions and test with the reader's actual role. Sharing options depend on the plan and access configuration; an analysis filter is not a complete access-control policy.

For external users, our Airtable client portal guide covers the access-design decision. A client who reads a periodic report may need a different experience from one who edits project information or approves deliverables.

When should reporting move beyond Airtable?

Airtable works well when the reporting data is close to the operational workflow and readers need to act on the underlying records. Keeping those elements together can reduce the manual exports between a status update and a review.

A business intelligence tool, designed for data analysis, becomes more attractive when reporting must combine many systems, support complex analytical calculations or maintain a large historical dataset with its own requirements.

Choose based on the actual reporting problem. A new reporting tool cannot repair unclear statuses, missing time entries or duplicated budgets. Equally, forcing every analysis into the operational base can make a useful system harder to maintain.

If the data comes from other tools, define which system owns each value, how it is updated and what happens when an update fails. A chart refreshing successfully does not establish that all of its source data is current.

Start with one review the team can use

Build a dashboard that helps someone make a decision, assign the next action and review the outcome. A few defined metrics, verifiable calculations and a useful exception list are a strong starting point.

HyperOps helps design Airtable business systems, including the data model, interfaces and team adoption. Reliable reporting then becomes part of the way the business operates, with rules the team can understand and maintain.

Frequently asked questions about Airtable dashboards