AJO Go-Live Checklist

A practical pre-launch checklist for Adobe Journey Optimizer journeys and campaigns. Last verified against Adobe Experience League documentation: 6 November 2026. Download the companion guide (PDF): every item explained, with where to find it in AJO.

How to use this checklist

Work through every section before publishing a journey or campaign to production. A journey goes live only when every box is ticked or a named owner has accepted the gap in writing.

Use one copy per journey or campaign.
Start it at least two weeks before launch: DNS, deliverability and data fixes take the longest.
Mark items that don’t apply (for example, SMS checks on an email-only journey) as N/A, with a short reason.
The sign-off table at the end is the final gate.

Note: AJO features and labels change often. Check feature names against the current Adobe Experience League documentation before you rely on them.

1. Channel and deliverability readiness

Email

Sending subdomain fully delegated (Adobe’s recommended method) or CNAME set up in production; allow 24–48 hours for DNS propagation
SPF and DKIM verified as passing; DMARC ownership decided (Adobe-managed per subdomain, or managed on the parent domain)
Domain certificate expiry alerts set up and routed to an owner
IP pool created before the email channel configuration
Production email channel configuration created (subdomain, IP pool, sender name, From / Reply-to / Error addresses)
If the High Throughput Transactional Messaging add-on is licensed: dedicated High throughput IP pool and channel configuration set up (self-service since Oct ‘26, for email and push)
Header and delivery settings overridden at the journey or campaign action level (From, Reply-To, recipient, list-unsubscribe) reviewed for each message
“Honor open tracking consent” setting decided; affected existing messages (such as transactional ones) republished if it is turned on
IP warmup plan agreed (needs a production sandbox), and launch volume fits the current warmup run
Reply-to and BCC addresses use domains with valid MX records
Reply-to inbox monitored; if needed, forwarding requested from Adobe Customer Care at least a week before launch (it takes about 3–4 days)
List-Unsubscribe enabled (mailto and one-click URL), plus an unsubscribe link in the email body
Legally required footer details present (such as a postal address), confirmed with legal for each country

Push / in-app

Production push credentials uploaded: iOS .p8 key with Key ID and Team ID; Android App ID and FCM credentials
Push channel configuration shows valid credentials linked (green check) for each App ID, including any personalized App ID values
iOS production build has the Mobile SDK messaging.useSandbox flag set to false
App release with the SDK setup is live in the app stores
Web push set up and tested, if the journey uses it
Push opt-in rates known, so expected reach is realistic

Mobile messages (SMS / MMS / RCS)

Provider integrated, webhook created and channel configuration set up in production (Sinch, Twilio, Infobip or a custom provider)
Separate provider credentials and webhooks for each sandbox
“Verify SMS connection” test received on a real device
Sender numbers or short codes approved for each target country (check telecom registration rules with your provider)
Separate sender ID for transactional messages, since a STOP reply blocks all messages from that sender
Opt-out keywords (STOP and others) working end to end; default keywords re-entered if custom keywords were added

Telecom registration and footer requirements come from regulations, not AJO.

2. Data and identity checks

Schemas and events

Every field used in conditions or personalization exists in a profile-enabled schema and dataset in production
Fields fit the entry type: no Experience event field groups in journeys that start with Read Audience, Audience Qualification or a business event
Trigger events are streamed (batch-ingested events, Query Service inserts and internal AJO datasets cannot trigger a journey)
Trigger events use one person-based identity type, the same for every event in the journey; identity values checked for casing (email is case-sensitive)
Event payloads stay under the 64 KB limit (larger events are dropped)

Timing and audiences

A real production event reaches the profile and enters the journey; allow up to 5 minutes for the first action
Wait activity added if the journey reads a profile created moments earlier
Entry audience size checked and matches expectations (not zero, not the whole database)
Batch audience timing understood (evaluated once a day); Audience Qualification given up to 10 minutes to activate
Read Audience volume within limits (5 concurrent jobs per organization; up to 20,000 profiles per second per sandbox)
Null or empty rate checked for key personalization fields

Custom actions and data sources

Custom actions point to production HTTPS endpoints on default ports, using POST, GET or PUT with JSON payloads
Endpoints handle at least 200 TPS and the default capping (300,000 calls per minute; 150,000 per 30 seconds for endpoints slower than 0.75 seconds)
Failure response payload configured, and the journey’s error and timeout paths tested
Custom Action / Data source timeout set on purpose in journey properties
Endpoints accept Adobe’s mTLS client certificate rotation, if mTLS is used
Custom actions preferred over external data sources for external lookups; data source field groups kept small

Guardrails

Expected volume reviewed against Adobe’s current guardrails page: 5,000 inbound events per second per organization, 1 MB journey instance per profile, 50 activities per journey, 200 journeys per production sandbox (counting live, closed, paused and dry-run journeys)

3. Content and personalization checks

Copy and approvals

Final copy approved by marketing, brand and legal
Proof senders have the Manage Simulate Content and Approve and publish permissions
Subject lines and preheaders finalized; no test text such as “TEST” or “lorem ipsum”
Content check run with no open issues (unsupported elements, Outlook and Gmail rendering)

Personalization and proofs

Every personalization field uses the Default fallback value helper, or Insert with fallback text for string attributes
Proofs reviewed with at least three different test profiles, including one with missing data (proofs go to at most 10 recipients)
Event and context personalization tested inside the journey (previews and proofs show profile data only)
Test profiles not frequency-capped (a capped profile shows the proof as finished but nothing is delivered)

Rendering, links and images

Email rendering checked with Litmus via Simulate content (AEP profiles), on mobile and desktop, including dark mode theme variants
Email content under 1 MB (2 MB hard limit after processing)
All links work, point to production URLs and carry the right tracking parameters
Domains used in personalized URLs are on the approved-domains list
SMS subdomain set up if SMS links are shortened and tracked; deep links tested after Adobe’s tracking redirect
Images load from production hosting and have alt text

Fragments and languages

Shared fragments (header, footer, legal text) are the approved versions and published after their last edit; none in Draft status
Language and regional variants checked; each AEM Content Fragment language variant published (there is no automatic fallback)

Mobile messages and push

SMS body length checked for the longest personalized version (Adobe docs: SMS up to 160 characters, MMS up to 1,600); segment count checked (160 GSM-7 / 70 Unicode characters per segment)
Push messages tested on real iOS and Android devices (display limits come from Apple and Google)

4. Journey logic checks

Entry and journey properties

Entry type is correct (event-triggered, audience-based or business event) and matches the design doc
No batch audience used in Audience Qualification or Exit Criteria: since Sep ‘26, new, draft and duplicated journeys that do this cannot be published
Messages built with the current Action activity, not the deprecated per-channel activities
Re-entrance chosen on purpose: allowed or not, and the re-entrance wait period set for unitary journeys (default 5 minutes, maximum 90 days); same rule in every journey version
Journey time zone set (a fixed zone, or taken from the profile)
Start and end dates correct (events outside the active window are discarded without an error)
Properties final before publishing: most become read-only once live, and changes then need a new version

Paths and timing

Every condition branch leads somewhere, including the fallback path (profiles that fail every branch exit the journey)
Wait times correct in production (no shortened test waits left in); custom wait expressions have no Z suffix or explicit time zone offset
Custom Action / Data source timeout settings reviewed
Exit criteria set, so customers leave when they reach the goal (for example, after purchasing)
Long waits and slow custom actions reviewed against the 10 pending events per profile limit
Journey fits within 50 activities and the 91-day global timeout

Overlap and documentation

Overlap with other live journeys reviewed; journey rule sets (entry and concurrency capping) applied where needed
Journey and all assets follow the naming convention
Journey design doc matches what was actually built

5. Consent, governance and contact policy

Consent and message type

Marketing messages respect each profile’s consent and subscription status (unsubscribes are held in Experience Platform, not in the suppression list)
Transactional messages classified correctly and contain no marketing content; every marketing message has an opt-out link
If consent policies are used (they need the Healthcare Shield or Privacy and Security Shield add-on): marketing actions set on channel configurations and custom actions; “None” used only for essential transactional messages

Suppression

Suppression list reviewed for this sandbox (hard bounces and spam complaints immediately; soft bounces after retries)
Retry threshold left at the default of 5 unless the deliverability owner agrees (Adobe warns values above 10 can hurt reputation)
Any suppression list override on an email action (Limited Availability since Oct ‘26) approved in writing by legal or compliance

Business rules

Frequency capping reviewed: the Global Default Rule Set applies to all journeys and campaigns; custom rule sets activated and attached to each journey and campaign action that needs them
Quiet hours defined in a custom channel rule set; time zone chosen (one standard zone, or recipients’ local time, where profiles without a time zone value aren’t covered); queue-or-discard choice made
Overlap risk accepted: a profile entering two journeys within a short window may not have the cap applied correctly

Governance and legal

Data usage labels and policies don’t block the activation (they are checked on profile attributes at publish time)
Regional privacy requirements reviewed with legal (for example GDPR or CCPA, where they apply)
Approval workflow completed and recorded

6. Testing sign-off

Test mode (test profiles, real messages)

Journey test mode run for every path (up to 100 test profiles per session; events fired from the interface only; waits shortened, 10 seconds by default)
Split branches tested separately, because test mode always takes the top branch of a split
Edge cases tested: missing data, opted-out profile, multiple identities, re-entry
Opted-out test profiles confirmed to receive nothing

Dry run (production data, nothing sent)

Dry run used on the error-free draft to check how real profiles flow through the paths (channel and custom actions don’t run; waits and data sources are off by default; it returns to Draft after 14 days)
Dry run reports exported before stopping it (the data is not kept afterwards)

Final checks

Seed list or internal recipients set up to receive live sends
Custom action failure tested: the journey behaves safely when the external API is down
All defects closed or accepted in writing
Production promotion verified: what’s in prod matches what was tested

7. Launch day runbook

Confirm the launch window: a weekday morning when the whole team is available (not a Friday or the day before a holiday)
Check that the launch owner, technical support and business approver are online
Subscribe the team to system alerts in the production sandbox (subscriptions are per sandbox, and journey alerts fire only for live journeys)
Re-check the entry audience size and recent event flow
Publish the journey or campaign; record who published it and when
Confirm the seed list receives the first messages and that they render correctly
Watch the first entries in journey reporting (entrances show in real time; dashboard metrics can take up to 30 minutes to refresh)
Post a launch note to the team channel, with links to reports and the rollback plan

8. First 72 hours: monitoring and rollback

Monitor

Entries, exits and step progression in journey reports
Journey step events checked for error, capped and timedout statuses, and for discarded events
Message delivery confirmed in the Message Feedback Event dataset; custom action results checked in the Journey Step Event dataset (a successful HTTP call doesn’t prove the external system delivered)
Delivery, bounce, complaint and unsubscribe rates compared with your own baseline; suppression list growth watched
Customer service inbox and social channels watched for complaints
Downstream effects: landing pages, promo codes and inventory hold up under the traffic

Stop or roll back if any of these happen

Trigger	Action
Wrong audience is receiving messages	Pause or stop the journey immediately; assess who was contacted
Broken personalization or links	Pause or close, fix content, re-test, publish a new version
Bounce or complaint rate well above baseline	Pause sends; involve the deliverability owner
Custom action or external API failing	Stop or route around the failing step
Duplicate or conflicting messages	Stop; review re-entry settings and journey overlap

Choose the right way to stop:

Option	What happens	Use when
Pause	New entries are discarded; profiles already in are held or discarded at the next action	Fixing an issue you expect to resume from
Close to new entrances	No new entries; profiles already in finish their path	The journey is wrong for new customers but safe for those in progress
Stop	All processing ends immediately for everyone	Emergencies only

A closed or stopped journey cannot be restarted: fix it and publish a new version, or duplicate it. Set numeric thresholds for the triggers above from your own historical baseline before launch.

9. Sign-off

The journey goes live only when every role below has signed.

Role	Name	Date	Signed off
Business owner
AJO developer / builder
QA lead
Data / AEP owner
Deliverability owner
Legal / privacy

References

All references are Adobe Experience League documentation for Adobe Journey Optimizer.

Part of the AJO Implementation Playbook. Free to use and adapt. Not affiliated with or endorsed by Adobe. Adobe and Adobe Journey Optimizer are trademarks of Adobe Inc.