Almanac

Consultant-focused KB for Microsoft Dynamics 365 Customer Insights – Journeys (formerly Marketing): implementation notes, gotchas, and configuration decisions beyond the official docs — across real-time journeys, segments, email and SMS marketing, event management, lead scoring, Copilot, analytics, and administration.

feature-dynamic-vs-static-segments.mdv1 · history
CurrentApplies to Real-time journeysUpdated 6 days agoSource Microsoft Learn

What it does

A dynamic segment re-evaluates its query on a refresh cycle, so members join and leave as their data changes. A static snapshot freezes membership at the moment you create it and leaves it there. Both are built in the same segment builder; the difference is the refresh rate setting on the segment.

Key facts

  • Static snapshot is chosen by setting the segment's refresh rate to Static snapshot in the segment's Settings. It isn't a separate object type — you build the criteria the normal way first.
  • A snapshot captures whoever met the criteria at creation. Nothing joins afterwards, and nothing leaves, regardless of what happens to the underlying data.
  • Separately from snapshots, you can pin explicit members into a segment with + Inclusion group and + Exclusion group, either by picking records from a Dataverse grid or by uploading a CSV.
  • Manual membership caps: up to 2,000,000 static members in total, across a maximum of 10 groups of 200,000 each.
  • CSV upload matches on an emailaddress1 column header. The search-by-name route for adding members is limited to 100 members.
  • Exclusion wins. If a record is in both an inclusion and an exclusion group, it's excluded.
  • Inclusion/exclusion groups can sit alongside query criteria in the same segment, so "everyone in this query, plus these forty people, minus the board" is a single segment.
  • Marketing lists — the Sales-side static list entity, not an outbound marketing artefact — survived the outbound removal and can still be referenced from real-time dynamic segments.
  • Outbound marketing segments are not usable. The msdyncrm_segment records still exist and the queries are readable, but the internal membership table was removed, so they're never populated. They can still appear in some real-time pickers. Don't touch them.

When to use / skip

Dynamic is the default and should stay the default. Reach for a static snapshot when the audience is defined by a moment rather than a state: everyone who was checked in at the event when the doors closed, everyone who held gold status on the last day of the financial year, the exact list a legal team signed off on Tuesday. In those cases a dynamic segment is actively wrong — it will keep growing after the moment has passed.

Snapshots are also the honest answer for seed and test lists. A fixed group of twenty internal testers should not be a query someone can accidentally widen.

Skip snapshots for anything recurring. People reach for them because dynamic membership feels uncontrolled, then discover six months later that the "VIP customers" list hasn't included a new VIP since launch. If the anxiety is about unexpected members, fix it with tighter criteria and a suppression segment, not by freezing the list.

Configuration decisions

  • Per segment, whether the audience is a state or a moment. That single question decides dynamic versus snapshot and is worth writing down next to each segment name.
  • Whether manual inclusion/exclusion groups are permitted at all, or whether every member must come from a query. Allowing manual lists is convenient and quietly untraceable.
  • If CSV upload is allowed, who produces the file and how the emailaddress1 matching is validated — records that don't match are simply not added.
  • What happens when a snapshot goes stale: rebuild the snapshot, or convert the requirement to a dynamic segment. Agree the process rather than leaving it to whoever notices.
  • Whether existing Sales marketing lists are reused as a membership source or replaced by native segment criteria.

Gotchas

  • A snapshot gives no signal that it's out of date. There's no expiry warning and no "last captured" badge in front of the marketer who's about to send to it. Aging snapshots are the most common cause of "why did that customer get the wrong email".
  • The 2,000,000 static member cap is a total across groups, and each group is capped at 200,000. A single 500,000-row CSV won't go in as one group.
  • CSV matching is on email address. Contacts with no email, duplicate emails, or a different primary email won't land where you expect, and there's no reconciliation report worth the name.
  • Exclusion precedence bites when two teams maintain different groups on the same segment. The excluding team always wins and the including team never finds out.
  • Legacy outbound segments visible in real-time pickers are a trap. They look normal, they have a name, and they have no members.
  • Snapshots don't respect subsequent consent withdrawal through membership — consent is still enforced at send, but the segment count you showed the client at sign-off will not match what actually goes out.

Consultant notes

  • Put the word "snapshot" in the segment name. It's the cheapest control available and it stops a marketer treating a frozen list as live.
  • When a client insists on uploading spreadsheets, agree it as a temporary migration measure with a date attached, otherwise it becomes the operating model.
  • Demo the exclusion-wins rule during UAT. It's the behaviour that gets escalated as a bug most often, and it's working as designed.
  • Before go-live, list every segment with a static refresh rate and confirm each one is deliberate. There will be at least one that isn't.
  • Tell the client plainly that outbound segments are dead weight and should not be referenced or "migrated" — rebuild the query in the real-time builder instead.

Worth another look if Microsoft adds a refresh or expiry indicator to snapshots, or raises the static member caps.

Was this accurate?