How to Create Your First User Journey in EngageLab MA
To create your first user journey in EngageLab MA, define your audience, connect the journey components, configure a message, and test the flow before launch. A user journey turns these rules into an automated messaging workflow.
This guide uses one example: sending a welcome email that directs eligible new users to your product’s getting-started page. You will build the flow, check it with controlled test accounts, and prepare it for your intended audience.
Jump to the preparation checklist, creation steps, or testing instructions.
Before You Start: Define the Audience, Goal, and Required Setup
For this example, the audience is identified new users eligible to receive your welcome email. The message has one purpose: help them find where to get started.
Check these items before opening the journey canvas:
| What you need | Where to check or what to prepare |
|---|---|
| An MA project with the required access | Confirm that you can create journeys and use the Email channel. Ask your project administrator if access is missing. |
| Usable user profiles | Check that profiles contain a user identifier, an attribute identifying new users, and an email address in the field your channel uses. Resolve missing data first. |
| Audience and entry rules | Define who qualifies, when they should enter, and how you will prevent unintended repeat welcomes. |
| An enabled Email channel | Verify the sender, verified sending domain, and contact-field mapping. Complete any missing channel setup first. |
| A welcome message and destination | Prepare a subject, short message, and one link to a working getting-started page. |
| Controlled test accounts | Prepare one qualifying new user and one existing user who should be excluded. Use inboxes you can access. |
If your journey uses email, configure the Email channel before setting up the message.
If the user records do not match your expectations, verify your user identifiers and tracking data in CDP before building the audience.
Create Your First Journey: A Welcome Email Example
The flow contains three components: Entrance → Email → Exit. It uses existing user data to identify eligible recipients.
1. Create a blank journey
Open the journey list in your MA project, select User Journey→Create your first journey, and choose a template or start from scratch. Name it First Journey - Welcome Email - Test so you can distinguish it from a later production version.

Locate the Entrance and Exit components. Add an Email message component between them.
2. Define the audience and review entry behavior
In the Entrance component, select the user attribute that identifies your new-user audience. An illustrative condition is onboarding_status = new.
This is an example custom attribute, not a built-in EngageLab field. Replace it with a field and value that already exist in your project, and apply your contact eligibility rules.
For the test version, add a restriction covering only your designated test identities. Combine that restriction with the business criteria using AND: users must belong to the test group and meet the new-user conditions.

Review when qualifying users actually enter, whether users already matching the criteria are included at launch, and whether repeat entry is possible. Matching an attribute does not by itself establish an immediate signup trigger. Decide how repeat welcomes will be prevented; message-frequency limits alone do not establish a one-time welcome.
3. Configure the welcome email
Select your enabled Email channel and the welcome message template. You may need to creat a template first.
→Go to the documentation to learn how to create an email template.
Check the sender details and confirm that the channel’s contact field contains the intended recipient’s address.
Keep the message focused. For example:
Subject: Welcome to [Product] — start here
Body: Welcome to [Product]. Our getting-started guide will walk you through your first setup. Open it whenever you’re ready to begin.
Button: Open the getting-started guide
Replace [Product] and link the button to your actual getting-started page. Preview the content and open the destination to check that it works for a new user.
4. Connect the components and save a draft
Connect Entrance to Email, then Email to Exit. Check that the journey has exactly one entrance, one exit, and a complete path through the message component. Save the journey as a draft.
At this point, the canvas should show the intended route and the Email component should have its required settings. Saving a draft is a configuration checkpoint; it does not verify that a message has been delivered.
Test the Journey with a Small, Controlled Audience
Keep the new-user criteria in place while testing. Replacing them with a single test ID would leave the business audience rule untested.
Confirm the execution method supported in your console. If running the flow requires publishing, publish only the version restricted to your test identities; this can send real messages.
Include these cases in that restricted group:
| Test account | Expected result |
|---|---|
| A: new user with a valid email address | Qualifies, enters according to the configured start behavior, and receives the intended welcome email. |
| B: existing user with a valid email address | Fails the new-user condition and receives no welcome email from this journey. |
| C: new user missing the selected email contact field | Cannot receive the email at that missing address. Inspect whether filtering or sending rejects the record; do not count it as a successful delivery. |
After starting the restricted flow, check the result at three levels:
- Journey: Open its statistics and review participation and completion. Repeat entries can increase the participant count, so do not assume it represents unique people.
- Message: Inspect the Email component’s sending records, including the target identifier, status, and sending time. Match the records to your test accounts.
- Inbox and destination: Confirm that account A receives the correct email and that its link opens the intended page. Confirm that B receives no message from this flow.
The journey analysis documentation explains where to find these statistics and records.
If A receives nothing, check its recorded attributes, entry behavior, contact-field mapping, and channel status. If B receives the message, revisit the audience conditions and their AND/OR relationship before launching more widely.
A sent message, a received email, and a completed journey are different checks. None alone proves that a user completed product onboarding.
Check and Publish the Journey
Before publishing, follow the steps to test your user journey.
Prepare a separate production draft using the validated flow. Duplicate the test version if your console supports it, or recreate the same configuration. Replace the test-only restriction with the intended audience scope, while preserving the new-user and contact eligibility rules.
For the final review, confirm that:
- The audience includes the intended new users and excludes existing users.
- Entry timing and repeat-entry behavior match your rollout plan.
- The Email channel, sender, template, contact field, and destination are correct.
- Every component is connected, and the controlled tests passed.
- The test version and any existing welcome journeys will not cause unintended duplicate messages.
Before launch, review frequency-control settings for your journey messages.
Select Publish, resolve any validation errors, and monitor the first sending records. An active journey cannot be edited directly, so review the production draft carefully before launch.
Next Steps After Your First Journey
Once the welcome flow behaves as expected, choose one improvement based on what users need next. That might be a follow-up message or a path based on a verified user action. Add and test one change at a time.
Explore Workflow Templates for ideas you can adapt to your audience, available data, and messaging goal.
FAQs
- What should I prepare before creating my first journey?
- Can I edit a journey after it is published?
