3.1 Condition Activities and Branching Logic

3.1 Conditions, Optimize, and Branching Logic

Journey branching turns data and business policy into paths. Current Journey Optimizer uses the Optimize activity for several path-selection methods. Existing journeys created with the older Condition activity continue to display their condition logic through Optimize, so exam wording may mention either name.

Path types

Optimize supports several methods:

• Data Source: evaluates an expression using available profile, event, journey, or contextual data.
• Time: chooses paths according to time-based criteria.
• Percentage Split: distributes profiles across paths by configured percentages.
• Date: chooses a path according to date criteria.
• Profile Cap: limits a path according to a profile count and routes excess profiles elsewhere.

Use the method named in the requirement. A percentage split is appropriate for randomized traffic allocation, not for “loyalty tier equals Gold.” A profile cap controls volume, not message frequency over time by itself.

Ordered evaluation

For condition-based paths, order matters. Journey Optimizer tests the paths in sequence and sends the profile down the first eligible path. A broad condition placed first can swallow profiles intended for a later specific condition.

Suppose the paths are:

1. lifetime value greater than 100;
2. lifetime value greater than 1,000;
3. otherwise.

A profile with value 2,000 satisfies both first and second, but follows the first. Reverse the first two or make the ranges mutually exclusive. This “first match wins” behavior is a common scenario trap.

An Otherwise path catches profiles that do not satisfy an earlier path. It is useful but should be intentional. A branch may also terminate without another activity; an unconnected branch is not automatically a publication error. The design question is whether ending there is intended and observable.

Data source expressions

Build expressions with fields actually available at that canvas point. A unitary event can expose selected event context. Profile fields require a resolvable identity and profile. Business-event journeys can expose selected business context after audience members enter.

Validate:

• field type: string, numeric, Boolean, or date;
• null and missing-value behavior;
• capitalization and exact enumerated values;
• time zone and date boundaries;
• whether the value comes from event context or Profile;
• operator precedence in compound expressions.

For a numeric threshold, test below, equal, and above. For a date window, test both edges. For a string, test missing and unexpected values. Do not assume a value is present because it appears on the schema.

Evaluation is not waiting

A condition evaluates when the profile reaches it. It does not wait for a future purchase event to arrive. If a journey must wait for a later signal, use a supported Reaction event pattern with its timeout path, or wait for a period and then evaluate data that is available at that time. The choice depends on whether the requirement is event arrival or a later snapshot.

Example: “If the member has Gold tier now, use the premium path” is a condition. “Wait up to two days for an order-completed event” requires a reaction-event design, not an “event-based condition.”

Percentage paths and experiments

A Percentage Split routes execution traffic, but it is not the same as a content experiment. A content experiment adds treatment measurement, confidence, metrics, and reporting. Use Percentage Split when the requirement is operational routing and Optimize/content experiment when the requirement is experimental inference.

Percentages should total the required distribution. Validate each path, including the low-volume one, and ensure downstream actions are equivalent except for the intended treatment.

Profile cap

Profile Cap can route only a defined number of profiles down a path. This can protect a scarce resource or bounded treatment, such as sending the first eligible profiles to a concierge action while others follow self-service. It is not a replacement for external endpoint throttling, channel caps, or consent.

Design review

For every branching activity:

1. name each path for the business meaning;
2. place more specific conditions before broad ones;
3. define null and fallback behavior;
4. decide whether an unmatched path should end;
5. test representative boundary profiles;
6. verify every action on every path;
7. inspect path counts after publication.

Boundary test matrix

For each path, record at least one value that should enter it and one that should not. Include the exact threshold, null, empty string, unexpected capitalization, and a profile satisfying multiple paths. This small matrix exposes ordering defects before publication and becomes evidence that the Otherwise path and any intentional terminal branch were reviewed.