search

email360 / ssjs-lib

An open-source library that takes the repetitive and complex tasks and simplifies them, enabling you to get the most out of Salesforce Marketing Cloud.
http://www.email360.io
Other
50 stars 14 forks source link

Question: Can one use the SSJS library over multiple business units? #6

Closed ehsky closed 2 years ago

ehsky commented 2 years ago

Is it possible to use the SSJS library over multiple business units if one moves the lib files to a shared folder? If possible, how will this impact authentication to marketing cloud API, when communication from different source MIDs?

Thanks in advance!

shdinx commented 2 years ago

Hey @ehsky,

It is possible but a bit tricky with the current version. I already have created a new version which allows to install the Lib on multiple BU's. This version is currently in testing.

In regards to the API, I have also extended this with the new version. In the settings file you can define the account_id for generating the token so you control which account_id the SSJS lib from the given BU has access to. By default I would recommend to use a global API and the settings will hold the MID as the acocunt_id, so when the token is created, it will only have access to the given MID.

If you can not wait for the new version, here is a way you can make it work in the interim:

The key part of why an installation on multiple BU's will fail is the customer key of the content blocks. If you use the same prefix or leave it default to email360, you will get an error on the second BU as content block customer keys are unique across the entire enterprise 2.0 environment.

A quick fix is using a different prefix per BU. You could use the MID for example.

When it comes to the API, you just need to extend the settings. Under credentials, you can add the account_id parameter. Either hardcode or use the function getMemberID() from the library, or the default way of using Platform.Function.AuthenticatedMemberID();

Read around access token here: https://developer.salesforce.com/docs/marketing/marketing-cloud/guide/access-token-s2s.html

You could either share the API integration from the parent BU and control it via account_id, or you can create one integration per BU and ignore account_id. If no account_id is provided, it will use the context of the BU in which the API integration was created. This gives you the flexibility to control access to your need.

If you have BUs for different brands with different requirements or strict access rules, you better off creating an API per BU and assign it to the libs own setting file.

Hope that helps

ehsky commented 2 years ago

Thanks Shdinx for tips and guidance! Yes this was very helpful and exactly what i was looking for.

ehsky commented 2 years ago

If you need help testing i can assist. Had already started on modifying the authentication method and hardcoded getMemberId to pass to account_id. Worked but was not a pretty solution.