Processing historical events
When historical events are loaded into the database, only actions that occurred within 7 days before the upload are processed. Events older than 7 days will not enter a flow.Example. If an action was uploaded on 10/20, an event dated 10/12 will not be processed.
Customers — how to restrict triggering by event
You can drop irrelevant events at the moment they appear and avoid unnecessary load on your project. To do this, use customer filters in the trigger block so that only relevant entries reach the flow. Available customer conditions:- Email — filled and (in)valid
- Mobile phone — filled and (in)valid
- Segment — (does not) belong to a recalculated or static segment
- Subscription — subscribed in the required brand, channel, or topic
- Mobile app — has an app with permission to receive mobile push
- Device — has a device with permission to receive web push on the site
Customer actions
Action issued
An action was issued. You can select several action templates at once.The flow triggers on backdated actions, but they must fall within the step group relevance window.How it works. Say a flow sends a campaign immediately after an order; the step group relevance is one day. An order arrives in the database on June 10 at 10:00 with an order date of June 6 at 20:00. The step could have fired between June 6 20:00 and June 7 20:00 (given the one-day relevance). That window has passed, so the flow drops the event and does not trigger. Now change the flow: put a 3-day wait between the order and the campaign. The 3 days are again counted from the action’s date, so the campaign can send between June 9 20:00 and June 10 20:00. The order falls within the step relevance, so the flow does run.
- Context filters: by action
- Dynamic wait: from an action field
- Event parameters: CustomerAction
Product-related action issued
A product-related action was issued: view, add to or remove from a list. You can select several action templates at once.The flow triggers on backdated actions, but they must fall within the step group relevance window. (See the example above under “Action issued.”)
- An order is not considered a product-related action.
- The action must be tied to a product. Otherwise, even if the matching template is issued, the flow will not start.
- Context filters: by action; by product
- Dynamic wait: from an action field; from a product field; product expiration date
- Event parameters: CustomerActionProduct; CustomerAction; Product
Customer left the site or app
The event fires after a session that matches the configured settings ends. A session is a customer’s presence on the site with the Maestra tracker installed. It automatically closes after half an hour of inactivity. You can also force it to close by entering the following in the Console tab of developer tools:- Adding a product to a list
- Viewing a product
- Viewing a product category
- Context filters: by session
- Event parameters: Session
Product list changed
Product added to the list
A new line was added to the customer’s list. The event does not react to an increase in the quantity of a product that is already on a line.- Context filters: by product on the list; by product
- Dynamic wait: from a product field; product expiration date
- Event parameters: ProductListItem; Product
Any change
A line was added to the customer’s list, or the list was adjusted (the line total or quantity changed). The event does not fire:- When the cart is cleared
- When a line is fully removed from the list, including when removal happens at the same time as an addition in a list set operation
- Context filters: by product on the list; by product
- Dynamic wait: from a product field; product expiration date
- Event parameters: ProductListItem; Product
Customer requested an authorization code
A code was created via an operation with the step Action — Generate authorization code.- Context filters: by action
- Dynamic wait: from an action field
- Event parameters: CustomerAction
Orders
Order status changed
The order moved to the selected status, including arriving in that status directly.The flow triggers on backdated orders, but two nuances apply:
- The action must fall within the step group relevance window.
- There must be no later change to the order. Otherwise the incoming data is no longer the most current for that order.
All order items transitioned
- Every item that came in with the order’s creation must reach the status. If one item is canceled, the flow won’t start.
- Items don’t have to transition to the status in a single action. If item changes arrive gradually, the flow starts once all items reach the required status.
- You can additionally limit the number of triggers per order.
- The count of transitions to the required status is measured from the moment the flow is turned on.
Any order item transitioned
- You can additionally limit the number of triggers per order.
- The count of transitions to the required status is measured from the moment the flow is turned on.
- Context filters: by order; by action
- Dynamic wait: from an order field; from an action field
- Event parameters: Order; CustomerAction
New order
The flow launches when a new order is created in any status.The flow triggers on backdated orders, but keep the step group relevance in mind.
- Context filters: by order; by action
- Dynamic wait: from an order field; from an action field
- Event parameters: Order; CustomerAction
Order data changed
The flow fires when a change occurs on the order. You can additionally limit the number of triggers per order. By default, the event fires on any change. If you select specific fields, the flow only fires when those fields change.The flow triggers on backdated orders, but the action must fall within the step group relevance window, and there must be no later change to the order.
- Context filters: by order; by action
- Dynamic wait: from an order field; from an action field
- Event parameters: Order; CustomerAction
Product in the order delivered
An order item moved to the Delivered status, including arriving in that status directly. Fires for each delivered item, even if they came in the same order. Delivering an order with two items launches the flow twice.- Fires again on an item if anything on it changes (price, quantity, custom fields).
- Products that moved to the specified status in the Delivered category
- Products that belong to one of the selected segments
- Context filters: by order item; by product
- Dynamic wait: from an order item field; from a product field; product expiration date
- Event parameters: OrderItem; Product
Product in the order paid
An order item moved to the Paid status, including arriving in that status directly. Fires for each paid item, even if they came in the same order. Paying for an order with two items launches the flow twice.- Fires again on an item if anything on it changes (price, quantity, custom fields).
- Products that moved to the specified status in the Paid category
- Products that belong to one of the selected segments
- Context filters: by order item; by product
- Dynamic wait: from an order item field; from a product field; product expiration date
- Event parameters: OrderItem; Product
Segments
Customer entered a segment
The customer entered the selected recalculated or static segment.Customer exited a segment
The customer left the selected recalculated or static segment.Customer profile changes
New customer
A new customer was added to the database in any way: manually, via API, or by file import. If a new Maestra ID appears, the event fires.Even if the new customer is immediately merged with an existing profile, a new profile was created, so the flow launches. To avoid duplicate triggering in these cases, limit the number of applications per customer to one.An import does not always create a new customer. If the customer already exists, the record is simply edited — in that case there is no “added to database” event.
Customer registered
A new customer was added via an operation with the step Customer — Register, Customer — Register or update, or Customer — Import. The event does not fire if:- The customer is being edited, not created, by the operation
- The customer was created from a personalization form
- The customer was created via an interface import
- Context filters: by action
- Dynamic wait: from an action field
- Event parameters: CustomerAction
Profiles of one customer merged
Any merge of customer profiles, including manual.Customer changed email
Change of email from one to another. Does not include filling in, wiping, or creating a customer with an email.With email confirmation
Includes adding an unconfirmed email when a confirmed one exists, or an email without confirmation data becoming unconfirmed. Does not include confirming an email, or an email without confirmation data becoming confirmed.Email became valid
Fires every time a customer’s email status changes from Invalid to Valid. Does not include replacing an invalid email with a new valid one.Customer confirmed email
On every email confirmation. Includes confirming the primary email, re-confirming, filling in an already-confirmed email, or an email without confirmation data becoming confirmed and primary. Does not include confirming an unconfirmed email when the customer has both a confirmed and unconfirmed email, or switching from one confirmed email to another.Customer changed mobile phone
Change of mobile number from one to another. Does not include filling in, wiping, or creating a customer with a phone.With phone confirmation
Includes adding an unconfirmed phone when a confirmed one exists, or a phone without confirmation data becoming unconfirmed. Does not include confirming a phone, or a phone without confirmation data becoming confirmed and primary.Phone number confirmed
On every phone confirmation. Use this event to launch transactional flows with guaranteed send speed.Customer data changed
A change in customer data that shows on the Change history tab: filling and wiping fields, recognizing an email as valid or invalid, and so on.Customer modified data
A change in customer data with an action from the Personal category that shows on the Change history tab.Customer custom field value changed
A selected custom field or calculated field on the customer changed. Includes filling, changing, or wiping the value.The custom field history storage feature does not affect this event.
Subscription status changed
The customer received the selected subscription status in a channel/topic. Includes the subscription moving to the required status (explicit or implicit), the customer being created already in the required status, and the subscription transitioning to the required status again. Does not include an implicit required status becoming explicit, or the primary customer ending up with the required status after a merge.Product changes
Product on a list changed
You can additionally restrict the event by selected product segments. Only products that belong to at least one of the selected segments will enter the flow.Product back in stock
A product on the customer’s list that was previously out of stock — or had no availability data — became available.- Fires every time: when it next goes unavailable and comes back, the flow runs again.
- Fires per product: if two products on the list become available, the flow runs twice.
- If the product has regional availability data for the customer’s zone, the flow triggers on changes in that region.
- If the product has any regional data but not for the customer’s zone, the flow does not trigger.
- If the product has regional data for the customer’s zone but availability in it is not filled in, the flow reacts to changes in the main feed.
- If the product has no regional data at all, the flow triggers on changes in the main feed.
- Context filters: by product on the list; by product
- Dynamic wait: from a product field; product expiration date
- Event parameters: ProductListItem; Product
Product out of stock
A product on the customer’s list that was previously in stock — or had no availability data — became unavailable.- Fires every time and per product.
- Context filters: by product on the list; by product
- Dynamic wait: from a product field; product expiration date
- Event parameters: ProductListItem; Product
Product price dropped
A product on the customer’s list dropped in price by N percent or more, or by $N or more. In detail: when a product is added to the list, the price at which the customer added it is recorded. This is independent of the product feed price and may differ from it. Then the product’s feed price may change. The flow compares whether the current price has dropped below the price the customer saved the product at. If so, the flow launches.- Fires every time, including further drops and on a new drop after an increase.
- Fires per product.
- Does not react to price being filled in. If the product previously had no price data, the price must change again after being filled in.
- Context filters: by product on the list; by product
- Dynamic wait: from a product field; product expiration date
- Event parameters: ProductListItem; Product
Product price increased
A product on the customer’s list rose in price by N percent or more, or by $N or more. Logic mirrors “Product price dropped” — fires every time, per product, does not react to fills, regional rules apply.- Context filters: by product on the list; by product
- Dynamic wait: from a product field; product expiration date
- Event parameters: ProductListItem; Product
Product custom field changed
The value of a custom field on a product from the customer’s list changed.- Fires on fill, change, or removal of the value.
- You can select several custom fields. If multiple selected fields on one product change at once, the flow runs once for that product.
- Fires per product.
- Context filters: by product on the list; by product
- Dynamic wait: from a product field; product expiration date
- Event parameters: ProductListItem; Product
Viewed product changed
You can additionally restrict the event by selected product segments. Only products that belong to at least one of the selected segments will enter the flow. The four sub-events — back in stock, out of stock, price dropped, price increased, and custom field changed — work the same as for the list, with two differences:- The trigger is based on a viewed product, not a list product.
- The reference price for “dropped” / “increased” comes from the price recorded at view time, not the price on a list.
- Context filters: by viewed product; by product; by action
- Dynamic wait: from a product field; product expiration date; from an action field
- Event parameters: ProductView; Product; CustomerAction
Product viewed
The customer viewed a product page.- Context filters: by viewed product; by product; by action
- Dynamic wait: from a product field; product expiration date; from an action field
- Event parameters: ProductView; Product; CustomerAction
Preferred product changed
Data for a product stored in a calculated field on the customer changed.Product price dropped
The price of the customer’s most-viewed or most-purchased product dropped by N percent or more, or by $N or more. How it works: when the product’s Price field changes, the flow compares whether it dropped by the configured percent or amount relative to the previous value. If so, the flow launches for customers who have this product stored in the specified calculated field.- Fires every time, including on further drops and on a new drop after an increase.
- Does not react to price being filled in.
- Context filters: by product
- Dynamic wait: from a product field; product expiration date
- Event parameters: Product
Loyalty
Customer balance went negative
After a balance change, it became negative. For example, a customer spent points earned from an order and then canceled the order. The event also fires if, after an award, the balance remains negative, or further deductions arrive.- Context filters: balance change; action
- Dynamic wait: point expiration; from an action field
- Event parameters: CustomerBalanceChange; CustomerAction
Bonus points became available (moved from blocked)
Awarded points became available.- If points are active immediately on award, the flow also fires.
- The event’s run time is set at the moment points are awarded.
- The flow must be turned on both at the moment of awarding and at the moment the points become available.
- Context filters: balance change; action
- Dynamic wait: point expiration; from an action field
- Event parameters: CustomerBalanceChange; CustomerAction
Specified balance changes
Any change to the balance on a points account: award, deduction, zeroing.- Context filters: balance change; action
- Dynamic wait: point expiration; from an action field
- Event parameters: CustomerBalanceChange; CustomerAction
Promo code issued
A single-use or referral promo code was issued.- Context filters: by promo code
- Event parameters: PromoCode
Customer applied a promo code
Use of any promo code, including multi-use, in any promotion, including external ones.- For multi-use and referral promo codes, the flow re-triggers on each order item the promo code applied to when the order status updates.
- For single-use promo codes, the flow re-triggers when the order status updates regardless of the number of items.
- Context filters: by promo code
- Event parameters: PromoCode
Customer’s referral promo code used
A referral promo code issued to the customer was used. When the order is modified, the flow re-triggers on each item the promo code was applied to.- Context filters: by promo code
- Event parameters: PromoCode
Discount card status changed
The card’s status became Activated, Blocked, or Not activated.Cards are always issued with a status change.
- Context filters: discount card info; action
- Dynamic wait: from a discount card info field; from an action field
- Event parameters: CustomerAction
Discount card replaced
Card replacement.Issuing a new card is not considered a replacement.
- Context filters: by action
- Dynamic wait: by action field
- Event parameters: CustomerAction
Campaign participation
Email generated for the customer in a campaign / Campaign sent to the customer
The customer received the configured campaign status.For other statuses (open, click, unsubscribe request), use the Action issued event with the corresponding template.
Other
Operation called
The flow launches only after the operation selected in the event is called with the step Action — Start flow. The customer is identified by the data passed in the call.- Context filters: by operation variables
- Dynamic wait: from an operation variable
- Event parameters: CustomParameters