I have a use case where I need to send a push notification to the same mobile app from two different business units. Can multiple business units be active at one time? Or can I switch to a different business unit after the app launch?
1 Answer
It is not possible to have same app connected to multiple business units. Switching between business units in a single app is also not very straightforward, as there are few risks connected with this since you need to opt-out in one BU before you can opt-in in another one. I am trying to explain this in some more details below:
App registration is asynchronous and a “success” response to the REST route does not indicate a successful device-contact registration. As a result, the SDK will believe the registration to be successful and report such to the SDK and the app if it’s listening even though it may have failed to process server-side. Registrations are processed in-batch which will always result in some delay between success reporting to the SDK, and possibly the app, and the updated device-contact registration actually being propagated throughout our internal systems.
If you attempt to opt-out the device-contact from receiving push notifications and the registration call fails the updated opt-in to the new BU will overwrite the opt-out registration on the SDK side and the user will never get opted-out of the old BU as we always send the latest device-contact registration from the SDK without regard to what may have previously failed. As a result, the contact-device will still receiving notifications for the original BU.
The SDK will not transfer existing contact-device details when switching BUs as there is no guarantee that the BUs have a consistent configuration on the server-side. As a result, the customer must keep track of device-contact specific Attributes, Tags and Contact Key and re-set those values after the BU is switched.
There currently is no concept of “log out” in the SDK as a Contact Key, once set, may not be cleared. This can lead to a bad customer behaviour as the need for the Contact Key to be unique is not enforceable from the SDK and the customer may set a common value like “anonymous” or “logged out”, etc. As a result, devices become merged into a LIFO contact-device registration where the most recently logged out user holds connections to all the devices.
Badging for iOS can be affected if the silent push for badges is received from the old BU. As a result, the consumer will be confused about changes to the badge count without a corresponding message to associate with the change.
-
Everything Lukas says is true. If you choose to attempt a BU switch, see gist.github.com/sfmc-mobilepushsdk/… This is considered the "best practice", but will not avoid many (any?) of the complications outlined in this answer. Commented Jan 29, 2021 at 13:21
-
2@BillMote "Everything Lukas says is true." - can you please tell this to my wife? Commented Jan 29, 2021 at 13:24
-
-
Thanks a lot for clearing that up. I was using sfmc_tearDown() and then calling sfmc_configure() with a new business unit, and registered contact key with it, and it seemed to receive push notification from the new business unit. Now I know that it is not foolproof. Commented Jan 29, 2021 at 16:56
-
I am going to use .sfmc_tearDown() and switch between two BUs, and my use case will be solved using this, but will/can this function be deprecated in near future? This would render my app implementation useless. cc @BillMote Commented Feb 1, 2021 at 7:21