Fix Duplicate Residents or Units from Integrations in TownSq

Duplicate residents or units in TownSq usually happen because the integration can’t reliably match records between systems, so it treats the same person or unit as “new” and creates another copy. Even if everything “meets requirements,” duplicates can still appear when IDs change, data formats don’t match exactly, or the sync is set to create records instead of only updating them.

 

Most common causes (plain language)

 

• No shared unique ID: TownSq and the other system may not share a stable “one-and-only” identifier for a unit or resident. If the integration matches by name, email, or unit label, small differences create a second record.
• Unit naming differences: “Unit 101” vs “101”, “Bldg 1-101” vs “101”, leading zeros, dashes, or spaces. The integration reads these as different units.
• Email/phone changes: If a resident’s email changes (or one system has blank email), matching fails and a duplicate resident is created.
• Household structure mismatch: One system stores “household + occupants,” another stores each person separately. During sync, it may create a new “resident” instead of linking to an existing household.
• Move-in/move-out timing: If a resident is marked moved out in one system but still active in the other, the next sync may create a “new” active resident.
• Two-way sync collisions: If both systems are allowed to create records, the same change can be created twice (once from each side).
• Re-imports or re-auth: Reconnecting the integration, re-importing, or changing mapping can reset matching rules and trigger “create” again.

 

How to confirm what’s happening

 

• Pick one duplicated unit/resident and compare fields side-by-side: unit label, building, email, phone, status, move-in date.
• Check integration logs/history for “created” vs “updated” actions and the matching key used (email, unit code, external ID).
• Look for formatting differences (spaces, punctuation, capitalization). Integrations often treat these as different.

 

How to stop duplicates (practical fixes)

 

• Force a single source of truth: choose which system is allowed to create units/residents; the other should only update.
• Standardize unit IDs: make unit labels consistent (same building/unit pattern everywhere). Avoid “Unit” prefixes and inconsistent dashes.
• Require a stable identifier: use external IDs if supported; otherwise enforce unique email for residents and a unique unit code for units.
• Clean before syncing: merge duplicates in the source system first, then sync. If you clean only in TownSq but the source still has duplicates, they will return.
• Pause sync during cleanup so the integration doesn’t recreate records while merging.

 

If all requirements are already met and duplicates still happen

 

• Ask support to verify matching rules: confirm exactly what fields the integration uses to match residents and units, and whether it is “create+update” or “update-only.”
• Check for hidden differences: trailing spaces, different building IDs, inactive vs active flags, or multiple emails.
• Request a one-time de-duplication plan: support may need to map existing TownSq records to external IDs so future syncs update instead of create.