SFMC - OOB Connectors vs Custom REST builds

On a recent assignment I had the opportunity to work on a Mulesoft-SFMC integration. Mulesoft, recently bought by SF, is one of the leading enterprise ETL PaaS providers and readily integrates with third party platforms using industry standard RESTful/SOAP API endpoints.

Mule Anypoint

Generally I was impressed with the Mule suite of features and components. The Mule Anypoint platform provides quick, efficient integration capabilities along with out-of-the-box patterns and functionality for streamlining data flows from source to target systems. These patterns allow rules to be implemented that can schedule, consolidate and error-handle large batches of data in near-realtime if necessary. On top of that Mule has a suite of connectors allowing low-code out-of-the-box integration with third-party platforms like SFMC.

Connector API limitations

Like Marketing Cloud Connect the Mule SFMC Connector uses the SFMC SOAP API. The SOAP API is a good fit for most requirements involving basic operations with Email Studio as well as providing programmatic access to Automation Studio. And given our use cases were quite straightforward SMS and Email triggered sends Mule/SFMC validated Connector seemed like a safe bet. But of course there were a few caveats.

Firstly, SFMC retired SMS sends from Email Studio last year. Whilst this makes perfect sense in terms of avoiding duplication of functionality it reduces the scope of functionality and channel messaging the SOAP API, and thus Connectors, can support.

Secondly, whilst the Mule SFMC Connector does allow for easier integration between Mule and SFMC much like Marketing Cloud Connect does with Salesforce CRM. But unlike MC Connect calls still need to be written using the SOAP API methods and routes.

More REST needed

Connectors need to start supporting the SFMC REST API. Whilst the SOAP API is a mainstay for programmatically accessing SFMC functionality it's limited to Email Studio and can't support the more sophisticated marketing applications like Journey and Content Builder. Support for Automation studio functionality is great but API driven automations aren't viewable via the SFMC GUI which makes monitoring and QA problematic. And now with the retirement of SMS interactions the SOAP API is only limited to the Email comms channel.

Right now any use cases needing more sophisticated functionality than simple triggered email sends require custom REST builds which defeats the purpose of introducing Connectors in the first place to an extent.

That said the REST API is lightweight and easy to implement, particularly on a platform like Mule. However, given the customisation needs it's still an option that contributes more to an eco-systems technical debt than a low-code/OOB connector would.

Hopefully SF will re-evaluate its Connector strategy and find a way to introduce more REST support. Until this happens custom REST implementations remain the best way of implementing cross-channel use cases for the time-being with Connectors best used for simple email sends or automations.