Find hidden duplicates. Review every merge before it runs
bluefactory matches records in a backup snapshot of your org on the fields and rules you choose, with zero API calls against production, then walks you through every match side by side. Winner rules pick the survivor, merges dry-run first, and a live merge can be undone.
Duplicates found where they cost nothing to look for
Zero API cost to hunt
Queries hit the backup in storage, so there is no SOQL against the live org and no API-limit anxiety. Scan as broadly and as often as you like, on objects you would never dare scan in production.
- Reads the snapshot
- No live org queries
- Scan repeatedly
Matching built for messy data
Each field gets its own comparison mode, plus phonetic fuzzy matching, swapped word order, punctuation stripping, and cross-field alternates for when the same value hides in two fields.
- Per-field modes
- Fuzzy and phonetic
- Optional record filter
Golden-record merges
Winner rules mark the survivor per group, and per-field rules decide what it keeps: fill its blanks from the duplicates, combine values, keep the most common, sum numbers, or set a constant.
- Winner rules per object
- Per-field keep rules
- Overrule any group
Gated, and reversible
Every merge defaults to a dry run that writes nothing, and a live run needs writes authorized for that specific org, re-checked on the server. A finished merge still comes back: records return with their original ids and children go back where they came from.
- Dry run by default
- Server-checked gate
- Undo, children included
Find them in the snapshot, merge them on your say-so
Matching built for messy data
Pick an object and the fields that make two records the same, each with its own comparison mode: exact, ignore case, ignore case and spaces, plus phonetic fuzzy matching, swapped word order, punctuation stripping, and cross-field alternates for when the same value hides in two fields. Scans run over a backup snapshot, so production is never queried.
Source: backup 19 Aug 02:00
Scan as broadly and as often as you like. Production pays nothing for it.
Frequently asked questions
Where a scan runs, how a duplicate is defined, and what it takes to write a merge.
Want a demo? Book a demo
Does this modify my production org?
Not until you tell it to, twice. Scans only read the backup snapshot, and every merge defaults to a dry run that writes nothing. Writing to the live org requires explicitly authorizing writes for that specific org when you launch the run, and the server re-checks that authorization before anything executes. A finished live merge can also be undone.
Where do the scans run?
Against a completed backup snapshot in storage, using queries over the backed-up data rather than SOQL. Production sees zero API calls during detection, so you can scan large objects repeatedly without touching limits or load.
How is a “duplicate” defined?
You define it: pick an object and the fields that make two records the same, each with its own comparison mode (exact, ignore case, or ignore case and spaces). On top of that you can enable phonetic fuzzy matching, swapped word order (“John Smith” matches “Smith John”), punctuation stripping, and cross-field alternates when a value hides in either of two fields. An optional filter narrows the scan to the records you care about.
Which record survives a merge?
Winner rules decide: pre-built ones like most recently modified or most complete, or custom rules that score records on your own conditions. The rules mark a suggested survivor per group, and you can overrule any group by hand before merging.
What happens to the losing records?
They merge into the survivor. Per-field rules decide the values it keeps: filling its blanks from the duplicates by default, or combining, keeping the most common, and more. Child records are re-pointed at the survivor, and the merged duplicates land in the Recycle Bin, which is what makes undo possible: they come back with their original ids, and re-pointed children are restored.
What do I need before I can scan?
A completed backup of the org: dedupe reads snapshots, so backup comes first. Any completed run works as a scan source, and the same snapshot doubles as your reference for what the data looked like before you cleaned it.
Clean the org without gambling on it
Back your org up, scan the snapshot for duplicates, and read every merge before a single write lands: dry-run first, undo after. You scan what you back up, so backup comes first.
