System refresh schedule and processing order

What it does

The system refresh is the scheduled run that pulls every ingested data source again and pushes the result through the whole chain — match, merge, then everything downstream of the unified profile. You set it once per environment under Settings > System > Schedule, and it is off until you turn it on.

Key facts

The refresh schedule toggle defaults to Off. A newly created environment refreshes only when someone presses refresh manually.
Frequency is Daily or Weekly. Weekly lets you pick one or more days of the week.
You set a time zone and one or more times, up to a maximum of four refreshes per day.
Sandbox environments do not run scheduled refreshes. That is a property of the environment type, not a setting you can turn on.
The processing chain is fixed and dependency-driven: data sources have no upstream dependency; match depends on the sources; merge depends on match; segments, measures, search and filter index, activities, enrichments, exports and insights all depend on merge; analysis preparation depends on segments.
Because of those dependencies, a task shows Queued while it waits for upstream work and Skipped when something upstream failed or was itself skipped. Neither is an error in its own right — go up the chain to find the actual failure.
Segments and measures can carry their own custom schedules independent of the system refresh.
Changing an established system refresh time can knock those custom segment and measure schedules out of step, so they stop running when you expect. Microsoft flags this explicitly.
Ingestion concurrency follows the same refresh limits as dataflows in Power BI, and the platform applies fair scheduling across unification, segment and measure jobs — queued jobs are not all processed in parallel.
A run in progress shows Refreshing and can be cancelled from the status, which reverts to the state of the previous successful refresh.

When to use / skip

Turn it on. The only environments that legitimately run without a schedule are sandboxes, which cannot have one anyway, and a production environment still in build where you would rather control the timing by hand.

The judgment call is frequency, and the honest answer is usually daily and once. Four times a day sounds attractive to a client who has been sold "real time", but the full chain reruns match and merge every time, and a mid-morning refresh that collides with the business looking at segments is a support ticket in waiting. Ask what downstream consumer actually needs fresher data. If the answer is an export to a campaign tool that sends in the morning, schedule to land before that, once, and stop. If the answer is genuinely operational latency, you are having a Dataverse or activity-level conversation instead, not a refresh-frequency one.

Configuration decisions

Daily or weekly, and if weekly, which days — align to when the source systems actually finish their own loads.
How many times a day, and what each extra run is for.
The time zone the schedule is expressed in, which for a UK client means deciding now what happens across the BST boundary.
Which time slot the run occupies relative to upstream ETL, downstream exports and the working day.
Whether segments and measures keep the system schedule or get custom ones, and who owns keeping those two in step.
Whether sandbox refreshes are triggered manually by the delivery team as part of a test cycle, or ignored.

Gotchas

Turning the schedule on is a separate act from configuring it. Environments quietly go live with the toggle off and nobody notices until someone asks why yesterday's data is a fortnight old.
Moving the system refresh time is the classic silent breakage: segments and measures with custom schedules keep their old times and fall out of alignment. Check both pages after any change.
Sandbox having no scheduled refresh means your UAT environment never exercises the schedule. Whatever the schedule breaks, it breaks first in production.
A failed data source does not fail loudly downstream — it produces a wall of Skipped tasks, and people chase the skipped exports rather than the source.
Cancelling a running refresh reverts to the previous refresh state rather than leaving a partial result, which is the right behaviour but catches out anyone expecting the partially processed data to stick.
Four refreshes a day is the ceiling, so any requirement phrased as hourly cannot be met by this feature at all. Better to say that in the workshop than in the go-live review.

Consultant notes

Put the refresh window on the same diagram as the client's upstream ETL. Most refresh complaints are actually source-timing complaints.
Demo the dependency chain on the Status tab rather than explaining it, so the client learns to read Queued and Skipped for themselves.
Push back hard on hourly expectations early, and redirect to Dataverse-based access for anything that needs to be closer to live.
Before go-live, take a screenshot of the schedule plus every custom segment and measure schedule, so drift is detectable later.
Agree who is allowed to change the refresh time in production, because one well-meaning change quietly desynchronises everything hanging off it.

Worth another look if the four-a-day cap moves, or if sandbox environments ever gain scheduled refreshes.