Build a data-backed Dashboard

Use this guide to turn a changing operational list into structured Data and a reusable Dashboard. The example tracks customer renewals, owners, risk, and next actions.

Start with the decision

Write the question the team must answer:

Which renewals need attention, why, and who owns the next action?

This question determines the fields and Dashboard blocks. Do not copy every spreadsheet column into the first model. Use:

Knowledge for durable policies, definitions, and procedures;
Data for records that change, such as renewals, tickets, invoices, or assets;
Dashboards for a repeatable view of that Data.

Create a Data model

Open Data, then select Models in the upper-right navigation. Select New model. Name the model after one business record, such as Customer Renewal. Define fields with stable business meaning:

Field	Type	Required?	Purpose
`customer_name`	string	Yes	Identifies the account
`account_owner`	string	No	Assigns operational responsibility
`renewal_date`	date	Yes	Supports time-based review
`contract_value`	number	No	Shows commercial impact
`risk_level`	choice: low, medium, high	No	Sets review priority
`status`	choice: planning, review, ready	Yes	Tracks lifecycle state
`next_action`	string	No	Records the required follow-up

Cromo Data Models page showing the active Customer Renewal model and its seven typed fields — A Data model is the schema contract for every table created from it.

Model rules

Use snake_case field names that remain meaningful outside one report.
Use a choice when the valid values are known.
Require only fields without which the record is unusable.
Keep policy prose out of the model; link the relevant Knowledge page from the process instead.
Create a new model version when the schema meaning changes.

An optional next_action is useful: the Dashboard can reveal records that still need one. Making every field required can hide data-quality work by preventing incomplete records from being recorded.

Create the table

Open Data → Tables, select New table, name it Renewals, and choose the Customer Renewal model. Add a small, varied data set before importing or entering a larger list:

Customer	Owner	Renewal	Value	Risk	Status
Northwind Labs	Alex Morgan	Sep 15, 2026	150,000	high	review
Blue Harbor	Maya Chen	Oct 3, 2026	82,500	medium	planning
Cedar Health	Alex Morgan	Dec 18, 2026	214,000	low	ready
Acme Retail	Maya Chen	Aug 28, 2026	126,000	high	review

Select Add row to enter a record. Correct validation errors before adding more data.

Cromo Data Tables page showing four renewal records with status, risk, next action, date, owner, and customer fields — The Renewals table contains four validated records created from the Customer Renewal model.

Verify the table

Check:

dates use the intended calendar day;
numeric values are numbers rather than formatted text;
choice values use one consistent spelling;
each record belongs to this Project;
missing values are genuinely unknown, not accidentally omitted.

Open Fields to compare the table columns with the model. If a field’s meaning is wrong, fix the model before the table becomes a shared dependency.

Test the data in Chat

Attach the Renewals table and ask a question with an explicit output contract:

Read the Renewals table.

Return customer_name, account_owner, renewal_date, contract_value,
risk_level, status, and next_action.

Show high-risk records first. Flag missing values. Do not infer or invent
a value that is not present in the table.

Compare every returned row with the table. If the answer is hard to request clearly, improve field names and choice values before building the Dashboard.

Ask Cromo to create the Dashboard

Open Chat or select Ask, then request a view tied to the operational decision:

Create and publish a Dashboard named Renewal Overview from the Renewals
table.

Include:
- a short review note;
- a bar chart of contract_value by risk_level;
- a searchable table with customer, owner, renewal date, risk, and value.

Use the existing table values. Label missing next actions for follow-up.
Do not update the Renewals table.

Cromo creates a Dashboard specification, validates its references, and publishes the active version. If the request is ambiguous, answer the follow-up questions before publishing.

Dashboard creation happens through Chat. The Dashboards page is where you open and manage published views.

Review the published Dashboard

Open Dashboards → Renewal Overview.

Cromo Renewal Overview Dashboard showing a review note, a contract value by risk chart, and a searchable renewals table — A published Dashboard can combine guidance, charts, and searchable live table rows.

Verify the result against the source table:

chart categories correspond to actual risk_level values;
dates and currency are formatted correctly;
the table contains the intended fields;
search finds a known customer or owner;
empty values remain visibly empty or are explicitly flagged;
notes describe the review process without inventing policy.

Use the refresh action on a data-backed block after records change.

Manage published Dashboards

Return to Dashboards to see the title, publication status, last update, and available actions.

Cromo Dashboards page showing the published Renewal Overview Dashboard and its management actions — The Dashboards list provides open, rename, and delete actions for each published view.

From the row actions you can:

open the Dashboard;
rename its display title;
delete it after confirming the impact.

Renaming the title keeps the route slug stable. Delete a Dashboard only when nobody relies on the view; deleting the view does not replace the need to decide what happens to its source table.

Keep the Dashboard trustworthy

Assign separate owners for:

Responsibility	Owner’s job
Model	Protect field meaning and approve schema changes
Table	Keep records current and correct validation errors
Dashboard	Verify blocks answer the intended decision
Process	Act on the records surfaced by the view

Use a Workflow when updates or review preparation repeat on a schedule. Keep policy definitions in Knowledge rather than embedding changing rules in chart titles. Recheck the Dashboard after:

changing the Data model;
adding, removing, or renaming fields;
changing choice values;
replacing a source table;
changing a Workflow that writes records;
changing connector access used by the underlying process.

Troubleshooting

New model or New table is unavailable

You need the Member, Admin, or Owner role and membership in the Project. Ask a Workspace Admin or Owner to verify both.

A row is rejected

Compare the value with the model: required fields must be present, numbers must be numeric, dates must be valid, and choices must use an allowed value.

Chat returns unexpected columns or rows

Attach the intended table explicitly and name the required fields in the prompt. Check that similarly named tables do not represent a different process.

The Dashboard cannot load a block

Open the source table and confirm that it still exists and contains the referenced fields. Then ask Cromo to update the Dashboard specification or recreate the affected block.

A chart looks numerically wrong

Compare its category and value fields with the underlying rows. A bar per record is different from a grouped total; state the intended grouping and aggregation explicitly when asking for the change.

Recent table changes do not appear

Use the block’s refresh action, then reopen the Dashboard. Confirm that the changed records belong to the same table and Project.

The Dashboard is correct but not actionable

Add the owner, status, date, risk, and next-action fields needed for a decision. Remove decorative blocks that do not change what the team does next.

Completion checklist

The operational question is explicit.
The model represents one business record.
Field names and choice values have stable meaning.
Representative rows validate correctly.
Chat returns the expected rows without invented values.
Dashboard chart and table match a manual data check.
Empty or missing values remain visible.
Model, table, Dashboard, and process owners are named.
Changes to the underlying Data trigger a Dashboard review.

Getting Started

Concepts

Guides

Examples

Reference

Build a data-backed Dashboard

Start with the decision