What data you get
| Field | What it is |
|---|---|
| Product | The product involved, if there is one |
| Customer ID | The shopper's numeric ID, or empty for a guest |
| Rule name | Which rule fired |
| Limit type | Quantity, Order value or Weight |
| What was violated | min, max, multiple, minValue, maxValue, minWeight, maxWeight or repurchase |
| Attempted amount | What the shopper tried to do |
| Allowed amount | What the rule actually permits |
| Unit | Units, a currency code, or a weight unit, depending on the limit type |
| Cart total | Defined but not populated yet |
| Where | product_page or cart |
| Shopper action | Tried to add to cart, or Stopped before adding |
What shopper action means
This field separates two signals that look identical in a log and mean very different things.
Tried to add to cart. The shopper clicked Add to cart and was stopped. A real attempt.
Stopped before adding. The shopper set a quantity the rule rejects and never clicked, usually because the button had already disabled itself. Demand signal, not an attempt.
A workflow that does not filter on this field runs for both equally. If it sends an email, posts to Slack or tags a customer, it will fire far more often than you expect, on events where nobody tried to complete anything.
Add a Flow condition, Shopper action is equal to Tried to add to cart, to any workflow that should only see genuine attempts.
This field was added after the trigger shipped. A workflow you built before it existed carries no condition on it, which means it is now running for both cases where it used to run for one. If your Slack channel got noisier without you changing anything, this is why.
Handling guests
Guests have no customer record, so Customer ID arrives as an empty text value rather than as a missing field. Roughly half of all blocks have no customer attached.
Any step that needs a real customer, such as tagging, emailing them directly or adding them to a segment, should sit behind a condition: Customer ID is not empty. Build for it from the start rather than finding out in production.
Five workflows worth building
Email the freight team on an oversized cart. Condition on Limit type equals Weight, then send an email carrying the rule name, the attempted and allowed amounts and the unit. This is the shipped "Oversized cart becomes a freight quote" template, covered in Ready-made workflow templates.
Slack alert above a value threshold. Condition on Attempted amount above a number that matters to you, then post to a channel with the rule name and product. This catches the handful of blocks a week worth a human look without flooding the channel.
Tag near-miss shoppers as wholesale leads. Condition on Limit type equals Order value, What was violated equals minValue, and Attempted amount above roughly 60 percent of Allowed amount. Someone that close to your minimum is a lead, not a shopper on the wrong store. Gate out guests first, then tag and notify a rep. This is the shipped "Near-miss carts become leads" template.
Log every real attempt to a spreadsheet. Filter to Shopper action equals Tried to add to cart, then append a row through Flow's spreadsheet connector with the rule name, product and amounts. A weekly review list that does not require opening the app.
Branch by limit type. Limit type and What was violated are both available, so one workflow can send Weight blocks to the freight team, tag Value blocks as leads and quietly log Quantity blocks. One trigger, several outcomes.
Common mistakes
- Not filtering shopper action. Covered above, and the most common cause of a workflow that fires more than expected.
- Assuming a customer always exists. Gate customer steps behind Customer ID is not empty.
- Building on cart total. It is not populated yet. Use Attempted amount, Allowed amount and Unit for anything value-based.
- Expecting a checkout-stage event. It fires where Prime MOQ observes the block, which is the storefront. Checkout enforcement itself is a separate mechanism, described in How limits are enforced at checkout.