Journey Optimizer Stop action and Validate button: what to do

The October 2026 Journey Optimizer notes change how journeys are built and cleaned up more than what they send. A new Stop action activity arrived on 12 October 2026, a Validate button arrived on 9 October 2026, and certificate-free JWT signing for custom actions entered Limited Availability on 13 October 2026. If you own live journeys, the Stop action and the validation change are the two that alter daily work.

Custom outbound channels also moved to General Availability on 2 October 2026, but this post leaves that to its own coverage and concentrates on the journey canvas, security and operations items around it.

Key takeaways

• The Stop action activity (12 October 2026) lets a journey remove a profile from up to five inbound activities or experiences without ending the journey.
• The Validate button (9 October 2026) moves configuration and message checks to a moment you choose, which should help large canvases stay responsive.
• HMAC-signed JWT for custom actions (13 October 2026) is Limited Availability; you request it through your Adobe representative.
• Coworker items such as alert recommendation cards and the Hygiene Analysis skill are listed as coming soon and are subject to change.
• Reduced step events for wait and event activities may shift the numbers in any report built on step event volumes.

What the Stop action activity changes in a journey

The notes describe the Stop action as an activity on the journey canvas that removes a profile from up to five inbound activities or experiences, directly from within a journey. The stated purpose is to decouple inbound disqualification from journey exit.

That sounds abstract, so take a case. A customer is in a welcome journey and is also being worked by an inbound experience that shows an offer on a web surface. They convert halfway through the journey. Before, the clean way to stop the offer was to end the journey or build a separate mechanism elsewhere. With the Stop action, the journey can keep going, perhaps sending an onboarding email, while quietly telling the inbound side to stop pushing the offer.

Who feels this most? Teams that mix outbound journeys with inbound experiences and have been working around the overlap with suppression audiences or duplicated logic. Teams that run only outbound email journeys will not see much difference.

One detail worth holding on to: the limit is five. The notes say up to five inbound activities or experiences, so a journey that needs to disqualify a profile from more than that needs a plan, such as a second Stop action further along or a rethink of how many inbound items overlap.

How to decide where a Stop action belongs

Don't scatter it everywhere. A Stop action is a side effect, and side effects hidden inside branching logic are hard to audit six months later.

A workable approach is to place it at decision points that already exist: after a purchase condition, after a consent change, after a profile enters a suppression state. Name the activity after the business reason, not the mechanism. A label such as Stop offer after conversion tells the next person more than Stop action 2.

Before adding any, list the inbound activities and experiences each journey touches. If nobody can produce that list, that is the real finding, and it is a good use of an afternoon before any build starts.

Why on-demand validation matters for larger canvases

The new Validate button runs configuration checks, including message checks, when you are ready to test or publish. The release notes frame the benefit as fewer repeated checks during editing and a canvas that stays responsive when it is large.

In practice this is a change in rhythm. Previously the tool could be re-checking as you worked. Now you build, then validate on purpose. For a ten-step nurture journey you may not notice. For a journey with many branches, several custom actions and a lot of message content, the difference is more likely to be felt.

There is a flip side. If checks only run when you ask, errors surface later than they used to. A builder who edits for an hour and then validates may face a pile of issues at once. Teams should agree on a habit: validate after each structural change, and always before handing a journey to a reviewer.

The notes do not say what the checks do or do not catch beyond configuration and message checks, so treat the button as the same safety net arriving at a different time, not as a stronger one. Check Adobe's documentation for the exact scope.

HMAC-signed JWT for custom actions: who should ask for it

Certificate-based custom authentication for custom actions now supports JWT client assertions signed with your OAuth client secret. The notes list HS256, HS384 and HS512, under the client_secret_jwt method, as an alternative to Adobe's RSA certificate. Configurations without an alg value continue to use RS256.

Two cautions follow from the source. First, this is Limited Availability for a set of customers, and access comes by contacting your Adobe representative. Second, the existing behaviour does not change for you unless you opt in, because configurations without alg stay on RS256.

Who benefits? Teams whose downstream endpoint or identity provider already expects client_secret_jwt, and who have been awkwardly bridging it with the certificate approach. If your custom actions authenticate fine today, there is no reason to chase access.

A security team should be in that conversation. Moving from a certificate to a shared client secret changes how secrets are stored, rotated and who can read them. That is a trade, not a free upgrade, and the secret-handling side is theirs to approve.

Coworker items, and the coming soon list

The notes mention a Business Performance Analysis skill, available from 7 October 2026, that analyses journey performance and gives optimisation recommendations in Adobe CX Enterprise Coworker chat. Treat it as a way to get a first read on performance, and compare what it says with your own reporting before acting.

A further group sits under coming soon, which Adobe flags as subject to change:

• AI recommendation cards on the Journey Optimizer home page when a Journey Custom Action failure or Journey Anomaly Detected alert fires, opening the journey with analysis pre-populated.
• Journey creation from the Coworker right rail, replacing the previous AI Assistant experience for generating journeys.
• A Hygiene Analysis skill that scans active and draft journeys for broken configurations, silent failures, and decaying or unused assets such as stale drafts, orphaned data sources and persistent custom action errors.
• Reduced step events for wait and event activities.
• A unified calendar for campaigns, journeys and orchestrated campaigns, listed as a usability improvement.

My position: the Hygiene Analysis skill is the most interesting of these, because most estates have more stale drafts and abandoned data sources than anyone admits. But it is not live yet, and nothing stops you doing a manual version of that sweep this month.

What to do and who owns it

The table below turns the changes into owners and actions. Dates are those given in the notes; the coming soon rows have no confirmed date.

How to roll it out and test it safely

Start in a sandbox that mirrors production, not in production. Each of these changes touches live behaviour, and two of them, the Stop action and step event counts, affect what happens to real profiles or real numbers.

For the Stop action, a simple test plan works:

1. Pick one journey with a known overlap with an inbound experience.
2. Add the Stop action at the point where the profile should be disqualified.
3. Push a test profile through and confirm it leaves the inbound activity while remaining in the journey.
4. Confirm a profile that should not be removed stays in place.
5. Document the activity and its reason, then roll to the next journey.

For validation, no rollout is needed beyond the habit. Run it before test and publish, and time how long your largest journeys take to open and edit so you have a before and after you can describe.

How to measure whether any of this helped

Measure the things the changes claim to affect, and nothing more. For the Stop action, count the cases where a profile previously received an inbound offer after converting. You may not have that number today, which is a reason to establish a baseline before building.

For validation, track builder experience: time to publish a change, and the number of issues found at review rather than at validate time. A drop in review rework is the real win.

For step events, compare counts before and after the change reaches your environment. Lower volumes on wait and event activities are expected, since Adobe says events will not be generated when the profile was not actually processed there. A dashboard that suddenly dips is more likely a definition change than a performance problem, so annotate it.

What not to do

• Don't request HMAC-signed JWT access just because it exists. Without a downstream need it adds a secret to manage and nothing else.
• Don't build around coming soon items. The notes say they are subject to change.
• Don't treat the Stop action as a cleanup for poor journey design. If five inbound activities need disqualifying, ask why they overlap.
• Don't let on-demand validation become validate never. A journey that reaches publish unchecked is the risk this change makes easier.
• Don't hand Coworker recommendations straight to production. They are a starting point for a human decision.

Where an implementation partner helps, and where you can go alone

Most of this is within a competent in-house team's reach. The validation habit, the manual stale-asset sweep and step-event dashboard review need no outside help.

A partner earns their fee in two places. The first is the journey and inbound orchestration audit: mapping which journeys touch which inbound experiences, and redesigning the overlaps so the Stop action is used deliberately. The second is custom action authentication, where the security design and the downstream integration both need an experienced hand. If you do bring one in, the Journey Optimizer partners page is a sensible place to start shortlisting, and the Journey Optimizer RFP template helps you write a brief that names these two areas instead of a vague request for optimisation. To compare firms side by side, use find partners.

Whatever you decide, keep Adobe's own documentation open for exact behaviour and availability in your environment, since the rollout is phased and your sandbox may see these changes on a different day than someone else's.

Sources

• Adobe Experience League: Journey Optimizer release notes — October 2026 updates for channels, journeys and the coming soon list, page last updated 15 October 2026.