On January 21, 2026 Salesforce deployed an urgent security patch to address high-severity vulnerabilities. While this patch was necessary against potential data exploits, the side effect resulted in every tracked link in every email sent from Salesforce Marketing Cloud Engagement (SFMC) prior to that date to be instantly deemed invalid.
So what does that actually mean? It means for organizations and brands with everything from multi-channel journeys, long-running welcome automations, or newsletters with a multitude of links, it was a strategic wake-up call.
The Silver Lining: Disruptive Innovation
It’s easy for many to look at this as a catalyst to hit the ejection button, but in reality, this is a classic example of “Disruptive Innovation” – an event that causes immediate pain but ultimately forces deep change. And history is full of these! Such as…
The Morris Worm (1988) when a Cornell graduate student released what was intended to be a small experiment to “gauge the size of the internet” which ended up crashing 10% of the world’s connected computers. BUT this was the literal birth of modern cybersecurity and led to the CERT (Computer Emergency Response Team).
The Knight Capital Glitch (2012) had software deployment gone wrong when the Knight Capital’s trading algorithms went rogue, buying and selling millions of shares in seconds. The results were a loss of over $400 million in 45 minutes. Knight Capital nearly went bankrupt, but it forced the financial sector (and eventually big tech) to adopt “Kill Switches,” automated deployment pipelines, and strict “Canary Testing” (where updates are rolled out to 1% of users first), which is now the gold standard for DevOps and Deployment Governance.
A simple, unpatched Apache Struts vulnerability led to The Equifax Breach in 2017 and the theft of personal data for 147 million people. The positive was that it put security front and center with leadership. Before Equifax, many C-suite executives viewed security as an “IT problem,” but after, it accelerated the adoption of laws like GDPR and CCPA, giving consumers more rights over their data.
With great resources from long-time Marketing Cloud Engagement users like Adam Thul from Polaris on how to fix things (see post here), history has a way of repeating itself, so this incident is the perfect catalyst to audit your instance through the lenses of governance, security, and long-term strategy.
Marketing Governance Framework 101
Governance isn’t about red tape. It’s about creating a “Golden Path” for your marketers. An effective model should be built on the pillars of ownership and stewardship. Executive Sponsors need to align marketing goals while managing the corporate risk and driving the overall vision. Product Owner(s) need to prioritize the backlog and manage the “Source of Truth” for data. Finally data stewards need to handle the day-to-day hygiene and ensure the integrity of subscriber data and integrations. Wrap all of this within business units that create data boundaries and sharing when necessary. This is essential and table stakes for global brands to ensure that a marketer in New York cannot accidentally email a customer list from Tokyo, while also maintaining regional compliance structures like GDPR and CCPA.
Embracing Modern Security
Salesforce has significantly tightened the screws on platform security, not only in the link security patch in January, but also API protocols. Taking a step back and ensuring identity and access management is in place so the overall “house” has the necessary locks and who has the keys needs are addressed. Multi-Factor Authentication (MFA) has to be a non-negotiable requirement. Ensuring all users (including API users) are routed through MFA or Single Sign-On (SSO) using SAML 2.0. At the user level, make sure custom roles are in place to restrict access to sensitive features like Automation Studio or Setup. Defaulting to the “everyone is an Administrator” is not the path.
Agentic Era Compliance
With the shift toward Agentforce Marketing and AI-driven agents, compliance is no longer a “set and forget” task. Consent Management has to be top of mind as regulators are utilizing tools to verify opt-outs, so preference centers must be integrated directly with the organization’s internal “Source of Truth” (ideally via Data 360) to reflect opt-outs in real-time.
Within the lens of AI transparency, maintaining an audit trail of decisions and edits needs to be put in place, especially if Einstein or Agentic workflows are generating content. This is increasingly required under new 2026 state privacy laws like Kentucky and Indiana. Finally, purging old Data Extensions and subscriber records that haven’t engaged in 18–24 months.
Here is a monitoring schedule that can be a baseline to build off of:
Task
Frequency
Purpose
User Audit
Quarterly
Deactivate dormant users and verify permission sets.
Setup Audit Trail
Monthly
Review who changed critical configurations or deleted Data Extensions.
Health Check
Weekly
Monitor automation failure rates and API limit usage.
User Audit
Quarterly
Deactivate dormant users and verify permission sets.
The Great Reset: Modernizing Marketing Governance
As we move forward in 2026, the most successful Marketing Cloud Engagement instances will be the ones that prioritize establishing a data foundation grounded in a marketing governance framework rooted in trust. Treating security as a feature, rather than a hurdle, to protect the most important aspects: a brand’s reputation and customers’ data.
If you’d like support with establishing your data foundation, governance, and security, reach out to the Sercante team. Our experts partner with marketing teams daily, designing and architecting data layers and frameworks that build trust and deeper customer relationships.
Product Note:Marketing Cloud Growth and Advanced are editions of Marketing Cloud Next and have also been referred to as Agentforce Marketing.
Managing consent records in Marketing Cloud on Core (aka Marketing Cloud Growth or Advanced Edition) has raised many questions. While most agree with the concept of consent, generating individual consent records each time a sales team member adds a new lead in Salesforce can be tedious. I’ve been asked many times if I could just create a flow to add consent when new leads are created. The answer is “Yes” and here’s how you can do it too.
Disclaimer
The Salesforce-recommended methods for capturing consent are the Consent Request element in form-triggered flows and consent imports. This record-triggered solution offers an alternative that has been thoroughly tested across multiple organizations without issue. However, due to a potential risk associated with caching, please perform comprehensive testing prior to deployment.
Consent Fields
Before creating consent records, we first need to understand the requirements. When doing a consent import, the following fields are captured in the wizard and through the import template. This process is very simple and the magic happens behind the scenes.
Channel – Communication delivery method (Email or SMS)
Communication Subscription – The individual subscription name (ex. Newsletter)
Consent Status – Indicates whether an individual has “Opted In” or “Opted Out” at the subscription level.
Email – Email address of the individual captured on the consent record.
Consent Date – The date/time that consent was captured.
When digging in a bit more, I found a field named Communication Subscription Consent Id. This field combines the email address and the Communication Subscription Channel Type Id with “#” between them to create a new field. This field is the key to creating a consent record.
Communication Subscription vs. Communication Subscription Chnl Type Id
It’s important to know the difference between these fields and where to find them. When creating your Communication Subscription Consent Id field in your flow, you’ll need to be sure to use the correct value.
The difference between these fields is that Communication Subscription Chnl Type Id references the email subscription and the channel. Communication Subscription is channel agnostic and only references the subscription.
Example
Communication Subscription – 0XlHs00000111ZZKAY
Refers to the Newsletter subscription
Communication Subscription Chnl Type Id – 0eBHs00000111n0MAA
Refers to the Newsletter subscription and email channel
You can find these values by creating a Salesforce report using the Communication Subscription Channel Type report type. You’ll see one record for each subscription and channel. In this example, I have four subscriptions on my preference page as I’m just using the email channel. If the SMS channel was in use, there would be 8 records.
Both of these values are going to be needed when creating your flow, so make a report in your org and be sure to save it. You can also view these values by accessing the records from the Communication Subscriptions and Communication Subscription Channel Types objects if you prefer.
Record-Triggered Flow Build
We’re finally to the fun part. But before we get started, consider a few questions.
Which object should trigger the flow?
When should the flow trigger?
What entry conditions should be used?
Are there any countries or states where double opt-in is required?
Start Element
I want my flow to only run when new leads are created. I also want to exclude leads that were created from a form submission. Marketing Cloud on Core forms require a consent element, so we don’t need to update these leads. Your start criteria will differ based on your needs.
Scheduled Path
Record-triggered flow can’t execute actions that make external callouts in a path that runs immediately. You can address this by adding a scheduled path with a slight delay. My path has a 1-minute delay from when the lead was created.
Decision Element
I did not exclude countries that require double opt-in from my start element intentionally. I decided to let them enter the flow and use a decision element to route them down a second path. The idea is that I can later add an action to send a transactional email to these leads encouraging them to update their subscription preferences.
Action Elements
Salesforce set us up for success by including the MessagingConsent.MessagingConsent action. All we need to do is configure it correctly and our consent records will be created. Like consent imports, you’ll need action for each of your subscriptions by channel.
When configuring actions, you’ll need to set values for the inputs below.
CommunicationSubscriptionChannelType*
This is the id that relates to the communication subscription and channel.
ConsentCapturedDateTime
Date/time that consent was captured.
ConsentId
This is the concatenated field that we discussed earlier that includes the email address and the Communication Subscription Channel Type Id.
ConsentStatus
Set value to OPT_IN or OPT_OUT.
ContactPointValue
The email address of the triggering record.
Name*
The communication subscription (id) from the report that we created earlier. This is the id that relates to the subscription only (does not include the channel).
*Note: You can create content records without these values, but I prefer to include them to more closely resemble the records created from consent imports.
Formula Resources
Next, we need to generate the consentid field that will be needed in the action elements. This can be done using a formula to generate the value using the email address (of the triggering record) and the Communication Subscription Chnl Type Id. You’ll need one resource per Communication Subscription Chnl Type Id.
Example Formula
{!$Record.Email} & “#” & “0eBHs00000111n0MAA”
Configured Action Element
Here’s an example of an action element that has been fully configured.
Final Flow
Here’s a look at the final flow.
Testing
After activating your flow, create a new lead in Salesforce. Upon creation, the consent values will be set to Opt Out. After a few minutes (allowing time for the scheduled path to run), verify the consent record was created by viewing the Communication Subscription Consent DMO in Data Explorer in Data Cloud.
Once the data from Data Cloud syncs back to the lead record, the consent values will be updated to Opt In in the Privacy Consent Status component.
Respect Consent & Be Responsible
The best practice recommendation is to create consent records using the consent element on form-triggered flows or by completing consent imports. While these recommendations make sense, generating consent records for individual records created by users can present challenges.
Record-triggered flows offer a good solution for automating consent records, but organizations must ensure compliance with regional, state, and company legal requirements. When in doubt, err on the side of caution and prioritize transparency in consent management.
In today’s international and digital business landscape, modern marketers often coordinate messaging and strategy across multiple countries or regions. Luckily, Marketing Cloud Account Engagement (Pardot) is an ideal tool to support those types of global marketing strategies. That’s because it enables marketers to find a balance between global coordination and initiatives that reflect the challenges and regulations of local markets.
Here are functions and customizations in Marketing Cloud Account Engagement that support an international marketing strategy.
Crossing Language Barriers
One of the most important considerations for an international marketing strategy is delivering high-quality, localized content that doesn’t provide any barriers to engagement through the local language.
Enable international users in a single Marketing Cloud Account Engagement instance
Administrators and individual users within Account Engagement can control the time zone, language and data formats in which the user interface (UI) is displayed.
Languages and locales currently support:
English
Japanese
German
Spanish
French
This can be configured by an Account Engagement admin upon creating a user record. Go to Account Engagement Setting > User Management Users.
Individual users can control their language and locale settings under Account Engagement Settings > Account Engagement > My Profile.
Marketing Asset Creation
While the user interface is limited to languages supported by Salesforce, all marketing assets in Account Engagement can be developed and customized in any language. For the most part, this just involves typing/inserting content in the language desired, but the following points detail areas where advanced customization is necessary to change the display language.
Form error message
The native form error message for lacking required fields in Account Engagement displays in English by default “Please correct the errors below.” This cannot be customized within the form creation wizard, but instead must be customized within the layout template.
To update, navigate to the layout template used by the form (Content > Layout Templates). Navigate to the form tab and replace the message after %%form-if-error%% with the desired text.
The structure may not exactly match the included screenshot if you are using a layout template that significantly differs from the default. Use this reference for Layout Template Form Code to determine what components may need to be updated.
Encoding special characters
You may encounter situations in which characters display incorrectly when importing data to Account Engagement. To ensure all characters display correctly, you have to use UTF-8 encoding.
Always confirm any exported data is edited and saved using UTF-8 encoding to ensure data is not improperly overwritten. To edit data with UTF-8 encoding in Excel, for example:
Export CSV data from Account Engagement
Navigate to Data > From Text (Get External Data) in Excel
Select the CSV export, and chose “Delimited” and File Origin > “Unicode (UTF-8),” then “Comma” to open the data with correct forming in Excel
Any custom layout templates developed for Account Engagement landing pages should also be sure to use UTF-8 encoding. Set the below meta tag in the <head> section of the layout template so any special characters render correctly.
Account Engagement only allows for one global unsubscribe page, which can limit the feasibility of supporting multiple languages or unique messaging on the page. However, the suggested way to allow recipients to manage communication preferences is the email preference center (EPC) feature, which enables recipients to choose specific segments they would like to be included or excluded from, in addition to universally unsubscribing.
Multiple EPCs can be set up under Account Engagement Email > Preferences Page, so customization to language and included distribution lists can be made per language.
To ensure the correct email preference center is included in different language emails, insert a link, choose “Email Preference Page,” and choose from the list of available pages.
In the form creation wizard, under 3. Look and Feel > Advanced, is a handy setting to enable a link that allows viewers to reset Account Engagement pre-population and dynamic form functions, in case it is pre-populated with the wrong information (which may be the case due to shared devices, etc.) However, similar to the form required field error message discussed above, this only renders in English by default, in the format “Not Name? Click here.”
To resolve, creating another form layout template update is required. Insert the following script between the opening and closing <head> tag in the “layout” tab of the desired layout template.
<script type="text/javascript" src="/js/jquery/jquery.min. js"></script>
<script type="text/javascript">
//Replace the Not... string
$(document).ready(function(){ var span = $('span.description');
span.html(span.html().replace("Not","Desired Replacement for Not")); span.html(span.html().replace("Click Here","Desired Replacement for Click Here"));
});
</script>
International Privacy and Data Management
With growing international business, also comes managing compliance with the various data protection and privacy laws in place across your target markets. It’s important to consult with your company’s legal counsel to ensure understanding of the regulations across various jurisdictions. Fortunately, Account Engagement includes a variety of features to enable and enforce compliant data collection and protection.
Tracking Cookies
Account Engagement uses a combination of third and first party cookies to track visitor web behavior and build a profile of data on prospects in your database. To customize how cookies behave and allow visitors to opt-out of tracking, you can:
Enable first-party cookies and disable third-party cookies under Account Engagement Settings > Account Settings
Honor “Do Not Track (DNT)” headers under by enabling under Account Engagement Settings > Account Settings
Display a banner requesting tracking opt-in in some or all countries via Account Engagement Settings > Domain Management > Edit Tracking Opt-in Preferences
Utilize the Tracking and Consent API to integrate with other systems and create custom solutions
Communication Preferences
Many regulations require that explicit and informed consent be collected before a recipient can be emailed marketing materials, as well allow recipients to revoke that consent at any time. Some industries also require detailed records of communications sent. Account Engagement enables this via:
Need help finding the right mix of Account Engagement solutions to meet your localization and compliance requirements? Reach out to the team at Sercante to get help customizing features and content in your org and enable your global team. And leave us a comment below to let us know any tips or tricks you’ve picked up for managing international teams with Account Engagement!
You’re a responsible marketer and adhere to the Salesforce Marketing Cloud Account Engagement (Pardot) Permission-Based Marketing Policy. You’ve enabled Marketing Data Sharing (MDS) rules to ensure that prospects who have not opted-in are not syncing to Pardot. Now you get a call from your Salesforce Admin about Pardot creating duplicates in Salesforce.
In this post, we’ll discuss how you can remain compliant AND prevent unintentional dupes in Salesforce.
Let’s start at the beginning
Most sales organizations use tools like Clearbit, Lusha, or ZoomInfo to research companies, find new contacts, review intent data, or enhance data.
These are perfectly valid use cases and can be very beneficial to organizations. However, the problems start when marketing begins emailing these records through Pardot.
What’s the problem? The email addresses are valid.
“Our customers certify that they will not use rented, traded, or purchased lists, email append lists, or any list that contains email addresses captured in any method other than express, customer-specific opt-in when using our system to send emails.”
Sending emails to acquired records is a clear violation of the permission-based marketing policy and can result in the suspension or termination of your account. I’d hate to be the person responsible for that!
What’s a marketer to do?
Verify your connector preferences
The first thing is to understand your connector settings in Pardot. Most accounts will be configured to automatically create prospects in Pardot if they are created as a Lead or Contact in Salesforce. This means that ANY lead or contact created in Salesforce from ANY source is going to end up in Pardot and could unknowingly be emailed by your marketing team.
Limit record entry with Marketing Data Sharing Rules
MDS is the safest way to make sure that data does not enter Pardot (Here’s a great post on MDS if you have questions – Pardot Marketing Data Sharing: Tips, Gotchas, and Setup). You can restrict which leads, contacts, opportunities, or custom objects sync to Pardot. The intent of MDS is to control the data that can be seen by the Pardot connector. The issue is that MDS does this job a little too well and this can result in duplicate leads being created in Salesforce.
MDS and duplicate records
Hold up a minute! Are you telling me that by doing the right thing, I could actually create duplicates in my Salesforce org? Yep.
Here’s the rub. Before creating a lead or contact in Salesforce, Pardot undergoes a series of checks to see if the prospect is in Salesforce already. The intent is to identify matching records and not create duplicates. Since MDS limits the visibility of the connector, Pardot is not able to find prospects who might be in SFDC from a source deemed “not marketable” if they visit your site and complete a Pardot form (for example).
For reference here are the checks performed by Pardot before creating a lead or contact in Salesforce.
Is there a lead or contact with a matching CRM ID?
Is there a contact with the same email address?
Is there a lead with the same email address?
Is the prospect assigned to a user in Pardot?
Here’s how we addressed this issue for one of my clients
Don’t activate MDS
It’s important that MDS is not activated in this solution. We want the prospects to sync from Salesforce to Pardot. We’re going to use custom fields and automation rules to make sure that we remain compliant and don’t create duplicates in Salesforce.
Create custom fields
The first step involves creating several custom fields in Salesforce and Pardot. We created first touch and last touch fields to capture the needed information on leads and contacts. In this case, we used Lead Source Detail and Lead Source Detail Most Recent.
Lead Source Detail – This is a FIRST TOUCH field that identifies the specifics of where the lead originated (ex. ZoomInfo).
Lead Source Detail Most Recent – This is a LAST TOUCH field that identifies the specifics of the most recent source that drove the prospect to your site (ex. LinkedIn).
Map data to your custom fields
We’re going to stick with the ZoomInfo example here since I see this product used in a lot of organizations. When setting up your CRM Integration in ZoomInfo, you have the ability to map fields to for your Account, Contact, and Lead Objects.
In this case, we mapped Lead Source (standard field) and the two custom fields that we created. We also set fixed values for each. Based on this configuration, any new records added from ZoomInfo into Salesforce will have the fixed values specified. This is super important.
Automation Rules
Remember the Pardot prospect mailability upgrade that took place with the Winter ‘22 release? We’re going to take advantage of it to make sure that we comply with the Marketing Cloud Account Engagement Permission-Based Marketing Policy. Don’t remember the changes? No problem – check out this post “Are You Ready for the Pardot Prospect Mailability Upgrade?” from Erin Duncan.
Automation Rule #1 – Set Do Not Email to TRUE
This automation rule will look for prospects in Pardot where Lead Source Detail and Lead Source Detail Most Recent equal “zoominfo”. This lets us know that the prospect was added into Salesforce from ZoomInfo, synced to Pardot, and that the person did not opt-in. As a result, we’ll mark the record as “Do Not Email.”
Automation Rule #2 – Set Do Not Email to FALSE
This automation rule will look for prospects in Pardot where Lead Source Detail is “zoominfo” and Lead Source Detail Most Recent is NOT “zoominfo.” This will show us that the person interacted with our marketing and is eligible to be emailed. It goes without saying that we only want to “activate” prospects who have given permission for us to email them. The Lead Source Detail Most recent field can be updated using completion actions or UTM parameters from URLs (that’s another post).
The short and sweet summary
This solution allows records added into Salesforce (that have not opted-in) to sync to Pardot. Automation rules in Pardot update the “Do Not Email” field based on Pardot interactions and opt-in status. This ensures that prospects who did not previously opt-in are updated correctly when they do opt-in and that no duplicates are created in Salesforce.
Let’s play by the rules AND not create duplicate records
Based on how your organization uses tools like Clearbit, Lusha, or ZoomInfo and the volume of records added to your Salesforce org, MDS might be the best solution for you. However, if a high volume of records are being added into Salesforce, I would recommend that you give this solution some consideration. The chances of duplicates being created in your system grows exponentially based on the number of records being added from external sources.
If you have any questions about this solution, MDS, or anything related to Marketing Cloud Account Engagement or Marketing Cloud Engagement, contact us with your questions.
You can keep your free snacks and ping pong tables. If we’ve learned one thing from the pandemic, it would be that employees really want the ability to work remotely — at least part of the time. While organizations have become more accepting of this new reality, IT departments are facing security challenges.
In this post, we’re looking at Salesforce Marketing Cloud security best practices for hybrid and remote work environments. We’ll review some of the security settings in Marketing Cloud that will allow your remote employees to work safely and take some of the stress off of your IT team.
Marketing Cloud security for remote and hybrid work models
Since the onset of the pandemic, the number of remote workers has grown exponentially and the hybrid work model is becoming the new norm. A 2021 Mckinsey & Company survey found that 52% of workers prefer a more flexible working model moving forward. And listening to those wishes is helping many employers to avoid the effects of the Great Resignation at their companies.
Luckily, Marketing Cloud is built with security in mind and it can be configured to allow your employees to work securely — wherever they may be.
Security Tip #1: Limit the Data in Salesforce Marketing Cloud
Salesforce Marketing Cloud is not a data warehouse. So don’t treat it like one.
When bringing data into SFMC, ask yourself how it will be used for segmentation. If data will not be used for segmentation, don’t import or sync it over. Data like credit card numbers should NEVER be stored in Marketing Cloud.
Special attention also needs to be applied when handling Personally Identifiable Information (PII). The Department of Homeland Security defines PII as:
As any information that permits the identity of an individual to be directly or indirectly inferred, including any information that is linked or linkable to that individual, regardless of whether the individual is a U.S. citizen, lawful permanent resident, visitor to the U.S., or employee or contractor to the Department.
Linked PII is information that can be used by itself to identify an individual (ex. Social Security number) and linkable PII is information that can be used in combination with other information to identify an individual. Depending on the type of data in your account and the industries you serve, additional security measures like data at rest encryption, field level encryption and tokenized sending might be necessary.
Security Tip #2: Control Access with Marketing Cloud Business Units
Even before creating users, I like to see how organizations are structured. If your organization operates in several regions, all users might not need access to all the data. The best way to secure data is to not grant access to it in the first place!
This is where business units come in. Business units in Marketing Cloud allow you to control access to information by creating a hierarchical structure. They also allow you to control branding elements including email display name, email reply address, and physical mailing address at the business unit level. You can even control the settings to allow unsubscribe at the business unit level or the enterprise.
Business units don’t have to be limited to geography. Your hierarchy can be built based on your unique needs. Building a hierarchy based on products is a great use case.
Note: Business Units are available in Enterprise and Enterprise 2.0 accounts.
Security Tip #3: Provide Users with the Correct Access Based on Need
Now that we’ve established our hierarchy and determined where users should be included, the next question is access level. Let’s start by talking about the differences between roles and permissions.
Permissions in Marketing Cloud are very granular. For this reason, the good folks at Salesforce have included default roles within Marketing Cloud based on common needs/scenarios (similar concept to the default user roles in Pardot). These are divided into Marketing Cloud and Email Studio Roles. I would highly recommend using these roles and limiting the creation of custom roles.
Marketing Cloud Role
Description
Marketing Cloud Administrator
This role assigns Marketing Cloud roles to users and manages channels, apps, and tools.
Marketing Cloud Viewer
This role views cross-channel marketing activity results in Marketing Cloud.
Marketing Cloud Channel Manager
This role creates and executes cross-channel interactive marketing campaigns and administers specific channels like Email Studio.
Marketing Cloud Security Administrator
This role maintains security settings and manages user activity and alerts.
Marketing Cloud Content Editor/Publisher
This role creates and delivers messages through applicable channel apps.
Email Studio Role
Description
Administrator
Access to all Email Studio functions including Setup, email creating, and creating data extensions.
Content Creator
Access to all content, shared folders, and tracking in Email Studio, but no access to data or administrative features.
Data Manager
Access to everything in Email Studio except email content
When assigning roles to users, you should always start with the lowest level that permits the individual to do their job. I’m always amazed when I log into an account for the first time and see all users have the Marketing Cloud Administrator and Administrator roles assigned. There’s simply no reason for this. I generally like to have two admins in an organization. It’s always good to have a backup in the event of an emergency!
It’s also worth noting that SFMC defaults to the most restrictive value when multiple roles are assigned to a user. For example, if a user was assigned the Content Creator, Marketing Cloud Channel Manager, and the Marketing Cloud Viewer roles, they would not be able to send an email. This is due to the fact that the Marketing Cloud Viewer is the most restrictive of the three roles and does not permit email sending.
It’s very possible that the same user will have access to multiple business units, but perform different functions in each. That’s perfectly fine and SFMC has you covered. Roles can be assigned at the business unit level so the same user could have admin access in one and view only in another. This is very handy and should be utilized if users don’t need full access to all the BUs that they are part of.
Security Tip #4: Follow Login and Password Best Practices
Marketing Cloud allows admins to set security policies very easily within the Security Setting under setup. However, I’m really surprised by how often I see accounts where the standard Salesforce recommendations are not followed. Take a minute to audit your account to ensure that they comply with the recommended account settings from Salesforce included below.
Field
Recommended Setting
Session Timeout
20 minutes
Login Expires After Inactivity
90 days or less
Invalid Logins Before Lockout
3
Count Invalid Logins Across Sessions
Yes
Minimum Username Length
8 characters
Minimum Password Length
8 characters or more
Enforce Password History
8 passwords remembered
User Passwords Expire In
90 days
Send Password Change Confirmation Email
Enable
Enable Audit Logging Data Collection
Enable
Security Tip #5: Limit Logins by IP Address
The Restrict Logins by IP Address (IP Allowlisting) setting allows you to define a list of IP addresses that can access your account.
This feature is optional and is set to Off by default, but can quickly be activated under Setup > Security Setting > Username and Logins. When activating, you’ll have the option to log non-allowed IP addresses and permit access or log non-allowed IP addresses and block access. Don’t forget to add IP addresses to your allowlist under Setup > Security > Login IP Allowlist if you choose to use this feature.
Security Tip #6: Limit Exports
Ask yourself this simple question…
Does this user need to extract data from SFMC to do their job?
If the answer is “no,” then don’t allow them to export. It’s that easy!
Data extracts are a security risk that I see in most accounts. While data in the hands of a user can be risky, the real concern is data sitting on a computer that is not properly secured. Once the data leaves SFMC, all bets are off. This is a huge risk with remote workers. Let’s mitigate this risk by limiting exports.
Data can be exported from SFMC using Data Extract activities in Automation Studio, from tracking in Email Studio, and from reports in Analytics Studio. While some reports can be viewed onscreen or downloaded as PDFs, email and file transfer locations are the primary ways that data is exported.
Email Export
Your data is sent from SFMC via email. This is pretty scary, but can be controlled with Export Email Allowlists. The email allowlist includes individual email addresses or domains that are authorized to receive email exports from your account.
Export Email Allowlists must be activated in your SFMC account by first selecting the Enforce Export Allowlist in Security Setting. You will then need to specify the individual email addresses and domains that are authorized to receive email exports within your Export Email Allowlist (Setup > Security > Export Email Allowlist).
File Transfer Locations
Marketing Cloud also makes use of file transfer locations to import and export data. The most common location is the Enhanced FTP Account, but you can also add additional locations under Setup > Administration > Data Management > File Locations.
To access data from the Enhanced FTP Site, users must login. Access to the data can be controlled by limiting users and not sharing login credentials. Marketing Cloud allows up to 10 FTP users per MID, allocate them wisely! Users can be granted Read Only or Full access.
Security Tip #7: Automate and Review Audit Trails
Audit Trails in Marketing Cloud can be used to track account access and activity. Reports can be automated through Automation Studio or through REST API extracts.
Before audit trails can be exported, the following actions must be taken to enable them in your account.
Enable Audit Trail Data Collection under Setup > Security > Security Settings
Assign the Marketing Cloud Security Administrator role to the user who will be extracting the data
Once these requirements are met, automations can be created in Automation Studio to extract the access and activity logs. Salesforce recommends that audit trail data be retrieved periodically based on a rolling window.
There are a couple of things to keep in mind when creating your automations.
You must create a Data Extract activity and select the desired extract type (Audit Trail Access Log or Audit Trail Activity Log).
Data is extracted to the Marketing Cloud Safehouse, so a File Transfer activity is needed to securely transfer files to the FTP location of your choice.
The automation is pretty simple and will look like this when complete.
The Basic Audit Trails are a great place to start. They are included in your account and have a 30-day retention period. Advanced Audit Trails, which can be purchased for an additional fee, extend the retention period to 60-days and include additional data related to Email Studio, CloudPages, MobileConnect, and more. Learn more about Basic and Advanced Audit Trails.
Take Action to Secure your Marketing Cloud account
This post includes some recommendations to help secure your Marketing Cloud account with the rise in remote workers. However, it is not inclusive of all the security capabilities of SFMC.
For more information, check out the following Trailhead modules or post your questions in the comments section. We’re here to help you succeed with Marketing Cloud! You can contact us with any questions.
We marketers have pivoted our strategies to comply with GDPR in the past, but a recent court ruling may have us scrambling to change the way we use Google Analytics with European website users.
In a groundbreaking court case, the Austrian Data Protection Authority decided that the use of Google Analytics is currently violating the GDPR. The primary reason Google Analytics is violating GDPR involves personal data privacy.
As a result, it’s time for marketers to wake up and pay closer attention to how they track and report on visitor data coming from European Union (EU) countries.
What is GDPR?
The thing we’re talking about here is the General Data Protection Regulation (GDPR). It’s a law passed by the EU in May 2017 that creates standards for organizations that market to, track, or handle personal data from EU residents.
GDPR applies to you if you’re doing business or marketing to people in the EU regardless of where your company is physically located.
Google Analytics is currently violating GDPR
The court case that led to the realization that Google Analytics violates GDPR stems from a complaint that landed on the doorstep of the Austrian Data Protection Authority (a.k.a. Datenschutzbehörde).
Here’s how it went down.
On August 14, 2020, a Google user accessed an Austrian website called NetDoktor, which has self-serve resources for learning about health issues. The website uses Google Analytics, which means data about the user is transmitted to Google. Website users have filed 100+ complaints since then with similar GDPR violations from Google Analytics.
The issue at hand is that sensitive data about EU website users is traveling through Google’s servers and across the pond to the US and other non-EU countries. As a result, that data is not being subjected to the privacy standards established through GDPR. (official legal response from Google here🤓)
So, in December 2021, the Austrian Data Protection Authority determined that the NetDoktor website’s usage of Google Analytics does not comply with GDPR. Other cases have come forward since that first case, which means this is something that’s here to stay.
What marketers on Salesforce need to know about GDPR and Google Analytics
If you’re a marketer using Salesforce Marketing Cloud or Tableau and you’re importing website user data through integrations with Google Analytics, then you’ll want to listen up. This is especially important if a large portion of your website users are located in a European Union country.
How to take action to stay GDPR compliant
We knew you’re a good seed. Here’s what you need to know to stay on the GDPR compliant side.
You’re already ahead of the curve if you’ve made the switch to first-party web tracking cookies. However, you’ll need to take additional steps to avoid legal action from website users living in EU countries regardless of the type of web tracking cookies you use (and we think you should switch to first-party cookies).
Verify privacy policy is up-to-date and available
Google Analytics requires all website owners using the Google Analytics Advertising features to display the privacy policy link on websites that utilize the service. And if you’re using advanced features to track website user data, then it’s likely that you’re using Google Analytics Advertising features.
Here’s what to include in your privacy policy:
The Google Analytics Advertising Features you’ve implemented
How you and third-party vendors use first-party cookies (such as the Google Analytics cookie) or other first-party identifiers, and third-party cookies (such as Google advertising cookies) or other third-party identifiers together
How visitors can opt-out of the Google Analytics Advertising features you use. This includes features used through Ads Settings, Ad Settings for mobile apps, or any other available means (for example, the NAI’s consumer opt-out).
Enable cookie consent on your website
Letting your website users know you’re using tracking tools to gather data from them is a great way to stay compliant with GDPR while using analytics tools like Google Analytics.
You can use a cookie consent vendor, such as OneTrust, to collect informed consent prior to dropping the tracking cookies into the website user’s browser. Cookie consent vendors make it easy for you to deliver a banner to your website visitors that collects their consent for tracking website browsing data using tracking cookies before they are activated and set.
We recommend you enable IP anonymization on your Google Analytics account to ensure you use pseudonymous identifiers. In addition, you can set the time period before the data stored by Google Analytics is automatically deleted from servers. Then, include that time period in the Google Analytics cookie banner.
The banner you use to collect cookie consent from website users should be a simple and clear message explaining:
How user data is collected
Purposes of data collection
Duration of the data collected
Vendors and technical details
If you’re using third-party cookies, the banner should also inform users that the website uses third-party cookies for profiling purposes to provide advertising insights.
What could happen if you take no action
So, maybe you missed the memo and you haven’t done anything to address your website’s usage of Google Analytics in EU countries. Or maybe you use some other analytics tracking tool, like Heap, Matomo, Statcounter, or Adobe Analytics, and didn’t realize this probably applies to you, too.
Well, it’s a good thing you’re here. We advise you to do two things:
Notify your legal counsel that there is a potential risk.
Get ahead of the regulations.
Violating the regulations doesn’t necessarily mean the GDPR privacy police are going to show up on your doorstep tomorrow. It means someone could complain about your collection of their web browsing data. That complaint could snowball into a lawsuit and all the expenses that go along with it.
That’s why it’s so important for you to collect informed consent before a cookie starts collecting data from a website user who’s visiting your site from an EU country.
Still confused by all of this? Tell us about it in the comments section.
