A data refresh schedule is the configured frequency and timing at which the data underlying a BI report is updated from its source systems — daily overnight, intraday on a defined interval, near-real-time through streaming, or on manual demand. It is the mechanism that determines how old the data is when a finance leader opens a dashboard. The concrete detail that matters: data refresh is not free. Every refresh consumes compute resources in the BI platform, places a query load on the source systems being extracted from, and adds to the platform’s operating cost. A dashboard refreshed every 15 minutes costs significantly more to operate than the same dashboard refreshed nightly — and for a management account report that is reviewed once a month, the 15-minute refresh delivers no additional decision value while consuming cost resources throughout the month.
Why This Matters for Finance Leaders in Egypt and the GCC
Data refresh scheduling in GCC enterprise environments must account for the source system availability windows that ERP maintenance creates. Oracle EBS and SAP environments in GCC enterprises typically run batch jobs, payroll processing, and period-end close operations overnight — windows during which heavy BI extraction queries can degrade ERP performance for operational users or conflict with the batch process for the next morning’s operations. The BI refresh schedule must be coordinated with the ERP operations schedule, not set independently. The finance BI team and the ERP operations team must jointly own the refresh schedule.
What Good Looks Like
A well-designed refresh schedule is differentiated by report type and business use. Real-time operational KPIs — cash position, today’s invoices processed, approval queue depth — are refreshed frequently because the decisions they support are time-sensitive. Monthly management accounts and board pack data are refreshed nightly at most, because a once-monthly review does not require intraday data currency. Historical trend reports may be refreshed weekly, because the trends they display do not change materially day to day. A single refresh schedule applied uniformly to all reports is either wasteful (refreshing static data too frequently) or inadequate (refreshing operational KPIs too infrequently). Each report class should have a refresh frequency justified by the currency requirement of the decisions it supports, visible to users as a “data as of” timestamp on the dashboard.
What Buyers Get Wrong
The specific failure in refresh schedule design is setting the refresh frequency based on technical defaults rather than business requirements. When the BI implementation team configures all datasets to refresh daily at 06:00 — because that is the platform default and no one asked about the frequency — they produce a refresh schedule that is appropriate for some reports and inappropriate for others. The cash management dashboard that needs to show the day’s treasury position by 08:00 refreshes at 06:00 using the prior day’s data, which defeats its purpose. The historical cost analysis that is reviewed quarterly refreshes at 06:00 every morning, consuming resources continuously for a report that is relevant once every three months. Refresh frequency should be specified in the report requirements and implemented as a conscious configuration decision, not inherited from a platform default.
How Loop Wise Solutions Approaches This
We define the data currency requirement for each report as part of the BI requirements documentation — explicitly asking the business sponsor “how old can this data be when you view this report and still make the right decision?” — and configuring the refresh schedule accordingly. We also produce a platform cost analysis of the refresh schedule, showing the cost implication of the aggregate refresh frequency, so that the business sponsor can make an informed trade-off between data currency and operating cost.
