Segment-triggered versus event-triggered journeys as the default pattern

What it does

Every real-time journey starts one of two ways. A segment-based journey takes a list of people who share attributes and walks them through. A trigger-based journey waits for something to happen to one person and reacts. You pick per journey, at creation, and you cannot change it afterwards — so the useful question is which one the client's team reaches for by default.

Key facts

Segment-based journeys come in three flavours: one-time with a static audience, one-time with a dynamic audience, and repeating on a schedule.
One-time static freezes membership at launch. Nobody added to the segment afterwards enters.
One-time dynamic lets newly added members enter when the segment refreshes. By default each person goes through once; the Allow audience members who re-join the segment to re-enter the journey option permits re-entry after they leave and re-join.
Repeating journeys re-enter every current member on every scheduled run, whether or not they went through before. Schedules count 24-hour days and 7-day weeks, and monthly runs use the same date, falling back to the last day of a short month.
A journey can start from a maximum of 15 segments, or fewer if the combined size limit is hit first. Exclusion segments have no count limit, but large exclusions slow the run.
Contacts and leads cannot be mixed as the audience of a single journey.
Segment-based journeys are not supported in environments using a custom Azure Data Lake account for segments.
Trigger-based journeys accept up to 29 input attributes on a custom trigger, and those attributes plus related-table data are available for entry conditions, branching and personalisation.
Published service limits: segment-based journeys run at up to 500,000 interactions an hour; trigger-based journeys process up to 2,500 triggers a minute, with latency stated as P90 under 3 minutes and P95 under 5 minutes at that rate. Beyond it, processing slows and triggers can fail.

When to use / skip

My default recommendation is trigger-based, and I would make it the house pattern on any new implementation where the client has a Dataverse-centred business — Sales, Service, Field Service, events. Trigger-based journeys are cheaper to reason about, they behave the same on day one and day four hundred, they enter one person at a time so a mistake damages one person rather than 80,000, and they express the thing the business actually said: "when a case is resolved, ask for feedback".

Segment-based is the right choice when the message is genuinely about a population rather than an individual — the monthly newsletter, a product-launch announcement, a win-back push at people who have not bought in six months. Reach for it when the entry condition is "who they are", not "what just happened".

Where I would do the opposite of my own default: if the client's marketing team is not technical and there is no developer capacity, trigger-based journeys built on custom triggers become a bottleneck, because someone has to instrument the trigger before marketing can use it. Dataverse-change triggers soften this a lot — they are no-code — but genuinely custom events need code. In a marketing-led, low-IT-engagement client, segment-based is the pattern the team can actually run without you, and a pattern they can run beats a better pattern they cannot.

The other honest exception is throughput. If a client is doing large broadcast sends, segment-based is what the 500,000-an-hour figure applies to. Trying to express a 400,000-recipient newsletter as a trigger is wrong twice over.

Watch the repeating-journey trap. Teams choose "repeating" thinking it means "keep picking up new people" and get "send to everyone again, weekly". That is one-time dynamic. It is the single most common misconfiguration I see, and it is the one that produces an apology email.

Configuration decisions

Per journey: one-time static, one-time dynamic, repeating, or trigger-based. Not changeable later.
For one-time dynamic, whether re-entry after re-joining the segment is allowed. Defaults to no.
Whether the trigger is a Dataverse record-change trigger, which marketing can build unaided, or a custom trigger, which needs an instrumented event and developer time.
Exit conditions: exit by trigger, exit by segment, or run to the end. Decide before build, not after the first send.
Audience entity — contact, lead, or Customer Insights – Data profile — and accepting that a single journey cannot mix them.

Gotchas

Repeating journeys re-enter everyone on every run. On a weekly schedule that is a weekly send to the whole segment, which is often not what was asked for.
The 15-segment start limit is a ceiling on segments, not on people. Hitting the combined size limit lowers it further, with no warning until you try.
Mixing contacts and leads in one journey is unsupported, and clients with a mixed database will ask for it in the first workshop.
Trigger latency degrades past 2,500 triggers a minute. A batch data load that touches thousands of rows can blow through that in seconds and generate failures that look like the journey is broken.
Dataverse triggers fire on any change to the watched columns, not on a particular value. Without a condition in the journey, resolving and reopening a case fires it twice.
Custom Azure Data Lake storage for segments rules out segment-based journeys entirely. Find out whether the client uses it before you plan around segments.

Consultant notes

Set the house pattern in the first design workshop and write it down. Teams that decide per journey end up with an inconsistent estate nobody can audit.
Demo the difference with a case-resolved trigger journey. Watching a single email arrive seconds after a case closes sells trigger-based better than any slide.
Push back on repeating journeys unless someone can articulate why the whole segment should be re-entered. Nine times in ten they meant one-time dynamic.
Before go-live, get the client to run a bulk data import in a sandbox and watch what the Dataverse triggers do. That is where the throughput surprise lives.
Agree who instruments custom triggers and how long it takes. If the answer is "the same developer who does everything else", plan the journey roadmap around Dataverse triggers instead.

Worth another look if the 15-segment start limit or the trigger throughput figures move, or if mixed contact and lead audiences become supported.