Customer Journey Builder

Trigger-based entry

Start a journey the moment a user does something that matters: adds to cart, fails a payment, places an order. No waiting for the next scheduled segment pull.

Trigger-based entry element setup screen in the Customer Journey Builder: point name Cart recovery, event add_to_cart, and an entry condition where cart_value is greater than 50

Start the moment it happens

You want your journey to start the moment something happens, not whenever the next segment refresh gets around to it. That’s easy to promise and hard to hold once more than one automation is running at a time: a cart-abandonment sequence sitting among a dozen others, each reasonable on its own. “We noticed you left something behind,” sent an hour later by a nightly batch, is a different message than one that’s already running before the person puts the phone down. Trigger-based entry is what closes that gap.

What Trigger-based entry does

Pick an event, and anyone who fires it enters the journey right then, instead of waiting on the next scan of a saved segment.

Reacts in real time

Enters the moment the event fires, not on the next scheduled scan.

Filters on the payload

Optional conditions on the event's own attributes qualify entry beyond its name.

Runs several sessions at once

Concurrency keyed to order_id or product_id lets one user hold multiple parallel runs.

Controls re-entry

Block a repeat trigger, or let it restart the session, per element.

SettingOptions
Event sourceSDK postEvent, REST API, default PW_* events, custom events, geozone entry
Entry conditionOptional: filter on the event's own attributes (attribute, operator, value)
Who entersThe user who fired the event, or a user named inside the event's payload
Re-entryDo not allow (default), or allow it and restart the session
ConcurrencyOne active session per user, or several, keyed to a session attribute like order_id or product_id
Setting
1 / 5
Event source
Options
SDK postEvent, REST API, default PW_* events, custom events, geozone entry
Setting
2 / 5
Entry condition
Options
Optional: filter on the event's own attributes (attribute, operator, value)
Setting
3 / 5
Who enters
Options
The user who fired the event, or a user named inside the event's payload
Setting
4 / 5
Re-entry
Options
Do not allow (default), or allow it and restart the session
Setting
5 / 5
Concurrency
Options
One active session per user, or several, keyed to a session attribute like order_id or product_id

Audience-based entry re-checks a segment on a schedule. This reacts inside the same moment the event fires, and running several sessions per user means 3 open orders can each drive their own status journey instead of colliding into one. Routing a later event back to the right one of those sessions is what Wait for Trigger’s session-scoped matching handles further down the canvas. The full element, conditions and re-entry control included, ships on the free plan.

Why it matters for the journey builder

A journey builder is only as good as its entry points. Audience-based entry covers the scheduled cadence: newsletters, win-back sweeps. What a builder needs on top of that is a way to react in the moment a payment fails or a cart gets left behind, and that’s what trigger-based entry gives Customer Journey Builder. It reads from the same event catalog the rest of the canvas already uses for segmentation and branching, so the signal that opens the door is the same one driving the flow after it.

What it hands off to next

An add_to_cart event fires and this starts a cart-recovery journey. A Wait for Trigger element then gives the buyer up to 90 days to complete the purchase before branching into win-back. Neither element sends anything on its own. Both hand off to a channel block, and the entry element decided who was in the flow to begin with.

The event that starts a session can also carry the key a later branch needs to tell one order apart from another, all on the same Customer Journey Builder canvas.

Events and journeys stay on infrastructure you can name

Every event a trigger-based entry element reads runs through the same infrastructure as the rest of the platform: Pushwoosh is SOC 2 Type I and ISO 27001:2022 certified, GDPR-compliant, and runs on its own hardware in the US and Germany, under BDSG. Full detail sits on the data safety page.

ISO 27001:2022 CertifiedISO 27001 CertifiedGDPR CompliantData Privacy FrameworkHIPAA CompliantSOC 2 Type I CertifiedOWASP Compliant

How it works

  1. Add the entry element

    On the canvas, add a Trigger-based entry element and pick the event: a default PW_* event, or a custom one sent through SDK postEvent or a server call.

  2. Qualify and target the entry

    Add a condition on the event's attributes to qualify entry, add_to_cart where cart_value is over 50, for example, and choose whether the person who fired the event enters, or the user named inside its payload.

  3. Set re-entry and concurrency

    Decide whether someone already inside the journey can trigger it again, and whether one user can hold several sessions at once, keyed to an attribute like order_id.

Good to know before you wire this up.

  • Pushwoosh does not publish a latency SLA from event to entry. The product describes this as real-time, not a numbered guarantee.
  • Re-entry is a binary switch on the element itself: block a new trigger, or restart the session. A graduated limit (once a day, once a week, once a month) lives at the journey level, not on this element.
  • This needs a real event stream behind it: SDK postEvent, or a server/API call carrying a hardware ID or User ID on the entry event. Without one, entry falls back to a scheduled or segment-based start.
  • A schedule-based start runs through a separate entry element on the same canvas.
  • Full trigger-based entry, conditions and re-entry included, ships on the free plan, up to 1,000 users. Events and journeys run on Pushwoosh-owned hardware in the US and Germany, under GDPR and BDSG. SOC 2 Type I.

Turn one event into a live journey.