Overview
Our first article introduced Central Customer at a high level. This article goes one level deeper into two of its core mechanics: how we determine that two customer records belong to the same real person (identity resolution), and how we bring your organization's existing customer history into a single, unified profile upon feature enablement (backfill).
These two topics work together: the same matching logic that runs one time during backfill also runs every time a customer is scanned or looked up going forward — so a person is identified the same way no matter when or where the match happens.
Data Normalization (Applies Everywhere)
Before we ever compare two customer records, we "clean up" the data on both sides the same way. This matters because the same real value is often entered inconsistently — a phone number typed with dashes vs. without, an email in mixed case, a name with extra spaces. Without cleanup, the same person could look like two different people just because of how their info was typed in.
Here's how each field is standardized before any comparison happens:
Driver's license / State ID: converted to all-uppercase and stripped of spaces, dashes, and other non-letter/number characters.
Phone number: reduced to digits only, with the leading "1" country code removed if present, so
(555) 123-4567and555-123-4567are recognized as the same number.Email address: lowercased and trimmed of extra spaces.
Name: extra spacing removed and converted to a consistent case.
Why this matters: this cleanup is the foundation that makes accurate matching possible in the first place — it ensures a real difference in the data (a different person) isn't confused with a cosmetic difference (a different way of typing the same thing), and vice versa.
Validation Rules — What Counts as a Real ID Number
Not everything typed into the "driver's license" field on a customer record is actually a driver's license number. Retail data commonly includes placeholder entries — things like blank entries, "N/A," "UNKNOWN," "0000000," or a string of the same repeated digit — entered when a staff member couldn't capture a real ID at the time.
We treat these placeholder values as "no ID on file" rather than as a real, matchable value. This is an important safeguard: if we treated placeholder text as a real ID, unrelated customers who happened to share the same placeholder (which happens constantly — plenty of records share "N/A" or "0000") would get incorrectly linked together as if they were the same person.
So a value is only trusted as a real ID once it passes this validation — otherwise, matching falls back to the other details on the profile (name, phone, email, date of birth) as described below.
What Counts as an "Exact" Match (Applies to Both Backfill and Ongoing Linking)
This is the most important concept in this article, since it governs both how backfill works and how ongoing customer scans/lookups work. When we say a match is "exact," we mean it's confident enough to link two profiles together automatically, with no staff review needed. Today, an exact match is defined as either of the following:
A validated ID number match. The customer's driver's license or state ID (after cleanup and validation, above) matches a number already on file for an existing profile. Since a real ID number is unique to one person, this is treated as certain.
A full-profile ("composite") match. When there's no usable ID number, we instead look at the combination of first name, last name, phone number, email, and date of birth. If all of these agree with an existing profile and that combination doesn't ambiguously match more than one existing profile, it's also treated as an exact match. If the same combination happens to match more than one existing profile, it's no longer treated as exact — it becomes a candidate for manual review instead (see below).
Anything short of the above — a partial match (say, just phone + last name, or just email), or a full-profile match that isn't unique — is not treated as exact, and never links automatically.
Backfill: Bringing In Existing Customer History
Backfill is what happens when Central Customer is first turned on for your organization. It is a one-time job, run once at feature enablement, that looks across all of your stores' existing customer records and consolidates the ones that are exact matches for the same real person into a single, unified profile — using the same matching rules described above.
It runs once, automatically, as part of turning the feature on — no action is needed from your team.
Only exact matches (ID match, or a unique full-profile match) are merged together during this process. If a group of records don't reach that bar, they are simply not merged and remain as separate profiles — backfill does not attempt "best guess" merges or ask a human to confirm ambiguous cases at this stage.
Once merged, purchase history, visit counts, and other details from every consolidated record carry forward into the resulting unified profile, rather than the customer appearing to start over.
Ongoing Linking: Customer Scan and Profile Lookup
After backfill, the same identity resolution logic keeps running any time your team scans a customer's ID or looks up a customer profile in Customer Management — whether that's a brand-new customer, or one who was already part of the backfill.
If an exact match is found (by the same definition above — ID match, or a unique full-profile match), the scan or lookup is linked automatically. No staff action is required; the existing unified profile is simply recognized and used.
If no exact match is found, but some possible matches exist (for example, matching on just phone + name, or just email), the system does not guess. Instead, it surfaces a prompt in the interface showing the potential matches it found, along with a confidence level for each one.
A staff member — who is with the customer in person — reviews the prompt and makes the call. They confirm which (if any) of the suggested profiles is actually this customer, then manually select and link it. If none of the suggestions are a match, a new profile is created instead. This human-in-the-loop step exists specifically because these situations are ambiguous enough that we want a person who can verify the customer's identity in person to make the final decision, rather than linking automatically.
Auto Linking: How Data Is Combined
Whether two records were linked during backfill or through an in-store scan/lookup, the same set of rules governs how their data is combined into the single unified profile:
Data | Rule | Why |
Name, phone, email, address | The most recently provided value wins; if a store doesn't provide a value, the existing one on file is kept | Assumes newer information is more likely to be a correction or update |
Customer type (Medical vs. Adult-Use) | Medical always wins, and is never downgraded back to Adult-Use | Medical status is treated as a permanent designation for the customer |
Customer status (Active vs. Deactivated) | Active always wins | A customer shouldn't be treated as deactivated just because they're inactive at one specific store |
Customer groups | Combined (union) across all stores — nothing is dropped unless a store explicitly clears its own group tags | Group membership is additive, not exclusive to one store |
Opt-in status | If the customer has opted in at any store, that applies everywhere | Consent given once should be honored everywhere |
Total visits | Summed across all stores | Reflects true total activity across the organization |
Last visit date | Most recent date wins | Always reflects the customer's latest known activity |
Documents (ID photos, medical cards, etc.) | All documents from every store are retained and visible everywhere — nothing is overwritten | Staff at any store should be able to view any document already on file, without asking the customer to resubmit it |
Notes | All notes from every store are retained and visible everywhere | Context recorded at one store should be available to any store the customer visits next |
Bans / warnings | Once flagged anywhere, it applies everywhere (and stays in effect) | A ban or warning is meant to be organization-wide, not store-specific |