Understand data update delays
Separate import, projection, email feedback, and analytics calculation to know how long to wait.
Updated
In short
Not every view updates at once. An integration first imports events, list projections update next, email feedback arrives after send, and some analytics waits for FX rates or readiness state. Check the timestamp for the relevant chain before retrying: a short, coherent lag is not data loss.
Expected result
You identify the pending chain and wait or escalate with the relevant timestamp.
Before you start
- Record source action time and timezone.
- Determine whether the subject is synchronization, communication, or analytics.
Procedure
- For source data, open integration and record latest success.
- For a list, compare with strongly consistent detail when available.
- For email, read feedback history after Sent.
- For analytics, check availability date, currency, and temporary message.
- Refresh once after the appropriate delay and give support both timestamps if it persists.
What Billabex does
Billabex uses event-sourced aggregates and several asynchronous projections. Temporary analytics errors fail explicitly rather than showing partial results, while other views retry on a later event.
If the result is not what you expected
- Repeated refresh does not speed a processing queue.
- Current detail with stale list often means projection lag.
- Give support source time, latest success, observed page, and object reference.