|
|
posted: October 14, 2022
tl;dr: When you just keep adding and adding features, you get software like Salesforce Marketing Cloud...
Lately I’ve had the fun experience of diving deep into implementing Salesforce Marketing Cloud (SFMC) on behalf of a client. I say “fun” because I enjoy learning pretty much all technology, not because SFMC itself is fun. In fact it is downright quirky, as well as complicated, inconsistent, and at times frustrating, but also powerful and feature-rich.
You can think of SFMC primarily as an email tool, although it does a bit more. I’ve used it to send bulk emails, triggered emails, and email journeys. I’ve set up and used the SFMC API, and built automations to move data into and out of SFMC. I’ve analyzed report data produced by SFMC, and investigated a variety of issues others were having with the tool. There’s always more to learn, but I’ve used it enough to form general impressions of it.
SFMC is the type of software product that results when you’ve spent more than two decades selling to corporate America, and you just keep adding features and major new areas of functionality without ever rewriting, pruning, redesigning, or re-architecting. There are parts of the user interface, such as Email Studio’s Triggered Sends, as well as the SOAP API, that make you feel like you’re using turn-of-the-century software. There are other parts of the software, such as Journey Builder with its more modern graphical user interface, and the REST API, that make it feel like you’ve lept ahead by a decade or more. Yet the SFMC folks don’t seem to bother to go back and modernize the old parts, probably because they don’t want to deprecate anything and run the risk of upsetting their corporate customers who have trained their personnel. If you still want to use the SOAP API instead of REST, it is fully documented and more feature-rich than the REST API, which is still catching up.
I’ve used the REST API, and there are a huge number of endpoints, many of which do nearly the same operation as other endpoints. If you want to add or update a contact, there are a variety of ways to do it. This creates the challenge of figuring out the best way to do a given task. Again this speaks to the folks at SFMC just adding new endpoints anytime a customer with sufficient clout asks for a slightly different, and in their mind better, way to do something.
The multiplicity of ways to do things extends to many other areas of SFMC. Want to send an email based on an external event sent by another system into the SFMC API? You can either do a Triggered Send or a very simple one-email Journey. You might not know ahead of time which is best. I prefer using Journey Builder because of its better user interface, but it also turns out that the email is sent faster: a Triggered Send email will sit in a queue for about a minute before being sent. Why can’t SFMC send a Triggered Send email as fast as a Journey Builder email? Probably because the code behind Journey Builder is newer and better written.
Quirks like the one-minute delay in Triggered Send emails being sent are why I’ve created an “SFMC Quirks” document, which I add to every time I run across something important yet non-intuitive. Want to add more than one person to a CC list in an email? You better put a semicolon, not a comma, between the email addresses, else you’ll get a cryptic error message. But first you need to enable the CC feature itself. What is the difference between “Job ID” and “Send ID”? There isn’t any: they are different names for the same identifier. There are plenty of other inconsistencies across the entire product.
The grouping of the various data extensions in the Subscribers menu of Email Studio is a bit perplexing
“Data extensions” are another SFMC feature that has clearly grown by addition over time. A data extension is a table that an SFMC user can create by defining all the columns, and then filling with data (rows) from a variety of sources. There are now four kinds: a regular Data Extension, a Shared Data Extension (which means it is accessible in all “business units” within SFMC), a Salesforce Data Extension (which means it can be made accessible to Salesforce CRM) and, of course, a Shared Salesforce Data Extension. Why is there not a single type of data extension with two checkboxes, “make shared” and “make accessible to Salesforce”? Why, in the Email Studio Subscribers menu, are they grouped and ordered as shown, which appears to imply that Salesforce Data Extensions and Shared Data Extensions belong together? I can only assume that this is the way things grew additively over time.
SFMC was not originally built in-house by the Salesforce corporation: it is the result of Salesforce’s acquisition of ExactTarget in 2013. You might think that would have given Salesforce enough time to remove all references to ExactTarget in the SFMC code. But no, you log into the product at the exacttarget.com domain, and you’ll occasionally see “ExactTarget” in the user interface and reports. I know that migrating away from an old name is more complicated than a global search-and-replace in the source code, but come on Salesforce, it’s been nearly a decade: don’t you want to claim this product as your own?
My final critique of SFMC would be much harder to change than eliminating all occurrences of ExactTarget: SFMC is not quite an event-driven, real-time system. Some aspects are: if you use Journey Builder, an external system can trigger an email to be sent, and it comes out quickly. An Automation Studio workflow can be triggered by events such as a file being deposited on the SFMC SFTP server. But other aspects of SFMC are not, and you may find yourself having to trigger an automation to run at the highest possible rate, which is once-an-hour, to get as close to real-time performance as possible. SFMC does not use a general purpose programming language to add customizations: instead, you’ll have to do most of your work in the SFMC variant of SQL, which isn’t nearly as feature rich as other SQL implementations I’ve used.
SFMC is a powerful tool, with many features that make it appealing to its customer base of large corporations. But due to its many quirks and complications, it is harder to use than other email systems. Don’t be surprised if you find yourself having to hire skilled SFMC consultants to help with the implementation.
Related post: Software that shouldn’t be fixed