The Duplicate Check Set to Exact
The item master carries duplicate detection, barcode collision checks, required attributes per category and an approval gate on nine critical fields. Every one of them is switched on. Three of them are configured to their most permissive setting, which is not the same thing.
Read this first
The governance machinery on the item master is real and more thorough than most: duplicate detection with fuzzy name matching, barcode collisions checked against assets as well as items, required attributes per category, and an approval workflow on nine fields where a change alters how an item behaves rather than how it reads. What deserves attention is the defaults. Fuzzy duplicate blocking is set to fire only at a hundred per cent similarity, which the exact-match check has already caught. Required attributes are configured for every category and the list is empty. The approval gate can be bypassed by anyone holding the permission. None of these is wrong for a product that must not block a new customer's first bulk import — and all three mean the honest answer to "is duplicate detection on" is yes, and the honest answer to "what will it stop" is different.
Two items called "Cement 32.5N 50kg bag" and "Cement 32.5N 50Kg Bag" are the same product, and only one of those spellings will be found by the person looking for it next week.
A duplicated item master is the quietest expensive problem in inventory. Nothing breaks. Stock is split across two records, so neither shows the true quantity. Reorder points fire on one and not the other. Two suppliers appear to be quoting for different things. Consumption history is halved, so demand forecasting is wrong in a direction nobody can see. And every report is subtly understated, because it is reporting on one of the two.
So a check that stops the second record being created is worth a great deal — which is exactly why it is worth knowing precisely what yours stops.
What is checked when an item is created
| Check | Default | What it stops today |
|---|---|---|
| Same name and category | On, blocking | An exact repeat after normalisation. Genuinely useful. |
| Similar name | On, threshold 100 | A hundred per cent match — which the check above already stopped. |
| Barcode collision | On, includes assets | A barcode already used by an item or an asset. Genuinely useful. |
| Required attributes per category | On, list empty | Nothing, until a list is configured. |
| Approval on critical changes | On, bypass allowed | A change by anyone without the permission. Holders proceed directly. |
Two of those five are doing substantial work from the first day. The other three are machinery waiting for a decision.
The threshold that cannot fire
The similarity check compares a new item's name against existing ones and produces a percentage. The setting that decides whether to block is a percentage too, and it defaults to a hundred.
A hundred per cent similarity means the strings are identical — which the exact name-and-category check has already refused. So the fuzzy check, out of the box, blocks nothing that was not already blocked.
Enabled and set to its most permissive value are the same thing from the outside, and the first one is what a settings screen reports.
The configuration also carries a second, lower threshold — a warning level at eighty-six per cent, well inside the range where "50kg bag" and "50Kg Bag" would be caught. The number is there, deliberately chosen, and it sits at a level that would catch the case this article opened with.
Whether to move the blocking threshold down towards it is a genuine judgement rather than an obvious fix. Fuzzy matching on product names produces false positives, and product names are frequently similar on purpose: "Bolt M8 40mm" and "Bolt M8 50mm" are different items whose names differ by one character. A threshold tight enough to catch a duplicated spelling is also tight enough to refuse a legitimate variant, and a buyer blocked from creating a real item will find a way around the check — usually by naming it something worse.
Where the blocking threshold should sit
It depends on your catalogue, and specifically on how much of it is a family of variants. A catalogue of distinct products tolerates a low threshold and benefits from it. A catalogue of sizes, gauges and lengths does not, because the variants genuinely are nearly-identical strings. The useful test is to take twenty pairs of real item names from your own list — ten true duplicates and ten legitimate variants — and find the threshold that separates them. If no threshold does, the answer is a warning rather than a block.
The window of fifty
A second limit shapes what the check can see. A new item is compared against a capped number of existing candidates — fifty by default.
The reason is straightforward. Fuzzy string comparison is not free, and it runs while somebody waits on a form submit. Comparing against every item in a catalogue of forty thousand is not a check, it is a timeout.
The consequence is that on a large catalogue, the duplicate you are about to create may simply not be in the comparison set. The check is honest about what it is — a fast guard against the common case, not an exhaustive search — and the practical reading is that it gets less effective as the catalogue grows, which is precisely when duplicates become more likely.
The part that is unambiguously good
Nine fields on an item are treated as critical, and changing any of them raises an approval rather than saving.
- The barcode, because it is how the item is identified by a scanner and a change silently redirects every future scan.
- The category, because it drives reporting, and moving an item between categories moves its history with it.
- The inventory account, because it decides which account the value lands in.
- The tax treatment, because it changes what is charged and what is filed.
- The tracking mode, and the lot, serial and expiry tracking switches, because turning tracking on or off changes what the system knows about stock that already exists.
- The first-expiry-first-out policy, because it decides which physical stock is issued next.
That list is well chosen. Every field on it changes how the item behaves rather than how it reads — a description or a photograph can be edited freely, and none of the nine can. And the approval carries a real control: the person who requested a change cannot approve their own request. It is due within two days.
The qualification is the bypass. Anyone holding the approval permission changes a critical field directly rather than raising a request. Which is reasonable — a workspace where the only person who can approve is also the only person who maintains items would otherwise be permanently stuck — and it means the control governs everybody except the people most likely to be making the change.
Four questions to ask about any item master governance
Is duplicate detection on, and at what threshold?
A good answer sounds like
Both numbers, not just the switch.
What ours actually is
On, exact-match blocking active, fuzzy threshold at a hundred so it adds nothing beyond exact. Always ask for the threshold — "it is enabled" is compatible with catching nothing.
How many existing items does it compare against?
A good answer sounds like
A number, and a reason for the cap.
What ours actually is
Fifty by default, capped because the comparison runs while somebody waits. Worth asking of any system: an uncapped check on a large catalogue is a slow form, and a capped one is a partial search.
Which fields require approval to change?
A good answer sounds like
A list, and it should be about behaviour rather than presentation.
What ours actually is
Nine, all of them fields that change how the item behaves. A vendor gating the description and not the tax treatment has not thought about it.
Can an approver change a critical field without an approval?
A good answer sounds like
A clear yes or no.
What ours actually is
Yes, by permission, and the requester still cannot approve their own request. Ask it plainly — a bypass is defensible and is worth knowing about.
Turning machinery into enforcement
Most of what follows is configuration rather than construction, which is the useful part: the checks exist and the decisions about how strict they should be are yours to make.
A warning tier alongside the block
A near-match shown to the person creating the item, letting them proceed deliberately, so a threshold can be set low enough to be useful without refusing legitimate variants.
Comparison beyond the window
A candidate set chosen by indexed matching rather than a flat cap, so the check keeps working as a catalogue grows past the point where duplicates start to matter.
Required attributes per category
The machinery is present and the list is empty. Deciding what a category must carry is a catalogue decision, and it is the item on this page with the shortest path from decision to effect.
We publish scope, not dates.
Scope item master governanceWhat AWRA OpsHub does today
- Duplicate detection on item creation and update, comparing normalised name and category against existing items and blocking an exact repeat.
- Fuzzy name similarity scoring with a configurable blocking threshold and a separately configurable warning threshold, both present in configuration.
- A cap on how many existing items are compared against, so the check runs inside a form submit rather than scanning a whole catalogue.
- Barcode collision checking that covers assets as well as inventory items, so a code cannot be shared across the two.
- An approval workflow on nine critical fields — barcode, category, inventory account, tax treatment, tracking mode, the lot, serial and expiry tracking switches, and the first-expiry-first-out policy.
- Segregation of duties on that approval: the person who requested a change cannot approve it.
- A two-day due window on a pending item master change, with explicit approve and reject paths that apply or discard the change.
- Per-category required attributes as configurable machinery, applied at create and update.
More we can add to your workspace
- A near-match warning shown at the point of creation, so the configured warning threshold reaches the person naming the item rather than living only in configuration.
- Candidate selection by indexed matching rather than a flat cap, so duplicate detection stays effective on a catalogue of tens of thousands.
- A populated set of required attributes per category, which is a catalogue decision rather than a build, and the shortest path here from a decision to an effect.
- A merge for two items already duplicated, combining stock, history and references into one record — the repair for what the checks did not catch.
- A periodic scan of the existing catalogue for near-duplicates, since the checks run at creation and the duplicates that matter most were created before they were tightened.
- Normalisation rules a workspace can extend, so a catalogue with its own abbreviations and unit spellings can teach the comparison what to treat as the same word.
Where we point you to a specialist
- We would decline to ship a low fuzzy blocking threshold as a default. Product names in a catalogue of variants differ legitimately by one character, and a buyer refused permission to create a real item works around the check by naming it something worse — which manufactures the duplicate the check existed to prevent.
- Where an industry classification or a customer-mandated coding scheme governs how items must be identified, that scheme governs and we implement it rather than offering our own normalisation as equivalent. Which scheme applies to you is a question for your own advisers.
- We hold that the approval gate belongs on fields that change how an item behaves rather than on everything. Gating a description trains people to click through approvals, and an approval everybody clicks through protects nothing on the day it matters.
A near-match warning at the point of creation is the item that changes behaviour most, because it lets the threshold be set where it is useful without ever refusing a legitimate variant. The scoring already exists and the warning level is already chosen.
Find your own threshold before you change it
Take twenty pairs of real item names from your catalogue — ten genuine duplicates, ten legitimate variants — and see whether any similarity threshold separates them. That test takes half an hour and tells you whether your answer is a stricter block or a warning, which is the actual decision.
Talk through your catalogueFrequently asked questions
Is duplicate detection switched on?
Yes, and the exact-match branch does real work: an item whose normalised name and category both match an existing one is refused. The fuzzy branch is switched on too and its blocking threshold defaults to a hundred per cent, meaning it fires only on identical strings — which the exact check has already caught. So the honest summary is that duplicate detection is on and, out of the box, what it stops is exact repeats.
What is the warning threshold for, then?
It is a second, lower similarity level present in the configuration at eighty-six per cent, which is well inside the range where two spellings of the same product would be caught. The number has been chosen deliberately. Surfacing it to the person creating an item, as a warning they can proceed past, is on the list of work we can add — and it is the change that would let the threshold sit somewhere useful without ever refusing a legitimate variant.
Why compare against only fifty existing items?
Because fuzzy string comparison runs while somebody waits on a form submit, and comparing against a catalogue of forty thousand is a timeout rather than a check. The cap is an honest engineering constraint. The consequence worth knowing is that the check becomes less effective as a catalogue grows, which is exactly when duplicates become more likely — and it is why indexed candidate selection appears on the list of work we can add.
Which item fields need approval to change?
Nine: the barcode, the category, the inventory account, the tax treatment, the tracking mode, the lot, serial and expiry tracking switches, and the first-expiry-first-out policy. What they have in common is that each changes how the item behaves rather than how it reads, so a description or a photograph can be edited freely. Requests are due within two days and the person who raised one cannot approve it.
Can somebody bypass the approval?
Anyone holding the approval permission changes a critical field directly rather than raising a request. That is deliberate — otherwise a workspace where one person both maintains items and approves changes would be permanently blocked — and it does mean the gate governs everybody except the people most likely to be making the change. Segregation of duties still holds where a request is raised.
What if we already have duplicates?
The checks run at creation, so items created before they were tightened are unaffected, and those are usually the ones that matter. Merging two duplicated items — combining their stock, history and references into one record — appears on the list of work we can add, as does a periodic scan of the existing catalogue for near-duplicates. Until then, the practical approach is to keep the survivor, move stock across with an adjustment, and rename the other so nobody finds it by searching.
