Low voucher Stock Notification

Bloomreach doesn't have a built-in alert for when voucher codes are running low. This guide shows you how to build a scenario that monitors your voucher pools and sends an email notification when codes drop below a threshold you define.

Prerequisites

• Basic familiarity with scenarios, aggregates, and custom events in Bloomreach.
• Voucher codes imported into at least 1 voucher pool and used in a campaign.

Overview

The scenario runs once a day, checks the available voucher count for a pool, stores the result in a custom event, and sends an email if the count falls below your threshold. You can scale it to cover multiple pools and multiple recipients.

Set up the notification scenario

Create sample customer

To store voucher data without attaching it to real customer profiles, create a dedicated customer in Bloomreach. This customer acts as a data container—the scenario saves custom events to it, and the email reads data from it.

1. Go to Data & Assets > Customers and create a new customer.

   

2. Fill in only the customer ID—this is the identifier you'll use to filter for this customer in the scenario.

Create a monitoring event

Create a custom event to store voucher count data. The scenario writes to this event on each run, and the email reads from it.

1. Go to Data & Assets > Data manager and select the Events tab.
2. Create a new event at the bottom of the list.
3. Add the following properties — rename them if needed:
   1. pool_name: The name of the voucher pool.
   2. total_codes: Total number of codes in the pool.
   3. available_codes: Number of codes still available.
   4. threshold: the count below which a notification is sent.

Build the voucher pool check scenario

The scenario runs once a day, checks a voucher pool, saves the values to the custom event on your sample customer, waits 2 minutes, then sends an email if the available count is below the threshold.

Voucher customer filter: Add a filter at the start of the scenario to target only the sample customer you created. This scopes all subsequent actions to that customer.

Add event action: In the Add event "voucher_notification" action, configure the 4 fields:

• total_codes and available_codes: Use Jinja from the Personalization tab in the email builder to pull the counts from the voucher pool.
• pool_name: Set manually to the name of the voucher pool. This appears in the email so you know which pool is running low.
• threshold: Set per pool based on how much lead time you need to top up codes.

Condition check: After waiting 2 minutes for data to settle, add a condition that checks whether available_codes is less than threshold. To compare 2 event attributes rather than a manual value, switch to Attributes mode using the toggle next to the field.

Set up aggregates for the email

Create 2 aggregates that read the latest values from the custom event. Use these in the email to show which pool is affected and how many codes are left.

Pool name aggregate: Returns the last value of pool_name from the monitoring event.

Available codes aggregate: Returns the last value of available_codes from the monitoring event.

Reference both aggregates in the email using the Personalization tab in the email builder.

Configure email settings

Set the recipient and sending policy in the Settings tab of the email.

Set the policy to 0 hours and use General consent if you're using the consent framework. This ensures the notification is sent regardless of the recipient's marketing consent status.

Scale the setup

Add more recipients

Duplicate the email action, connect it to the same condition, and change the recipient in the email settings for each copy.

Add more voucher pools

Duplicate the scenario tab for each additional pool. In the duplicated tab, update:

• The pool_name field in the Add event action.
• The Jinja in total_codes and available_codes to reference the correct pool.
• The threshold value for that pool.

Stagger the tabs by at least 10 minutes apart. The email reads the last occurrence of the monitoring event, so tabs running too close together may overwrite each other's data before the email is sent.