Adobe Experience Cloud

The Adovo AJO Playbook

A practical guide to designing, testing and troubleshooting Adobe Journey Optimizer journey entry and audience timing.

By Adovo

November 5, 2026

Design, test and troubleshoot journey entry and audience timing.

Your audience has members, but the journey shows fewer entries than expected. Start by finding where those people stopped: audience selection, identity resolution, journey entry or the action itself. Each stage answers a different question.

Use this playbook to design, test and troubleshoot entry in Adobe Journey Optimizer (AJO). Follow the workflow through audience selection, data readiness, identity, testing, diagnosis, migration and day-to-day operation. Channel configuration, message rendering and deliverability need their own checks once a profile reaches an action.

The examples use a fictional loyalty programme with illustrative profiles and timestamps. Treat their expected outcomes as test cases to validate in your own sandbox.

How to use the guide

If you are building a journey, follow the seven chapters and complete the shared workbook as you go. If you are troubleshooting, use the symptom index to find your starting point.

Throughout the guide, keep one case file with the sandbox, audience and journey version IDs, controlled identity values, settings and UTC timestamps. Save the query or report behind each observation. The workbook supplies the fields, so you can concentrate on the investigation. Mask personal identifiers when sharing the case.

Use the shared workbook to retain your decisions. Definitions are in the glossary, and the references link the relevant AJO community discussions and Adobe documentation.

Explore the Adobe playbooks

All four playbooks | Business owners | Decision makers | Practitioners

Related guides: AEP · Real-Time CDP · Audience Manager

Find your starting point

Audience members exist, but nobody enters: check the entry contract, then reconcile the missing profiles. Existing membership, a new qualification event and selection for a scheduled read have different meanings.
A scheduled run appears to use an older audience: build the readiness timeline. Identify the evaluation and export associated with that occurrence.
Profiles are visible, but the audience remains empty: use the zero-entry investigation. Confirm the audience rule and evaluation outcome before rebuilding the journey.
An event is queryable, but the journey never starts: inspect the event route and identity. A stored record does not establish a supported trigger path.
Reentry controls are missing, or people receive repeat contacts: separate recurrence, active instances and contact policy.
Test mode reports success, but the expected path is absent: check the test prerequisites and identifiers, then trace the profile in Chapter 5.
A live journey cannot be republished after a change: use the migration inventory and cutover checks.

Each symptom selects an investigation. Several different causes can produce the same zero-entry total.

The running example: a loyalty programme

The fictional programme needs three journeys with different entry requirements.

A daily member-update selection should include eligible members, with a business rule limiting the update to once in a rolling 28-day period. This is the scheduled audience scenario.
A tier-upgrade welcome should follow a new qualifying membership change in a supported streaming audience. Existing members should receive any backfill through a separately planned process. This is the qualification scenario.
An order acknowledgement should follow an individual order event. If one member has two orders, the design must state whether each order needs its own journey instance. This is the unitary-event scenario.

Use these six profile states when testing the example journeys:

S01 already belongs to the audience before the listening journey is published.
S02 qualifies after the listening journey becomes operational.
S03 meets the audience rule but lacks the people-based identity selected for entry.
S04 arrives after the data cutoff for the occurrence being investigated.
S05 leaves the audience and later qualifies again.
S06 already has an active instance of the journey.

Reset the starting state for each exercise. S01 can be a valid candidate for a scheduled read while generating no new qualification event. The order scenario also needs its own order identifiers and event payloads. A shared profile label does not make the entry rules interchangeable.

1. Define the entry contract

Begin with a sentence that names the intended person, trigger and business outcome. For the scheduled example: each daily run considers eligible loyalty members for an update, subject to a recorded 28-day contact rule. For the tier example: a new eligible tier qualification starts the welcome process after the listener is operational. For the order example: a supported order event starts the acknowledgement associated with that order.

Avoid starting with a node someone has used before. Write down what should happen to S01 and S02 first. If both should be considered on the next scheduled occurrence, describe a population-selection requirement. If only the later membership change should cause entry, describe a qualification-listening requirement. If the business observation is an order being placed, specify the event and its identity.

Choose the entry pattern

Read Audience is the starting point for a defined population processed once or on a schedule. Audience Qualification listens for supported audience entrance or exit changes. A unitary-event journey starts from an individual supported event associated with a profile. Adobe also supports business-event patterns that lead into audience processing; those need their own contract and are outside the running example. See Adobe's entry-management guidance.

For the daily member update, start with Read Audience. For the tier welcome, check whether both the audience and its underlying signals support qualification listening. For the order acknowledgement, check that the source emits the event through the supported ingestion route. Audience origin and evaluation method belong in the entry contract because they affect the options available later.

If an acknowledgement must arrive within a particular interval, test the whole path against that deadline. Streaming describes part of the data flow; propagation, admission and channel execution still contribute to the elapsed time.

Existing membership needs an explicit decision

Audience Qualification does not replay an entrance event simply because an already-qualified profile is present when a journey is published. A qualification activity later in a journey starts listening when the profile reaches it. A membership check and a listener for a later change answer different questions. Adobe documents these distinctions in the qualification state model.

Allow for initial activation too. Adobe instructs practitioners to wait ten minutes after publishing a new qualification journey before using it, because the listener depends on a service cache refresh. For a controlled test, note publication time and send the qualifying change after that activation interval. This guidance covers listener activation, not the end-to-end time from a source change to a message.

This explains why the programme must decide what to do with S01. If existing tier members need a welcome or migration message, define a controlled backfill population, its contact policy and its relationship to the new listener. Re-sending source records to manufacture a change can also create duplicates or alter other consumers' behavior. Treat replay as a separate integration decision.

In the before-publication membership question, the reader wanted existing members to enter a new listening journey. Ask what new change those members would generate. If the answer is none, a backfill needs its own selection. The thread's older batch configuration also needs the current migration guidance in Chapter 6.

Separate selection from admission

The 100, 102 or two profiles question is a good design exercise. Suppose a first read considers 100 members, two more join, and nobody leaves. A subsequent full read considers the 102-member population. An incremental read of a supported audience considers the two new members if their memberships fall inside the applicable lookback window. Chapter 2 explains that window.

Selection is only the first count. A missing identity or an active instance can prevent entry, and a later contact rule can prevent a send. Compare the selected identities with actual entrants before following them to the action.

Record the contract before configuring

Use the entry-contract worksheet to record:

The business observation or population that should cause processing.
The audience origin and evaluation method, or the supported event source.
The selected people-based identity and the unit of contact: person, membership change or order.
The initial population and any backfill requirement.
The intended schedule, freshness requirement and policy when data is late.
The repeat-contact rule and evidence that should prevent an unwanted contact.

For the tier welcome, a useful acceptance statement is: S01 has no new qualification to process; S02 should become an entry candidate after a qualifying change is propagated and the listener is operational. For the daily selection, both may be candidates, subject to the contact rule. Review these statements with the business owner before implementing the canvas.

Before configuring the canvas, agree what should happen to existing members, new qualifiers and people already contacted. Those decisions determine which settings make sense.

2. Establish data readiness

An ingestion job can succeed while a scheduled journey still lacks the audience it needs. Work forward from source arrival to find the next unfinished stage.

For an audience-based design, follow source arrival, profile availability, audience evaluation, export readiness and journey entry. For an event-based design, follow creation, submission, ingestion acknowledgement and entry. The timestamp ledger lets you compare that sequence with the scheduled occurrence or business deadline.

Build a timestamp ledger

Use one timezone for the investigation, preferably UTC, while retaining the timezone displayed by each source. A date without a time is rarely enough to explain a missed occurrence. Include the audience ID and journey version ID so that the ledger cannot silently combine two versions or two similarly named audiences.

The readiness worksheet should distinguish these records:

The source record or batch that contains the intended change, with its business timestamp and arrival time.
The ingestion job or request that accepted it, including completion or failure evidence.
The audience evaluation job and result associated with the occurrence.
The export or availability evidence relevant to the journey's audience origin.
The configured journey start, freshness window and timezone.
The observed run start and entry evidence for the test identities.

If your role cannot see a job or system dataset, include that access gap in the case. An inaccessible view cannot tell you whether the job ran.

Coordinate the daily read with fresh data

Adobe's Read Audience scheduling guidance describes a daily option to wait for fresh batch audience data within a configured window of up to six hours. An occurrence is skipped when fresher data is not available by the end of that window. The option is specific to daily recurrence; changing the journey schedule does not reschedule the audience evaluation itself.

Know which memberships an incremental read can select

Adobe documents a default incremental lookback of 24 hours from the latest audience evaluation job. Enabling Trigger after batch audience evaluation extends it to the last successful journey execution, regardless of how long ago that execution occurred. The trigger is available only for daily recurrence. See the incremental-read rules.

After a skipped run, compare membership timestamps with the window that actually applies. A weekly or monthly incremental schedule does not inherit the daily trigger's last-success behavior. Test how it handles a membership change outside the default window rather than assuming it catches every change since the preceding occurrence. The first incremental occurrence still considers the full supported population.

Follow a delayed daily occurrence

In the daily example, yesterday's occurrence succeeded. Today's evaluation starts at 07:30 UTC and completes at 07:47. Export completes at 10:12, after the journey's scheduled 10:00 start. With the freshness trigger enabled and a window ending at 13:00, the occurrence can proceed once it detects the fresh data. Its actual start needs its own observation; export completion alone does not supply that time. If fresh data remains unavailable at 13:00, the expected outcome is a skipped occurrence.

Choose an operating margin from observed behavior in the target environment and the business deadline.

The audience-refresh discussion offers several different buffers. Its accepted answer helps explain the export stage; the proposed durations are not a worst-case guarantee. The related batch-trigger question asks what happens when the wait expires. Decide whether the missed contact can catch up, should wait for tomorrow or has expired.

Check freshness at the condition you are investigating

Audience selection and a later condition can read different representations of data. Adobe's inAudience documentation describes different propagation behavior for the batch projection used before a Wait in a Read Audience journey and the streaming projection used in a unitary journey or after a Wait. It also documents constraints on the audience-name parameter.

Test the condition at the actual node with a known profile state. A Wait can accommodate propagation along the relevant data path. First rule out a wrong field path or missing identity, since extra time will leave those defects in place.

S04 arrives after the daily cutoff. In the worked design below, that member waits for tomorrow's snapshot. A time-limited offer might instead expire. The business cutoff determines which outcome is correct.

Decide whether the design fits the timing requirement

For Edge audiences, record Edge evaluation and the propagation needed by the journey separately. The AJO community question about Edge audiences arose because the reader inferred journey-entry latency from Edge evaluation speed. Adobe's audience evaluation overview distinguishes evaluation methods and the capabilities of the underlying event data.

An individual business event may suit a supported unitary route; a daily population update needs a readiness gate and a missed-run policy. Choose the path against the required deadline, then measure the part of the flow on which that deadline depends.

3. Configure identity and repeat-entry policy

An email address on a profile, a namespace named Email and the value entered in a test dialog are different things. AJO needs the actual identity value in the namespace selected for this entry.

Use S03 to test that requirement: it meets the audience rule but lacks the selected identity. For an event-based case, also check where the identity appears in the payload and how the event configuration resolves it.

Verify the entry identity

For Read Audience, Adobe requires the selected identity to exist on the profiles being read. Audience Qualification also requires a people-based namespace when it starts the journey. A product or order identifier used as a lookup key is not automatically a people-based entry identity. Check the actual namespace configuration in the target sandbox, using the Read Audience prerequisites and qualification configuration.

Compare a known valid identity with S03. If only the first enters, look for the actual exclusion reason. Also check the merge policy when the resolved profile has different attributes from the profile you expected.

Verify the event route before its expression

Adobe requires journey-triggering events to arrive through the supported streaming route. A record inserted through Query Service, a batch-ingested event or a row from an internal Journey Optimizer tracking dataset is not a supported unitary trigger merely because it is visible on a profile. See the event guardrails.

For the order example, verify the schema, selected identity, event configuration, actual payload and submission path with the integration owner. Check the event's matching rule or required event ID, then confirm that the intended live version is listening. Keep a controlled event that should match and another that should not match.

The phrase system-generated needs care. A unitary event can use a system-generated event ID supplied by its AJO event configuration. That is different from using AJO's internal Message Feedback or Email Tracking records as the source of a new journey trigger. Adobe distinguishes the supported event-ID types in Work with journey events.

The AJO community's unsubscribe-trigger question and two-journey feedback discussion show why source validation comes first. In the second case, the author could query feedback records, but the proposed second journey did not trigger. Changing a namespace or adding time to a condition does not make that source supported.

If the requirement is a response to a supported message interaction inside the same journey, assess Adobe's Reaction activity. If the requirement is reporting or exporting delivery feedback to another system, design and measure that integration separately. Do not promise a feedback-delivery deadline from the fact that the data eventually appears in Query Service.

Give each recurrence control a separate job

A recurring Read Audience design has several decisions that AJO community discussions often group under reentry. Review these individually in the current scheduling documentation:

The scheduler determines when an occurrence is considered.
Incremental read determines selection for later occurrences of a supported audience. The initial occurrence still processes the initial population.
Force reentrance on recurrence removes profiles still active when the next occurrence starts. It does not turn those profiles into newly qualified members for incremental selection.
The daily batch-freshness option determines whether the occurrence waits for fresher batch data and when it should skip.
Your business contact policy determines whether a person should receive another contact for the same purpose.

Inspect the journey schedule properties for the recurring options. The clarification in the migration discussion specifically points readers to the journey schedule rather than treating Incremental read as a field on the Read Audience node itself.

Audience origin also matters. Adobe currently documents that custom-upload and other external audiences, including Federated Audience Composition, are processed in full on recurrence despite the Incremental read toggle. Record the origin before promising delta-only behavior. Force reentrance still concerns active participation; it does not establish permanent contact suppression.

For the daily member-update example, consider S06 midway through a multi-day path when tomorrow's occurrence begins. With force reentrance enabled, that work can be interrupted by the recurrence. If the member must complete the current path, preserve that requirement when choosing the setting. Test S05 separately: leaving an audience and requalifying later is different from remaining continuously qualified.

Define the scope of repeated contact

Adobe's profile-entry guidance distinguishes recurring reads from unitary reentrance and describes active-instance checks across journey versions. A new version does not move people out of an earlier active instance. Record the actual discard reason when a profile is blocked; publishing another version is not evidence that S06 can start again immediately.

The missing reentrance-control thread asks a more useful business question than its title suggests: how do we prevent another contact for four weeks? The permanent-exclusion question goes further and asks for a lifetime rule. Neither requirement is fully specified by finding a toggle.

For the 28-day rule, define the person and message purpose being suppressed, the milestone that starts the period, the authoritative history and the delay before that history becomes usable. A journey version ID alone usually makes a poor business key when the policy must survive a new version or a copied design. Consider a stable business-purpose identifier and an owner for its history.

The write order matters. Reserving eligibility before a send can suppress a retry after failure; writing only after success can leave room for duplicate attempts. The worked design below makes a choice about that interval. Your implementation still needs to demonstrate its consistency under overlap and failure, alongside the applicable channel consent and suppression checks.

For two concurrent orders, assess supplemental identifiers. Adobe supports them for eligible event-triggered and Read Audience journeys, with specific schema and instance restrictions; they are not supported for journeys starting with Audience Qualification. A supplemental order identifier changes the unit of execution. It does not replace a contact policy or prove that replaying the same order is safe.

Worked design: a daily read with a 28-day contact rule

This example uses illustrative names, keys and timestamps. Use IDs from your sandbox when applying the design. It requires a custom contact service whose behavior is specified below. AJO does not provide that service; build and validate it as part of your integration.

The business wants eligible members considered every day, even if they have remained in the audience for weeks. It therefore chooses a full read. Incremental selection would be a poor substitute for the contact rule: a continuously qualified member could become eligible for another contact without generating a new audience entrance.

Use these design inputs:

Contract LOY-DAILY-01; training sandbox; people-based namespace LoyaltyMemberId; purpose key loyalty-member-update.
An AEP batch-evaluated audience of active, eligible loyalty members. The audience includes membership eligibility; the later contact decision handles contact history.
Daily recurrence at 10:00 UTC; Incremental read off; Force reentrance on recurrence off; Trigger after batch audience evaluation on, with a three-hour window ending at 13:00.
A source cutoff of 07:00 UTC for the example's 07:30 evaluation. Later arrivals wait for the next snapshot. A skipped occurrence waits for the next daily run; it does not create an extra catch-up send.
A new occurrence reads the full available population. Existing active instances remain subject to the journey's admission rules. The six-case exercise below uses the same journey and namespace; S06 has an active earlier-version instance.

In this design, the action requests delivery through a contact service that owns the history ledger. The path is Read Audience, one custom action to that service, then the corresponding end path. There is no additional AJO Email action after the request. A design using AJO's native channel actions needs its own tested way to coordinate the contact decision and history updates.

The contact service must meet this contract:

The ledger key combines namespace, person identity and purpose. The integration owner maintains accepted-request timestamps and unresolved requests for that key.
The contact milestone is the delivery provider accepting the request. It starts the 28-day period, even if delivery later fails. This policy favors preventing repeat attempts; it does not measure successful inbox delivery.
At request time t, allow another request only when there is no previous accepted request or the latest accepted timestamp is at least 28 days old. Block timestamps strictly later than t minus 28 days, through t inclusive. A future timestamp is a data error and is held for review.
An unresolved request also holds further work for that person and purpose. Missing history because a person has never been contacted is eligible; failure to read history is an error and sends nothing.
A request key combines the occurrence reference, person and purpose. Retries retain that key. The service must serialize the decision for the ledger key and persist a pending request before calling the provider. If that write fails, it sends nothing. Its duplicate-request behavior and retention of the provider reference are acceptance requirements, not an AJO exactly-once guarantee.
A provider rejection before acceptance creates no accepted-contact timestamp. An ambiguous timeout or an accepted request whose ledger update fails remains held until the integration owner reconciles it. A later run must not blindly resend it.

The service must also apply the consent and suppression requirements of its delivery channel. Being in this loyalty audience does not establish permission to contact someone.

Now fix the comparison time at 29 November 2026, 10:20:00 UTC. The exact 28-day boundary is 1 November, 10:20:00 UTC. A previous acceptance exactly at that boundary is old enough; one at 10:20:01 is still inside the blocked interval. In operation, the service evaluates each request at its own request time.

With these rules, S01 can be read again and allowed at the boundary, while a requalified S05 can enter and still be blocked by more recent contact history. The validation workbook walks all six states through these settings. Use the identity worksheet to copy the policy into your own design, changing the milestone and failure choices where the business requires different behavior.

4. Validate before launch

Before clicking a test button, decide what result would settle the question. To check S03, you need to distinguish rejection for a missing identity from a successful entry. To check the 28-day rule, you need the contact decision and ledger state as well as the journey path.

The six states cover intended entries and exclusions. The worked matrix supplies expected outcomes; actual-result fields stay empty until a controlled run produces them.

Choose a method that exercises the requirement

Adobe offers three validation methods with different data and execution behavior. Check availability in the target sandbox and compare them using Choose a validation method.

Journey Simulation uses simulated users for rapid flow checks. Its documented exclusions include consent, suppression, exit criteria and capping checks. It can send messages to configured execution addresses and make real external calls. It cannot certify those excluded production controls.
Journey Test mode uses persistent AEP test profiles. It is useful for stepping through a draft with known profile data and controlled identity values. It can send real messages to those profiles' actual inboxes.
Journey Dry run uses production audience data while bypassing channel and custom actions. It is useful for examining audience reach and branches, but it does not prove delivery or a custom-action response. Availability and permissions need to be confirmed.

Use addresses and endpoints controlled by the test team when a method can execute real actions. Naming a profile test does not, by itself, prevent a real inbox or integration from being contacted. For non-production sandboxes, Adobe directs readers to Test mode rather than assuming that Simulation is available everywhere.

Use Test mode for a controlled profile trace

Start by running Validate and resolving the reported configuration errors. Confirm that the draft uses the required namespace and that the chosen AEP profile is marked as a test profile. Enter its actual identifier value in the trigger dialog, then inspect the journey log for that same identity and version. Adobe describes these steps and limitations in Test your journey.

Check the journey's configured start and end dates before triggering it. The active window must include the current test time. Adobe documents DISPATCHER DISCARD #16 when a test event falls outside that window, even though the trigger appears accepted. If you temporarily move the start date for a test, restore the intended schedule before publication.

The AJO community's successful-trigger-but-no-activity case was resolved when the author entered the actual email value instead of the word Email. That is a useful negative control: deliberately compare an incorrect identifier with the known test identity, and confirm that the evidence distinguishes them.

A fast test can hide a timing failure. Test mode normally shortens waits and event timeouts to ten seconds; a later interaction can therefore take the timeout path. Reaction-event timeouts have a separate minimum and default of forty seconds. Choose a test duration that fits the event you are waiting for. Percentage splits select the top branch in Test mode, so reorder those branches when exercising another path and restore the intended design afterward. Keep these overrides with the result.

Keep the production entry path in the acceptance test

In the AJO community's Read Audience testing discussion, one suggestion replaces a batch read with a streaming qualification design to iterate faster. That can help isolate downstream logic. It leaves the original audience origin, batch export, schedule and incremental-selection behavior untested.

The daily design's acceptance case needs the batch audience, full-read setting, freshness trigger and contact service. A shortcut that removes one of them leaves that part of the design untested.

Use the six expected outcomes in Workbook 4. In particular, S05 tests the difference between entry and contact, while S06 tests an active earlier instance. A successful S02 cannot stand in for either case.

Use Dry run within its documented boundaries

Adobe's Dry run execution guide documents behaviors that affect interpretation: custom actions are bypassed and return null, waits and external data sources have configurable behavior, and scheduled reads are anchored to activation rather than preserving the configured live clock time. Dry run also has specific behavior for reactions and business rules.

Dry run can help inspect audience reach and flow. In the worked design, it bypasses the contact service and returns a null response, so it cannot exercise the 28-day decision or the provider's acceptance. Its changed schedule also leaves the intended 10:00 batch coordination unproven.

Dry run generates step events too. Keep its dryRunID with the test results, and exclude records with inDryRun true when later measuring live activity. Chapter 5 gives the field path and null handling. Export any Dry run reports you need before stopping that mode, because Adobe limits their availability to the active run.

Define the launch decision

The validation matrix should show which requirements passed and which remain open: flow logic, audience selection, schedule coordination, contact controls and delivery integration. Each open requirement needs a specific next test.

For the final acceptance check, retain the intended entry pattern, schedule and audience origin. Bound the population to approved test identities and direct actions to destinations the team controls. Arrange the normal operational approval before running it. This check covers the behavior that the earlier simulation or manual trace could not exercise.

Make the launch decision against those individual results. Save the test output before clearing a session, since Test mode reporting is removed when that mode is disabled.

5. Diagnose missing or delayed entries

Start with one journey version, one occurrence or time window, and a small set of profile identities. State the expected result using the entry contract. Then find the first observation that differs from it.

Change one suspected cause at a time. If a new schedule, namespace and expression arrive together, a successful rerun will leave you guessing which change mattered. The investigation worksheet keeps that reasoning with the result.

Audience members exist, but the journey has no entries

Check the entry pattern first. For a new qualification listener, compare publication time, Adobe's ten-minute activation interval and the membership-change time. For a mid-journey listener, compare the change with the time the profile reached that node. For Read Audience, identify the actual occurrence, selected population and readiness result. Then check the entry identity.

Next inspect the journey's entry and exclusion evidence, including active instances and configured business rules. A profile can be a valid audience member while failing a later admission or action check. Keep the reason attached to the profile identity and version rather than explaining the whole gap with a general statement about latency.

The AJO community's 46 members versus 35 entries question remained unresolved after the author compared another set of counts. Use it as a warning about denominators. Define the expected eligible set and observed entry set over the same interval. Find the missing identities and explain their individual outcomes; subtracting two totals does not identify the affected people.

Profiles are present, but the audience remains empty

Confirm the audience definition against a known profile and the relevant event or attribute timestamps. Check whether the expected evaluation job exists, whether it succeeded, and whether the next availability stage completed. Verify the sandbox, origin and merge-policy assumptions. If your role cannot see a monitoring view, retain that limitation instead of interpreting it as a missing backend process.

In the AJO community's zero-qualified-profiles discussion, the author corrected the original observation from no evaluation runs to a failed evaluation. The author later reported that Adobe Support was investigating export jobs. The discussion does not contain an independently verified repair or a successful final rerun.

The useful next step in that situation is a support case containing the failed job and a reproducible audience rule. Changing journey conditions cannot establish that the failed pipeline stage recovered; a successful rerun of that stage can.

The occurrence skipped or used unexpected membership

Rebuild the timeline from Chapter 2. Check the snapshot, freshness window, last successful run and applicable incremental lookback. S04's source arrival belongs against that occurrence's cutoff. A profile screen opened later may show a membership state the run never read.

The Read Audience scheduling discussion includes delayed-entry observations and proposed explanations involving snapshots and lookback. Those explanations should lead to configuration-specific checks. They do not establish that every delayed entry is correct or that a currently exited profile should always be admitted.

If the business requires an additional eligibility decision before an action, specify the authoritative state and test the condition at that node. Record its data freshness using the inAudience timing guidance. Adding a later condition does not retroactively change who entered the journey.

An event is stored, but no entry appears

Return to the source route before rewriting the condition. Confirm that the record came through the supported trigger path, that its identity and event configuration match, and that the intended version was listening. Then inspect any discard evidence for that identity and event.

Keep the event's business timestamp, submission time, ingestion acknowledgement and query-visibility time separate. Query visibility can be delayed. It is useful evidence of stored data, but it is not a timestamp for the journey's admission decision. For internal feedback records, use the supported reporting or integration design rather than attempting to turn the same stored row into an unsupported unitary trigger.

Profile data is present, but a condition chooses the wrong branch

Check the exact field path, the resolved identity, the value's type and the collection element being evaluated. In an AJO community profile-condition discussion, the author initially suspected a timing issue. The author clarified that the relevant preference could appear at different array positions.

For a custom preference array, the business requirement might be that one element has both the required preference type and an allowed flag. Test those conditions on the same element. Finding a matching type in one element and an allowed flag in another can produce the wrong result. Positional checks such as the first element need a documented ordering guarantee that this example does not have.

Adobe provides collection-management functions for filtering and selecting collection elements. Build the expression for your actual field group and collection context in the expression editor. Check the applicable channel-consent controls separately from custom preference logic.

Useful negative cases include a missing array, an empty array, a matching type with a disallowed flag, unrelated allowed entries, and multiple matching entries with conflicting values. Define the intended conflict behavior with the data owner. Test expression correctness before treating a longer Wait as the explanation for a changed branch.

Entry succeeded, but the message result is absent

Follow the same identity and journey instance from entry to the action. Distinguish an activity being processed, an action attempt, an action error, a feedback record and channel delivery evidence. The scheduling discussion above also raises a question about missing email results after journey progress. Investigate that result at the action boundary before reopening the audience-entry diagnosis.

Adobe's query examples provide separate starting points for profile paths, Read Audience operations, qualification discards, action errors and business-rule exclusions. Use the current examples for the actual dataset and schema available in your sandbox. Preserve the query, filters, execution time and result window alongside the investigation.

In particular, journeyVersionID identifies the version, profileID corresponds to the journey namespace, and instanceID distinguishes an execution. An activity-level export event may have no profile-specific record, so a query filtered only to one profile can miss the export failure that affected the occurrence. A zero-row query also needs its own checks: dataset, fields, permissions, time filter and reporting availability.

For live reporting, exclude Dry run step events using _experience.journeyOrchestration.stepEvents.inDryRun: retain null or false, and exclude true. Filtering only for false loses live records whose flag is null. For a Dry run investigation, retain true and select the relevant _experience.journeyOrchestration.stepEvents.dryRunID. Adobe documents both fields in Dry run step events. A version filter alone does not establish execution mode; keep the intended time window as well. This is a reporting check, not an explanation established for the historical 46/35 case.

Prepare an escalation another team can use

Include the sandbox, audience and journey version IDs, the relevant settings, exact identity values in an approved channel, UTC timestamps, job references and expected-versus-observed behavior. Attach the smallest controlled case and distinguish what you observed from what you inferred. Include the evidence that contradicts the initial hypothesis.

For an integration crossing AEP, AJO and an external delivery system, agree which reference each team will record. The AJO community's end-to-end traceability question is unanswered; it identifies a real need without proving a particular logging implementation. Verify the identifiers actually available at each boundary and arrange external endpoint logs where required. Do not assume journey step events contain every outbound payload and response body.

Close the investigation when the controlled rerun supports the explanation and the required cases pass. If the gap remains, hand over the reproducible case with its failed or unresolved status intact.

6. Change or migrate a journey

A change to the entry pattern changes the meaning of the population being processed. Treat it as a behavioral migration. The audience name and message can remain the same while the treatment of existing members, later qualifiers and exits changes.

Adobe's current batch-audience migration guide states that batch audiences are no longer supported in Audience Qualification or audience-based exit criteria for new publication. Existing live journeys are not automatically stopped. Drafts, duplicates and journeys being republished must meet the current restrictions. A working live configuration is therefore insufficient evidence that the next publication will succeed.

The AJO community's batch-qualification migration discussion contains both proposed workarounds and later clarification. Read the full discussion before treating an accepted answer as a complete implementation. A streaming audience that merely wraps a batch dependency does not establish that the underlying data has become timely enough for the business requirement.

Inventory the behavior you need to preserve

Start with the current entry type, audience origin, namespace, schedule, exit rules and active instances. Then inspect downstream conditions and actions for assumptions about that entry context. A field supplied by an event may need a different source in the replacement design.

Separate three populations: people already contacted, people eligible but never processed, and people still active in the old journey. The migration must state how each is treated. Add the expected handling of a person who qualifies, leaves and qualifies again during the transition.

For the daily member update, Read Audience can express scheduled population selection. It does not reproduce every entrance-and-exit transition of the old listener. If prompt removal after an audience exit is a requirement, document a supported exit design and test its timing separately. The current migration guidance points to eligible streaming audiences for qualification and audience-based exits. Where the required batch-dependent behavior has no suitable replacement, retain that gap in the migration record and involve the Adobe team before approving the change.

Changing from Audience Qualification to Read Audience also changes the journey type. Adobe's journey validation errors require versions of one journey to keep the same entry activity type. Plan a separate journey when the replacement needs a different entry type; a new version alone is not the migration mechanism.

Decide what the first run will do

An incremental Read Audience configuration does not inherit the old journey's processed population. For a supported audience, its first occurrence considers the full population; later occurrences use the incremental behavior described in the Read Audience documentation. Check the separate restrictions for externally generated audiences.

S01 may already have been contacted by the legacy journey. The replacement needs access to that history before deciding on another contact. In the worked design, the stable purpose key survives the change and the contact service holds requests when history is unavailable. A new journey's selection toggle has no knowledge of that history.

The migration discussion's settings clarification locates incremental read in the recurring journey's schedule configuration. Verify the current controls in the target tenant. A missing setting should prompt a check of the schedule and supported audience origin before any redesign of the data.

Compare old and proposed behavior before cutover

Use the migration worksheet to compare the old and proposed outcomes for S01 to S06. Add the two-order cases if processing is per order. The daily worked design uses full reads with Incremental read off; a replacement using incremental selection needs its own lookback and missed-run tests.

Compare the sets of identities and relevant business keys at entry and at the contact decision. Matching total counts can hide different people. Explain intended differences, such as a separately approved backfill, instead of making the replacement imitate an accidental limitation of the old journey.

Keep the validation boundaries from Chapter 4. Test the first scheduled read, required exits and contact-history behavior through methods that actually exercise them.

Plan the handover and the recovery path

Choose a transition window and specify who admits new work, who finishes existing work, and how delayed data is reconciled. Consider the interval between closing the old listener and the replacement becoming operational. Also consider an overlap in which both designs might process the same business event. Record the handling of either case before changing a live journey.

Adobe distinguishes closing a journey from stopping it. Close to new entrances blocks new admissions while allowing profiles already inside to finish. Stop ends processing for profiles already inside as well. Neither action is a reversible pause. Choose the action according to the approved treatment of those profiles, with the required operator permissions.

For a version change that retains the journey type, profiles already in an earlier version continue there. Publishing a later version does not transfer them or bypass the active-instance rules. For a separate replacement journey, independently verify the shared contact policy and any overlap controls; do not assume the old journey's active-instance restriction protects the new one. See entry management.

A recovery plan should name the trigger for halting new work, the operator, the retained configuration and the reconciliation process. It must account for messages already sent and contact history already written. Restoring an earlier design cannot undo those outcomes. Retain the pre-change population and the observed processing ledger so that a controlled recovery can distinguish unprocessed work from completed contacts.

Approve the migration when the six profile states have an agreed outcome, the first run has a bounded population, the exit requirement is preserved or explicitly redesigned, and the operator can account for the handover window. An unresolved difference belongs in the release decision.

7. Operate and maintain the entry contract

Once the journey is live, use the entry contract to decide what deserves attention. A healthy entry total can still hide a late batch, the wrong identities or a broken contact rule.

Check readiness early enough to respond before the daily freshness window closes. For an order acknowledgement, compare observed event-to-entry time with the required response time. Set thresholds from the workload and business deadline.

Monitor the processing boundaries

Maintain a record for each scheduled occurrence or investigated event window. Include the source cutoff, evaluation and export outcome where relevant, expected candidates, observed entrants, explained exclusions, action attempts and unresolved differences. Label a skipped run separately from a successful run with an empty population.

When a count changes, compare identities before attributing the change to platform performance. A larger audience can coexist with fewer admissible profiles because the namespace, active-instance state or contact history changed. A smaller entry count can also be correct after an approved suppression rule takes effect.

In the daily example, the operator first checks evaluation and fresh-snapshot availability. After entry, S03 and S06 should be absent from the new instance set for different reasons. At the contact stage, S05 should be blocked by history. Those checks are more useful than expecting one audience total to equal the number of messages.

Assign the evidence to an owner

Route a source or evaluation failure to the data owner. Route an unexplained entry gap to the journey owner with the version and identities. Route an action failure to the channel or integration owner with the instance and provider reference. The business owner approves changes to the contact milestone and policy.

One person can hold several roles, but each boundary needs an accountable owner. Agree on the reference that connects the teams' records. The unanswered AEP-to-AJO-to-external-system logging question is a useful reminder to establish this before an incident.

Retain only the identifiers and payload detail needed for the approved investigation and retention policy. Keep sensitive identity values in the controlled system used by the team, with masked references in shared notes. Verify that the required datasets and endpoint logs are accessible to the people expected to diagnose a failure.

Reopen the contract when its inputs change

Review the contract after an audience-definition change, a new audience origin, a schedule or timezone adjustment, a namespace or merge-policy change, a source-schema change, a new version, or a change to the contact-history implementation. Changes to Adobe capabilities or restrictions also require a review of the affected chapter and tests.

Check stored expressions after renaming an audience. Adobe's inAudience reference notes that expressions using the audience name do not automatically update when that name changes. Include names as well as IDs in the change record.

Repeat the cases affected by the change and attach the new results to that version. Keep the earlier results with the configuration they tested.

Use the ownership worksheet as the operational handover. The journey is ready for routine operation when the next operator can identify a missed obligation, find its evidence, and contact the owner who can act on it.

Shared workbook

Copy these seven worksheets into your team's working system. Use the LOY-DAILY-01 design from Chapter 3 as a starting point, then enter your own settings. Use the expected outcomes to plan tests and record your results in the blank fields.

Use the same contract ID, sandbox and version across the worksheets. Keep UTC timestamps alongside each system's displayed timezone. Mark unavailable observations and who can obtain them.

Workbook 1. Entry contract

Blank entry contract:

Contract ID and sandbox: ______
Business owner and journey owner: ______
Business outcome and deadline: ______
Journey and version IDs: ______
Entry pattern and audience or event ID: ______
Audience origin and evaluation method: ______
People-based namespace and unit of processing: ______
Initial population and backfill treatment: ______
Schedule, timezone and source cutoff: ______
Freshness window and late or skipped-run policy: ______
Contact milestone, policy period and history owner: ______
Acceptance cases and result location: ______

Filled design: LOY-DAILY-01, training sandbox, LoyaltyMemberId, person-level daily member update. The journey owner configures an AEP batch audience, a 10:00 UTC full read, a three-hour freshness window, and both Incremental read and Force reentrance off. The business owner approves the accepted-request milestone and rolling 28-day rule; the integration owner owns its contact ledger. The source cutoff is 07:00. Late members wait for the next snapshot, and skipped runs wait for tomorrow without an extra catch-up send. Chapter 3 supplies the request and failure policy; Workbook 4 supplies the six expected outcomes.

Workbook 2. Identity and repeat contact

Blank identity and policy record:

Contract and case IDs: ______
Namespace label, namespace ID and controlled identity value: ______
Business-object key, if applicable: ______
Starting audience membership and active version or instance: ______
Recurrence, Incremental read and Force reentrance settings: ______
History source, ledger key and accountable writer: ______
Contact milestone and UTC timestamp field: ______
Exact blocking interval and equality rule: ______
Unknown, unavailable or future-dated history behavior: ______
Pending-request, overlap and retry behavior: ______
Result, evidence and reviewer: ______

Filled policy: the custom contact service owns history keyed by LoyaltyMemberId, identity value and loyalty-member-update. At 29 November 2026, 10:20:00 UTC, the blocked interval is later than 1 November, 10:20:00 through the comparison time inclusive. A contact exactly at the lower boundary is old enough. History read errors and unresolved requests send nothing and go to the integration owner. Rejections before provider acceptance create no accepted-contact timestamp; ambiguous outcomes stay held. The same occurrence/person/purpose request key survives a retry. Test these service requirements under concurrent and failure conditions.

For an order-level design, add two order IDs for the same person and decide which contacts are independent. A person-level 28-day rule would suppress an order acknowledgement that may be required. Check supplemental-identifier eligibility separately.

Workbook 3. Readiness timeline

For each observation, record its timestamp, timezone, system reference, outcome and evidence location:

Source business event or batch cutoff.
Arrival and ingestion acknowledgement or completion.
Audience evaluation start, end and outcome, where applicable.
Export or downstream availability evidence associated with that evaluation.
Scheduled occurrence and configured freshness deadline.
Actual run start and profile-entry evidence.
Any later membership condition, action attempt and result needed for the case.

Filled timeline: on 29 November, source cutoff is 07:00 UTC, evaluation runs from 07:30 to 07:47, the scheduled occurrence is 10:00 and export completes at 10:12. The freshness deadline is 13:00. The example's contact-decision comparison is at 10:20; it is not a measured entry timestamp. Actual run start, entry and action times must be captured during the controlled test.

Add the incremental lookback rule if that setting is on. For qualification tests, add publication time, the ten-minute activation interval, arrival at any mid-journey listener and qualification-change time. Those observations answer different questions from the batch timeline.

Workbook 4. Validation matrix

Create a separate test record for each case. For the daily example, use Chapter 3's full-read settings and the 29 November 2026 snapshot. Compare the contact decisions at the example time 10:20:00 UTC. Unless a case says otherwise, assume a valid namespace, no active instance, readable history, applicable channel eligibility and a successful provider acceptance. The cases below specify expected outcomes; capture actual results when you run them.

S01, identity L-001: already a member before publication, present in this snapshot, last accepted contact at 1 November 10:20:00 UTC. Expected: selected, admitted and allowed at the exact 28-day boundary. On provider acceptance, the service writes a new accepted-contact timestamp. This is why full reads are useful for continuously qualified members.
S02, identity L-002: qualifies on 28 November at 20:00 UTC, appears in the next day's snapshot and has no previous accepted contact. Expected: selected, admitted and allowed. A repeat request with the same request key must return the existing outcome without a second provider submission.
S03: meets the membership rule in the snapshot but has no LoyaltyMemberId value. Expected: no admission through that namespace and no contact-service request. Check the exclusion evidence rather than treating a missing message as sufficient proof.
S04, identity L-004: source data arrives on 29 November at 08:15 UTC, after the 07:00 cutoff and the example evaluation. It is absent from that snapshot. Expected: no selection or entry for this occurrence. On 30 November, it is considered by the full read if the next snapshot includes it and it remains eligible; with no history or active instance, it can proceed to the contact decision.
S05, identity L-005: exits on 27 November, requalifies on 28 November at 18:00 UTC and is present in this snapshot. Its last accepted contact was 15 November at 11:00 UTC. Expected: selected and admitted, then blocked by the 28-day history rule. Requalification does not reset that history, and the service makes no new provider submission.
S06, identity L-006: present with a valid namespace, but still active in an earlier version of this same journey. Expected: no new instance while that participation blocks reentry. Force reentrance is off, so the recurrence does not reset the old instance. Use the actual version and instance references to distinguish its continuing work from a new request.

Exercise the service's failure cases too: a history read error sends nothing; a provider rejection before acceptance leaves no accepted timestamp; an ambiguous timeout stays held; a known never-contacted person can be allowed. Test a second competing request for the same ledger key and a timestamp one second inside the blocked interval. The integration owner must demonstrate that the service meets its contract.

Blank test record to copy for each case:

Contract, case, sandbox and journey version IDs: ______
Controlled identity and starting state: ______
Snapshot or event reference and execution mode: ______
Publication or listener activation times, if applicable: ______
Test start/end window and current time: ______
Wait overrides or reordered percentage branches: ______
Expected selection, admission and contact decision: ______
Validation method and behavior it does not exercise: ______
Actual selection, admission, contact result and timestamps: ______
Query or report, request key and relevant instance references: ______
Pass, fail or unresolved; reviewer and next action: ______

Use the intended batch entry path for audience and schedule acceptance. Test mode or a simulated branch can help isolate logic, but Dry run bypasses the service. Add order-level, preference-array and other cases when extending the design. Keep actual results empty until the appropriate test runs.

Workbook 5. Investigation log

Investigation fields:

Symptom, business impact, occurrence or event window, and first observed time.
Sandbox, audience ID, journey ID and version ID.
Controlled identity references and instance IDs when available.
Execution mode; inDryRun filter and dryRunID when applicable.
Expected set, observed set and identities requiring explanation.
Earliest known divergence and evidence supporting it.
Query text or report filters, dataset, execution time, result window and access limitations.
Hypothesis, contradicting evidence, proposed controlled check and owner.
Observed outcome, unresolved gap and next action.

For the 46/35 count problem raised in the AJO community, start by aligning the occurrence, namespace, identity sets and execution mode. Eleven is the numerical difference; it does not tell you which people are absent or why. If only totals are available, obtaining the identity sets is the next investigation step.

For a support escalation, include the relevant job reference and the exact failed result. If a job first appeared absent and was later found failed, preserve the correction so the next investigator does not repeat the original assumption.

Workbook 6. Migration comparison

Migration comparison fields:

Current and proposed journey IDs, versions and entry types.
Audience origin, evaluation method, schedule and namespace on each side.
Required entry, exit and repeat-contact behavior.
Existing contacted population, eligible unprocessed population and active old instances.
First replacement-run population and the source of its exclusions.
Old behavior, required new behavior, actual new behavior and evidence for each validation case.
Handover window, admission owner, overlap or gap policy, recovery trigger and operator.
Unresolved differences, approval owner and reconciliation record.

For the worked daily design, replace the legacy batch-qualification entry with a separate full-read journey and preserve its contact-history purpose key. Incremental read stays off. If you choose an incremental replacement instead, test its full initial population and later lookback behavior. Any old audience-exit requirement remains a separate acceptance item. Agree how old active instances finish and test the replacement's overlap controls independently.

The comparison is incomplete if it contains only a new canvas screenshot. It needs the observed population and state-transition results, with any intentional differences approved.

Workbook 7. Ownership and review

Ownership and review fields:

Business owner: deadline, contact milestone and policy decisions.
Data owner: source arrival, profile state, evaluation and export evidence.
Journey owner: entry contract, configuration, version record and admission investigation.
Channel or integration owner: action attempts, endpoint evidence and delivery investigation.
Operator: monitoring cadence, thresholds, escalation route and authority for live changes.
Evidence location, access, masking and retention policy.
Last tested configuration, review date, documentation check and next review trigger.
Open risks, decision owner and agreed follow-up.

Daily-design handover: before 13:00 UTC, the operator checks readiness against the freshness deadline. Failed evaluation goes to the data owner; an entry gap goes to the journey owner; a held or failed contact request goes to the integration owner. The business owner decides any exception to the 28-day policy. Fill in the actual names, escalation times and access arrangements before handover.

Ask another practitioner to trace S05 from the snapshot through entry to its blocked contact decision. If they cannot find the relevant history timestamp or version, fix that gap before an incident makes it urgent.

Glossary

Entry contract: a planning record of who should enter, why, when and under which contact rules.
Candidate: a person or business key considered by the intended selection or trigger. Candidate status does not guarantee admission.
Admission: the journey entry established by the relevant execution evidence.
Audience Qualification: a journey activity that listens for supported audience membership changes.
Read Audience: an entry activity that processes a defined audience population according to its supported configuration.
Snapshot: the evaluated population representation relevant to an audience operation. Record which evaluation it reflects.
Freshness window: the configured period during which a supported daily Read Audience occurrence waits for qualifying newer audience data.
Namespace: the identity system selected for entry; the profile also needs a valid value in that system.
Journey version ID: the identifier of a particular journey version, needed to avoid mixing evidence from different configurations.
Instance ID: an execution identifier used to distinguish a profile's journey executions in the available reporting data.
Recurrence: the schedule for repeated audience processing. It is separate from the business repeat-contact policy.
Contact milestone: the business-defined event, such as an approved action attempt, used to record a contact for the policy. Its implementation must be specified and tested.

References

Use these AJO community discussions to explore the individual cases and Adobe's product references for configuration details and supported behavior.

AJO community discussions

Batch-audience qualification migration: migration constraints, first-run behavior and clarification of incremental-read settings.
Audience refresh versus journey execution: observed delays and the need for a readiness timeline.
Read Audience scheduling behavior: delayed entries, population assumptions and later action-result questions.
Zero qualified profiles despite visible profiles: a correction identifying failed jobs and an unresolved support investigation.
Read Audience versus qualification counts: full versus incremental selection and membership-listening distinctions.
Membership established before publication: the treatment of existing members.
Edge audiences and qualification entry: propagation and entry expectations.
Stored events without unitary entry: supported trigger routes and terminology.
Using message feedback to start another journey: internal feedback, reporting and trigger limitations.
Reentrance controls on scheduled Read Audience: recurrence versus the business contact interval.
Testing journeys dependent on audience queries: the limits of logic-only testing.
Test-mode activation without the expected path: the author's correction of the identifier value.

Related AJO community discussions

Waiting for batch evaluation: freshness and skip behavior.
Practical uses of qualification and Read Audience: entry and exit requirements.
Audience count versus actual entrants: unresolved set reconciliation.
Daily Read Audience operation: recurring selection and membership changes.
Preventing repeat entry: the need to specify the lifetime or period-based business policy.
Testing qualification and Read Audience: questions that require current validation-method guidance.
End-to-end integration traceability: an unanswered logging requirement.
Profile-array condition correction: variable array position and condition selection after an initial timing hypothesis.

Product references

Use the relevant Adobe documentation for feature behavior, configuration and availability in your tenant:

Adobe documentation attribution

Technical guidance in this playbook draws on the linked Adobe Journey Optimizer documentation. The AdobeDocs source repository license is reproduced here for that material:

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Bring one journey to review

Bring the entry contract, a readiness timeline and one identity-level investigation to an Adovo journey review. Include the expected population, relevant version IDs and any unresolved acceptance case. Use masked records when sharing the initial material.

Request an AJO journey review