A new feature that lets an administrator update many prices at once by defining a subset (e.g., all Vietnam fabric products) and a formula (e.g., increase by 5%), preview the result, and apply it in a single action — with an easy undo.
Today this kind of change is manual: prices are edited one at a time, or worked around in a separate spreadsheet and re-imported. Annual price increases, factory-wide adjustments, and reactive changes (like tariff shifts) all live in that manual workflow.
- Pick a subset — filter the existing Prices screen by Model, Factory, Cover Type, etc.
- Pick a formula — Increase by %, Decrease by %, Add fixed amount, Subtract fixed amount, Set to value, with a rounding option (whole dollar,
.99,.95, $5, $10, …). - Preview — see the proposed change on each affected row (before → after, total impact, range of changes) before anything is saved.
- Confirm — type
APPLYto unlock the Apply button, as a safety gate against accidental mass changes. - Undo — a short window where the whole batch can be rolled back in one click. A permanent audit log keeps a record of every batch (who, what, when).
A working clickable prototype of this flow is linked in the full RFC. No install, no login — the page mirrors the real Prices screen and lets reviewers walk through the full experience.
| What it is | Good for | Main trade-off | |
|---|---|---|---|
| A | "Bulk Update" button + preview modal on the existing Prices screen | One-off mass changes, familiar UI | Filter steps repeat if done quarterly |
| B | Export filtered subset to Excel, edit there, re-import | Complex per-row math; power users | Requires switching apps |
| C | Saved "Pricing Rules" — define once, apply on demand or on a schedule | Recurring updates (annual increases, vendor-driven) | More to build |
Build in stages. Start with A — it covers the immediate use case, builds on a screen users already know, and every other direction reuses its preview / apply / undo plumbing. Layer B and C on top as the real usage pattern becomes clearer. This sequencing avoids re-doing work and ships value fast.
These shape the feature meaningfully — we'd value input before finalizing:
- How often does the same kind of update repeat? If the "annual Vietnam adjustment" is real and recurring, Direction C (Saved Rules) earns its build cost early.
- Who is allowed to do mass updates? Same people who can import prices today, or a narrower group?
- Which rounding styles are actually used? Whole dollars?
.99or.95retail "charm" pricing? Round to nearest $5 or $10? - How should a bulk update interact with sale prices (
special_price)? Move them together with the base price? Leave sale prices alone? Require users to pick one field explicitly? - Are there price floors or minimum margins? — e.g., never below cost, never below a category minimum — and if violated, should the system hard-fail those rows, clamp silently, or block the whole batch?
- What's the worst-case "oops" to protect against? Drives how heavy the confirm step and undo window should be.
Not required reading for the client — mentioned so there are no surprises:
- All three directions share the same underlying "apply formula to a filtered subset" engine, so preview, audit, and undo work identically regardless of which front-door is used.
- Large subsets (thousands of rows) process as a background job with a progress indicator and email-on-completion; small subsets apply instantly.
- Every batch is logged with the user, filter, formula, timestamp, and a row-level snapshot that powers undo for a configurable window (default 90 days). The high-level audit entry is kept indefinitely.
- Statistics for the preview (average change, totals, range) are computed by the database, so previewing a very large batch stays responsive.
- Concurrent overlapping batches are prevented automatically — two admins can't accidentally run competing updates on the same subset at the same time.
Full RFC with mockups, flow diagrams, and the interactive prototype: see the companion gist / docs/rfc-349-mass-formula-updates.md.