Consolidating contact info from multiple sources (without duplication or omission)

Topic Labels: Base design
429 0
Showing results for 
Search instead for 
Did you mean: 
5 - Automation Enthusiast
5 - Automation Enthusiast

Hi all,
Here’s where I’m trying to get:
A business contacts CRM that is both a DB of all contacts, contact-specific files & links, and also has multiple “pipelines” for each contact.

The core consideration is this:
Contacts can originate from multiple sources: Instagram, Twitter, IRL, etc which will determine which FIRST unique identifier I acquire. Sometimes it will be insta’ handle, sometimes a name, sometimes an email.

Then as said, I will have different pipelines (journeys/kanbans) for different products, etc. I need a way to link to a record (a unique identifier) without knowing WHICH identifier I’m going to get first. Does it make sense to create unique internal IDs that become my “common language” across all tables?

I was init trying to create a sheet for each social platform, and then wanted any new entry on that table to auto-populate into the master contacts table where additional info can be entered as know. This was just for cleanliness and not having to side scroll TOO but…

a) is this making two tables where one will do? (ie keep social contact info for each platform on a single table?) Is there a reason to have a table for each social platform?

b) I’m worried about creating multiple records for a contact when a common identifier isn’t yet known; anyone have a solve for this? Example: someone engages with us on Insta’ AND then fills out a form with an email address. Does it make sense to create an internal “contact-ID” rather than use name, email, handle, etc (mindfull that I wont always have some of these at 1st contact)

(and yes, i’ve read a few articles here on base structuring) but given the above, 1) how would you divide data up for ease of use)
and 2) How best to pull new contacts from multiple sources, create non-duplicated contacts, and then link records across tables when their may not “yet” be any common identifier known.


0 Replies 0