> For the complete documentation index, see [llms.txt](https://user.netmera.com/netmera-user-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://user.netmera.com/netmera-user-guide/omnichannel-engagement/journey-orchestration/journey-components/action/journey-trigger.md).

# Journey trigger

Journey Trigger connects journeys so you can build a customer experience from multiple reusable journey flows.

A customer experience does not always need to live in a single journey. Different parts of the experience may have their own logic, goals, timing, and data requirements. With Journey Trigger, you can separate these parts into individual journeys and connect them when one stage needs to start another.

A journey can **trigger another journey**, pass the information that journey needs, and continue the overall experience across multiple journey layers.

This makes Journey Trigger useful for building **modular and reusable journey systems**.

### Connect multiple stages of an experience

A complex experience can be divided into separate journeys, with each journey responsible for one stage. For example, an application experience can be organized as:

**Application** → **Document Collection** → **Verification** → **Activation**

The Application journey can trigger Document Collection after approval. Document Collection can then trigger Verification after the required documents are completed. Verification can trigger Activation after verification is successful.

Each journey remains independently configurable while the connected journeys work together as one larger experience.

#### Reuse the same journey in different experiences

A single target journey can be triggered by multiple source journeys.

For example:

<table><thead><tr><th width="128.30078125">Source journey</th><th width="155.6953125">Trigger point</th><th>Target journey</th><th width="158.80078125">Trigger point</th><th>Target Journey</th></tr></thead><tbody><tr><td><strong>Loan Application</strong></td><td>Application approved</td><td><strong>Document Collection</strong></td><td>Documentation approved</td><td><strong>Onboarding</strong></td></tr><tr><td><strong>Card Application</strong></td><td>Application approved</td><td><strong>Document Collection</strong></td><td>Documentation approved</td><td><strong>Onboarding</strong></td></tr><tr><td><strong>Account Upgrade</strong></td><td>Application approved</td><td><strong>Document Collection</strong></td><td>Documentation approved</td><td><strong>Onboarding</strong></td></tr></tbody></table>

Instead of creating separate flows, create journeys once and reuse it wherever the same process is required.

### How Journey Trigger works

Journey Trigger connects two journeys:

<table><thead><tr><th width="183.1640625">Component</th><th>What it means</th></tr></thead><tbody><tr><td><strong>Source journey</strong></td><td>The journey where the Journey Trigger action is placed. It determines when the target journey should be triggered.</td></tr><tr><td><strong>Target journey</strong></td><td>The journey that Netmera attempts to enroll the user in.</td></tr><tr><td><strong>Caller Context</strong></td><td>Information that the source journey passes to the target journey so it can use data already available earlier in the experience.</td></tr></tbody></table>

The source journey determines **when** to start the next journey.

The target journey determines **what happens next**.

Caller Context determines **what information is available to the target**.

For example, a source journey may approve an application and trigger a Document Collection journey. The source can pass the application's ID to the target, allowing Document Collection to work with the correct application without asking the user for the ID again.

### Build journeys as a system

Journey Trigger is not limited to connecting two journeys.

A target journey can also trigger another journey. This allows you to create multiple layers of connected journeys.

For example:

**Application**\
→ **Document Collection**\
→ **Verification**\
→ **Activation**

Here, Document Collection is both:

* a **target** because Application triggers it, and
* a **source** because it can trigger Verification.

This pattern allows each journey to focus on a specific responsibility while still being part of the same customer experience.

#### Example: Application lifecycle

Consider an application process with four stages:

<table><thead><tr><th width="191.2421875">Journey</th><th>Responsibility</th><th>Trigger condition</th></tr></thead><tbody><tr><td><strong>Application</strong></td><td>Manages the application process</td><td>Starting point</td></tr><tr><td><strong>Document Collection</strong></td><td>Collects required documents</td><td>Application is approved</td></tr><tr><td><strong>Verification</strong></td><td>Verifies submitted information</td><td>Documents are completed</td></tr><tr><td><strong>Activation</strong></td><td>Activates the approved service</td><td>Verification is completed</td></tr></tbody></table>

Each stage can be developed and maintained independently.

If the document-collection process is also required by another application type, the same **Document Collection** journey can be reused as the target of that journey.

This creates a journey system rather than a collection of isolated journeys.

### Before you configure Journey Trigger

The target journey needs to be prepared to receive users from another journey.

The following conditions must be met:

<table><thead><tr><th width="171.73046875">Requirement</th><th>Description</th></tr></thead><tbody><tr><td><strong>Journey type</strong></td><td>The target must be an <strong>Action Based</strong> journey.</td></tr><tr><td><strong>Entry event</strong></td><td>The target must use <strong>Journey Trigger</strong> as its entry event.</td></tr><tr><td><strong>Status</strong></td><td>The target must be <strong>Active</strong> when the trigger runs.</td></tr><tr><td><strong>Self-triggering</strong></td><td>A journey cannot trigger itself.</td></tr></tbody></table>

Only active Action Based journeys that use Journey Trigger as their entry event are available as target journeys.

If you plan to use Caller Context, also determine which information the target journey needs from its source.

> **Important:** Configure and launch the target journey before selecting it from the source journey.

### Step 1: Prepare the target journey

Create or open the journey that should receive users.

1. In **Entry Rules**, select **Action Based**.
2. In **Select Event**, select **Journey Trigger**.
3. Configure the journey's steps and conditions.
4. Launch the journey.

The target must be **Active** when the source journey reaches its Journey Trigger action.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FNh5cZBNMOzpKrnZKagaq%2Fimage.png?alt=media&amp;token=62111286-7ab2-4730-b76f-9b744d5edc3e" alt="Target journey entry rules configured for Journey Trigger" width="557"><figcaption><p>Configure the target journey with the <strong>Journey Trigger</strong> entry event.</p></figcaption></figure>

### Step 2: Add Journey Trigger to the source journey

Open the journey that should initiate the target journey.

1. Select **Build**.
2. Select **Add Step** at the point where the target journey should start.
3. Under **Action**, select **Journey Trigger**.
4. Open the Journey Trigger step.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2Fn7WF6TEDCTUPlsKbrpDm%2Fimage.png?alt=media&amp;token=5ac1f20e-23c6-4816-8970-0b3d185ad13e" alt="Journey Trigger action in the journey builder" width="288"><figcaption><p>Select <strong>Journey Trigger</strong> from the Action section.</p></figcaption></figure>

Place the action at the point that represents the transition to the next part of the customer experience. For example, if Document Collection should begin only after an application is approved, place Journey Trigger immediately after the approval step.

### Step 3: Select the target journey

1. Enter a **Step Name**.
2. In **Target Journey**, select the journey that should receive the user.
3. Review the target journey's status.
4. Select **Apply**.

The target journey list displays the status of available journeys, such as **Active**, **Paused**, or **Draft**.

Select an **Active** journey configured with **Journey Trigger** as its entry event.

> **Example:** If the current journey is Loan Application and the next stage should collect documents, select Document Collection as the target journey.

<figure><img src="https://1642824329-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FX6uilbEAw42gqsudlclY%2Fuploads%2FBXiSOLjmmxma6r3Zb5IW%2Fimage.png?alt=media&amp;token=80ab4a6f-dc1f-4a23-9aea-6b13220c4d51" alt="Journey Trigger target journey selection" width="375"><figcaption><p>Select a target journey and review its status.</p></figcaption></figure>

### Step 4: Configure Caller Context

A target journey often needs information that was already collected or generated in the source journey.

**Caller Context** allows the source journey to pass this information to the target. For example, the Application journey may already have an application ID:

**Application journey**

`applicationId = 12345`

When the journey triggers Document Collection, it can pass the application ID.

**Document Collection journey**

`${caller.applicationId}`

The target can then use the application ID in supported expression fields without asking the user for it again. This becomes particularly useful when journeys are connected across multiple layers.

Each Caller Context row defines one value that the target journey can access.

<table><thead><tr><th width="118.12109375">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Name</strong></td><td>The name used to reference the value in the target journey.</td></tr><tr><td><strong>Source</strong></td><td>Determines where the value comes from: <strong>User</strong>, <strong>Journey</strong>, <strong>Caller</strong>, or <strong>Constant</strong>.</td></tr><tr><td><strong>Value</strong></td><td>The specific profile attribute, journey variable, caller value, or fixed value to pass.</td></tr><tr><td><strong>Data Type</strong></td><td>Defines the data type of a <strong>Constant</strong> value.</td></tr></tbody></table>

The name becomes part of the expression used by the target journey.

For example, if the Name is `applicationId`, the target can reference the value as `${caller.applicationId}`.

#### Choose a value source

#### User

Use **User** when the value comes from the user's profile.

**Example:** A customer type stored as a user attribute.

#### Journey

Use **Journey** when the value comes from the current source journey.

This is useful for information collected or calculated during the journey.

**Example:** An `applicationId` journey variable.

#### Caller

Use **Caller** when the value was previously passed into the current journey. This is particularly useful for multi-layered journey systems. For example:

**Application** passes `applicationId` → **Document Collection**

Document Collection can pass that same value → **Verification**

The context can therefore continue through multiple journey layers.

#### Constant

Use **Constant** when every user should receive the same fixed value. For example, a Document Collection journey could receive a fixed `documentType` value.

**Data Type** is required when **Constant** is selected.

#### Pass context through multiple journeys

Consider this journey system:

**Application** → **Document Collection** → **Verification**

The Application journey has an `applicationId`.

**Application → Document Collection**

Configure Caller Context with:

<table><thead><tr><th width="171.5859375">Name</th><th width="147.4921875">Source</th><th>Value</th></tr></thead><tbody><tr><td><code>applicationId</code></td><td><strong>Journey</strong></td><td>The application ID journey variable</td></tr></tbody></table>

Document Collection can access the value as `${caller.applicationId}`.

**Document Collection → Verification**

If Verification also needs the application ID, Document Collection can pass the value it received using the **Caller** source.

| Name            | Source     | Value                                                 |
| --------------- | ---------- | ----------------------------------------------------- |
| `applicationId` | **Caller** | The application ID received from the previous journey |

Verification can then access the value using `${caller.applicationId}`. This allows the same piece of context to travel through multiple journey layers.

> **Tip:** Keep Caller Context focused on information the target actually needs. Treat the values passed between journeys as part of the target journey's expected input.

### What happens when Journey Trigger runs?

When an eligible user reaches a Journey Trigger action, Netmera attempts to enroll the user in the selected target journey.

The process is:

1. The user reaches the Journey Trigger action in the source journey.
2. Netmera identifies the configured target journey.
3. Netmera attempts to enroll the user in that target journey.
4. Any configured Caller Context values are passed to the target.
5. The target journey starts according to its own configuration.

The target journey then operates independently according to its own steps, conditions, timing, and configuration.

If the target journey is also configured with Journey Trigger, it can trigger another journey and continue the overall experience.

> **Journey Trigger connects journeys; it does not turn multiple journeys into one journey.** Each journey remains independently configured and managed.

### Monitor Journey Trigger

Use Journey Trigger statistics to understand whether the connection between the source and target journeys is working as expected.

Select the **statistics** icon to view:

<table><thead><tr><th width="174.01953125">Metric</th><th>Description</th></tr></thead><tbody><tr><td><strong>Entry Count</strong></td><td>Number of users who reached the Journey Trigger step.</td></tr><tr><td><strong>Triggered Count</strong></td><td>Number of successful target journey triggers.</td></tr><tr><td><strong>Failed Count</strong></td><td>Number of unsuccessful trigger attempts.</td></tr><tr><td><strong>Target Journey</strong></td><td>The journey currently configured as the target.</td></tr></tbody></table>

#### Example

If the statistics show:

<table><thead><tr><th width="368.9921875">Metric</th><th align="right">Count</th></tr></thead><tbody><tr><td><strong>Entry Count</strong></td><td align="right">1,000</td></tr><tr><td><strong>Triggered Count</strong></td><td align="right">950</td></tr><tr><td><strong>Failed Count</strong></td><td align="right">50</td></tr></tbody></table>

This means 1,000 users reached the Journey Trigger action, and Netmera successfully triggered the target journey for 950 users. The difference indicates that 50 trigger attempts were unsuccessful.

For a multi-layered journey system, monitor each Journey Trigger connection separately to identify where a failure occurs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://user.netmera.com/netmera-user-guide/omnichannel-engagement/journey-orchestration/journey-components/action/journey-trigger.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.