How to connect Salesforce to your CMS: challenges & issues

Connecting the CMS to Salesforce is a major demand among Jahia users. With Salesforce integration, companies can synchronize data from their CRM with data collected on their website, in either direction. This makes it possible, for example, to improve personalization on the website thanks to data included in the CRM, or to refine the sales approach thanks to prospect behavioral data collected on the website and transmitted to Salesforce.

We asked one of the architects of this connector to tell us more about its capabilities, and help you understand how you too could benefit.

Can you tell us how this integration came about?

In Apache Unomi we have a powerful rules engines that is not very visible to most newcomers, but, for some, enables cool ways of integrating systems. To illustrate this, we had the idea to integrate with a CRM at a very early of the project. This was even discussed during the work on the OASIS Context Server specification. Apache Unomi being an implementation of this specification, it became the logical place to provide a connector to Salesforce as an example of its CRM integration capabilities.

What does the connection between Salesforce CRM and Jahia CMS enable?

This connector integrates with the new UI rules in the Jahia CMS and makes it possible to :

• Update a Salesforce Lead from an Apache Unomi profile (rule action 1)
• Update an Apache Unomi profile from a Salesforce Lead (rule action 2)

The connector creates a correspondance between the Salesforce Leads and the Apache Unomi profiles using a common key. The usual key is the email address but other keys may be defined. The connector also enables to update data both ways.

These two functionalities are implemented as Apache Unomi rule actions, meaning that the core of the connector has actually been contributed to the Apache Foundation as part of the Apache Unomi project.

Why are the features divided between Jahia and Apache Unomi?

Jahia CDP can be seen as mostly an operational solution built on top of Apache Unomi, as well as a deep integration layer with our DXP CMS. The reason for this split of functionality is that we wanted to have an open source server that many systems could integrate with. Unfortunately we couldn't find an already existing project so we started working on both a specification and an implementation at the same time. Having a separate customer data platform makes it easy to scale and integrate in very flexible ways.

Why is it so complex for developers to create this type of connector?

There are multiple challenges :

• Building a server such as Apache Unomi from scratch is quite an undertaking. We had to clearly defined its APIs, and then build a server that is highly scalable. We made it a little easier by using ElasticSearch as the main storage and querying engine but implementing a rule engine that is highly flexible and customizable was quite tricky initially.
• Building a completely new User Interface for Marketing Factory is also quite a big project, and as in many such projects it have to go through multiple iterations to get things to the way they are today. And we're continuing to improve the Salesforce integration with Jahia!

The strong integration with Jahia's DXP solution was also an important goal from the start, without compromising Jahia Customer Data Platform’s or Apache Unomi’s flexibility. This integration really makes it possible for our existing users to complement their deployments with personalization and A/B testing using the usual Jahia DX UI. This also one of the reasons why the CDP was implemented as a Jahia DXP module that interacts with Apache Unomi through its REST API.

What are the potential outcomes of the Salesforce Unomi integration for other Unomi projects?

From a purely technical and API-first point of view, any Apache Unomi user may use the Salesforce rule actions to integrate their custom solutions.