The magic behind the Marketing Cloud Connector

The first thing that came to my mind when I started to study about the Marketing Cloud Connector was the famous scene of the movie Interestellar when the bulk beings can perceive five dimensions as opposed to four, able to see every moment in the past, present, and future.

In spite of the obvious differences, the Marketing Cloud Connector is able to connect different dimensions in the Salesforce Universe, the information suddenly appears in Marketing Cloud coming from a parallel world called Sales Cloud or Service Cloud.

From now on, we could call it “The Connector” and, long story short, it is the link that allows the synchronization of the data between Marketing Cloud and Salescloud. Before going into details about the configuration, the Connector is the way we can feed Marketing Cloud to build our campaigns and journeys.

When in doubt, doubt the doubt!

The most common architecture diagram of a Marketing Cloud project includes Marketing Cloud, Sales Cloud (or even more Clouds), a data warehouse, reporting tools, other mailing tools… but, that is not necessarily the unique reason to start synchronizing our customer data between the different systems.

As we mentioned in previous posts, most of the decisions should be made based on the source of truth, the system that is allocating the master data. So, if this is the case of Sales Cloud, then the Connector turns to take the pitch.

The aim of the Connector is to synchronize just the objects and fields of Sales Cloud that include the information we need to do marketing in Marketing Cloud: send emails, targetting, create journeys, send SMS, trigger campaigns, interact with Sales Cloud…

In case of doubt and as a best practice, once the Connector has been configured, do synchronize just the list of essential objects and fields you need for an initial set-up and, later on, start to add new fields as it is being needed for the upcoming campaigns. Please note that the more information we synchronize, the more time Marketing Cloud takes to process it, as it happens in the performance in Journey Builder.

The Connector set-up

The configuration itself is really straight forward (I will not commit in a time effort estimation) but it is really fast to do it.

The important point here is the definition of the previous step: decide the architecture of the Business Units, how is the data model in place, what information has to be synchronized, decide between scope or non-scope by user, Production vs Sandbox… This is what really takes a lot of time in terms of business decision and the technical point of view, but it is needed to make sure all the teams and the business needs are considered before starting with the set-up of the Connector.

The configuration has to be done both in Marketing Cloud and Sales Cloud by the Admins, and the steps to follow are really well explained in the documentation.

The rule of the 15 minutes

15 minutes, that is the number we have to keep in mind. 15 minutes is the minimum period of time the Connector refreshes the data from Sales Cloud to Marketing Cloud. It is a unidirectional synchronization. If we want to update something from Marketing Cloud to Sales Cloud then we have to talk about Journey Builder, AMPScript, APIs…

Every time a new object is synchronized, a new Synchronized Data Extension is automatically created and updated every 15 minutes in Marketing Cloud. In essence, it works as a standard Data Extension: we can create SQL queries and filters based on it, but not using it as the entry source of a Journey, for example, as it is a ‘live table’ whose data is updated periodically.

Label Name VS API Name

This is probably the most controversial topic. Once the Connector is working and we start working with information coming from the Synchronized Data Extensions, we realize that the name of the fields don’t match with the ones we are familiarized with in Sales Cloud.

This is because the Connector retrieves the API name of the fields instead of the label (the user-friendly one). From my point of view, this is a limitation of the feature but we have to deal with it.

This is the main reason why marketers, admins and the people that are working with Sales Cloud have to sit together to understand how is the information stored: which attribute of the customer is stored where and under what name? how many different objects do I need to create the target for my next campaign?

The standard fields in Sales Cloud already provide a standard API name but we can customize it when creating custom fields so, in a way, we can become these fields more user-friendly for the end-user.

If this is not an option, there is another workaround more customizable but it could compromise the ‘real-time’ of the synchronization. The way it works is basically based on using SQL queries to translate the API name of fields of the Synchronized Data Extension into a user-friendly name in a new Standard Data Extension.

Email tracking, to sync or not to sync?

We talked about customer data, objects and fields but, what about the email tracking? We can also synchronize it to Sales Cloud but we have to consider that the pricing licence in Sales Cloud is storage-based, so here we have another business decision to make.

We can synchronize all the email tracking, just the aggregate one of a period of time, or directly do not synchronized it.

Closing the loop

Now we know how the information travels from Sales Cloud to Marketing Cloud, it is time to see how it works the other way around.

The first note is that it is not automatic done but we can make it work (and in real-time). That is why we mainly have Sales Cloud activities in Journey Builder, AMPScript code or APIs integrations. The most used is the Journeys approach. We have activities specifically created to create or update fields in Sales Cloud, that we can easily drag-and-drop and configured directly from the canvas.

Please make sure a Sales Cloud Admin or the end-user, with the right knowledge of the data model in Sales Cloud, is checking the configuration of these activities in the Journey as we are working with data in Production that may impact the entire database.

It works the same way with AMPScript and the API calls. There are specific functions that can help us to improve the campaigns where we need to work with real-time interaction.

For example, when we send an email where we offer some of our products and, by the time the customer (or lead) clicks into the product image we need to create an Opportunity in Sales Cloud. Or when we want to update the customer preferences by the time he clicks in the ‘Submit’ button of our custom preference center created in Marketing Cloud using CloudPages.