Linked Conditions

Beta Callout

Linked Conditions is a Beta feature. To enable it, reach out to your CSM or drop an email to


Oftentimes, it is necessary to create customized checks that vary for individual users based on their properties or previous actions registered through events. Linked Conditions facilitate such conditional checks that can be added to a flow to determine the user's path. By doing so, marketers can devise intelligent checks based on user attributes, actions, and journey progress instead of specifying fixed values.

For example, you can check if a user has added a product to a cart at least once but has yet to purchase it or purchase a product from the same brand that they were browsing using linked conditions. You can add a check in the Flow's entry condition that assesses whether the user has purchased the particular category of the product or the specific product that they had added to the cart earlier without specifying the same manually.

Consider a user John, who browses shoes on an e-commerce platform. John adds a pair of Brogues to his cart. Since he performs an add-to-cart event, he qualifies for getting evaluated for the Flow F1.

Here's how the linked conditional check works in the Flow.

If John has executed an Add to Cart event:

  • Check if he has not executed a Product Purchase event 2 hours after the Add to Cart event
  • Match the product id of the product added to the cart and the product id in the product purchase event

Dynamic condition FLOWS_updated.png

Linked Conditions can help you use a Flow such as the one described above for multiple products and product categories, as the check against product purchase is not tied to a static value but is dynamically checked against the parent event (the add-to-cart event in this case). You can use dynamic checks to send tailored communication about flight delays to users who have purchased a ticket on a flight or send payment reminders to customers who are yet to pay their bill for a specific card in their account which has an upcoming payment deadline.

Use Cases

Here are a few examples of how to utilize Linked Conditions for specific purposes:

  • Wildcard Check between Two Events - This is an effective approach for allowing users to enter a flow only when certain events have occurred, but others have not. Consider the case where an organization wants to create a rule to send a reminder notification to customers who have credit cards, have received their bill statements, and haven't paid the bill for one or more cards. The linked conditions approach can be useful here.

    Consider a flow where users with bank credit card accounts are considered when they have not paid their bill. Adding the following conditional check:

      • Does the user have a bill-generated event for them?
      • Does the user have a paid bill event for them?
      • Compare the bill-generated event with the payment done or paid event by dynamically comparing the Payment Bill.Card_ID = Bill Generated.Card_ID

    Enter users who satisfy this criteria inside the flow that sends them payment reminder campaigns. Ignore other users from the flow. In such a setup, we capture the triggering event of bill statement generation, wait for a user action to occur indicating payment of the bill for a specified time duration, and if this action is not taken for either of the cards in the user account, send a reminder notification to the user to pay their bill for that specific card. This approach provides a customizable and automated method of responding to specific user behavior within a system.

  • Repetition of the same parent event X times with the same attribute - This is a technique that can be used to permit users to enter a flow who have completed a specific action, such as searching for a product multiple times.

    For instance, if an e-commerce platform wants to create a personalized user experience that enables customers to pick up on their previous searches, this approach can be used effectively. Consider a flow where the following linked condition is present: has the user performed multiple searches for a keyword or product within a specified time period while in the flow, and does the user have an active session, or are they a frequent buyer?
    If yes, move the user along a path in the flow where they will be sent campaigns that suggest similar products, deals, or promotions based on their search history.


  1. You can reach out to high-intent users and engage with them best using other potent features such as BTS and MPC. 
  2. You can choose to evaluate users at the entry stage, during conditional stages, or both with the flexibility this feature lends.
  3. Easy way to define rules and find high-intent users.
  4. More flexibility in defining Conditions/ rules to Target users in Flows.
  5. A smaller number of Flows required to achieve a use case

Adding Linked Conditions

Linked Conditions can be added to a Flow in the following sections:

Entry Conditions Has Done Stage Conditional Split Stage

Consider a Flow that sends intimations or reminders for upcoming flights. The following checks can be added at the entry-level to achieve this:

    1. Has the user purchased a ticket on any Flight with an upcoming trip date?
    2. Ensure that the user has not canceled their ticket.

You can also send campaigns to nudge users to upgrade their tickets or cross-sell other services while communicating such information with the users.


Note: While flows are capable of tracking a user's progress and initiating specific actions based on specified conditions being met, they can only accommodate a single instance of a user at any given time. If you expect users to satisfy the linked condition multiple times and would want to send a message for all those instances, MoEngage recommends using linked triggers in event-triggered campaigns.

Now that you have explored the various uses of Linked Conditions, go to the Flows - Cross Channel Messaging section to read about the capabilities of Flows and create one.



Was this article helpful?
1 out of 1 found this helpful

How can we improve this article?