How fast does customer data need to update?

A reminder is due to go out at 5:05 p.m. The customer books at 5:01. Does the message still send?

That four-minute gap is a better starting point for a real-time integration discussion than a demand to make every dashboard live. The booking must reach the decision before the message is released. A report showing yesterday's revenue has a different deadline.

Trace the whole delay

In this illustrative timeline, the booking feed runs every 15 minutes and the next collection is at 5:15.

• 5:00. What happens: A campaign audience is prepared. Consequence: The customer is eligible based on information available then
• 5:01. What happens: The customer books in the service platform. Consequence: The source has changed; the campaign has not
• 5:05. What happens: The message is released. Consequence: The stale audience permits the reminder
• 5:15. What happens: The next scheduled collection retrieves the booking. Consequence: The report catches up after the action

Refreshing the dashboard every minute does not fix the source collection delay. Nor does receiving an event immediately help if the worker processing it has a ten-minute backlog.

The time that matters includes collection, processing, identity matching, destination refresh, and the final decision. Measure that complete path.

Choose the method around the action

For a morning customer worklist, scheduled collection may be adequate when staff verify recent activity before contacting someone. For a triggered message that must respond to a new booking within minutes, an event-driven path deserves evaluation when the source supports it.

Workato's documented HubSpot new-or-updated-record trigger checks for new or updated records on a polling interval. Airbyte's HubSpot streams use different collection modes. “Integrated with the CRM” does not establish the timing of a particular change. See the Workato trigger and Airbyte source documentation.

Set a proposed requirement the implementation can test. For the booking example, the team might require booking changes to reach campaign eligibility within one minute, with a final eligibility check immediately before release. The minute is a design target for this scenario, not a vendor guarantee.

A final check reduces the stale audience window

The sending workflow should check current booking and suppression state before dispatch. If the booking feed is behind its agreed deadline, hold the message or route the customer for review.

There is still a boundary between checking eligibility and an external provider accepting a message. Test what can be cancelled and how the system records a change arriving during that boundary. Avoid promising instant cancellation that the destination cannot perform.

Recover without repeating the action

Events can arrive late or be delivered again. Record their identifiers and processing state, reject stale overwrites using the agreed version rules, and compare with the source periodically to find gaps. A repeated notification should update the same booking rather than produce another reminder.

Our recommendation for this scenario is to spend on the booking-to-message path first. Give the monthly report its own refresh schedule. The business deadline tells you where speed earns its cost.