Current State: Subscribers from one of the child business units (let's call it - ChildBU_ABC) needs to be separated and we need an easy way to distinguish subscribers from this child business (so subscribers do not get mixed up with other business units).

For example: [email protected] can exist in multiple business unit

Requirement is: To keep [email protected] separate in ChildBU_ABC separate from other business units

Reason: Legal reasons as we do not want emails from other BUs to be sent to subscribers from this BU or status from others shouldn't impact this BU

Workaround: One solution I came up with is that when contacts will be imported in Data Extensions as email audience (before they are subscribers), the subscriberkey can be a concatenation of email and a value something like

ChildBU_ABC|[email protected]

Is this a good approach? I think for this approach, we will need to always need to add a step after DE import where we create a new subscriberkey value.

Any recommendations on this approach? or a different idea?

NOTE- In this case there is NO connected CRRM. Hence, there is no unique identifier.

  • 1
    Is this account not connected to a Salesforce ORG or any other CRM that already provides unique user identifiers (like subscriber keys)? Using email addresses is as unique identifiers is always a bad idea as they can change over the lifetime of a client Oct 24, 2023 at 6:33
  • That is correct, we don't have a CRM. Amd in this case these contacts that I'm referring to do not have a unique identifier. Yes, I agree email as subscriberkey is not a good practice but in this case there is no choice hence looking into this approach. Please advise
    – kl2
    Oct 24, 2023 at 10:01

2 Answers 2


Understood: The "recommended" way (sales cloud as identity provider) is not possible. Make it known that there is a high chance of this coming back and biting.

Second best, by some margin - custom build your own stuff.

Even then - never use email as subscriberkey.

Tons of reasons. Three:

a) emails change. Keys shouldn't.

b) emails are Personally Identifiable, keys shouldn't be. You want to pass them around, they will be in every table etc. You risk data breaches where it's completely unnecessary. Don't.

c) emails are shared. Keys should't be.

These are all terrible mistakes. You say "you have no choice", but you do.

If you need something unique, use a GUID. This can be done in AMPScript, SSJS and SQL, in other words, in any automated process. No non-automated process should assign Ids anyway. So any import will have to be processed in some form.

Tons of systems assign GUIDs. So be sure to prefix the guid so you have a common pattern. Just like Sales Cloud makes a Contact 003 + something unique, build your key something like xyz_guid() where xyz_ is static and thus recognizably "assigned by you", and guid() is always unique. Even if you have other weird processes going, you'll always recognize "your keys"

SQL: newId()

SSJS: Platform.Function.GUID()

AMPscript: GUID()

all of these can be concatenated (e.g. SET @myCustomKey = concat("xyz_",GUID())

  • Hi Jonas, thank you so much for sharing your feedback. Yes, I completely agree with your recommendations that email as subscriberkey is not the right approach. The complexity in our use-case is that import of contacts / subscribers is NOT going to be once to any central or common data extension that will act as a database. But, audience will be imported each time there is a new campaign since email marketing is very much based on imports (which involves a mix of contacts and prospects coming from different sources).
    – kl2
    Oct 24, 2023 at 11:53
  • Assigning a unique ID / Key within SFMC is going to be challenging in this specific scenario since a sub-set of the audience may be common in some audience data extensions and some population may be unique. Hence there is no each way to track what ID has been already assigned to a subscriber and what not. Hence, my question was around EmailAddress since that is the only common value that will stay the same across all audiences. If I decide to concatenate (MID + EmailAddress), the generated value will be consistent. But, if you have any recommendation to overcome this challenge, please advise.
    – kl2
    Oct 24, 2023 at 11:56
  • Hi @Jonas , I just wanted to ask if you got a chance to review my response?
    – kl2
    Oct 24, 2023 at 21:24
  • You describe a design / architecture problem. It needs a design / architecture solution, it is NOT a good idea to knowingly add technical debt on it. That way you'd simply have two problems. An "interface" that means imports happen anywhere, anytime unchecked, needs a better design incl. some form of centralized ID generation. Also note: billable Contacts are NOT created on import from anywhere (just in MCC Synch), they are created on send. So you have the chance to create keys after import. Use email to deduplicate, but the keys you assign should definitely under no circumstance be emails. Oct 25, 2023 at 6:45
  • Thanks Jonas for your response. I agree this is not the best use-case scenario where there is no centralized tables & import will be happening anytime, anywhere. But, this is the current business use-case as email recipient lists will be coming on AdHoc basis from multiple sources for every new outside email. Adding a middleware system to generate IDs is just not an option. Option 2, post import, are you suggesting adding the audience in a centralized DE and then each import should have a step to match records with the central ID then delta should be assigned ID? Isn't that a technical debt?
    – kl2
    Oct 25, 2023 at 23:51

I would go about the below solution instead of making the email address as a unique identifier.

  • Once the data is imported , add a sql query that will generate a random id and append it with BU MID instead of BU Name (As BU Name may change due to rebranding and similar reasons).

  • The SQL can look like something :

    select email, concat(BU_MID,newid()) as subscriberkey from ImportedDE

If you feel that the primary key is too long, you can shorten the newid() as left(newid(),8).

Another issue that can happen if you include the email address in the unique identifier, if the email address changes, you will start having the issue of bad data. Hence, it is a best practise that you use a random id (along with appended BU ID) as the subscriberkey

  • Hi Swati, thank you for the recommendation. I'm my case, audience will be imported in different data extensions (in other words, different campaigns will have different imported audience in DEs).. So, assigning a random NEW ID, how to keep a track of these new IDs? Also- what is the likelihood of not getting the same ID if there are multiple audiences saved in different DEs where an email address may exist in different DEs, so uses may end up assigning multiple IDs to same emails.
    – kl2
    Oct 24, 2023 at 11:16
  • In other words, there is no central database. The emails will be sent based on imported audience in data extensions. Each new campaign will end up with new data import and new data extension.
    – kl2
    Oct 24, 2023 at 11:20
  • Hi Swati, I just wanted to ask if you got a chance to review my response?
    – kl2
    Oct 24, 2023 at 21:23
  • Hi @Swati Mishra - I wanted to follow-up if you got a chance to review my response.
    – kl2
    Nov 1, 2023 at 11:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .