Feature · Data Dashboard

Data dashboard software that reads live records, not a warehouse synced yesterday.

Charts, KPI tiles, drill-down surfaces, scheduled inbox snapshots, and permission-aware shares all read directly from the Strkr CRM, forecasting, campaign, messaging, projects, and audit log records. No data warehouse, no modeling layer, no sync job, no BI license. The dashboard is the record.

Start free trial See pricing
What a data dashboard should do in 2026

The nine jobs the dashboard surface actually has to carry.

A data dashboard is one of the most abused words in business software. The lightweight end of the market ships a tile layout with static placeholder numbers. The middleware end ships a chart library tied to a data warehouse the operator has to maintain. The heavy end ships a full BI platform with a modeling layer, a semantic layer, and a licensing conversation. For a mid-market revenue team in 2026, the useful shape sits closer to the lightweight end but with the data read live from the system of record. The dashboard needs to show the right metrics for the role reading it, drill down to the underlying records, refresh continuously, respect permissions, compose a weekly snapshot in the inbox, and be editable without an engineering ticket. The nine jobs below are the ones that separate a production dashboard surface from a demo. Strkr ships all nine as native primitives inside the CRM. The dashboard builder is a surface alongside the records, not a product the admin has to procure separately.

Live data read

The tile reads the current state.

Every tile reads the current state of the underlying records. Open pipeline is the pipeline as of this second. ARR is the live ARR. Open opportunities is the current count. The dashboard the CRO opens at 09:00 Monday shows the state as of 09:00 Monday rather than yesterday-end.

Chart variety

Line, bar, pie, funnel, scatter, heatmap, sparkline.

The chart library carries line, bar, pie, funnel, scatter, heatmap, and sparkline primitives. Each one is configurable with a point-and-click editor. The admin picks the chart type that matches the question rather than forcing every answer onto a bar chart because that was the only option.

KPI tiles

A big number with a trend indicator.

KPI tiles show a big number with an optional trend indicator (up, down, flat) and a configurable comparison (last week, last month, last quarter, target). The CRO reads the KPI line at the top of the dashboard in two seconds and knows whether the function is on plan.

Drill-down

Click a tile, see the records behind it.

Every tile is clickable. Click the open pipeline tile and see the actual deals. Click the at-risk count and see the specific accounts. The dashboard is a navigation surface, not a reporting dead end. The reviewer opens the detail record and acts from there.

Filters and segments

Scope the whole dashboard by any field.

A filter bar at the top of the dashboard scopes every tile to a selected segment: by region, by product, by segment, by rep, by quarter. One filter change reshapes the entire view. The admin builds the dashboard once and the reader slices it by their lens of the business.

Permission-aware

The same dashboard renders differently per role.

A dashboard respects field-level and row-level permissions on every refresh. A VP sees the roll-up; the SDR sees their own queue. A finance partner sees billing fields the sales team cannot. The same template renders differently for different viewers based on their permissions.

Scheduled snapshots

A weekly email with the current numbers.

Every dashboard can schedule a snapshot delivery. The CRO gets a Monday morning email with the current pipeline, forecast, and win rate. The CMO gets a Friday snapshot with the campaign ROI line. The reader opens the inbox and sees the numbers before opening the app.

Shareable links

A URL the viewer can read with their permissions.

Share a dashboard as a link. The viewer sees the current state with their own permissions applied. External board members and advisors see what they are allowed to see. The link respects access controls on every refresh, which is the only safe shape under external audit.

Editable without engineering

Admins add tiles, remove tiles, change ranges.

The admin edits any dashboard with the point-and-click builder. Add a tile, remove a tile, change the time range, change the segment, change the chart type. No SQL, no engineering ticket, no BI-tool specialist. The dashboard moves with the business as the function matures.

The dashboard builder in detail

How an admin builds a dashboard in under an hour.

The Strkr dashboard builder is a drag-and-drop surface with a palette of tile types, a canvas with a configurable grid, a data source selector that lists every reportable field on every object, and a chart configurator for each tile. The admin opens a blank dashboard, picks tiles, places them on the grid, references the data sources, saves, and shares the link. The dashboard goes live reading real data in minutes. The elements below are the ones every admin encounters in the first hour. Each one is editable, inspectable, and testable without engineering support.

Tile palette

KPI, chart, table, funnel, map, text.

The tile palette lists every tile type: KPI (big number with trend), chart (line, bar, pie, scatter, heatmap), table (sortable, filterable rows), funnel (stage progression), map (geographic distribution), and text (markdown-formatted narrative). The admin drags the tile type that matches the question onto the canvas.

Data source selector

Every reportable field on every object.

The data source selector lists every reportable field on every object: CRM records, pipeline, forecast, campaigns, messaging, projects, support, audit log. The admin picks the field and the aggregation (count, sum, average, median, min, max). The tile queries the live record source on every refresh.

Grid layout

Configurable rows and columns.

The dashboard canvas is a configurable grid with rows and columns. The admin drags tiles into the grid, resizes them, and reorders them. The layout snaps to the grid so tiles align cleanly. Responsive rendering handles tablet and mobile without the admin having to configure separate views.

Chart configurator

Series, axes, colors, labels, legends.

Each chart tile has a configurator for series, axes, colors, labels, and legends. The admin picks the x-axis field, picks one or more y-axis series, picks the color palette, and configures the legend placement. The chart renders live. Changes update the preview in real time.

Filter bar

Scope the whole dashboard with one control.

The filter bar at the top of the dashboard scopes every tile to a selected segment. Filters support single-select, multi-select, date range, and search. The admin configures which filters appear on the bar; the reader uses them to slice the view.

Date range

Last 7 days, last 30, QTD, YTD, custom.

The date range selector at the top of the dashboard scopes time-based tiles. Predefined ranges cover the common analysis windows. Custom ranges support any start-end pair. Every time-aware tile picks up the selected range automatically.

Comparison toggles

This period vs last period or vs target.

KPI tiles carry a comparison toggle: compare the current value to the same period last cycle, to a configured target, or to a baseline. The trend arrow and the percent change render automatically. The CRO sees not just the number but the direction.

Preview and publish

See the dashboard before saving it.

The preview surface shows the dashboard as the reader will see it with the current permission context. The admin confirms the layout, the data correctness, and the readability before publishing. A publish lands the dashboard on the admin's configured surface (homepage, module page, dedicated URL).

Version history

Every save is a version with a diff.

Every save creates a version of the dashboard with a diff against the previous one. The admin pulls up any prior version and reverts in two clicks. The version history is a first-class surface rather than a hidden database table, which lets the admin experiment freely without fearing an unrecoverable change.

The data-source model

What a reportable field is, and how the dashboard queries it.

The dashboard builder reads from a reportable-field model that spans every object in Strkr. A reportable field is any field (standard or custom) that the admin has not explicitly suppressed from reporting. The reportable field set is the natural superset: every field matters until the admin says otherwise. The dashboard builder queries the live record source on every refresh, so a change on a record propagates to every dashboard tile referencing the field within seconds. The elements below describe the shape of the data-source model and how the builder uses it. The admin never writes SQL; the model is a graph the builder traverses on behalf of the admin.

Reportable fields

Standard, custom, roll-up, computed.

The reportable field set includes every standard field (name, amount, stage, owner), every custom field admins have added, every roll-up field (parent-account ARR, team quota attainment), and every computed field (deal risk, health tier). The admin references the field by name in the data source selector.

Aggregations

Count, sum, average, median, percentile.

The aggregation set covers count, sum, average, median, min, max, percentile (p50, p75, p90, p95, p99), standard deviation, and distinct count. The admin picks the aggregation that matches the question. Percentile aggregations are often more revealing than averages, and the builder makes them a first-class choice.

Group by

Any categorical field, any date granularity.

The group-by selector supports any categorical field (segment, product, region, owner, stage) and any date granularity (day, week, month, quarter, year, fiscal quarter). The admin picks the grouping that matches the question. The chart renders with one group per bar or line.

Filters

Any field, any boolean condition.

The filter set supports any field with any boolean condition: equals, not equals, contains, greater than, less than, between, is null, is not null. Multiple filters compound with AND. The admin builds a filter in the form rather than writing a WHERE clause.

Joins across objects

Deal-to-account, campaign-to-contact, ticket-to-account.

The data source selector follows the natural relationships between objects. The admin references a field on a related object (the account industry on a deal, the contact title on a campaign enrollment, the account tier on a support ticket) without constructing an explicit join. The traversal is implicit and permission-aware.

Time ranges

The record age against the configured window.

Time-based tiles filter records by created-at, modified-at, closed-at, or any configured timestamp field against the selected range. The admin picks the timestamp field and the range. The engine returns the matching records on every refresh.

Row-level permissions

The query returns only records the reader can read.

The query engine enforces row-level permissions on every read. A reader with access to only their own records sees aggregations over their own records. A reader with access to the whole function sees the full rollup. The dashboard respects the permission posture at query time, not through a wrapper.

Field-level permissions

Fields the reader cannot see are masked.

A field marked restricted for a reader is masked in dashboard tiles. The tile shows a masked value or a count without the sensitive field. The reader cannot infer the restricted value from an aggregation, which closes the back door that competing dashboard tools often leave open.

Refresh policy

Continuous read, with optional caching.

The default refresh policy is continuous read: every dashboard load queries the live records. For high-traffic dashboards, the admin can enable caching with a configurable TTL (5 seconds, 30 seconds, 5 minutes) to reduce load. The CRO dashboard typically runs at continuous; the public-shared dashboard runs at 30-second cache.

What the dashboard answers for different functions

How a sales leader, a marketing operator, and a finance partner use the surface.

A dashboard answers different questions for different functions, which is why role-scoped templates ship as the starting point in Strkr. The sales leader reads deal risk, pipeline health, and win rate variance. The marketing operator reads campaign ROI, cost per MQL, and conversion by segment. The finance partner reads revenue recognition, cash runway, and ARR waterfall. The CSM manager reads health tier distribution, open renewals, and expansion signals. The nine views below describe the specific questions each function brings to the dashboard surface and the specific tiles that answer each one. The admin configures the template once per function; the function reads it every day.

Sales leader

Deal risk, pipeline health, win rate.

The sales leader opens the dashboard to see at-risk deal count by rep, pipeline health score, win rate trailing 12 months, average cycle length, and pipeline coverage against the next quarter. The Monday forecast call starts on the data points that need coaching rather than on a dashboard dig.

Marketing operator

Campaign ROI, MQL mix, conversion by segment.

The marketing operator reads campaign ROI across the trailing 90 days, MQL volume mix by source, conversion by segment, and cost per MQL by channel. The quarterly board report composes from the same dashboard the operator uses daily, which closes the credibility gap on sourced-pipeline numbers.

Finance partner

Revenue recognition, cash runway, ARR waterfall.

The finance partner reads recognized revenue by quarter, cash runway, net retention by cohort, and ARR waterfall (new, expansion, contraction, churn). The CFO walks board meetings from the dashboard rather than from a slide deck prepared the night before.

CSM manager

Health distribution, renewal queue, expansion plays.

The CSM manager reads health tier distribution per CSM, open renewals in the 180-day window per CSM, expansion plays fired per CSM, and churn risk list per CSM. The weekly scrub runs from the dashboard with specific accounts and specific CSMs already identified for intervention.

Support manager

Queue depth, SLA attainment, CSAT.

The support manager reads the live queue depth by severity, SLA attainment trailing 7 days, escalation count by agent, and CSAT trend. The morning standup runs from the dashboard with specific tickets and specific agents already identified for support.

Product manager

Feature adoption, usage trends, feedback mix.

The product manager reads feature adoption curves (if product telemetry is attached), usage trend sparklines across top accounts, and the mix of feedback submissions by category. The quarterly roadmap conversation references real adoption data rather than a vibe.

Executive sponsor

ARR, net retention, bookings, strategic KPI.

The executive sponsor reads a short dashboard of ARR, net retention, bookings growth, pipeline coverage, and the one strategic KPI the function is currently prioritizing. The executive opens the dashboard in a meeting and reads the state in sixty seconds.

RevOps lead

System hygiene, enforcement rate, admin backlog.

The RevOps lead reads pipeline hygiene flag count by rep, data cleanliness score by object, enforcement rule pass rate, lead routing SLA attainment, and the admin backlog of pending configuration changes. The function health shows up in one place rather than three consoles.

Board or advisor

The sanitized executive view.

The board template renders the specific metrics the board asks for every quarter: ARR, net retention, bookings growth, pipeline coverage, CAC, LTV, cash runway, headcount, strategic KPI. The CEO shares the dashboard link with the board; the board sees the current state before the meeting with the admin-configured sanitization applied.

How data dashboards connect to the rest of Strkr

The surface that pulls from every object and respects every permission.

A data dashboard earns its keep by reading the live records across every surface the business operates on. In Strkr the dashboard builder reads from every object in the data model: CRM records, pipeline, forecast rollups, campaigns, messaging history, projects, support tickets, document references, and audit logs. Every field is reportable unless the admin has suppressed it. Every permission applies on every refresh. The relationships below are the ones every function exercises when building or extending a dashboard.

CRM records

Account, contact, deal, lead, custom objects.

Every field on every CRM object is available to the dashboard builder. Build a tile on open pipeline by segment, a tile on contact count by tier, a tile on deals above the executive threshold. The CRM is the primary data source for most dashboards.

Pipeline and forecast

Rollups by rep, team, segment, quarter.

The forecast surface rolls up by rep, team, segment, product, and quarter. Every rollup is a dashboard tile. The CRO forecast dashboard, the VP Sales team dashboard, and the AE personal dashboard all read from the same forecast rollup, which keeps the numbers consistent across levels.

Campaign records

Marketing performance tiles.

Every campaign field is a reportable column. Build a dashboard on open rate by segment, cost per MQL by channel, campaign ROI by quarter. The CMO dashboard pulls from the same records the marketing operator pulls from, so the numbers converge across the function.

Messaging history

Email and SMS engagement tiles.

Every send, open, click, reply, bounce, and SMS delivery is a tile source. Build a dashboard on cadence effectiveness by SDR, email volume by day, SMS reply rate by channel. The dashboard reads live from the Strkr Messaging surface with the full consent and audit log posture applied.

Projects records

Sprint, release, backlog tiles.

The Projects module ships its records to the dashboard builder. Build a tile on sprint velocity, release cadence, backlog depth. The engineering function reads from the same dashboard surface the revenue function reads from, which is a cross-functional operating practice most organizations have been chasing for years.

Support tickets

Queue depth, SLA attainment, CSAT.

The support records (ticket queue, SLA, CSAT, escalations) all flow into the dashboard builder. The VP Support, the support manager, the agent, and the account team all read support data from the same surface. The CSM looking at an at-risk account sees the open tickets without switching tools.

Audit log

Operations dashboards on log data.

The audit log is a reportable source. Build a tile on flow run success rate, enforcement rule pass rate, admin action volume. The RevOps dashboard pulls from the audit log and surfaces operational health that would otherwise be invisible.

Strkr AI

Model usage, draft volume, score distribution.

Strkr AI usage is reportable. Build a tile on drafts composed per week, score distribution across the contact base, verification pass rate on outbound. The admin sees the AI usage across the tenant without a separate billing dashboard, since there is no credit meter to track.

Permission model

One template renders differently per role.

A dashboard respects field-level and row-level permissions on every refresh. One template, many views, right data to the right reader. Compliance posture holds across every refresh and across every shared link, which is the only safe shape for external board access.

Data dashboard software that reads live records, not a warehouse synced yesterday.

Live data read, chart variety, KPI tiles, drill-down, filter bar, permission-aware rendering, scheduled snapshots, shareable links, and point-and-click editing all ship on every paid tier. No data warehouse, no modeling layer, no sync job, no BI license.

Start free See dashboard examples
Common questions

What buyers ask about this feature.

What is a data dashboard and how does Strkr handle it differently from a BI tool?

A data dashboard is a composed view of charts, KPI tiles, tables, and other visualizations that answer business questions from the live state of the organization. The classic approach uses a BI tool (Looker, Tableau, Power BI) with a data warehouse behind it, a modeling layer, a semantic layer, and an engineering team maintaining the pipeline from the operational system to the warehouse. The native approach lives inside the system of record. Strkr reads live records from the CRM, forecasting, campaign, messaging, projects, support, and audit log surfaces directly. There is no warehouse, no modeling layer, no sync job, and no separate BI license. The number on the CRO dashboard is the same number the AE sees in the pipeline because they read the same table. For deep ad-hoc analytical work, a specialized BI tool may still have a role, but the day-to-day operational dashboards that run most functions fit inside Strkr.

What chart types and tile types ship on the Strkr dashboard builder?

Six primary tile types. KPI (big number with trend indicator and configurable comparison), chart (line, bar, pie, scatter, heatmap, funnel), table (sortable and filterable rows with configurable columns), funnel (stage progression with conversion rates), map (geographic distribution), and text (markdown-formatted narrative for context). Chart tiles configure series, axes, colors, labels, and legends through a point-and-click editor. KPI tiles configure the primary metric, comparison period, and target. Table tiles configure sortable and filterable columns with per-column aggregation. The admin picks the tile type that matches the question rather than forcing every answer onto a bar chart.

How does Strkr handle permissions when sharing a data dashboard externally?

A dashboard respects field-level and row-level permissions on every refresh. Share a dashboard link with an executive, a board member, or an external advisor; the viewer sees only the data their configured permissions allow. External board members typically see the sanitized executive roll-up without row-level detail. The CFO sees financial fields the sales team cannot. The CRO sees pipeline fields the marketing team may not. The same template renders differently for different viewers based on their permissions. External shares expire on a configurable schedule and can require authentication (SSO, email verification, or password), so the posture stays tight across audit and compliance review.

How does Strkr handle refresh cadence for data dashboards?

The default refresh policy is continuous read: every dashboard load queries the live records. For high-traffic dashboards (public shared links, embedded views on partner portals), the admin can enable caching with a configurable TTL of 5 seconds, 30 seconds, or 5 minutes to reduce load. Scheduled snapshots deliver a frozen view at the configured cadence (Monday morning, Friday afternoon, nightly) to configured recipients. The CRO dashboard typically runs continuous; the public-shared quarterly board dashboard runs at 30-second cache; the weekly executive brief runs as a Monday snapshot. The admin picks the right posture per dashboard.

Can I build a data dashboard without engineering support or BI expertise?

Yes. The dashboard builder is a point-and-click surface. The admin opens a blank dashboard, picks tile types from the palette, drags them onto a configurable grid, references data sources from the reportable field selector (every field on every object is listed), picks an aggregation and a grouping, configures the chart in a form, previews the live rendering, and publishes. No SQL, no modeling layer, no BI-tool specialist. The admin uses the same primitives the engineering function uses for its own operational dashboards. Fifteen role-scoped templates ship enabled on every paid tier as starting points, so most admins start from a template and customize rather than building from a blank canvas.

Does Strkr support drilling down from a dashboard tile to the underlying records?

Yes. Every tile is clickable. Click the open pipeline tile and see the actual deals that compose the number in a sortable, filterable list. Click the at-risk count and see the specific accounts with the risk reasons attached. Click a campaign tile and see the campaign records with the sends, opens, replies, and sourced pipeline attached. The dashboard is a navigation surface, not a reporting dead end. The reviewer opens the detail record and acts from there, which is the shape that lets a Monday forecast call open on specific deals and resolve them in the same conversation rather than pivoting to a separate CRM view.

Related features

Pair this with...

Dashboard Software Dashboard Examples CRM Dashboard KPI Dashboard Sales Dashboard Sales Analytics

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing