Overview

Annex Cloud's User Journey feature provides a comprehensive framework for designing and managing customer engagement paths within your loyalty ecosystem. It enables businesses to create, monitor, and optimize how members interact with the platform over time, driving deeper engagement and sustained loyalty.

This guide walks you through the complete process of creating a User Journey in the platform. A journey defines the sequence of actions or events that a member must take - such as completing specific tasks or meeting conditions—to earn rewards or badges.

As a user, you can configure:

• Entry criteria to determine which members qualify for a journey,
• Tracked actions that members must perform, and
• Outcome triggers such as issuing rewards or awarding badges.

With this structured setup, you can craft personalized, event-driven experiences that recognize and incentivize member behaviors in real time.

Navigation: Products > User Journey

Journey Canvas and Interaction

The journey canvas enables:

• Drag-and-drop functionality for building journey flows.
• Custom rule sets for different Nodes.
• Interactive elements like System and API events, loyalty actions, conditions to define user paths.
• Flow Controls: Ensuring minimal logic within each block while maintaining journey flexibility.

Step 1: Set the Journey 

Click the three-dot menu next to User Journey in the top-left corner and in the pop-up window, enter the required details to configure your journey.

1. Name: The title assigned to the specific user journey for easy identification.
2. Description: A brief summary describing the objective and expected outcome of the user journey.
3. Start Date: The date on which the user journey begins tracking member interactions.
4. End Date: The date on which the user journey ends tracking events.
5. Set Attribute: Click the +Set Attribute button above to add one or more attributes.

• Drag the entry node onto the canvas—this serves as the starting point of the journey.
  Click on the node to open its configuration panel and add additional details as required.
  

  

• Locate the label field at the top right of the journey configuration page.
• Enter a meaningful name that helps you identify the purpose of the journey.
  • Example: Demo User Journey

This label is intended for internal use only. It is included in API responses but is not visible to members.

Step 2: Configure the Entry Type

Decide how members can enter the journey.

• Click on the "Entry Type" dropdown.
• You’ll see two options:
  
  • Open-Ended
  • Conditional

Open-Ended Entry

• This allows any member to participate without restrictions.
• Use this if the journey should be available to all members at any time.
• Example: A welcome journey for new signups.

Conditional Entry

Conditional Entry allows you to control whether a member is eligible to enter and complete a journey based on predefined criteria. Enable this option if you want to restrict participation using conditions such as Start Eligibility, Progress Restriction, and Frequency Criteria.

• Start Eligibility: 
  This feature specifies the days a member can participate in the journey from the opt-in date. For example, if you enter 10:
  • Members who opt in within 10 days can participate in the journey.
  • The opt-in date must be within 10 days when participating in the journey, not the journey start date.
  • Once a member participates in the journey, they can complete the journey before it ends without restrictions.
  • Example: Journey Details
    • Start Date = Jan 1, 2025
    • End Date = Mar 31, 2025
    • The member opt-in date is Feb 1, 2025
    • The member would be able to participate in the journey within 10 days from the opt-in date, which is Feb 10, 2025
    • On Feb 11, 2025, even if the member performs the action/event, the journey will not progress.
    • Once the member starts the journey on/before Feb 10, 2025, the member can complete it by Mar 31, 2025, before the journey ends.
       

• Progress Restriction: 
  This feature sets the days a member must finish the journey from the opt-in date. For example, if you enter 10:
  • Members must complete the journey within 10 days of opting in.
  • If a member partially completes the journey, they cannot progress after 10 days from opt-in.
  • The journey status for that member will be abandoned.
  • Progress restriction must be equal to or greater than the start eligibility days.
  • Example: Journey Details
    • Start Date = Jan 1, 2025
    • End Date = Mar 31, 2025
    • The member opt-in date is Feb 1, 2025
    • The member should participate in the journey and complete it within 10 days from the opt-in date, which is Feb 10, 2025
    • On Feb 11, 2025 even if the member performs the action/event, the journey will not progress.
    • If the member starts the Journey Feb 4, 2025, but fails to complete it by Feb 10, 2025, the member won't be able to complete it after 10th. The journey status will become abandoned on Feb 11, 2025
      
       
• Frequency Criteria 

        This feature sets how often a member can participate and complete the journey within a set duration. For example, if you set 2 per month:

• A member can participate and complete the journey twice per calendar month.
• If a member completes it twice, two journey entries appear for them.
• If a member partially completes the journey, it will be abandoned the next month, and they must restart from the first event.
• Details like frequency, duration, and status are available in the API.

Note: Under the frequency criteria, set the duration to DAY, WEEK, MONTH, QUARTER, or YEAR, as shown below:

• Example: Journey Details
  • Start Date = Jan 1, 2025
  • End Date = Mar 31, 2025
  • A member will be able to participate and can complete a journey twice in each calendar month.
  • January two times, February two times, March two times.
  • A separate entry will be displayed on each journey completion.
  • If a member completes the journey first time in January and partially completes second time in the same month, the partially completed journey will be abandoned in February.
  • A member will have to start the journey from the beginning in February. 

Details

• Allow members who are part of the specified segments.
  • The segments may have their own rules and conditions set.
  • The system should check if the member belongs to the segment.
  • If yes, the member will be eligible for the journey when the member performs the actions and events based on the journey configurations.
  • Multiple segments can be configured as entry conditions with AND/OR conditions.

Journey Progression

• Entry conditions will be checked and validated only once when the member starts the journey.
• Once the member progresses in the journey, and if the member is removed from the specified segment, the member will continue on the journey progressions.
• The system will not evaluate the entry condition every time the member progresses in the journey.

Step 3: Add Loyalty Actions

Loyalty actions are member behaviors that trigger journey progression. You can optionally limit each action to a specific date range by setting an action window.

To add a loyalty action:

1. From the User Events section in the left-hand panel, drag the Loyalty Actions node onto the canvas and connect it to the preceding node (for example, the Entry node).
2. Click the node to open the Loyalty Actions configuration panel.
3. In the Label field, enter a name to identify this step internally. The label appears on the node in the canvas. Example: Action
4. Click Choose Loyalty Action to open the list of available actions.
5. Select an action from the dropdown. Each action is shown with its Action ID in brackets. Example: Issuance Purchase (174)
6. (Optional) Turn on Set Action Window to define a start and end date for this action. See Set an Action Window below.

These actions are what the system tracks when members engage with your platform. When a member performs the selected action, the system checks whether they qualify to progress in the journey or receive rewards.

To remove the loyalty action from the journey, click Remove Node.

Set an Action Window (Optional)

The Set Action Window toggle lets you define the period during which the selected loyalty action is valid for this node. Use it when an action should count toward the journey only during a specific campaign or promotional period, instead of for the full duration of the journey.

By default, the toggle is off and the action has no date restriction at the node level.

To set an action window:

1. In the Loyalty Actions configuration panel, turn on the Set Action Window toggle. The Start Date and End Date fields appear.
2. In the Start Date field, click the calendar icon and select the date from which the action becomes valid.
3. In the End Date field, click the calendar icon and select the date after which the action is no longer valid.

Dates are displayed in YYYY-MM-DD format (for example, 2026-10-23).

 

Field	Description	Example
Set Action Window	Toggle to enable or disable a date range for this action.	On
Start Date	The date from which the member's action counts toward this node.	2026-10-23
End Date	The date until which the member's action counts toward this node.	2026-10-23

Note: At least one date (Start Date or End Date) must be selected when Set Action Window is turned on. The Start Date and End Date can be the same date to limit the action to a single day.

 

Action Window Validation Rules

The configuration panel validates the dates as you enter them. If a rule isn't met, the affected fields are highlighted in red and an error message appears.

Condition	Error message	How to resolve
Set Action Window is on, but neither date is selected	At least one date must be selected.	Select a Start Date, an End Date, or both, or turn off the toggle.
Start Date is later than End Date	Start date cannot be after end date.	Select a Start Date on or before the End Date.
End Date is earlier than Start Date	End date cannot be before start date.	Select an End Date on or after the Start Date.

No date selected: both date fields are highlighted, and the error appears below the toggle.

Start Date after End Date: an error appears under each date field.

 

 

Step 4: Configure Rewards and Rewards Group (Optional)

Rewards are automatically issued to members when specific journey conditions are met.

• Navigate to the Rewards section.
• In the label field, type a name for internal use.
  • Example: Reward 1 
• Click on “Choose Reward” and select a reward from your available options.
  • Example: $10 off discount. 

Once configured, the platform will issue the reward automatically when a member reaches the defined stage in the journey.

2.  Configure Rewards Group

The Reward Group Node allows you to offer multiple reward options within a journey, letting members choose the reward(s) that are most valuable to them. This increases engagement by personalizing the experience and allowing users more control over their incentives. 

How It Works:  Reward Group allows you to add one or more rewards to the group. There is no restriction on adding a reward to a single group. When the member progresses through the journey and completes the required actions or events configured before the Reward Group, they will be able to choose reward(s) from the group.

You can also specify how many rewards a member can choose by setting the selection number. Once the member selects the reward(s), they will automatically move to the next node in the journey.

Steps to Configure the Reward Group Node:

1. Navigate to your Journey

• Go to the Journeys section in the platform.
• Open an existing journey or create a new one.

2. Add the Reward Group Node

• From the left-hand panel, drag and drop the Reward Group Node into your journey canvas at the appropriate stage.

3. Enter a Label

• In the Label field, provide a descriptive name to identify the reward group.
• Example: “Reward Group – Tier 1 Completion”

4. Set the Reward Count: In the Reward Count field, define how many rewards a member can select from the group.

5. Add Reward Options to the Reward Group

• Click Choose Rewards to select from your available reward inventory.
• Add as many rewards as needed to the reward group, ensuring that each reward is active and available for use.

6. (Optional) Add Multiple Reward Groups

• If needed, you can add multiple Reward Selection Nodes throughout a journey.
• You may reuse the same reward across different groups or nodes.

3. Configure Rewards Hold Days

This feature lets you place rewards on hold for a specified number of days after a member makes a purchase. To use this functionality, enable the “Set Additional Rules” option.

Once enabled, configure the following:

1. Number of hold days: Enter how many days the reward points should remain on hold after the member completes an action. The hold period begins on the same day the reward is earned.
   Example: If you set the hold period to 2 days, the reward will be credited only after two days from the date it was earned.
2. Blocking Events: Select an event from the dropdown list. If the member performs the selected event within the hold period, the reward will be permanently blocked.
   Example: If “Return” is selected and the member returns a product within the hold period, they will lose eligibility for that reward permanently and it cannot be used in the future.

Step 5: Add a Badge (Optional)

• Scroll to the Badges section.
• Provide a label to name this badge trigger.
  • Example: Badge 1
• Click on “Choose Badge” and select one from your existing badge library.
  • Example: Badge 123

Badges enhance member motivation and are often displayed in member profiles or dashboards.

Step 6: Configure Event Groups (Optional)

• Drag and drop the Event Group to the canvas below badges. 
• Enter a Group label to describe this group of events.
  • Example: Event Group 1
• Set the Execution Flow to:
  • Unordered – Events can be completed in any order. (This is the current supported mode.)

Now, set the rules for event tracking:

• Click “Set Additional Rules”.
• Under “How to track the counts?”, select:
  • Cumulative — This tracks all events together.
  • Per Event – This tracks each event type separately.

You can now add individual events to the group:

1. Drag and drop events into the Event Group node. 

• System Events– Events generated by system activity.
• API Event– Events triggered by API calls from your platform.

API events:

Overview:
API Events are used to track member progress through specific steps in a User Journey. A journey step is marked as complete when the configured API Event is successfully received for the corresponding member. API Events can be configured as individual nodes or placed under an Event Group.

• Label: events 1
• Event Name: digital- membership-2

When a member performs a specific action a system-integrated API call is made using the Events API. This event acts as a trigger, marking the relevant journey step as complete for that member. Once the event with the correct label and event name is received, the journey engine automatically updates the member’s progress and advances them to the next step.

    2. Define the Repeat Count – how many times the event must occur.

• Example: System Event – 5 times, API Event – 2 times.

You may define an OR condition so that members can qualify if any one of the listed event criteria is met.

Step 7: Review and publish

• Click “Save as draft” to store the journey setup.
• Click “Publish” to make the journey live for members. If the journey configuration has a start date and an end date, the journey will be published as 'SCHEDULED'

Only members who meet the defined criteria will enter the journey, and all triggers will function automatically once the journey is active.

Benefit Issuance

The Benefit Issuance Node lets you award different rewards or badges to different members within the same journey, based on each member's current attributes. When a member completes the action or event node that precedes the Benefit Issuance Node, the system automatically checks the conditions you have defined and issues the first benefit whose condition the member satisfies.

You can add as many conditional benefits as you need one for premium members, one for standard members, one for employees, and so on each tied to a member extended attribute such as subscription status, membership tier, or an enrolment flag. You can also add a Fallback Benefit to make sure that members who do not match any condition still receive something at that stage of the journey.

Conditions are evaluated in real time at the moment of issuance. This means that if a member's attributes change between journey levels for example, their subscription lapses mid-journey the system will pick up the updated value and issue the correct benefit for that level.

Steps to Configure the Benefit Issuance Node

1. Navigate to Your Journey

Go to the Journeys section in the platform. Open an existing journey or create a new one.

2. Add the Benefit Issuance Node

In the journey canvas, open the Flow Control section in the left-hand panel. Drag and drop the Benefit Issuance Node into the canvas and place it after the action or event node whose completion should trigger the benefit.

3. Add a Benefit to the Node

Inside the Benefit Issuance Node, drag in a Reward or Badge item. Once added, click the benefit to open its settings and select the specific reward or badge you want to issue from the list of active items in your catalog.

Repeat this step for each member segment you want to cover. For example:

Premium members: add a Reward, then select your premium reward from the list.

Standard members: add a second Reward, then select your standard reward.

Note: You can add as many benefit nodes as you need. There is no limit on the number of conditional benefits in a single Benefit Issuance Node.

4. Define a Condition for Each Benefit

Each benefit you add needs a condition that tells the system which members should receive it. To set a condition, open the benefit's settings and do the following:

Select the member extended attribute you want to evaluate from the preset attribute names for example, Birthdate, Subscription, MemberLevel, or EnrolmentStatus etc.

Enter the value the attribute must match for example, True, Premium, or Active.

When a member reaches this node, the system works through your conditions in order from top to bottom and issues the benefit for the first condition that matches. You can reorder the conditions by dragging the benefit nodes within the group.

5. Add a Fallback Benefit (Recommended)

A Fallback Benefit is issued to any member who does not match any of your defined conditions. Adding a fallback is optional, but it ensures that no member passes through this node without receiving a benefit.

To add a fallback:

Add a new benefit node to the group in the same way as the others.

Select the reward or badge you want to use as the fallback.

Enable the Fallback toggle on that benefit node. Do not add a condition to it a fallback benefit must remain condition-free.

Note: You can only designate one fallback per Benefit Issuance Node. If you do not configure a fallback and a member does not match any condition, the node will complete with no benefit issued. That member will not be able to receive a benefit from this node at a later point in the journey.

6. Save and Publish

Once you have finished configuring all your conditional benefits and the fallback, save your changes and publish the journey. From that point on, every member who reaches the Benefit Issuance Node will automatically receive the benefit that matches their current attributes no further action required.

What You Can Configure

Rules

Rule	What it means for you
Only one benefit is awarded per Benefit Issuance Node.	The first condition that matches the member's attributes wins. All other conditions are skipped.
No condition matches + fallback is configured.	The fallback benefit is issued automatically.
No condition matches + no fallback is configured.	The node completes with no benefit issued. The member cannot receive that benefit at a later stage.
A fallback benefit cannot carry a condition.	Remove any conditions from the benefit before marking it as the fallback.
Only one fallback is allowed per node.	You cannot mark more than one benefit as the fallback in a single Benefit Issuance Node.
Rewards on hold cannot be used.	Make sure the reward is active and not on hold before adding it to the node.

 

Badge Accumulation Group

A Badge Accumulation Group is a Flow Control node in the Loyalty Journey builder. It groups multiple individual Badges nodes together and acts as a condition-check gate — the journey only moves past this node once the configured badge condition is satisfied for that member.

How it's configured:

 

Each badge inside the group is added as its own node (e.g., badge1 → mapped to a specific badge like ADLV-01(ADLV-01), badge2 → mapped to another badge like Badge_6_test (Badge_6)). Each badge node has a Label and a Choose Badge dropdown to select which badge it refers to.

When Set Additional Rules is enabled

There are two ways to track the count

Per Badge: In this type, the count is calculated separately for each badge based on the criteria defined for that specific badge. We can apply AND and OR conditions to control how each badge count is evaluated.

Cumulative Count: In this type, the count is applied across a group of badges. The cumulative count should always be less than the total number of badges in the group. For example, if a group contains 4 badges, we can set the cumulative count to 3.

Example:
A Badge Accumulation Group contains Badge1 and Badge2. If the group is configured with an AND/OR condition of "Badge2 OR Badge1" (both optional individually, but at least one required), a member who earns either badge will satisfy the group and move forward in the journey.

Notes:

The Badge Accumulation Group is a condition/gate node — it does not award anything;it only considers badges earned through journeys and ignores manually assigned badges or badges from other sources.

It's typically placed between an Entry point and a Rewards or Benefit node, so that a reward is only issued after the badge condition is met.

Reward Group

A Reward Group is a Flow Control node that groups multiple Rewards nodes together, similar in structure to a Badge Accumulation Group, Reward group does not evaluate on reward; it makes the rewards inside the group available when the previous node is completed instead of badges.

How it's configured:

Each reward inside the group is its own node with a Label and a Choose Reward dropdown (e.g., Automate Check2 (20327963)).

The group's completion condition is based on a reward count: the number of rewards claimed by the member must be less than the total number of reward nodes configured inside the group.

By default, a reward is considered "unavailable" in the journey's context until its triggering action is performed. Once the relevant action (e.g., a loyalty action or points-earning action) is performed, it then becomes "available" within that journey's context.

Example:
A Reward Group contains 3 configured rewards. A member becomes eligible for the group once they've claimed a number of rewards within the group that satisfies the configured reward count (e.g., at least 1 of the 3). The Reward Availability API can be queried with the journey ID and member email to check claim status for that member.

Notes:

• Rewards cannot be assigned directly from the reward group. Once group rewards are available, assign them to a member at the journey level using the /api/3.0/users/{{email_id}}/journeys/select_reward API.
• Reward availability is journey-scoped — the same reward might behave differently (available/unavailable) depending on which journey context it's being checked in.

Await

Await is a Flow Control node used to pause the journey for a defined waiting period before the journey evaluates the next step. It's most commonly used right after a Purchase node, to account for return/cancellation windows before finalizing whether a spend-based condition has truly been met.

How it's configured / works:

• It is tightly coupled with the Purchase node. A Purchase node defines a spend condition (e.g., Spend Amount operator >= value 1000 USD, within a Start Date/End Date range), along with a Spend Calculation Based On setting (e.g., Consider Hold).
• After the purchase condition's evaluation window ends, the Await node introduces an additional waiting period (e.g., 10 days) before the journey proceeds further (e.g., into a Rewards node).
• This waiting period exists specifically to accommodate returns/cancellations: if a customer's purchase is cancelled or the item is returned within the return-policy window, that purchase amount is excluded from the spend calculation. Only the remaining (non-cancelled) purchase amount counts toward completing the condition.
• Once the Await period lapses, the final evaluation is done using only the confirmed (non-returned) purchase amount, and the journey moves to the next node based on that final value.

Example:
A customer needs to spend ₹1,000 to qualify for a reward. They make a purchase of ₹1,500 on a given date. Instead of immediately awarding the reward, the journey enters an Await node with a 10-day wait period (e.g., last date + 10 days) to allow for the return window. If no cancellation/return happens in that window, the final evaluation confirms the ₹1,000+ spend and the member proceeds to the Rewards node. If part of the purchase is returned during that window, the recalculated spend is used instead.

Notes:

• Await is essential for purchase-based conditions where cancellations or returns could otherwise cause a reward/badge/point to be issued incorrectly.
• The "Consider Hold" setting on the Purchase node works together with Await — purchases in a hold/pending-return state are treated as not-yet-final until the Await period completes.

Audit Logs for Journey Configuration Changes

Audit logs for Journey configurations provide a transparent record of all admin-level changes made within a Journey. These logs enhance traceability, security, and accountability by capturing detailed information about who made changes, when they occurred, and what was modified.

Each Journey log entry includes the following information:

• Date: The exact date and time the event occurred.
  Example: 10/03/2025 11:58:13
• User Details: The name and email of the user who performed the action.
  Example: Jennifer Carpenter, jcarpenter@annexcloud.com
• Event Details: The type of event or action taken.
  Example: New Journey created
• Old: The previous state of the Journey (if applicable).
  Example: NA (for newly created journeys)
• New: The updated or new Journey state.
  Example: User Journey
• Source: The origin of the action, typically the IP address or platform used.
  Example: 223.233.81.88

Parameters Explanation

After creating the journey, you can view its details on the Manage User Journey page as shown below:

1. Name

• This represents the name of the user journey.
• It helps users easily identify and distinguish between different journeys.
• Example: Testing_AC_copy

2. ID

• A unique system-generated identifier assigned to each user journey.
• Used for backend tracking and API references.
• Example: aa32668c-8176-494a-ab8e-8e4f023942b3

3. Description

• Provides a brief explanation or purpose of the user journey.
• Helps in understanding what the journey is intended for.
• Example: User Journey

4. Status

Indicates the current state of the user journey. It can be one of the following:

• LIVE: The journey is active and currently in use.
• DRAFT: The journey is in progress and not yet published.
• ARCHIVE: The journey is inactive and stored for future reference.

5. Actions

This section allows you to perform various operations on a user journey:

• Edit: Click to modify the existing journey. Upon clicking, you will be redirected to the editing page where you can update the journey details.
• Archive: Click to mark the journey as inactive.
• Audit: Click to view the change history or activity logs of the user journey.

Copy Journey Feature

Copy: This feature allows you to create a duplicate of an existing user journey.

To create a copy, click the Copy icon. A pop-up window will appear where you need to provide the required details:

• Target Site: Select the site where you want to create the duplicate journey. The dropdown list will display all sites you have access to. This is a required field.
• Journey Name: Enter the name for the duplicated journey. This name will be displayed once the journey is copied. This is a required field.

After providing all the required information, click Copy Journey to create a duplicate of the journey in the selected site.

Configuring point awards

The Points Node is used in a journey to award loyalty points to a member after a specific action is completed. This node is typically placed after an action node (e.g., purchase, signup, or any tracked activity), and it is automatically triggered once the preceding action is successfully completed.

 

 

 

Parameter	Description	Example
Label	A custom name to identify the node within the journey for better clarity.	Signup Bonus Points, First Purchase Reward
Select Action	Defines the action type; only Manual Credit is supported to award points.	Select Manual Credit to give points after signup
Set Points	Enable this flag to award points based on the Points field. If OFF, points will be awarded based on the selected action.
Points	The number of loyalty points to be credited to the member’s account.	100 → User will receive 100 points
Expiration Settings	Toggle to enable/disable expiry of points; if disabled, points never expire.	Enabled for promo points, Disabled for lifetime points
Expiration Type	Defines expiry logic when enabled: Rolling (after X days) or Calendar. The expiration limits can be applied as: Rolling: Points expire after a configured number of days based on the points Earned Date. For example, if this field is set to Rolling, and the Days field is set to 30, points earned on March 1 will expire on March 30. Points earned on March 5 expire on April 5, 30 days from the date they were earned. Calendar: Points expire based on the calendar time frame following the Earned Date. Options include Week, Month, and Year. Enter the number of units (week, month, year) for the points to expire. Note: Selecting the expiration type as Calendar displays an additional field called Count.	Rolling
Day	Number of days after which points expire (applicable for Rolling type only).	10 → Points expire 10 days after being awarded
Reason	Description for why points are awarded, useful for audit and tracking.	Reward for onboarding, Cashback on Order #1234

 

 

Additional Notes

• Users are the administrators or business users creating and managing journeys.
• Members are the loyalty program participants who qualify for journeys based on their actions.
• Currently supported logic includes OR/AND conditions and unordered event execution.
• More advanced conditions such as tier-based entry and sequential event flows will be added in future updates.