Journey entry: trigger-based versus segment-based

What it does

Every real-time journey starts one of two ways. Either a trigger fires for one person and they enter within seconds, or a segment is evaluated and its members enter together on a schedule. You choose this on the start tile when you create the journey, and it is fixed for the life of that journey.

Key facts

The journey type is set at creation and cannot be switched afterwards. If you picked wrong, you rebuild.
Segment-based journeys accept up to 15 segments on the start tile, and you cannot mix audience types — contact-based and lead-based segments can't sit in the same journey.
Segment journeys have three frequency modes: one-time with a static audience (only members at launch), one-time that also picks up newly added members as the segment refreshes, and repeating on a daily, weekly or monthly schedule.
A repeating segment journey re-enters every current member on each run. It is not a "new members only" run, which is the single most common misreading of that setting.
The one-time-with-new-members mode has a separate re-entry toggle for people who leave the segment and rejoin it.
Start date and time are entered with a time zone and converted to UTC underneath.
Trigger-based entry can be filtered with conditions on the trigger's own attributes — Microsoft documents up to 29 conditions on the entry tile.
Both journey types support exclusion segments at entry and rate limiting: a number of people per hour or per day, plus which days of the week entry is permitted.
Rate limiting caps entry per interval, it does not smooth delivery. A limit of 60 per hour lets all 60 in as fast as they arrive, not one a minute.
Audience source — contact, lead, or Customer Insights - Data customer profile — is an app-level setting, not a per-journey one.

When to use / skip

Trigger-based is the right default for anything a customer or a system does at a moment in time: form submitted, case resolved, order shipped, cart abandoned. Segment-based is for the things a business decides to do on a calendar — the newsletter, the renewal batch, the quarterly nurture push.

The judgement call people get wrong is the middle ground: "everyone whose renewal is 30 days away". That looks like a segment, and you can build it as a daily repeating segment journey, but it behaves much better as a Dataverse trigger on the renewal date field or an attribute branch on a date. Repeating segment journeys pull the whole membership each run and you then spend your evening working out why 4,000 people got a second email.

If the marketing team's mental model is still "build a list, send to the list", they will ask for segment-based journeys for everything. Push back where the event is genuinely per-customer, because trigger-based journeys give you per-person timing, personalisation from the trigger payload, and far cleaner analytics.

Configuration decisions

Journey type per use case, decided before build starts — this is a one-way door and it dictates whether the timing logic lives in the segment or in the trigger.
For segment journeys: static, dynamic with new members, or repeating — and if repeating, whether the audience genuinely wants re-entry each run.
Whether re-entry is allowed at all, and if so what stops the same person receiving the same message twice in a week (that is a frequency cap conversation, not a journey one).
Which exclusion segments sit on the entry tile — typically a global suppression segment plus anything campaign-specific.
Whether entry needs rate limiting, and on what basis: contact centre capacity, SMS provider throughput, or web infrastructure behind a call to action.
Audience source for the environment, agreed once with the client. Contact-based is the common answer; customer profile only if Customer Insights - Data is genuinely in the solution.

Gotchas

Rate limiting plus quiet times produces bursts. People accumulate in the journey during the quiet window, then everything releases at once when it lifts — the rate limit does not apply on the way out.
A repeating segment journey with a monthly schedule anchored to the 31st runs on the last day of shorter months. Fine, but tell the client before they see 28 February on the run history.
Segment refresh cadence, not the journey, determines how quickly new members enter a dynamic one-time journey. If the segment is slow to refresh, the journey looks broken when it isn't.
Exclusion segments at entry only stop people getting in. They do not remove anyone already in flight — that needs an exit segment.
All content in the journey must be in "Ready to send" state before you can publish. Draft emails silently block go-live, and the error surface is not always obvious on a large journey.
Mixing audience types is blocked at save, but only once you have already built the flow, so check segment audience types early.

Consultant notes

Get the journey type decision into design sign-off explicitly. "We'll decide during build" costs you a rebuild later.
Demo the difference with a real example the client recognises — abandoned cart versus monthly newsletter — rather than explaining it abstractly. It lands in about ninety seconds.
Before go-live, check the rate limit against the downstream system, not against the marketing plan. The number that matters is what the call centre or the web front end can absorb.
Watch repeating journeys in their first two cycles. Most re-contact complaints show up on run two, not run one.
If the client wants "send to a list", ask what happens to someone who joins that list tomorrow. Their answer picks the frequency mode for you.

Worth another look if Microsoft ever allows converting between journey types, or raises the 15-segment start limit.