Segment builder: rules, sub-rules and set operators

What it does

The segment builder turns filters over the unified customer table and its related tables into a stored output table of customer records. You assemble conditions into rules, nest them with sub-rules, and combine separate rules with union, intersect or except.

Key facts

Built from Insights > Segments > New > Build your own. You name the segment and, separately, the output table — that table name is what exports, measures and other segments will reference later.
A condition is attribute + operator + value. The operator list depends on the data type: numerical, string, date or boolean.
Conditions inside a rule join with AND or OR. AND is the default when a rule has several conditions and is the one that works across different tables.
OR has a real constraint: every condition joined by OR has to sit on tables that are in that rule's relationship path. Mixed-table OR logic is where people get stuck.
Add sub-rule gives you nesting inside a single rule. That is the mechanism for expressing "A and (B or C)" properly, rather than trying to fake it with extra top-level rules.
Separate rules combine with set operators: Union (either), Intersect (both), Except (in the first, not in the second). Except is directional, so the order of the rules changes the answer.
Each rule carries its own relationship path to the customer table. If only one path exists the system picks it; otherwise use Set relationship path. Different paths produce genuinely different member counts from the same conditions.
Relationship depth in the segment and measure builders is capped at 20 levels of table path.
Projected attributes add columns from a related table to the output. They only work over one-to-many relationships. If the attribute is more than one hop away, it has to be used in every rule in the query; one hop away, it doesn't. Projections are also factored in when rules are combined with set operators.
Date conditions switch between fixed dates and a floating date range — floating is what you want for anything that will run on a schedule.
Saving leaves the segment inactive as a draft. It only produces members after you Run it.
Active segments and measures together are capped at 1,000 as a soft limit; past that Microsoft's own guidance is that refresh times degrade and out-of-memory failures start appearing.

When to use / skip

Use the full builder whenever the audience definition is more than one attribute test, or when the logic reaches through a related table — orders, subscriptions, activities, measure outputs. That is most real segments. Skip it when someone wants "everyone in Manchester" or "everyone whose lifetime value measure is over £500"; a quick segment does that in a fraction of the time and produces exactly the same kind of output table.

The builder is also the wrong tool for real-time targeting. Everything here is batch — members are as of the last successful refresh. Push back, too, when a client asks for dozens of near-identical segments, one per campaign variant or region. That pattern eats the 1,000 soft limit and the refresh window, and a smaller set of segments plus destination-side filtering usually does the same job.

Configuration decisions

Output table naming convention. It's set at creation, it's what downstream consumers bind to, and renaming later means fixing everything that reads it. Agree a convention on day one.
Relationship path per rule where more than one path exists. This is an analytical decision, not a click — pick the path that matches the business meaning and record why.
Whether the logic belongs in sub-rules inside one rule or in separate rules joined by set operators. Sub-rules keep the intent readable; set operators are clearer when the two populations are genuinely different audiences.
Whether to project attributes at all. Projection makes the output richer for the destination system but changes the shape of the output table, so decide before anything consumes it.
Fixed versus floating dates on every date condition, driven by whether the segment is one-off or scheduled.

Gotchas

OR across tables outside the relationship path just isn't available. People assume they've mis-clicked; they haven't.
Except is order-sensitive and the UI makes it easy to get backwards. Check the member count against expectation before anyone builds a campaign on it.
The builder does not suggest valid values for a condition. There's no picker showing you the actual contents of a column — go to Data > Tables and look at the data before typing a value, or you'll build a segment that returns zero members because the code is "GB" not "UK".
Projecting from a one-to-many relationship means the output table no longer has one tidy row per customer. Confirm what the downstream export or system expects before you rely on it.
Saving is not running. A segment sitting in draft with a member count from a preview is not a segment anyone can export.
Changing the underlying data model — a new relationship, a renamed column — can quietly break the relationship path a segment depends on. Segments do not warn you at design time.

Consultant notes

Demo the sub-rule and set-operator combination early. Most business users have only ever seen flat AND lists and will accept a worse definition simply because they didn't know nesting existed.
Insist on a naming and tagging convention before the first workshop. Retro-fitting one across 200 segments is a miserable week.
Before go-live, run each segment once and compare the count with whatever the client's current source of truth says. A 5% gap is usually a relationship path or a date-range question, and it is much cheaper to answer then than after the first campaign.
Tell the client plainly that segment counts move with the refresh schedule, not with their CRM. The first "why is this number different from Dynamics?" call always comes.
Keep an eye on the combined segment and measure count as the estate grows; that's the limit that bites quietly two years into a delivery.

Worth another look if Microsoft loosens the OR-across-relationship-path constraint, or changes how projected attributes shape the output table.