I had some prior experience with other marketing automation platforms when I first started using Salesforce Marketing Cloud, which made it simpler for me to comprehend its features and how it differed from its rivals. But I didn’t begin to understand the questions I ought to be considering when assessing a solution at the enterprise level until I started working with other Salesforce Architects and Enterprise Architects who weren’t experts in Marketing Cloud. That was laborious and time-consuming. The Salesforce Well-Architect Framework would have been quite helpful in such situation.

Although the framework mostly concentrates on the core Salesforce platform, the ideas it covers can also be used to other tools. I’ve been able to apply the clear structure it provides to the solutions I’m working on. Let’s look at a few instances:

Is your solution safe?

A client of mine wanted to develop a unique profile and preference hub that would be usable from both the Salesforce Commerce Cloud and the Marketing Cloud . We would have used the regular Marketing Cloud capability, which uses the SubscriberKey to identify contacts and automatically encrypts it, if Commerce Cloud hadn’t been a part of the solution. In our situation, however, this wasn’t an option, therefore we were forced to identify clients by sending the Salesforce Contact ID from the Commerce Cloud to the Engagement Cloud Page.

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:

• Do you transfer any personally identifiable data between platforms that has to be encrypted, such as ContactID and Membership ID?
• Does your product adhere to all relevant industry standards for data encryption?

Do you have the necessary procedures in place to abide with the law?

In a number of different jurisdictions, data privacy laws include provisions for the right to be forgotten. To erase all information about a contact upon request, organisations must have the proper systems in place. There are many intricacies to bear in mind when it comes to Marketing Cloud, and data privacy is explored in detail in Well-Architected — Compliant.

One is that it can be simple to believe that deleting a contact record in CRM would also delete it from Marketing Cloud if Marketing Cloud is integrated with your primary CRM platform, but this isn’t always the case. Records that have been deleted from your Salesforce CRM system no longer appear in Marketing Cloud’s synchronised data extensions. Create a custom automation to locate the records and remove them from the underlying database tables if you genuinely wish to delete them.

Additionally, subject data access requests (SDARs), which are official queries regarding information an organisation has acquired, are difficult to respond to since Marketing Cloud does not offer an enterprise-wide searchable interface. The key is having thorough documentation on the tables and data extensions where your contact information will be kept, as well as a process flow diagram for supporting SDAR. Here is a comparison of the various methods for Marketing Cloud data collection. More information on the significance of excellent documentation may be found in Well-Architected — Simple.

When using Marketing Cloud, the following questions should be on your mind about compliance:

• How will your solution manage requests for subject data access or the right to be forgotten?
• Do you need to create an automated to make sure you can abide by local laws?
• Are any specific reports required to be created in order to comply with regulatory requests?

In your automations, have you taken data quantities and error handling into account?

The query will fail if you are exporting data from SFMC and the data extension you are exporting from is blank. You can easily stop the export when there are no data by simply adding a verification activity before the export so that the automation can proceed without interruption.

The effort required to fully automate their solution will probably not be worth the impact if users only need to conduct a certain action on 1-2 records every month. In this case, you might think about using a manual method.

You should get familiar with Well-Architected — Reliable and the Marketing Cloud restrictions described here before using greater volume scenarios. A Data Extension can hold an unlimited amount of rows, however for Data Extension Extracts to be successful, the target Data Extension should have no more than 30 million rows and 10+ columns. Learn about the suggested thresholds if you’re using APIs to update your data extensions.

Sometimes a specific asset (such as records in a data extension) is unrestricted, but other features utilising that same asset (such as Amp-script lookups, data extracts, and queries timing out after 30 minutes) are restricted. So, some queries to consider are:

• By eliminating records that are no longer required, are you maintaining proper platform hygiene?
• Do your automations provide a return on investment, and do you construct them in priority order?
• Do the automations in your solution gracefully manage errors?

Although certainly not all-inclusive, I hope these ideas and questions will enable you to develop more durable and dependable Marketing Cloud solutions for your clients.

I am also forward to hearing from you.

What are some of the questions you really must ask?