Applying Salesforce Well-Architected to Marketing Cloud Implementations
When I started with Salesforce Marketing Cloud Engagements, I had some experience with other marketing automation platforms, which made it easier for me to understand its capabilities and differences from other competitors. But it wasn’t until I started working with other Salesforce Architects and Enterprise Architects that weren’t specialized in Marketing Cloud that I started to appreciate the questions I should ask when evaluating a solution at an enterprise level. That took time and was not easy. Having access to the Salesforce Well-Architect Framework would have made my life much easier.
While the framework primarily focuses on the core Salesforce platform, the concepts it covers can be used with other tools as well. It provides an easy-to-follow structure that I’ve been able to apply to the solutions I’m working on. Let’s take a look at some examples:
Is your solution secure?
One of my customers wanted to create a custom profile and preference center that would be accessible from both Salesforce Commerce Cloud and Marketing Cloud Engagement. If Commerce Cloud hadn’t been part of the solution, we would have used the standard Marketing Cloud functionality, which uses the SubscriberKey to identify contacts and encrypts it automatically. This wasn’t an option in our case though, and we ended up having to identify customers by passing the Salesforce Contact ID from Commerce Cloud to the Engagement Cloud Page instead.
Our approach worked, but it also created a new issue since Marketing cloud doesn’t perform the same encryption by default in custom solutions. So passing the Contact ID as a parameter without encrypting it could have given anyone access to personally identifiable customer information which would have resulted in the loss of trust and legal issues.
The Well-Architected framework helped us realize that we needed to prioritize finding a way to encrypt the ContactID. When you are evaluating your Marketing Cloud solutions, make sure to ask yourself:
- Are you passing any personally identifiable information across platforms that should be encrypted (e.g. ContactID, Membership ID)?
- Does your solution meet all applicable industry requirements for data encryption?
Do you have the right processes in place to comply with legal guidelines?
The right to be forgotten is included in data privacy laws in a variety of different regions. This means that organizations have to have the right mechanisms in place to remove all data about a contact upon request. Data Privacy is covered extensively in Well-Architected — Compliant and there are a lot of nuances to keep in mind when it comes to Marketing Cloud.
One is that if you have Marketing Cloud connected to your core CRM platform, it can be easy to assume that deleting a contact record in CRM will also delete it from Marketing Cloud, but this actually isn’t the case. Deleting records from your Salesforce CRM system only stops them from appearing in synchronized data extensions in Marketing Cloud. If you want to actually delete the records, you’ll need to create a custom automation to identify them and remove them from the underlying database tables.
Additionally, Marketing Cloud Engagement does not provide an enterprise-wide searchable interface, which makes it difficult to address subject data access requests (SDARs), which are formal inquiries about information an organization has collected. Having good documentation about the tables and data extensions where your contact information will be stored and mapping the process that should be followed to support SDAR, is key. Here is a comparison of the different ways in which you can gather data out of Marketing Cloud Engagement. You can also read more about the need for good documentation in Well-Architected — Simple.
Questions to ask yourself about compliance when you’re implementing Marketing Cloud are:
- How will your solution handle right to be forgotten or subject data access requests?
- Do you need to build an automation to ensure that you can comply with local regulations?
- Do you need to design any special reports to support regulatory requests?
Have you considered data volumes and error handling in your automations?
If you are exporting data out of SFMC and the data extension you’re exporting from is blank, the query will fail. By simply including a verification activity prior to the export you can allow the automation to continue running without failure but stop the export when there are no data.
If users only have to perform a certain action on 1–2 records per month, the effort involved with fully automating their solution likely won’t be worth the impact and you should consider using a manual process instead.
For higher volume scenarios, you should familiarize yourself with Well-Architected — Reliable and the Marketing Cloud Engagement limits documented here. There is no limit to the number of rows a Data Extension can store, but in order for Data Extension Extracts to complete successfully, their target Data Extension should be limited to less than 30 million rows/10+ columns. If you are using APIs to update your data extensions, familiarize yourself with the recommended thresholds.
Sometimes there are no limits to a specific assets (e.g. records in a data extension), but limits apply to other functionalities using that same asset (e.g. Ampscript lookups, data extracts, queries timing out after 30 mins). So some questions to ask are:
- Are you maintaining good platform hygiene by deleting records that are no longer needed?
- Is there a return on investment associated with your automations and are you building them in priority order?
- Do the automations in your solution handle errors gracefully?
This is obviously not an exhaustive list but I hope these considerations and questions will help you create more robust and reliable Marketing Cloud solutions for your customers. I am keen to hear from you as well. What are some of your must ask questions?
Resources
