Best way to bring SFMC consolidated data views onto SFSC PersonAccount / Contact record?

Question

We are trying to find the best way to push data from SFMC to SFSC for a given use case.

The use case is the following: as a Sales Cloud user, I want to have a clear view on all the communications a Contact has received in past X months. I want to avoid using Individual Email Results object as it consumes a lot of space and is not really customizable.

We currently have 2 options in mind:

1. Create a Lightening Web Component that will execute a GET API call towards a given data extension in SFMC with some parameters (PersonContactId, dataRange, InteractionType). This DE would contain consolidated data views (open, click, sent, ...) and would be used to return a list of filtered rows (based on input parameters) to the GET API call. The returned list can then be used to display the records in a related list.

2. Second option is to use SFSC External Objects. We could also have an API integration making sure that our DE of consolidated data views is used to fuel the external object at any time. That external object can then be used to display records in a related list on PersonAccount/Contact record.

Both solutions have pro's and con's. API consumption is one, storage in SFSC also, security might as well. I'm not going to influence here because I'd like to have different opinions, with pro's and con's, on how the community would perform this and why.

Many thanks for your help,

Answer 1

Absolutely on board with avoiding IER.

Option 1 is pretty much how I set it up (though in my case it's a POST request with preliminary authentication via OAUTH, not a GET).

• External objects are pricey

• Storage is pricey, so you'd just be in IER style problems all over again.

• Not only that, but storing the same data in two places is bad if you can do it in one. I do not see much of a benefit of storing data twice.

If the requirement is pure viewing, then a component does the job. reporting to my knowledge isnt possible both ways, that would of course change things.

• The API approach helps to keep it abstract. You can reuse the same thing for different data without a new external object etc. for each usecase. potential usecases: send history, publication level permissioning, einsteinscores, journey status, bounce status on all subscribers, list detective checks....