Acumatica GI — Real-Time vs Snapshot Patterns

Every GI is "live" in the sense that it queries current data on every execution — there is no caching layer built into the GI engine itself. Whether that live query is the right architecture for a given use case is a separate question, and conflating "GIs are always real-time" with "real-time is always what I want" causes both performance problems and, less obviously, correctness problems.

What "the GI is live" actually costs

Every time a GI runs — grid load, refresh, dashboard tick, scheduled export — it issues a fresh query against the transactional tables. There is no automatic result caching between requests, no materialized intermediate state. That is exactly right for "show me this specific invoice's current balance" and exactly wrong for "show a company-wide KPI that fifty people glance at all day" — the second case pays the full query cost every single time, for data that realistically only changes a few times a day.

When a snapshot is actually more correct, not just faster

There is a subtler reason to prefer a snapshot beyond raw performance: period-based financial reporting often wants a specific point-in-time view, and a "live" GI queried at different moments during a busy posting day can return different numbers for what is nominally "the same report" — which is confusing for anyone comparing what they saw at 9 a.m. to what a colleague sees at 3 p.m. A snapshot taken once (say, at end of day) and reported from consistently removes that ambiguity entirely; it is not just cheaper, it is the more defensible answer for "what did the aged AR report say on the 30th."

Building a snapshot in practice

A snapshot is not a GI feature — it is a scheduled job (a processing screen or a simple graph action under Automation Schedules) that runs a query and writes the results into a plain summary DAC, timestamped. The GI you actually expose to users then queries that summary table instead of the live transactional data:

1. Scheduled job (nightly, or every N hours) runs the expensive aggregation
   query against GLTran / ARTran, writes results to KGDailyBalanceSnapshot
   with a SnapshotDate column.

2. User-facing GI queries KGDailyBalanceSnapshot directly:
   SelectFrom<KGDailyBalanceSnapshot>.Where<SnapshotDate.IsEqual<LatestSnapshot>>

3. GI header displays "As of {SnapshotDate}" pulled from the same table,
   so users always know exactly how current the number is.

That last point — always surfacing the as-of timestamp — is the detail that separates a good snapshot design from a confusing one. Users forgive stale data readily as long as they know it is stale; what erodes trust is a report that looks live but silently is not.

A hybrid worth knowing: event-driven refresh

Between fully live and fixed-schedule snapshot sits an event-driven refresh: Business Events trigger the snapshot job on meaningful transitions (a GL batch release, a period close) rather than on a fixed timer. This gets you snapshot-level query performance with freshness that tracks actual business events rather than an arbitrary clock — worth the extra setup when the data's natural cadence is "changes a few times a day, unpredictably" rather than either constant or perfectly scheduled.

Wrapping up

GIs are live by default because there is no caching layer under them — that is a fact about the platform, not a design recommendation for every report. For high-traffic, low-volatility numbers, a scheduled or event-triggered snapshot table is often both faster and more correct than a live query, as long as the as-of time is surfaced honestly to whoever is reading it.