The direct answer: clean duplicate outlet records before an SFA rollout by freezing routine creation, assigning a stable master ID, normalizing comparison fields, building a candidate queue, and merging only after an authorized reviewer verifies identity and open commitments. A matching name or map pin is a candidate signal, not proof; hold any merge that cannot preserve source IDs or visit history.
Set up a controlled outlet cleanup before SFA configuration
Form a small data-governance group: an outlet data owner, field sales reviewer, finance or credit reviewer, trade marketing reviewer for claims, and a privacy contact where personal data is involved. They approve rules, resolve disputes and sign off merges. Keep a decision log. During final cutover, freeze routine creation where practical and route new requests to the data owner.
Define the stable master ID first
A master outlet ID should identify the location for its commercial life without encoding mutable attributes such as route, salesperson, channel or street address. Never recycle a retired ID. Keep every source-system key as an alias in a crosswalk so old orders, visits, claims and reports still resolve after a merge. If a merge cannot retain the source ID, hold the merge.
Normalize for comparison, not destruction
Keep raw values and create separate comparison fields. Standardize legal suffixes, banner names, punctuation, street types, building and floor details, market names, district, city and postcode. Normalize phone formats for review, but mask contact details in working files and limit access to approved reviewers. Do not publish personal contact data in shared trackers. A shared phone is a candidate signal, not proof; one owner may use the same number for several outlets.
Detect candidate duplicates, then prove them
Use ranked candidate rules rather than one match. Useful signals include the same source key across systems, an exact normalized name with the same street address, a shared phone with the same address, a similar name in the same postcode, or a shared map pin within a bounded area. These rules create a review queue, not a merge decision. Names are reused, pins can mark a mall or market centre, and addresses can be incomplete. A close match is a reason for verification.
Decide branch versus duplicate before merging. A branch is a separate selling location or account. A duplicate is two records for the same in-scope outlet. A delivery point, warehouse or billing account for the same store may need a documented relationship rather than a merge. If the reviewer cannot establish the relationship, keep the records separate and park the case with a reason.
| Source field | Cleanse rule | Required before merge? | Review note |
|---|---|---|---|
| Source outlet key | Map to a master ID; retain every source key as an alias; never recycle. | Yes | The crosswalk must survive the merge. |
| Outlet name | Trim, standardize punctuation, banner and legal suffix; keep raw. | Yes | Name alone is not proof of identity. |
| Address elements | Split street, building, floor, market, district, city and postcode; standardize abbreviations; keep raw. | Yes | Check floor and market conflicts. |
| Coordinates | Retain source and precision; use only as a candidate signal. | Optional | Never merge on a pin alone. |
| Phone and contact | Mask in working files; restrict to approved reviewers; follow privacy policy. | Review only | Do not publish; contact details may be shared. |
| Account, owner and channel | Retain for routing and approval; do not treat as identity proof. | Yes | Separate accounts can share an owner. |
| Open commitments | List orders, invoices, credit notes, claims, contracts and follow-ups. | Before merge | Block the merge if mapping is unclear. |
| Status and visit history | Retain dates, tasks, evidence and status; link to the master ID. | Before merge | Do not erase history. |
Review and merge under control
Use this merge-decision checklist for every candidate; the reviewer should be able to explain the decision without reopening the whole file.
- Confirm the outlet exists, is in scope and is the same selling location or account.
- Check the entrance, building, floor, market and delivery point against the address, not only a map pin.
- Confirm ownership, banner and account relationship; identify any branch or delivery point.
- List open orders, unpaid invoices, credit notes, trade promotion claims, rebates, contracts, scheduled visits, open follow-ups and submitted evidence.
- Reconcile balances and claim amounts before transfer; stop if they cannot be mapped.
- Choose the survivor master ID and record every alias ID in the crosswalk.
- Assign the account owner, route and permissions after merge.
- Obtain second approval for merges touching balances, claims or contracts.
- Test in a non-production copy, execute in production and re-run affected reports.
Preserving history is not optional. Visit dates, tasks, outcomes and evidence references should remain retrievable from the master outlet. If the software cannot preserve the crosswalk or history, do not merge until the vendor confirms a workable approach.
Verify the cleaned outlet file before go-live
Completion is a tested state: the candidate queue is closed or parked with reasons; no two active master IDs represent the same in-scope outlet; every merged source ID resolves to the survivor; open commitments are reconciled; visit history is linked; permissions and audit logs are in place. Test by searching an old source ID, opening a historical visit, checking an order or claim total and exporting the crosswalk. Sample merged records and ask field reviewers to confirm them.
Ask the SFA vendor for evidence rather than assurances. Does outlet creation enforce a unique master ID? Are source IDs retained as aliases? Does a merge preserve open orders, claims and visit history? Is approval role-based and audited? Can contact fields be masked? Can you export the crosswalk? Request a demonstration with sample outlets. For a related pre-purchase test, see Store Audit Data Quality: Test It Before Buying SFA Software.
Airpalm publicly describes mobile visits, route planning, store audits, sales orders, inventory and promotion management (airpalm.com, checked 9 October 2026). Those workflows depend on outlet identity, so include deduplication, alias retention and merge approval in implementation scoping. The public description does not establish a specific deduplication or merge feature; verify it with a demonstration using your own sample records. A sensible next step is to run the field mapping and checklist against one controlled outlet extract before cutover.
Frequently asked questions (FAQ)
Should merged duplicate outlet records be deleted?
No. Keep the source record or at least its source ID as an inactive alias so historical orders, visits and claims can still resolve. Delete only after confirming that no report, integration or audit trail depends on the old record.
Can a shared map pin or outlet name justify an automatic merge?
No. A name can be reused and a pin can be imprecise or mark a shared building. Use both only as candidate signals, then verify the selling location, account relationship and any open commitments with an authorized reviewer.
Who should approve a merge involving an open balance or trade claim?
The outlet data owner and field sales reviewer should confirm identity. Finance or credit should reconcile balances, and trade marketing should confirm claim treatment. Require a second approval for any merge that touches balances, claims or contracts.
How should contact data be handled during the cleanup?
Mask personal contact details in working files, restrict access to approved reviewers and use the data only for the agreed verification purpose. Do not publish contact data in trackers or shared exports, and follow your organization’s privacy policy.
Put this guide into practice
This general-purpose worksheet is a starting point. Adapt its fields, responsibilities and rules to your business process.
