One loose filter, run first
A fuzzy name match run before any exact pass groups people and companies that only look alike. Run on automation, it merges records that were never duplicates.
Salesforce deduplication with Cloudingo means finding duplicate leads, contacts, accounts and custom-object records with matching filters, then merging each group into one surviving record under rules you have agreed. Twopir Consulting designs the filters, the master-record and field rules, the related-record handling and the merge sequence, then runs the merges in reviewed waves with a recovery plan in place. One accurate record per customer, with its activity, ownership and history kept.
Trusted by 500+ organizations — including clinical, legal and professional-services businesses that rely on one accurate customer record in Salesforce.










What We Deduplicate
Cloudingo will find and merge duplicates quickly. Speed is not the risk. The damage in a dedupe project comes from what a merge decides: which record survives, which values win, and where the related records go. These are the six mistakes we see most often.
A fuzzy name match run before any exact pass groups people and companies that only look alike. Run on automation, it merges records that were never duplicates.
Left on a default, the master can be the oldest record, with the oldest owner and the stalest status. Every value nobody wrote a rule for is then taken from it.
Without field groups, a merge can fill blanks one field at a time and leave an address with its street from one record and its city and postcode from another.
On a custom-object merge, a related object set to "do nothing" is deleted or orphaned along with the losing record. Nobody notices until a report goes blank.
Flows, triggers, validation rules and governor limits all run during a merge. Cloudingo states it cannot troubleshoot them, so a mass job fails partway through or fires automation nobody expected.
The Salesforce recycle bin can bring a merged record back, but not its related-record links. Cloudingo's Undo & Restore only covers merges made after it was switched on.
Cloudingo deduplication is the process of finding duplicate Salesforce records with Cloudingo's matching filters and merging each duplicate group into one master record, using merge rules that decide which record survives and which field values it keeps. It covers leads, contacts, accounts and person accounts, lead-to-contact and lead-to-account matching, and, on Cloudingo's Professional and Enterprise plans, objects Salesforce cannot merge natively, such as opportunities, cases and campaign members.
Three parties are involved, and it helps to keep them apart. Cloudingo, an AppExchange app from Symphonic Source, runs in the cloud outside your org and connects to Salesforce over OAuth. It provides the filters, rules, merge modes and the Undo & Restore backups. Salesforce performs the merge itself and applies its own behaviour: your flows, triggers and validation rules run, and the surviving record keeps the oldest created date. Twopir Consulting designs and runs the deduplication: the filters, the rules, the related-record settings, the test merges and the merge waves on this page. Product behaviour is documented in the Cloudingo help documentation on merge rules.
How does that compare with doing it natively? In Cloudingo's own comparison, Salesforce's built-in duplicate management matches on a few fields with exact or fuzzy logic, merges at most three records at a time, and leaves the master and field choices to a person, record by record. Cloudingo adds more matching algorithms, rule-driven merges of larger groups and unattended automation. If you are weighing other AppExchange tools instead, we also work with Duplicate Check for Salesforce and Validity DemandTools.
New to the product? Our getting-started guide to Cloudingo covers the basics. This page is about the deduplication work itself. Installing and configuring the app is covered by our Cloudingo implementation services.
A Cloudingo filter compares chosen fields with a matching algorithm per field. Filters behave like reports: they show duplicate groups and change nothing until a merge is submitted. So we design them in tiers, from exact matches that can merge unattended to looser matches that a person reviews.
| Field | Matching approach and why |
|---|---|
| Exact. Email is the most unique identifier on a person record, so loosening it adds false positives. | |
| First name | Synonym, so formal and informal variants (Stephen, Steven, Steve) match. |
| Last name | First N characters, reviewed by hand, because a short prefix catches typos and unrelated surnames alike. |
| Phone | Numeric only, so formatting differences in brackets, spaces and dashes stop hiding a match. |
| Company or account name | Cloudingo's Company Clean algorithm, which normalises variants such as Acme, Acme Inc. and The Acme Company. |
| Website | Domain, which compares the core of the web address and ignores prefixes and paths. |
| Street, city, state, country | Fuzzy for street and city; synonym for state and country (TX and Texas). Not used in early passes. |
Filters combine fields with AND logic and take up to five OR conditions. Matching gets more reliable when the values are standardised first, which is why formatting, normalisation and stale-record work sit with our Cloudingo data cleansing services and often run before or between dedupe passes.
Filters decide what is a duplicate. Merge rules decide what the surviving record looks like afterwards, and they are where most business logic lives. We write each rule down with the reason for it, and agree it with the people who own the data, before anything merges.
| Rule layer | Options in Cloudingo | What we decide with you |
|---|---|---|
| Master record | First record by newest or oldest created or modified date, most complete, most related data (activities, notes, cases, opportunities), highest or lowest value in a field, a priority value, or the record with an active owner. | Which record your teams would call the real one: often the record a system of record or integration ID points at, not simply the newest. |
| Default field rule | A source (newest or oldest by created or modified date) plus an override: override the master when blank, never override, always override with a value, or always override even with a blank. | How blanks on the master get filled. "Override master when blank" is the common choice; the blank-overwriting option needs a deliberate reason. |
| Specific field rules | Per-field rules that take precedence: newest modified, a ranked priority list of values, or combining values such as multi-select picklists. | Fields where a different record should win: the latest phone, the most advanced lifecycle status, every interest a person ticked. |
| Field groups | A controlling field pulls a whole group of fields from the same record, for example a complete address block. | Which fields must travel together, so no merged record mixes values from two sources. |
| Exceptions | Exclusion rules keep chosen records out of automatic merging while they stay visible in the merge preview. | Which records a person must always review: key accounts, partner records, anything with an open deal or case. |
| Owner mapping | Reassigns records owned by inactive users or queues to a new owner during merge or conversion. | Who inherits orphaned ownership, so a merged account does not land with someone who left last year. |
Cloudingo ships an editable default rule for leads, contacts, accounts and person accounts. We copy it into named rules per object and subset rather than editing it blind, and a rule library can carry a tested rule to another connected environment. One behaviour is Salesforce's, not Cloudingo's: the surviving record always keeps the oldest created date and created-by user, so reports built on created date need to account for it.
A duplicate is rarely a single record. It is an account with its contacts, a person who exists as a lead and a contact, or an opportunity attached to the copy that is about to be removed. We plan which objects to dedupe, in what order, and where every related record ends up.
Account duplicates are matched on name with address, phone or website. Merging them first means contacts can then be compared inside the right parent account.
Person records are matched on email and name, with phone or account name as a second key. Person accounts are supported where your org uses them.
A lead that already exists as a contact is found with convert filters and converted onto the existing contact in bulk, instead of becoming a second person record.
New leads from a company you already sell to are matched to the existing account on name, email domain or website, so sales sees one relationship.
On a standard merge, Cloudingo keeps notes, attachments and relationships intact on the surviving record. A pre-merge report shows which records merge into which.
Opportunities, cases, campaign members and your own objects can be deduped on Professional (up to three objects) or Enterprise (unlimited), once Cloudingo enables each one.
On custom-object merges, each related object is moved to the master, copied onto it, or left alone. Master-detail children only move when their relationship allows reparenting.
Heavily related records can hit Salesforce CPU and query limits during a merge, and flows or triggers fire on the survivor. We test merges with their real related data first.
Cloudingo offers several ways to run the same filter and rule. The choice depends on how much you trust the filter, not how many duplicates it found. A filter earns its way from manual review to automation.
| Merge mode | How it runs | When we use it |
|---|---|---|
| Manual merge | One duplicate group at a time, side by side, with the master and field values editable before the merge. | New filters, low-confidence matches, key accounts and every sample merge we test with your data owners. |
| Mass merge | Selected groups on one page of results merged together, with the rules pre-selecting master and values. | High-confidence filters with a page or so of groups left to clear. |
| Automated merge | An automation job merges every group in a filter and keeps running without anyone logged in. Jobs can be scheduled daily or weekly, or run on demand. | Proven exact-match filters with many pages of results, and the recurring jobs that keep the org clean. |
| Real-time merge | Runs continuously on new and changed records, on Professional and Enterprise. One real-time filter per object, standard objects only, up to 100,000 duplicate groups per 24 hours; overflow becomes an automation job. | The single most reliable filter per object, after it has run clean in automation. Not available for cross-match, convert, match-on-empty or custom-object filters. |
| API integration | On Enterprise, incoming data from another system passes through Cloudingo filters and is merged as it arrives. | Integrations that keep recreating duplicates, where fixing the source is not an option. |
The order matters as much as the rules. Each step produces something your team signs off before the next one starts, and nothing is mass merged until a sample of it has been merged by hand and checked in Salesforce.
We count duplicate groups per object with filters run as reports, confirm your own Salesforce backup, switch on Undo & Restore where your plan includes it, and review the connected user's field access.
DeliverableDuplicate baseline and recovery plan
Tiered filters per object, from exact to looser matches, scoped by record type or subset where needed. Each filter's results are sampled and false positives fed back into the design.
DeliverableFilter set with a confidence rating each
Master, default field, specific field, field group, exception and owner-mapping rules, plus related-object settings for custom objects, agreed with the people who own each object.
DeliverableSigned-off rule design
Pre-merge reports and manual merges on a sample of groups, checked in Salesforce: the surviving values, the related records, the flows and validations that fired, and a test restore.
DeliverableTested sample and approved filters
Accounts, then leads, then contacts, then leads against contacts, with the tightest filters first. Mass and automated jobs run per wave, and post-merge reports are reviewed before the next.
DeliverableMerge log and post-merge reports
Scheduled automation jobs, a real-time filter per object where it is safe, deduplicated imports, and a short runbook so your admins know which filters run when and who reviews what.
DeliverableRunning schedule and admin runbook
Cloudingo's Undo & Restore, included from the Professional plan, can unmerge records it merged and reattach their related data. It is a safety net with clear limits, and Cloudingo itself says it is no substitute for a backup. Knowing those limits is part of planning the merge.
| Question | How Undo & Restore behaves |
|---|---|
| Which merges can be undone? | Only merges and lead conversions made after the feature was enabled. Earlier merges have no backup plan. |
| How long are backups kept? | Up to 45 days on Cloudingo storage, or as long as you choose on your own AWS or Azure storage. |
| Which objects are covered? | Accounts, cases, contacts, leads, opportunities and tasks by default. Other related and custom objects need an advanced setting enabled by Cloudingo support. |
| Can we restore in bulk? | No. Restores run one duplicate group at a time, for the rare merge that went wrong. |
| Does the record come back as it was? | The restored record is inserted again with a new Salesforce ID. Values overwritten on the master are not restored, though the backup file can be downloaded to recover them. |
| What else is not restored? | Contact-to-multiple-account relationships created during the merge. With Salesforce's recycle bin alone, merged records come back without their related-object links. |
A one-off cleanup decays as soon as the next import lands. We finish a deduplication project by handing over the controls that keep new duplicates out, set to the same filters and rules that cleaned the backlog.
Proven filters run daily or weekly as automation jobs, so duplicates that slip in are merged on a cadence your team can see in Cloudingo's dashboard.
On Professional and Enterprise, one trusted filter per standard object merges duplicates as records arrive or change, within Cloudingo's daily limits.
Cloudingo's import tool checks each CSV row against existing records, merges matches and inserts only what is new, instead of loading a list straight into Salesforce.
Cloudingo merges duplicates after they exist. Stopping a user creating one is a different job: the same provider sells DupeCatcher for that, and native Salesforce rules can also do it.
Prevention also needs an owner. Who reviews the manual-merge queue, who approves a new filter, and how duplicate counts are reported are governance questions, and we cover them in Cloudingo Salesforce data quality consulting. If you do not yet know how many duplicates you have, or where they come from, start with a Cloudingo Salesforce data quality audit. For ongoing help after hand-off, Salesforce support is a standing offer.
These are customer stories Cloudingo has published, not Twopir engagements. They are here because they show the patterns a deduplication plan has to handle. Each fact is as Cloudingo reports it.
Cloudingo reports that at Docker, a credit-card app created an account per transaction, leaving as many as sixty accounts for one company.
Cloudingo reports that Hotze Health and Wellness Center moved from Microsoft Dynamics without cleaning first, and now runs about twelve filters daily with a monthly review of unmerged records.
Cloudingo quotes Proficio saying that some of its accounts had more than forty duplicates.
Merging records is a change to your data model in miniature: ownership, automation, integrations and reports all feel it. A dedupe partner needs to know the org as well as the tool.
Flows, triggers, validation rules, sharing and integrations all react to a merge. We review them first, because Cloudingo cannot troubleshoot them and a failed mass job is the expensive way to find out.
Which record is the real one, which values win and who must review what are decisions for your sales, service and finance owners. We turn their answers into written rules, then into configuration.
Every filter is sampled, every rule is checked on a manual merge, and a test restore is run before the first automated job. Waves are reviewed one at a time.
Cloudingo is licensed from its vendor; we design and run the work around it. Our advice on plans, merge modes, or whether a native Salesforce rule would do the job, is about fit for your org.
You get the rule design, the filter set with confidence ratings, the schedule and a runbook your admins can maintain, not a one-off cleanup that drifts back.
A duplicate baseline per object, tiered matching filters, master-record and field-level merge rules, related-record and custom-object settings, and a recovery plan with Undo & Restore. Then test merges on a sample, merges in reviewed waves (accounts, then leads, then contacts, then leads against contacts), post-merge reports, and a prevention hand-off with scheduled jobs and a runbook. Installing and configuring Cloudingo itself is a separate implementation service.
Through merge rules. A master rule picks the surviving record, for example the newest or oldest by created or modified date, the most complete record, the one with the most related data, a priority value or an active owner. Default and specific field rules then decide which values the survivor keeps, and field groups keep related fields such as an address together. We agree these rules with your data owners before anything merges.
Yes. Convert filters match leads against existing contacts or accounts, on email and name for contacts and on company name, email domain or website for accounts, and convert them in bulk onto the existing records. Lead-to-contact matching usually runs last, after accounts, leads and contacts have each been deduplicated on their own.
On a standard merge, notes, attachments and relationships stay intact on the surviving record. For objects Salesforce cannot merge natively, each related object is set to move to the master, copy onto it, or do nothing, and anything set to do nothing is deleted or orphaned with the losing record. Master-detail children only move when the relationship allows reparenting, so we test merges with real related data first.
Yes, within limits. Undo & Restore, included from Cloudingo's Professional plan, can unmerge records merged after the feature was enabled and reattach their related data. Backups are kept up to 45 days on Cloudingo storage or longer on your own AWS or Azure storage, restores run one group at a time, and the restored record gets a new Salesforce ID. Cloudingo says it is not a substitute for a backup, so we take one before the first mass merge.
Both, for different filters. Automated merge runs a whole filter as a job, on demand or on a daily or weekly schedule, and suits proven exact-match filters. Real-time merge, on Professional and Enterprise, runs continuously but allows one filter per standard object and excludes cross-match, convert, match-on-empty and custom-object filters, so we reserve it for the single most reliable filter per object once it has run clean in automation.
In Cloudingo's own comparison, Salesforce's native tools match on a few fields with exact or fuzzy logic, merge at most three records at a time, and need a person to choose the master and field values for each merge. Cloudingo adds more matching algorithms, rule-driven merges of larger groups, cross-object lead matching, custom-object merges on higher plans and unattended automation. Native duplicate rules still have a place in blocking duplicates at entry.
A first conversation covers which objects are duplicated, where the duplicates come from, which Cloudingo plan you hold and what has already been tried: enough to outline the filters, the rules and the merge order, and what the project would take. No obligation to proceed.
Talk to a Salesforce architect who runs Cloudingo deduplication