How Georgia Logistics Teams Clean Duplicate Consignee-Site Records

Table of Contents

Toggle

Why Do Georgia Logistics Teams Need Accurate Consignee-Site Records?

In this anonymized composite scenario, a Georgia logistics team finds that the same consignee delivery site appears under several Salesforce names after warehouse-system imports. Account coverage and service reports split across those entries, while another nearby facility under the same parent must remain separate. An illustrative 15,000-row review shows how the admin can verify site identity, preview changes in ZaapIT, and keep backup, bulk undo, and restore available for supported affected records.

Why Duplicate Consignee-Site Data Matters in Georgia Logistics

The Georgia Ports Authority reported that Savannah handled nearly 5.7 million TEUs in calendar 2025; that is port traffic, not a Salesforce record count. More directly relevant to this use case, a 2022 Georgia Tech logistics dissertation describes duplicate rows and inconsistent supplier or consignee names in a third-party logistics dataset assembled from different systems. Its research is not a study of the composite Georgia company below. It shows why a consignee’s name alone is a weak key: one physical delivery site can acquire multiple labels, while two distinct facilities under one company can look deceptively similar.

Use Case: One Delivery Site, Several Salesforce Records

A 3PL’s customer-service team creates a consignee record for a Savannah-area distribution center. A warehouse-system feed later imports the same site with an abbreviated company name and a slightly different street suffix; a sales rep creates a third entry using the parent brand. Calls and service Cases attach to different Accounts or facility records, so a coverage report counts several destinations where operations recognizes one. Yet the parent also operates a second warehouse nearby. Merging on company name and ZIP alone could hide that real second site.

The admin sets the identity grain before deduplication: one verified physical delivery site, linked to the right parent company. Depending on the Salesforce org, that site may be modeled as a child Account or a custom Facility record. The team preserves distinct dock locations, operating contacts, hours, access instructions, and external warehouse identifiers where they identify genuinely separate locations. CRM cleanup does not change shipment routing in a transportation-management system unless a reviewed integration explicitly propagates those changes.

What Salesforce Matching Can and Cannot Decide

Salesforce’s standard Account matching rule compares combinations of name, street, city, ZIP, phone, and website. The standard Account duplicate rule alerts on creation by default but allows the user to save the possible duplicate. These controls can surface candidates; they cannot establish whether two entries represent the same receiving facility or different sites owned by the same company. If facility identity is stored in a custom object, the admin must examine that object’s import keys and matching configuration separately. A Salesforce Help article also notes that missing city or ZIP values can prevent the standard Account rule from finding a match.

A Controlled ZaapIT Review of 15,000 Illustrative Rows

1. Capture the baseline: export the illustrative 15,000 in-scope Account or Facility rows with Salesforce IDs, source-system IDs, parent links, location fields, contacts, open Cases, owner, and relevant report totals. Include only fields reviewers are authorized to handle.
2. Profile candidate duplicates: use ZaapIT filters and matching review to group name and address variants. Keep a separate exception queue for shared ZIPs, multiple docks, changed warehouse IDs, and facilities with conflicting operational contacts.
3. Confirm the identity crosswalk: an operations owner verifies each physical site against the approved facility master. The admin records which Salesforce IDs map to one site and which are valid separate locations.
4. Preview and back up: review the selected rows and related records before any bulk action. Test the ZaapIT backup and restore path on a small pilot, and preserve the old-to-new ID mapping.
5. Run controlled batches: normalize approved names and addresses, or merge only approved duplicate records where the configured object and relationships support it. Pause on errors or unexpected automation and review the next batch before continuing.
6. Validate and recover: reconcile changed IDs, distinct physical-site counts, parent relationships, contacts, open Cases, and service reports. For supported ZaapIT actions, use bulk undo or restore if a mapping is wrong; repair any external warehouse or transportation system separately.

The example scope is a review population, not a claim that all 15,000 rows should be edited. Backup, bulk undo, and restore reduce the risk of approved mass changes only when tested for the exact action and related-record scope.

How the Team Checks That the Cleanup Worked

The composite team samples both combined and deliberately separate sites. It checks the verified site key, parent Account, dock-specific contacts, open Cases, owner, and report grouping against the baseline. Exception records stay in review until operations confirms their identity. New imports use the approved external site ID or enter a review queue when the ID is missing; a similar name by itself never silently rewrites a destination.

• Every changed row has an approved before-and-after ID mapping.
• Distinct physical sites are counted separately from parent companies and dock references.
• Location-specific service history and contacts remain visible to the right team.
• Restore tests and failed-row logs are retained for the affected ZaapIT operations.