How bulk changes work
The five Marketing areas are introduced in Marketing: the five areas.
Wallets, vouchers, personal promotions and promotional codes all support changing many records at once. They follow the same three-step shape, and learning it once covers all four.
The three steps
| Step | What it does | Permission |
|---|---|---|
| 1. Check | Counts what would be affected. Changes nothing | The area's view permission |
| 2. Apply | Starts the change as a background job | The area's edit permission |
| 3. Track | Follows the job until it finishes | The area's edit permission |
The check step is deliberately harmless and deliberately separate. It exists so you can see the blast radius before committing to it.
Always run the check. It takes seconds and it is the only preview you get. A count that looks wrong — far larger or far smaller than expected — means your criteria are wrong, and that is much cheaper to discover now.
Step 2 runs in the background
Apply does not finish while you wait. It returns a job that runs on its own, and you follow its progress.
This matters in three ways:
- Closing the screen doesn't stop it. The job carries on.
- Progress is polled, so the figure you see may lag slightly behind reality.
- A job that is still running is not a job that failed. Give a large change time before assuming something is wrong.
Already-redeemed records are never touched
Every bulk operation acts only on records that have not been redeemed.
| Area | What is protected |
|---|---|
| Wallets | Credit already spent |
| Vouchers | Vouchers already used |
| Personal promotions | Promotions already applied to an order |
| Promotional codes | Coupons already redeemed |
You cannot retroactively change or remove value a customer has already received. This is why bulk operations are recoverable in practice, and it is also the usual explanation for a count being smaller than expected.
Delete and update are separate operations
Bulk update changes fields — typically dates or amounts — on matching records. Bulk delete removes them.
Both are protected by the same non-redeemed rule, and both have their own check step. They are not variants of one action: pick the one you mean.
Promotional codes work differently — read this
Promotional codes use the same three words for a materially different operation.
| In wallets, vouchers, personal promotions | In promotional codes |
|---|---|
| Check counts matching records | Check asks whether the campaign has any redeemed coupons |
| Apply updates matching records | Apply deletes the whole campaign and its coupons — and only if none has been redeemed |
So in promotional codes, "apply bulk changes" is a delete, gated on the campaign being entirely unused. If even one coupon has been redeemed, it will not proceed.
To retire a campaign that has been used, expire it instead — see Promotional codes.
This is the single most dangerous naming overlap in the chapter. In four areas "apply" means update; in promotional codes it means delete a campaign. Check which screen you are on before clicking it.
A safe sequence
- Set your criteria narrowly.
- Check, and read the count.
- If the count surprises you, stop and work out why.
- Apply.
- Track to completion.
- Spot-check a couple of affected records.
If a job seems stuck
Give it time proportional to the count — tens of thousands of records take a while. If progress genuinely stops advancing, don't re-run the apply: a second job on the same criteria can compound the first. Report it with the area, the criteria and roughly when you started.