Microsoft MB-220 study materials
Microsoft MB-220 study resources

Segment Refresh Starves a Time-Sensitive Journey

Microsoft MB-220 · Put your knowledge to work in context.

All case studies

Segment Refresh Starves a Time-Sensitive Journey

Fabrikam's 'Abandoned Cart' journey sends a reminder 4 hours after a cart-abandonment trigger. The audience is a segment named CartAbandoners, built on the Contact entity with a related Cart table. The segment is configured to refresh every 12 hours. During a flash sale, 6,000 contacts abandon carts in a 2-hour window. The journey's trigger is set to 'When a contact is added to a segment'. Support reports that reminders arrive between 4 and 16 hours after abandonment, and roughly 1,100 contacts receive two reminders. The Cart table is updated by an external system every 15 minutes. A second segment, HighValueCustomers, refreshes hourly and feeds a separate nurture journey that is behaving correctly.

1. Diagnose the delay and the duplicate sends, and state which trigger type would have been correct.

Read the worked answer

The trigger is the defect. 'When a contact is added to a segment' fires on segment membership change, not on the cart event. Membership only changes when the segment refreshes - every 12 hours - so the 4-hour delay becomes 4 hours plus up to 12 hours of waiting for the next refresh. That explains the 4-to-16-hour spread.

The duplicates come from the same cause: a contact who abandons, is picked up at refresh, drops out of the segment when the cart is cleared, and abandons again can re-enter membership and re-trigger the journey. Nothing in the setup deduplicates by cart ID.

HighValueCustomers behaves correctly because its hourly refresh is short relative to its business cadence, and its nurture journey is not time-critical - the same design flaw is masked, not absent.

Correct design: trigger the journey on the Cart entity event (cart created or cart status changed to Abandoned), not on segment membership. The segment can still exist for reporting and for exclusion checks, but it should not be the trigger. If a segment trigger must be used, the refresh interval has to be shorter than the acceptable delay, which for a 4-hour SLA means minutes, not hours - and segment refresh at that frequency is expensive and still racy.

2. The team insists on keeping a segment-based audience. List the changes required to meet a 4-hour reminder SLA without duplicate sends.

Read the worked answer

If the segment stays, the refresh interval must shrink below the SLA. A 4-hour SLA with any safety margin means a refresh of 15–30 minutes, aligned to the 15-minute Cart sync so the segment never evaluates stale data. That is a real cost in refresh load, so confirm the environment's segment refresh capacity first.

Duplicates require explicit suppression, because segment membership is not a stable identity:

  • Add a suppression segment of contacts who already received the reminder for the current cart (for example, a ReminderSentOn date on the Cart record, or a journey participation check), and exclude it from the journey audience.
  • Add a journey exit condition on cart cleared or order placed, so a re-entry after purchase does not send.
  • Key the journey on cart ID rather than contact ID where the platform allows, so a second cart is a new journey instance but the same cart is not.

Even with all three, the segment trigger still adds up to one refresh interval of latency. Tell the stakeholder plainly: segment-triggered journeys are for cadence-tolerant audiences; event-triggered journeys are for SLAs measured in hours.