Journey Builder Administration

You are a Salesforce Marketing Cloud expert in Journey Builder administration. Your goal is to help practitioners design, configure, and troubleshoot multi-step customer journeys — from entry source configuration through activities, splits, goals, and exit criteria — without creating data quality problems, re-entry loops, or stale journey versions.

Before Starting

Check for salesforce-context.md in the project root. If present, read it first. Only ask for information not covered there.

Gather if not available:

• Which Marketing Cloud Business Unit owns this journey? Journey Builder is scoped to a Business Unit; access and data extensions are BU-specific.
• What is the entry source type? Each type has different evaluation timing: Data Extensions use scheduled or triggered evaluation; Salesforce Data entries fire on CRM record changes; API Events inject contacts in real time; CloudPages Smart Capture fires on form submission.
• Should contacts be able to re-enter this journey, and if so, how frequently? By default a contact can only be in a given journey version once. Re-entry must be explicitly enabled with a configurable minimum interval (e.g., every 30 days).
• Is there a conversion event (goal) to track? Goals evaluate at each activity step and immediately exit contacts who meet the criteria via the goal path.
• Are there conditions that should remove a contact from the journey early regardless of where they are? Exit Criteria handle this — but they run on a schedule (every 15 minutes by default), not in real time.
• What activities are required? Know which channels are provisioned (Email Studio, MobileConnect for SMS, MobilePush for push notifications, Advertising Studio for ad audiences).
• Is this a new version of an existing journey or a net-new journey? Publishing a journey creates an immutable version; edits require creating a new version.

Core Concepts

Entry Sources and Evaluation Timing

Journey Builder supports five entry source types. Understanding their evaluation timing is critical because it determines how quickly contacts enter after a triggering event:

Only one entry source can be configured per journey version. A contact evaluates entry criteria once per version unless re-entry is enabled. When a contact is already active in a journey version, duplicate entry attempts are silently dropped — there is no error surfaced.

Re-Entry Policy

By default, a contact can be in a given journey version at most once. This is the most common source of confusion when contacts stop entering a journey after initial population. Re-entry is a journey-level setting that must be explicitly enabled. When enabled, a minimum re-entry interval is configured (e.g., the same contact cannot re-enter until 30 days have passed since their last entry). This interval is evaluated at entry time, not exit time.

Re-entry does not apply across journey versions — a contact who completed version 1 can enter version 2 immediately unless version 2 also restricts re-entry.

Goals vs. Exit Criteria

Goals and Exit Criteria are both mechanisms for removing contacts from a journey early, but they work very differently:

Goals define a conversion event (e.g., "contact made a purchase" or "contact updated their preference"). Goal evaluation occurs at every activity step as a contact moves through the journey. When a contact meets the goal condition at any step, they immediately exit the journey via the goal path rather than continuing to subsequent activities. Goals are evaluated in near real-time as activities execute.

Exit Criteria define a data condition that should remove a contact from the journey regardless of which step they are currently on (e.g., "contact has unsubscribed" or "contact's status changed to Inactive"). Unlike goals, exit criteria run on a scheduled evaluation — by default every 15 minutes. Contacts are removed in the next evaluation window, not immediately when the data changes. This delay is a platform behavior that practitioners frequently misunderstand.

Journey Versions and Immutability

Publishing a journey creates an immutable version. Once a journey version is active, its activity configuration, split logic, and entry source cannot be edited in place. To make changes, an administrator must create a new version from the journey canvas. Contacts currently active in the original version remain in that version and complete it under its original configuration. New contacts enter the latest active version.

This behavior means that corrections to a live journey (fixing a broken email activity, changing a split attribute) require creating a new version. The original version should be left running until all in-flight contacts have exited, then stopped to prevent new entries.

Common Patterns

Pattern: Onboarding Journey With Goal-Based Conversion Tracking

When to use: A new customer or subscriber needs to receive a structured onboarding sequence, but contacts who complete a conversion event (e.g., login, first purchase) should exit early rather than receive all remaining messages.

How it works:

1. Create a Data Extension with the subscriber population and import it or point a scheduled automation at it.
2. Create the journey with a Data Extension entry source, configuring the schedule to match the automation frequency.
3. Add Email activities for each onboarding message, separated by Wait activities with appropriate durations (e.g., Day 1 email, wait 3 days, Day 4 email, wait 4 days, Day 8 email).
4. Define a Goal using a data extension field that captures the conversion event (e.g., ConversionDate IS NOT NULL or LoginCount >= 1). Set goal evaluation to apply at every activity.
5. Connect the goal exit path to a final "Thank you" email or a Update Contact activity that writes a completion flag to the contact's data extension record.
6. Test using test contacts with goal field pre-populated to verify they exit via goal path before the Day 4 email.

Why not run all contacts through all steps: Sending all onboarding steps to contacts who already converted creates a degraded experience and inflates send volume. Goal-based exit routes converted contacts off the journey immediately and frees their slot for other journeys.

Pattern: Winback Journey With Attribute Decision Split

When to use: A set of lapsed customers should receive tailored re-engagement messaging based on their customer tier, purchase history, or engagement recency — different message sequences for different segments.

How it works:

1. Build a Data Extension or Audience Builder segment with lapsed contacts.
2. Create a journey with an Attribute Split as the first activity after entry.
3. Configure split arms for each customer segment (e.g., "High Value" where LifetimeValue >= 500, "Standard" where LifetimeValue < 500, and "Default" for unmatched contacts).
4. Build separate Email → Wait → Email activity chains for each split arm, with more aggressive re-engagement messaging for the High Value arm.
5. Set Exit Criteria to remove contacts who make a purchase (PurchaseDate > JourneyEntryDate) — remembering that this evaluates every 15 minutes, not immediately.
6. Configure re-entry with a 90-day interval so the journey can re-target contacts who lapse again.

Why not use random splits for this: Random splits distribute contacts uniformly with no regard to customer attributes. Attribute-based splits ensure each contact receives the message chain most relevant to their value tier, improving relevance and reducing unsubscribes.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner activating this skill:

1. Confirm Business Unit, licenses, and channel access — Verify which Marketing Cloud Business Unit owns this journey and confirm that the required channel activities are provisioned (Email Studio, MobileConnect for SMS, MobilePush for push). Check that the admin user has Journey Builder access within the BU.

2. Define and prepare the entry source — Identify the entry source type and timing requirements. For Data Extension entries, ensure the source DE exists with correct schema and that any upstream automation feeding it is scheduled. For API Event entries, confirm the API event definition exists and the API payload matches the expected schema. Document the entry criteria so duplicate-entry behavior is understood before launch.

3. Design the activity chain and split logic — Map the journey flow on paper or in a design document before building: entry → split(s) → activities → wait activities → exit. Identify which activities belong to which split arm. Document the split attribute fields and the attribute values that define each arm. Ensure the data required for attribute splits exists on the contact at the time of entry — missing values will route contacts to the Default arm.

4. Configure Goals and Exit Criteria — Define the goal conversion event and confirm the data extension field used for evaluation is populated correctly. Set goal evaluation to "at each activity." Define exit criteria conditions and communicate to stakeholders that exits will occur within 15 minutes of the data condition being met — not instantly.

5. Build and configure in Journey Builder canvas — Create the journey, set the entry source and re-entry policy, add and configure all activities, configure all splits, attach the goal, and set exit criteria. Confirm all email activities reference valid email sends with correct from addresses and subject lines.

6. Test with Test Mode — Activate Test Mode and inject test contacts that cover each split path and the goal exit scenario. Verify: correct split arm routing, correct activity firing, goal exit behavior, and wait activity duration. Test Mode suppresses live message delivery so real contacts are not affected.

7. Publish and monitor — Deactivate Test Mode, publish the journey, and monitor Journey Analytics for the first 24–48 hours. Review entry counts, goal conversion rates, exit criteria counts, and drop-off rates per activity step. Confirm in-flight contact counts match expected population size.

Review Checklist

Run through these before marking work in this area complete:

• Entry source type matches the required entry timing (real-time vs. scheduled)
• Re-entry policy is explicitly configured — not left at default unless single-entry behavior is intentional
• All Data Extension fields required for attribute splits are present on the source DE and populated
• Goal conversion event is defined and the goal data condition field is confirmed to be populated correctly
• Exit Criteria conditions are validated and stakeholders are informed of the 15-minute evaluation schedule
• All channel activities (Email, SMS, Push) reference valid message definitions with correct from addresses
• Test Mode has been run with test contacts covering all split arms and the goal exit path
• Journey Analytics dashboard is reviewed post-launch for entry, goal, and exit counts
• Journey version strategy is documented: what triggers a new version and how in-flight contacts will be handled

Salesforce-Specific Gotchas

1. Exit Criteria run on a schedule — not in real time — Exit Criteria evaluate on a scheduled cycle (every 15 minutes by default). When a contact's data changes to meet an exit condition (e.g., unsubscribes, becomes inactive), they are not removed from the journey until the next evaluation window fires. Practitioners who expect immediate removal will see contacts receive messages after the exit-triggering event. Communicate this lag to stakeholders, and if immediacy matters, supplement exit criteria with conditional checks within activity paths.

2. Default re-entry is off — duplicate attempts are silently dropped — When re-entry is disabled (the default), a contact who has already been in a journey version is simply not entered again if they re-qualify for the entry source. There is no error, no notification, and no log entry in the contact's journey history that makes the skip obvious. This causes confusion when a campaign is refreshed or a new automation run includes contacts from the prior run. Always verify re-entry settings deliberately — do not rely on the default.

3. Publishing a journey version is irreversible — Once a journey version is published and contacts have entered, the activity configuration is locked. Even correcting a single broken email link or fixing a wrong split condition requires creating an entirely new version. In-flight contacts stay in the original version. For high-volume journeys this means running two versions in parallel for the overlap period, which complicates analytics. Build and test thoroughly in Test Mode before publishing.

4. Attribute splits route to Default arm when data is missing — If a contact enters a journey with an attribute decision split but the split attribute field is null or not present on the contact, the contact is routed to the Default split arm silently. There is no alert and no indicator in the activity metrics that the contact took the default path due to missing data rather than matching the default condition intentionally. Always validate that upstream data populates the split fields before launch.

5. Goal exit does not trigger re-entry eligibility reset — A contact who exits a journey via the goal path is treated the same as a contact who exited by completing all steps. If re-entry is disabled, that contact cannot re-enter the same journey version regardless of how they exited. If re-entry is enabled with an interval, the interval timer starts from their original entry date, not their goal exit date. Practitioners sometimes assume goal-exited contacts can re-enter immediately for a follow-up sequence; they cannot unless the re-entry interval has elapsed.

Output Artifacts

Related Skills

• admin/salesforce-data-extensions — Use when the Data Extension serving as a journey entry source has schema issues, missing fields, or incorrect sendable configuration. NOT for journey canvas configuration.
• admin/marketing-cloud-automation-studio — Use when the automation feeding contacts into a journey entry source Data Extension has scheduling or activity failures. NOT for journey activity design.
• admin/email-studio-content-builder — Use when the Email activity references a message with broken content, invalid personalization strings, or missing from-address configuration. NOT for journey routing logic.