Acumatica GI on Dashboards — Best Practices

Every Acumatica dashboard widget is backed by a Generic Inquiry, which means every dashboard performance problem, every "the number looks wrong" ticket, and every "can we add one more filter" request is actually a GI design question wearing a dashboard's clothes. Treating dashboard GIs as a distinct discipline from ad hoc reporting GIs has saved me a lot of rework.

Design for the widget type, not for flexibility

A GI feeding an ad hoc grid can afford twelve columns and three optional parameters because a human is sitting there filtering interactively. A GI feeding a dashboard chart or indicator widget is rendered automatically on page load, usually for every user who has that dashboard, with no interactive filtering unless you deliberately wire dashboard-level filters. That changes the design goals:

• Bound the result set with defaults, not with the expectation someone will filter. A KPI tile is not the place to discover an unfiltered GI is slow — it runs on every page load, for everyone.
• Pre-aggregate rather than relying on the widget to summarize. Chart widgets can sum client-side, but it is cheaper and more correct to hand them an already-grouped result (see the aggregation/HAVING pattern) than to ship raw transaction rows to a chart control.
• One GI, one purpose. Reusing a broad "everything AR" GI across five different dashboard widgets by relying on each widget's own filter configuration is how a schema change three months later breaks five widgets in ways nobody predicted. I give each dashboard widget its own narrowly-scoped GI even when there is overlap, and accept the duplication.

Refresh behavior is a dashboard-level setting, not a GI setting

Dashboard widgets have their own auto-refresh interval configured on the dashboard designer, independent of anything in the underlying GI. A common mistake is assuming a GI marked for OData exposure or a "live" data source is automatically live on the dashboard — it is not; if the dashboard's refresh is set to manual or a long interval, users are looking at stale data regardless of how current the GI's own query is. Set refresh intervals deliberately per dashboard based on how volatile the underlying data actually is: an executive KPI dashboard refreshing every 30 seconds against GLTran is usually pointless load for data that only changes at batch-posting cadence.

Dashboard-level filters and drill-down wiring

Dashboard filters (the filter bar many dashboards expose) pass values into GI parameters by name-matching, which means your GI's parameter naming has to be deliberate and consistent across every widget you want a shared filter to control — a date-range filter on the dashboard only reaches widgets whose underlying GIs declare a parameter with the matching name. I keep a small naming convention (@FromDate/@ToDate, @BranchID) applied consistently across every dashboard-feeding GI in a project specifically so filters wire up without per-widget debugging.

Drill-down (clicking a dashboard tile to open the underlying GI or a target screen) depends on the GI exposing a sensible navigation target — usually a key field wired to open the source document. Test drill-down as a restricted user, not as admin: a manager dashboard tile that drills into a screen the viewing user has no access rights to produces an access-denied page instead of the expected document, which is a bad first impression on exactly the executive audience these dashboards are built for.

Wrapping up

Dashboard-feeding GIs need narrower scope, deliberate defaults (since nobody is filtering interactively), pre-aggregated results rather than raw rows, and parameter names that align with the dashboard's filter bar. Refresh intervals live on the dashboard, not the GI, and should track how often the underlying data actually changes rather than how anxious the request sounded.