Automated workflow triggers dashboard refresh but data lags behind

CRM Salesforce
, , , , , , , ,
1

We’ve set up workflow automation to refresh our executive dashboard whenever high-value opportunities close. The workflow rule triggers on Opportunity Stage change to ‘Closed Won’ when Amount > $100K, and it’s configured to refresh the dashboard using a custom action. The refresh executes successfully according to the workflow history, but the dashboard data shows a significant lag - sometimes 15-20 minutes before the newly closed opportunity appears in the dashboard totals.

The dashboard refresh schedule is set to refresh every hour, but we need near real-time updates for these critical deals. We’re on Summer '24 and using Lightning dashboards. The workflow rule fires immediately when the opportunity stage changes, and the debug logs show the refresh action completing. However, the dashboard continues displaying the old totals until the next scheduled refresh cycle. Is there a limitation with workflow-triggered dashboard refreshes, or do we need a Lightning component workaround to achieve true real-time dashboard updates?

system 2

Your workflow approach has several limitations that explain the lag:

First, dashboard refresh schedule constraints override workflow-triggered refreshes. Even though your workflow fires the refresh action, Lightning dashboards in Summer '24 have a minimum refresh interval of 60 minutes for system stability. When you trigger a refresh via workflow, it requests a refresh but that request gets throttled by the dashboard’s configured refresh schedule. If the dashboard just refreshed 10 minutes ago, your workflow-triggered refresh won’t execute until the next scheduled interval. This is by design to prevent excessive refresh load on the system.

Second, workflow rule limitations prevent true real-time dashboard updates. Workflow rules can only trigger asynchronous actions, and dashboard refreshes are processed in a background job queue. That queue has variable processing time depending on org load, number of concurrent jobs, and system resources. The 15-20 minute lag you’re seeing is the queue processing time plus the dashboard refresh execution time. You can’t bypass this queue with workflow rules.

Third, the Lightning component workaround is the correct solution for real-time updates. Instead of using workflow-triggered refreshes, implement a custom Lightning component that displays the key metrics from your dashboard. The component uses Lightning Data Service to subscribe to Opportunity record changes. When an opportunity stage changes to ‘Closed Won’, the component automatically re-queries the data and updates the display without requiring a full dashboard refresh.

Here’s the implementation approach: Create a Lightning Web Component that queries opportunities using wire adapters with refreshApex for real-time updates. Deploy this component to your executive dashboard page as a replacement for the traditional dashboard components. When opportunities update, the component detects the change through platform events and refreshes its data immediately. This gives you true real-time visibility without relying on the dashboard refresh queue.

Alternatively, if you must use standard dashboard components, switch from workflow rules to Flow with scheduled paths. Create a Flow that monitors high-value opportunity closures and triggers immediate dashboard refreshes, but also implements retry logic to handle queue delays. The Flow can check if the dashboard data updated successfully and retry the refresh if needed.

The fundamental issue is that workflow-triggered dashboard refreshes aren’t designed for real-time scenarios - they’re meant for periodic updates. For executive dashboards requiring immediate visibility into critical deals, custom Lightning components are the recommended approach in Summer '24 and beyond.

This draft is based on general Salesforce knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Workflow rules can trigger dashboard refresh actions, but those refreshes are queued and processed asynchronously. The refresh request goes into a queue and gets processed based on system load and priority. During high-traffic periods, the queue can delay refreshes by 15-30 minutes. This is a known limitation with workflow-triggered refreshes. You might need to look at alternative approaches like using a Lightning component that refreshes on page load.

4

Check your dashboard’s data source. If it’s pulling from reports that have their own refresh schedule, the workflow might be refreshing the dashboard component but not the underlying report data. The report needs to be a ‘real-time’ report or you need to trigger a report refresh before the dashboard refresh. Summer '24 has some restrictions on how frequently reports can be refreshed programmatically.

6

That’s an interesting point about the report refresh. Our dashboard components are based on reports that have a standard refresh schedule. So even if the workflow refreshes the dashboard, the underlying report data might be stale? How do we trigger a report refresh from the workflow before refreshing the dashboard?

7

You can’t directly refresh a report from a workflow rule - that’s one of the workflow rule limitations. You’d need to use a Process Builder or Flow to call an Apex class that refreshes the report first, then refreshes the dashboard. But honestly, for real-time updates, Lightning components are the better approach. Create a custom Lightning component that subscribes to platform events or uses Lightning Data Service to detect opportunity changes and refresh the dashboard automatically. That bypasses the workflow refresh queue entirely.

8

The 15-20 minute lag is actually pretty typical for workflow-triggered dashboard refreshes. The refresh action queues a job that competes with all other scheduled dashboard refreshes, report generation jobs, and other system processes. During peak hours, that queue can get backed up significantly. If you need true real-time visibility, consider embedding the opportunity data directly in a Lightning component using SOQL queries instead of relying on dashboard components. That way, every page load fetches fresh data directly from the database.