2

I have clients who recently mentioned, whenever they trigger a particular action in their sandbox, the record gets injected into live SFMC journeys if it meets the criteria.

This is very strange as SFMC is only connected to Prod, not to Sandboxes (just one BU). I was wondering if others have experienced this?

The only thing I noticed is that these clients made a copy of the prod CRM org (so including the managed package, connector settings, API user etc) after the SFMC connector was set up in Prod.

However, the sandbox org ID is different, so technically any Sandbox records should not go into MC?

1 Answer 1

0

I found something in "my documentation", original source is Salesforce Partner Community from 06/2019. I can share the deeplink if you have access. All of the following is a full quote, I am just not using the syntax so it works with the code samples:

"In the past, when you refresh fully copy sandboxes, the MC connector connection on the sandbox would be broken regardless of the connector settings you have.

However, this expected behaviour appeared to have changed lately. Now, it appears to copy the live MC API user token into the full copy sandbox and the connector works with it as well. Hence, you run into a situation where both the full copy sandbox and prod org virtually being connected to the same production MC BU (ie. Both authenticated as the same MC API user) and Journey Builder doesn’t differentiate between the org origin of the API call.

Hence, any triggering JB Process Builder entry events from the full copy sandbox would actually call the corresponding production Journeys as long as the entry criteria is met. In the case where there are Salesforce AmpScript retrieves on the corresponding Journey emails, they will throw errors as they would be using the IDs from the full copy sandbox but querying the production org instead.

One would have to execute the following script in the dev console to clear the API user token manually upon the completion of full sandbox refresh to prevent this from happening (replace MID# with actual number):

et4ae5.SupportUtilities.deleteUserTokens('APIUSER')
et4ae5.SupportUtilities.deleteUserTokens('APIUSER|MID#')

This behaviour appears to only affect the full copy sandboxes and potentially partial copy sandboxes as well. Given that the connector requires specific managed package custom object records to function. As a precautionary measure, it is recommended running the scripts above for any full & partial copy sandboxes upon refresh or creation.

Please also note that this behavior goes against the behavior outlined in the following help article: https://help.salesforce.com/articleView?id=000249278&type=1&sfdcIFrameOrigin=null "

2
  • Thanks Jonas! I just got the same reply from Salesforce Support. :) Commented Apr 18, 2021 at 22:41
  • when I run the script et4ae5.SupportUtilities.deleteUserTokens('APIUSER') et4ae5.SupportUtilities.deleteUserTokens('APIUSER|MID#') in the dev console I get: et4ae5.SupportUtilities.DELETE_USER_TOKENS_FAILED can someone help? Commented Feb 29 at 11:03

You must log in to answer this question.

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