A customer guide to how Eightfold's native dataset, widget, and dashboard architecture works end to end — how custom filters and raw data exports are powered, and why native dashboards reflect more current data than dashboards backed by Amazon QuickSight's SPICE cache.

Architecture at a Glance

Figure 1 — Native dashboards remove two layers from the path between you and your data: no SPICE cache and no materialized view layer to fall behind. Each widget queries StarRocks base tables directly, live, on every view.

A native dashboard has three layers between your screen and your data: the dashboard UI, the modelled base tables, and StarRocks as the data warehouse. Every widget queries those base tables directly — there is no SPICE-style in-memory cache and no materialized-view pre-aggregation layer sitting in between for the data to go stale in. Some other BI stacks, such as QuickSight paired with a Redshift warehouse, add both of those layers on top of the base tables, for five layers total between the UI and the warehouse.

The Architecture: Dataset → Widget → Dashboard

Every native chart, table, and dashboard is built from three layered building blocks. Understanding the relationship between them explains both how quickly changes propagate and how your data stays secure and current.

Dataset

A dataset is the governed, reusable definition of what data to pull — a named, secured query over your Eightfold data (for example, "Applications by Stage" or "Candidate Pipeline Events"). A dataset is defined once and can power any number of widgets across any number of dashboards.

Widget

A widget is a single chart, table, or KPI tile built on top of a dataset. A widget adds the specific slicing you want to see — how to group the data (by month, by recruiter, by stage), how to summarize it (count, sum, average), and how to sort or drill into it — without needing its own private copy of the underlying query.

Dashboard

A dashboard is a named page that arranges widgets into sections/tabs and adds shared, dashboard-level filters that apply across every widget on the page at once, alongside any filters scoped to just one widget.

What this means for you: because widgets reference their dataset by name rather than embedding a private copy of its query, a correction or enhancement made once at the dataset level is automatically reflected everywhere that dataset is used — every widget, every dashboard — with no need to re-author each one individually. It also means your security rules are enforced consistently for every widget built on a given dataset.

How a Dashboard Actually Gets Its Data

Dashboards load in two stages

When you open a native dashboard, Eightfold first loads its layout — which widgets exist, how they're arranged, and which filters are available. No chart data has been queried yet at this point. Each widget then independently fetches its own data the moment it actually scrolls into view. In practice, this means opening a dashboard with twenty widgets does not fire twenty queries before you've even scrolled down — only the widgets you actually look at run a query.

No intermediate cache

This is the most important architectural fact behind data freshness: there is no separate, pre-computed copy of your dashboard's numbers sitting between you and the warehouse. Every time a widget's chart is displayed, Eightfold builds and runs that widget's query live, at that moment, directly against your analytics warehouse. What you see on screen is the state of your data at the instant you loaded it — not a snapshot taken at some earlier point.

Access rules are enforced on every query, not once

Row-level security is not a separate access check performed once when you log in or when a dashboard was configured. It is built directly into the same live query described above, every single time a widget runs. Both your data and your access to that data are always evaluated against the current moment — never against a permission snapshot that could be out of date.

What this means for you: a native dashboard is never "waiting to catch up." Every widget you look at reflects your Eightfold data as it exists right now, recalculated fresh on every view, with your current access rules applied at the same time.

Custom Filters

Two scopes of filtering

Dashboard-level filters live in a filter bar at the top of the page and apply to every widget on that page simultaneously. Widget-level filters narrow just a single chart without affecting the rest of the dashboard. The two can be combined freely.

Standard filter types

• Date ranges — relative presets (e.g. "last 7 days") or an explicit start/end date.
• Dropdown / multi-select — chosen from a defined list of values.
• Free-text search — with type-ahead suggestions drawn live from your actual data, not a static list.

Filtering on your own custom fields

Beyond Eightfold's standard fields, native dashboards can also filter on custom fields your organization has configured. These are extracted directly out of the same underlying data your dashboards already query, so a custom-field filter behaves exactly like a standard one — no separate system, no separate refresh cadence, and no extra step required to keep it "in sync."

Filters run against live data, not a cached snapshot

Applying or changing a filter re-runs the widget's query against the warehouse right then, with the filter translated directly into the query itself. It is never a re-slice of a previously-fetched or cached dataset — a filtered view is exactly as current as an unfiltered one. Filter selections also live in the page's URL, so a specific filtered view is shareable and bookmarkable, reproducing the same slice of data for a teammate who opens that link.

What this means for you: filtering never trades away freshness. A dashboard filtered down to "this quarter, EMEA, Engineering requisitions" is exactly as current as the unfiltered view — because it's the same live query, just with more conditions attached.

Exporting the Underlying Raw Data

What export gives you

Every widget supports exporting its underlying row-level detail — not just the summarized numbers shown in the chart. A chart showing "applications by month," for example, can be exported as the individual application records that make up each month's count.

Choosing columns

Before exporting, you choose which columns to include. Eightfold pre-selects the columns already used by the chart you're exporting from, and you're free to add other columns available in the underlying dataset or remove ones you don't need.

Two ways to get your data

Same filters, same security, every time

An export is built from the exact same query logic as the widget it came from — the same dashboard and widget filters you have applied, and the same row-level access rules, are applied to the export automatically. The only difference is that export returns full, unaggregated row-level detail instead of the chart's grouped/summarized view. You can never export data through this path that you would not already be permitted to see on the dashboard itself.

Tip: because export reuses the same live query as the dashboard, an exported report is always as current as the dashboard was at the moment you clicked Export — not a periodic batch file generated earlier.

Why Native Dashboards Are Faster and Fresher

Built for live dashboard workloads

Native dashboards run on StarRocks — a modern, columnar, vectorized query engine purpose-built for exactly this pattern: many concurrent, low-latency dashboard queries running directly against continuously streaming data. Real-time materialized views keep commonly-used aggregates continuously up to date as new events arrive, rather than depending on a periodic batch refresh job.

How this differs from QuickSight SPICE

Some Eightfold customer dashboards are built on Amazon QuickSight, and some of those QuickSight datasets use SPICE — Amazon's in-memory caching layer. A SPICE dataset is a stored snapshot, refreshed once per day by a scheduled Airflow job rather than queried live. If that daily refresh is delayed or skipped, the numbers on a SPICE-backed dashboard can be well over a day behind the true current state of your data — and applying a filter on that dashboard only re-slices the same stale snapshot; it does not reach back to the source system for newer data.

Note: this isn't a critique of QuickSight generally — QuickSight also supports direct-query mode without SPICE, and not every QuickSight dashboard is SPICE-backed. When a dataset is specifically configured on SPICE import mode, the staleness described above is an inherent, by-design property of that mode — the tradeoff SPICE makes for fast in-memory performance without hitting the source warehouse on every view.

What this means for you: if a decision depends on today's numbers — this morning's application volume, this hour's pipeline movement — a native dashboard will reflect it. A SPICE-backed QuickSight dashboard may not, until its next scheduled refresh.

Summary & Support

Your Eightfold Customer Success or Technical Account Manager can walk through which of your specific dashboards are native versus QuickSight-based, and — for any QuickSight dashboards — what refresh schedule each SPICE dataset is on. For questions about custom filters, custom fields, or export limits for your account, reach out to your Eightfold technical contact and reference this guide.