2.3 Business Events & Audience Broadcast Execution

2.3 Business Events and Audience Broadcast Execution

Section 1.3 explains when a business event is the right pattern. This section focuses on building and operating it correctly.

Configure the business signal

Begin with a time-series XDM schema based on ExperienceEvent. The event represents the business occurrence, so its primary identity uses a non-people namespace: for example, a disruption ID, store incident ID, or regional alert ID. Configure the event in Journey Optimizer and select the contextual fields downstream logic needs, including the event ID and timestamp.

The non-people identity distinguishes the signal from a unitary customer event. It does not become a join key that Journey Optimizer uses to scan all profiles.

Keep event context concise. A service incident might expose region, severity, start time, estimated restoration time, and a status page URL. Sensitive or unnecessary fields should not be selected merely because they exist in the source schema.

Build the required canvas opening

Place Business Event first. Journey Optimizer inserts Read Audience after it. Configure the audience and its identity namespace on that activity. Read Audience is the only supported immediate successor.

The audience must already express the target population. If the incident affects region West, the audience might be “active customers in West with service notifications permitted.” Data ingestion and segmentation are responsible for maintaining that membership. The event does not calculate a flight-to-passenger or store-to-shopper relationship at runtime.

This preselection also means one general audience may be too broad. If each incoming event must target a different dynamic cohort and that cohort cannot be represented by the configured audience design, reconsider upstream segmentation or choose a different orchestration architecture.

Plan for export time

After the event arrives, Journey Optimizer exports the selected audience. Adobe documents approximately 15 minutes to one hour for this stage. Channel processing then adds its own latency. State this clearly with stakeholders: the design is event-initiated, but it is not an immediate profile-key broadcast.

A business requirement such as “warn everyone within 60 seconds” conflicts with this documented pattern. The practitioner should not hide that conflict behind the phrase “real time.”

Use event and profile context

Once audience members enter, each follows an individual path. Downstream conditions can evaluate profile attributes and the business-event fields exposed by configuration. Content might combine a person's name and language from Profile with incident severity and restoration time from event context.

Use the product's field selectors to insert context. Test missing values and supply safe content fallbacks. If a profile lacks a usable channel address or is opted out, audience membership alone does not make the delivery valid.

Multiple execution and concurrency

Recurring business occurrences require deliberate settings. Configure whether the journey permits multiple executions and understand how a new event interacts with a current run. Test this with distinct event IDs before production.

Also review:

• journey reentrance for audience members;
• profiles already active in a prior execution;
• frequency and fatigue controls;
• custom-action throttling;
• large audience export and action throughput;
• downstream channel caps and suppression;
• the global 91-day journey lifetime.

A second event should not accidentally terminate a needed response or send duplicate notices. Where updates are expected, design a clear sequence—for example, incident opened, status updated, incident resolved—and decide whether those are separate journeys or separate controlled executions.

Validation scenario

For a regional outage journey:

1. Create an approved test audience containing a small set of test profiles.
2. Verify the non-person event schema and unique occurrence ID.
3. Configure the Business Event and selected context fields.
4. Confirm the automatically added Read Audience uses the test audience and correct namespace.
5. Validate the journey and channel configurations.
6. Send the event and account for audience-export time.
7. Inspect entries, action results, errors, and discards.
8. Repeat with a new event ID to test multiple-execution behavior.
9. Replace the test audience only after governance and operational review.

Common exam traps

• Choosing a people identity as the defining business-event identity.
• Placing a Condition between Business Event and Read Audience.
• Claiming an XDM relationship automatically resolves affected profiles.
• Promising immediate broadcast despite the audience export.
• Mixing Business Event with Audience Qualification in the same journey.
• Assuming every audience member is channel-eligible.