Recently we had the privilege to help a retailer in the Netherlands to take the next step in their ambition to transition from an order-centric to a customer-centric company by implementing Salesforce. A major part of this transformation is enabling personalized, integrated, and continuous experiences to customers. How? By bringing together all customer data dispersed in different systems like SAP (for order management, logistics and financial processes), webshop (for all internet orders), marketing tools, spreadsheets etc, the renowned Customer 360.

    Although this organization is not unique in its ambition, a recent Mulesoft study shows integration is still a significant challenge for 85% of global organizations — stalling digital transformation projects and negatively impacting customer experience and revenue. In addition, this study shows that, in retail organizations, 91% of respondents report that data silos are creating business challenges.

    This project was no different, and integration was one of the significant challenges. However, by utilizing the suite of available options for integration with Salesforce and combining this with the strength of the MuleSoft Anypoint Platform we jointly set a major step towards a Customer 360 view, and we delivered the first modern, flexible and reusable set of APIs. In this blog post, we will share some of the learnings.

    1. Utilize the power of events

    Nowadays, Salesforce offers a wide range of events enabling an event-based architecture like Streaming API, Change Data Capture and Platform Events. We fully exploited the new capabilities in the Spring ’20 release, where many new objects got enabled for event notifications through Change Data Capture. Ideal for quickly notifying other systems or applications of changes in data. In cases where we wanted more control over the event that was published, we used Platform Events.

    Utilizing these two types of events enabled us to set up integrations with configuration, and without code. From now on, we can use Before-Save updates in Salesforce Flows. This was introduced in the Spring ’20 release. Important, as, for reasons of maintainability, we strived to keep the system free of custom development. Only when strictly necessary, we used custom development.

    The Salesforce Connector on the MuleSoft Anypoint Platform can quickly subscribe to the events and distribute the data to any system that needs an update in any format required. This way-of-working makes the solution extremely flexible.

    The event-based architecture is an excellent option for outbound events. However, it can also be useful for inbound events. For example, in an inbound scenario, a platform event can be published from Mulesoft, starting a process builder or a flow to enforce the required business logic in Salesforce.

    1. Apply data virtualization where it makes sense

    Whereas the event-based architecture is great when distributing data, in some use cases, it is not necessary to physically store the data in Salesforce. In these cases, Salesforce Connect is very useful to virtualize the data. Examples of this are simply showing sales orders and deliveries that reside in another system like SAP ERP. By virtualizing the data, the overall solution becomes less complex and better maintainable.

    With Salesforce Connect you can use the virtualized data as External Objects, just like any standard object, on every screen, in every search, and on every report without the need to store the data in Salesforce. When trying this without Salesforce Connect, custom development is necessary for each and every occurrence. However, when using Salesforce Connect, this can be done with configuration only—again contributing to the maintainability and flexibility of the solution.

    Of course, Salesforce Connect is no silver bullet and should only be applied there where it makes sense. Examples of use cases where Salesforce Connect does not make sense include situations in which standard functionality in Salesforce requires the data to be stored in a standard object. For example, case management functionality which cannot function when cases are virtualized. Also the performance of the lookup must be sufficient so it does not hinder the user experience.

    As Salesforce Connect requires OData, the Mulesoft Apikit OData extension provides great value in enabling OData APIs, even when the backend does not support OData.

    1. Create an Application Network for reusability

    When designing and implementing the APIs, we profited from Mulesoft’s API-led Connectivity Approach that results in an Application Network. Adopting Mulesoft’s three-layered approach has proven to be successful in developing reusable assets that were easy to adapt to changes. This approach significantly contributed to a very stable go live and the ability to solve the (few) hypercare issues quickly. In addition, by making them discoverable, this empowers the business to tap into the APIs to realize business value.

    Reusability is spurred by exposing every integration asset as a managed API. In practice, this means that, for example, an integration asset used in a data virtualization scenario (reading sales orders from SAP ERP) is set up in such a way that it can easily be reused. For example, in a scenario where the sales orders need to be synchronized with another system, which requires an entirely different integration pattern than the OData pattern in data virtualization. This increases developer productivity and lowers the overall total cost of ownership.

    By applying these practices, it is perfectly possible to design and implement a modern integration architecture without substantial custom development. Do you have any questions regarding Salesforce Integration and/or Mulesoft? Or do you want to know more? Nextview has extensive Salesforce, Mulesoft and SAP experience and can help you with any integration challenge. So, please reach out to me by dropping me a message at