When you send to a Salesforce Report in Content Builder, the platform creates a temporary DE in the Root DE folder with a retention policy of 5 days named SalesForce-[guid], for example: SalesForce-a5ec4b43-9080-4dd4-93b5-a9650c4072b5 (and I thought Salesforce didn't have an uppercase F!).

Anyway, the following fields are created in the Sendable DE with the Subscriber Key relationship of "SubscriberKey relates to Subscribers on Subscriber Key".


So far so good. However, I note that sometimes when I select a Report of Salesforce Contacts (as the target audience in Contact Builder Send Flow), some Contacts are assigned a GUID value for the SubscriberKey, instead of an 18 digit SF Id, as per the example below:


This is problematic as [I assume] that the Subscriber record would be created with the Subscriber Key as this GUID value?! Also, I have some AMPscript code in my email to lookup fields from Contact_Salesforce sychronized DE based on the value of the _subscriberKey system personalization string.

Does anyone know why this behavior occurs? I'm trying to come up with a logical explanation and can't. These are not brand new Contacts (they have been in Contact_Salesforce DE for a while). I can't figure out why this would happen.

  • My guess is that this is treated same as Triggered Sends that are set to not add to All Subs. (Sent to hidden TSD table, not to All Subs). So, in order to allow multiple iterations of Report Sends to go out uniquely, they put a random GUID as Subkey in the 'temp' de so they do not interact or connect with any other sends. To get around your issue with _subscriberKey is to place a conditional looking at _DataSourceName and see if it starts with SalesForce- if so use value from SFOrgID instead of _subscriberKey in your variable used for lookup – Gortonington Apr 4 '19 at 13:08
  • 1
    @gortonington: I think you mean AlternateKey as substitute field for _subscriberkey. The SFOrgId identifies the connected org. – Stephan de Paly Apr 4 '19 at 20:50
  • You are correct @StephandePaly. That is what I get for rushing. – Gortonington Apr 4 '19 at 20:51

I don't have an idea why this would happen in the context of normal behaviour. This looks like some sort of api issue where it fails to set the subscriberkey correctly and then uses this guid to create a valid row. You should raise this with support.

If it is somehow practical for your send context you could do the following to avoid creating weird subscriber data (yes, it's cumbersome as hell):

  1. Include an exclusion script that checks the subscriberkey field for strings that do not match the contact syntax (003...) or do match the guid syntax
  2. Create a filtered DE based on the same logic.
  3. Change the subscriber relationship of the filtered DE to AlternateKey (this still contains the correct contact id value)
  4. Move the filtered DE to the Salesforce Data Extension folder structure
  5. Send the email to this audience as well

However, I suspect that this a known issue for which they created the AlternateKey field in the first place. They probably configured a backend process that identifies ill-set subscriberkeys and switches to AlternateKey for subscriber relationship at send time.

I would really be interested in what support has to say about this...


The GUID happens because the contact was sync during the deleting process


Understand How Contact Deletion Functions with Synchronized Data Sources

If you delete contacts in Marketing Cloud and a data source synchronizes before the deletion process completes, the process adds a contact record in All Contacts with an 8-4-4-4-12 character UUID. To prevent this occurrence, delete contact records from Sales or Service Cloud before deleting contacts in Marketing Cloud, or turn off the data synchronization process for that data source. These new records include the actual Salesforce ID in the ID field of the synchronized data source. The _contactkey field contains the UUID-style contact key used in All Contacts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.