Almanac
Microsoft/d365ci-journeysDynamics 365

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.

d365ci-journeys/02-segments-and-audiences/feature-realtime-segment-builder.md
feature-realtime-segment-builder.mdv1 · history
CurrentApplies to Real-time journeysUpdated 6 days agoSource Microsoft Learn ↗

What it does

The segment builder is the query canvas where you define who a journey talks to. You pick a target audience type, then stack groups of conditions drawn from the audience table's own columns, from related Dataverse tables, from interaction history, and from manually chosen or uploaded members. Outbound marketing's segment designer is gone — this is the only builder that matters now.

Key facts

  • Three target audience types: Contact, Lead and unified profile (Customer Insights – Data). Leads can be targeted directly; there's no requirement for a parent contact any more.
  • Conditions live in groups. Groups combine with AND by default, and you can switch to OR. Exclusion groups subtract members.
  • Related-table condition scoping is positional: two conditions in the same group must be satisfied by the same related record; split across groups, different related records can each satisfy one condition. This is the single most misread behaviour in the builder.
  • Behavioural conditions come from Elements > Behavioral — email opens and clicks, website visits, form submissions, event interactions, Customer Voice survey responses, subscription activity — each with an editable time window and frequency.
  • Calculated fields, formula fields and virtual tables are not supported as segment criteria.
  • Related tables need Track changes switched on in Dataverse, or the table's data won't be usable in segmentation.
  • Marketers can add their own tables via +Add table next to Related tables in the Elements pane. Sync can take up to 24 hours, and during that window size estimates and member previews are unavailable for segments using it.
  • Contact point consent can't be added as a related table. Consent is expressed through dedicated consent criteria (compliance profile, purpose, optional topic, channel, and a "Will send" choice), which uses the same evaluation logic as journey execution.
  • Protected columns are hidden from the builder unless an admin turns on the Use protected fields in segments feature switch under Settings > Overview > Feature switches.
  • The underlying query is MQL. Turning on the Query edit feature switch exposes a </> Query view so you can read, copy and hand-edit it — useful when a segment is being generated by the Segment Builder API.

When to use / skip

You'll use it on every real-time journeys project, so the question isn't whether but how far to push it. Attribute and related-table conditions are cheap and reliable; use them freely. Behavioural conditions are where people get carried away — a segment defined as "opened any email in the last 30 days AND visited the pricing page AND has an open opportunity" is easy to build and miserable to debug when the count comes back at eleven. Build behavioural logic incrementally, checking the estimate after each block.

Where I'd push back: using segments to express journey branching. If the audience is stable and the difference is a downstream condition, put it on an attribute branch inside the journey rather than spawning five near-identical segments that all have to be evaluated on a refresh cycle. Segments are a shared, refreshed asset; branches are free.

Configuration decisions

  • Which audience type each segment targets — contact, lead or unified profile. This determines which segments can be paired for exclusion later, so agree a convention before anyone builds anything.
  • Which custom tables get synced into the builder, and who is allowed to add them. Each one consumes Dataverse database storage and needs change tracking.
  • Whether the Query edit feature switch is on. Turning it on is how you get repeatable, reviewable segment definitions; leaving it off keeps casual users out of MQL.
  • Whether protected fields are exposed to segmentation, and whether you accept the inference risk that comes with it.
  • Naming and ownership: segments are environment-wide objects with an owner and, where business-unit scoping is enabled, a scope. Decide early who owns marketing-wide segments versus regional ones.
  • How far you allow behavioural conditions to go, given they slow refresh and block member preview.

Gotchas

  • The same/different-related-record grouping rule silently changes results rather than erroring. "Account named Contoso" and "Account in Valencia" in one group means one account matching both; in two groups it means the contact is linked to a Contoso account and, separately, to some account in Valencia. Both are valid segments. Only one is what the client asked for.
  • Refresh in the builder is a best-effort estimate, not a count. For large or complex segments it may not return at all. You only get an exact membership figure once the segment is marked ready to use.
  • Behavioural segments don't offer a members preview. If a stakeholder wants to eyeball the list before sign-off, you can't give it to them at design time.
  • Adding a table to the builder is not instant. Plan a day of lead time before a workshop where you intend to demo segmentation on a custom table.
  • Enabling protected fields is an environment-level decision with a real data-exposure consequence: someone who can't read the Gender column can still build a segment on it and infer the value of every member.
  • Turning on change tracking for a chatty table has a knock-on effect on Dataverse storage and platform load that nobody will attribute back to you until the storage bill arrives.

Consultant notes

  • Demo the same/different related-record behaviour early, with a deliberately wrong segment. It lands better as a five-minute demonstration than as a bullet in a design document.
  • Before the first build workshop, get change tracking enabled and any custom tables synced. Waiting 24 hours in front of the client is a bad look.
  • Ask for the top ten audiences the business actually mails to. In practice most clients need far fewer segments than they think, and consolidating them cuts refresh load and maintenance.
  • If the client has any developer capability, turn on Query edit and treat segment definitions as reviewable artefacts. Copying MQL between environments beats rebuilding by hand.
  • Check consent criteria are used for anything compliance-related rather than someone's home-grown "do not email" flag on the contact record.

Worth another look if the query editor comes out of feature-switch status, or if the behavioural block list grows again.

Was this accurate?
Related
Audience source: contacts, leads and profiles02-segments-and-audiencesJourney entry: trigger-based versus segment-based01-real-time-journeysSegment refresh cycles and membership behaviour02-segments-and-audiencesRunning segments off Dataverse or off Customer Insights – Data10-decision-guidesQuery assist for segment building06-copilot-in-ci-journeysSegmenting on Customer Insights – Data profiles02-segments-and-audiences