Import customer list without creating duplicates

I am preparing to import approximately 12,000 customer records from our legacy CRM into FieldPulse. I have reviewed the bulk import documentation and have a concern regarding duplicate prevention.

Our legacy system contains multiple entries for the same customer due to historical data quality issues. I have confirmed that:

  1. Approximately 2,300 records share phone numbers with at least one other record
  2. Approximately 1,800 records share email addresses with at least one other record
  3. Approximately 890 records have matching first name, last name, and street address but different contact methods

My questions are as follows:

  1. What match key(s) does the FieldPulse import process use to identify potential duplicates?
  2. Is there a configurable merge rule set, or is deduplication handled automatically according to a fixed hierarchy?
  3. Can I specify which record should be considered "master" when duplicates are detected (e.g., most recent updated date, most complete data)?
  4. Does the import provide a preview or dry-run option showing which records would be merged versus created as new?
  5. Are there any constraints on which fields can be used as custom match keys?

I have noted that the import template includes columns for "Customer ID (External)" — it is not clear whether this field participates in deduplication logic or is strictly for reference.

Prior to executing this import, I require a reproducible process that does not create duplicate customer records, as remediation would be operationally costly.

Environment details: I will be using the web interface bulk import function, not the API, for this operation. Our account is on the Enterprise tier.

Parents
  • +1 to Eli's hierarchy — ran into this exact scenario last quarter with ~8K records.

    Heads up on the phone normalization: it strips all non-digits, so extensions get borked. "555-123-4567 ext 204" becomes "5551234567204" and might collide weirdly. We pre-cleaned extensions into a separate custom field.

    Also worth noting: the "first in CSV wins" rule applies within a single import batch. If you're doing this in chunks (which I'd recommend at 12K), the match logic does not look across previously imported batches. So split your CSV by some natural grouping and sort each chunk carefully.

    YMMV on the field accumulation — we saw some inconsistent behavior with custom fields where the second record's empty values overwrote the first record's populated custom fields. Couldn't reproduce reliably though, so might have been user error on our end.

  • Thank you, Eli and Devon. The extension stripping behavior is noted — I will sanitize phone numbers accordingly.

    Regarding custom field accumulation: I have confirmed in a test environment with 50 records that empty values in the second record do not overwrite populated values in the first. However, I cannot guarantee this behavior at scale.

    I have one follow-up question: Is there any mechanism to receive a report post-import indicating which records were merged versus created? The Audit Log does not appear to capture import-level operations, only individual record changes.

Reply
  • Thank you, Eli and Devon. The extension stripping behavior is noted — I will sanitize phone numbers accordingly.

    Regarding custom field accumulation: I have confirmed in a test environment with 50 records that empty values in the second record do not overwrite populated values in the first. However, I cannot guarantee this behavior at scale.

    I have one follow-up question: Is there any mechanism to receive a report post-import indicating which records were merged versus created? The Audit Log does not appear to capture import-level operations, only individual record changes.

Children
No Data