# How bulk changes work

The five Marketing areas are introduced in [Marketing: the five areas](/books/console-yF7/page/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](/books/console-yF7/page/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

1. Set your criteria narrowly.
2. **Check**, and read the count.
3. If the count surprises you, stop and work out why.
4. Apply.
5. Track to completion.
6. 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.