Categories

Getting Started

Learn through 101 guides and easy solutions.

View all

Pro Tips

Dive into the weeds with advanced tips.

View all

New Features

Evolve with the Salesforce platform feature updates.

View all

Community

Get to know our community and join the action.

View all

Category

Privacy & Compliance

beach resort
  • New Features, Privacy & Compliance, Release Notes

Upcoming Salesforce Platform Security Changes and How to Prepare

With the upcoming June 2026 updates Salesforce has just announced, Salesforce is once again raising the bar for platform security. While these updates are designed to keep your data safer than ever, they do require some proactive heavy lifting from admins to ensure integrations don’t break and user access remains seamless.

In line with the messaging we’ve seen from Salesforce recently—focusing on the intersection of AI, Data, and Trust—these enhancements are mandatory. We want to make sure you’re ahead of the curve. Let’s dive into the core security requirements and what you need to do to prepare.

Email Domain Verification 

  • What is changing: Salesforce now strictly requires all outbound email-sending domains to be verified. To verify a domain, you must establish ownership using either DKIM key (recommended) or a verified entry in the authorized email domains list. As part of this change, Salesforce will no longer deliver emails from unverified domains, even if the specific sender’s individual email address was previously verified.
  • Why it matters: Email deliverability is becoming stricter globally, with major mail providers increasingly filtering or rejecting unauthenticated domains. If your organization attempts to send an email from an unverified domain, the delivery will fail and the email will be silently dropped. It won’t generate a bounce notification or an error message for your automations.
  • Who is impacted: Any emails sent directly from the Salesforce platform, which includes emails sent via the Email Composer, Apex email, Flow-triggered emails and even system-generated emails like notifications of a new Lead or Opportunity assignment.
  • Timeline: Enforcement began rolling out to sandboxes in March 2026, and production orgs in April 2026. 
  • How to prepare: 
    • You can check the verification status in your org by going to Deliverability settings in Setup and enter your domain in the Check Domain Verification section.
    • Ensure your email sending domains are verified using one of the following methods:
    • Enable a Safety Net: To minimize immediate business disruption while waiting for domain verification, enable “Use a substitute email address for unverified domains” on the Deliverability Setup page. 
Domain verification section

MFA Mandatory for All Users

  • What is changing:  While Multi-Factor Authentication (MFA) has been a contractual “requirement” for some time, Salesforce is moving toward technical enforcement for all UI logins (i.e. the login.salesforce.com page). This means any user logging into the Salesforce UI must use Multi-Factor Authentication. The ability to toggle this off for specific profiles or bypass it via legacy settings is being deprecated.
  • Why it matters: Data breaches are commonly linked to compromised credentials. Making MFA a technical requirement for every single user, ensures that even if a password is compromised via social engineering, your org remains protected.
  • Who is impacted: All users logging into Salesforce (direct UI or SSO logins) in production or sandbox orgs and do not have one of these permissions: System Administrator profile, Modify All Data, View All Data, Customize Application, or Author Apex. (Users with these permissions are considered “privileged” and have their own MFA requirements, see the next section)
  • Timeline: Enforcement is rolling out in waves, starting in Sandboxes on June 22, 2026, and production orgs starting July 20th.
    • Ahead of enforcement, orgs that have the setting “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org”  disabled may start seeing this pop-up message as a heads-up on the upcoming enforcement.
    • Orgs with that have been updated will see the “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” setting (under Setup > Session Settings)  enabled and greyed out.
MFA Reminder pop-up message
  • How to prepare:
    • Audit users still not using MFA to assess who will be impacted. Use the “Identity Verification Methods Report” to view the methods being used by your organization.
    • Identify users relying on the “Waive Multi-Factor Authentication for Exempt Users” permission. To restore this exemption for valid use cases (e.g., automated testing tools), you can contact Salesforce Support for approval.
    • Identify the MFA methods available for your users and determine how they choose a method during initial registration.
    • If you are using Single Sign-On (SSO) through another identity provider (e.g. Okta, Entra), make sure that provider is using MFA and sending valid signals to validate MFA was used (for more information, see Salesforce’s breakdown of signal requirements).
    • Ensure users are prepared for the change and how to register their MFA method.  
  • More information: Prepare for MFA Enforcement for All Employee Users

Phishing-Resistant MFA for Admins or Privileged Users

  • What is changing: Salesforce is introducing a requirement for phishing-resistant MFA for users with “privileged” access. This means moving away from verification codes and toward FIDO2/WebAuthn-based passkeys, hardware security keys (e.g. YubiKeys) or built-in authenticators (e.g. Windows Hello or FaceID) that use FIDO2/WebAuthn standards.
  • Why it matters: Admins hold the keys to the kingdom. Phishing-resistant methods ensure a stronger protection against identity-based threats, and ensures access is tied to authorized users. 
  • Who is impacted: 
  • This change affects all users logging into Salesforce (direct UI or SSO logins) in production or sandbox orgs who meet any of the following conditions:
    • Users assigned with the System Administrator profile
    • Users assigned with any one of these privileged permissions: Modify All Data, View All Data, Customize Application, or Author Apex
  • Once in effect, users will be prompted to register their phishing-resistant MFA method on their next login. 
What it will look like to register the phishing-resistant MFA method on the next login.
  • Timeline: This change will be introduced in sandboxes starting June 22, 2026, and in production orgs starting July 1, 2026
  • How to prepare:

Containment for “High Risk” Connections

  • What is changing: Salesforce will automatically detect and contain traffic that:
    • Are from “High-Risk” connections through Connected App or API usage.
      • Examples of “high risk” connections include anonymizing VPNs (e.g. NordVPN, ExpressVPN, Surfshark, or ProtonVPN), Proxies (e.g. HideMyAss or KProxy) or high-risk IP addresses (e.g. public wifi, blocklisted IPs)
      • Connected App or API usage may include integrations, plugins (e.g. Salesforce Inspector Reloaded) or use of CLI tools.
    • Are significant, novel deviations from typical user login activity based on network, client, authentication events, and geolocation. (detected through an AI-driven monitoring system)
    • If a high risk connection is identified, the following actions will be taken:
      • The affected user account will be frozen.
      • All OAuth refresh tokens granted to the user will be revoked.
      • An email will be delivered to org admins from Salesforce Security (See Administrator Notifications below).
      • The affected user will need to contact their org admin to restore access to their account.
  • Why it matters: This enhancement is aimed at protecting against suspicious activity via anonymizing VPNs, proxies, or high-risk IP addresses; credential harvesting; and token theft. 
  • Timeline: This change started April 24, 2026
  • How to prepare:
    • Ensure users running integrations, plugins or connects are not doing so from high-risk sources
    • If automated containment affects a user, review their session and restore access by unfreezing their user
    • Users will need to avoid connecting from high-risk connections to prevent re-containment. They will also need reauthorize any connected apps
    • If your only admin account is locked out, contact Salesforce Support by phone to have your account reactivated  
  • More information: Preventing Connections from Anonymizing VPNs, Proxies and High-Risk IP Addresses

Step-Up Authentication for Reports

  • What is changing: Salesforce is introducing “Step-Up Authentication.” Even if a user is already logged in, they will be prompted to re-verify their identity (via MFA) when they attempt to run or view reports if a configurable amount of time has passed since their last step-up challenge.
What it looks like when a user is prompted to re-verify their identity (via MFA)
  • Why it matters: This change is intended to prevent malicious data breaches or unauthorized transfer of data to external locations. Given that report views and exports can be susceptible to scraping or unauthorized external use, the step-up authentication ensures these actions require a stronger authentication challenge.
  • Who is affected: This change impacts all users (direct login or SSO) who run or export reports.
  • Timeline: Sandboxes will see this available starting May 27, 026 and enforced starting June 3, 2026. Production orgs will see this available starting May 27, 026 and enforced starting June 10, 2026. 
  • How to prepare:
    • Ensure all users (especially SSO users) have a registered Salesforce MFA method, a valid email, or an SMS phone number, as they will need this to pass the challenge.
    • Review and Configure the Policy: In Setup, go to Identity Verification settings and adjust the cool-down period threshold if your business requires a timeframe different from the 120-minute default.

The Bottom Line

June 2026 is right around the corner. By leaning into preparing for these enhancements now, you’re not just racing to a deadline—you’re hardening your business against the next generation of digital threats.

As you prepare for the rollout, keep these three steps top of mind:

  • Audit: Identify which users will be impacted by the permission changes.
  • Test: Run your critical processes in a Sandbox environment.
  • Educate: Ensure your stakeholders understand the ‘why’ behind the new security protocols.

With a clear plan in place, the transition to a more secure Salesforce platform will be a seamless one.Need a hand getting your security posture ready for 2026? The Sercante team is ready to help you audit and prepare your org for these upcoming changes and your overall security posture. Reach out today!

Read more

Monochrome Cityscape Through Steel Bridge Structure
  • Privacy & Compliance, Pro Tips

The Silver Lining of the Great Reset: Modernizing Marketing Governance

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:

TaskFrequencyPurpose
User AuditQuarterlyDeactivate dormant users and verify permission sets.
Setup Audit TrailMonthlyReview who changed critical configurations or deleted Data Extensions.
Health CheckWeeklyMonitor automation failure rates and API limit usage.
User AuditQuarterlyDeactivate 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.

Read more

  • Emails & Forms, Privacy & Compliance, Pro Tips, Strategy

Using Account Engagement (Pardot) in a Global Market

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:

  1. Export CSV data from Account Engagement
  2. Navigate to Data > From Text (Get External Data) in Excel
  3. 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.

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8”>

Unsubscribe and Email Preference Center Pages

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. 

Learn about other customizations that can be made to Pardot unsubscribe and email preference pages.

“Not you?”/Form Reset Link

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
  • Customize Account Engagement cookie duration via 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:

Additional permission-based marketing resources: 

Data Security

Data stored in Account Engagement is kept securely to meet international data processing regulations, along with strict user login requirements. 

Here is documentation from Salesforce on these practices:

Other Resources from The Spot on Managing Global Compliance

What’s Next 

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!

Read more

  • Data Management, Privacy & Compliance, Pro Tips

Pardot Marketing Data Sharing Rules: Prevent Duplicates in Salesforce

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.

Salesforce has a Marketing Cloud Account Engagement Permission-Based Marketing Policy that strictly prohibits the sending of emails to customers or prospects who have not expressly opted-in to receive them. 

“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.

Read more

  • Data Management, Privacy & Compliance, Pro Tips, Strategy

7 Marketing Cloud Security Tips for a Hybrid Work Environment

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. 

Let’s take a look at some ways you can protect your data in addition to using multi-factor authentication (MFA).

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 are micro-level security.
  • Roles are macro-level security.
    • They are a collection of 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 RoleDescription
Marketing Cloud AdministratorThis role assigns Marketing Cloud roles to users and manages channels, apps, and tools.
Marketing Cloud ViewerThis role views cross-channel marketing activity results in Marketing Cloud.
Marketing Cloud Channel ManagerThis role creates and executes cross-channel interactive marketing campaigns and administers specific channels like Email Studio.
Marketing Cloud Security AdministratorThis role maintains security settings and manages user activity and alerts.
Marketing Cloud Content Editor/PublisherThis role creates and delivers messages through applicable channel apps.
Email Studio RoleDescription
AdministratorAccess to all Email Studio functions including Setup, email creating, and creating data extensions.
Content CreatorAccess to all content, shared folders, and tracking in Email Studio, but no access to data or administrative features.
Data ManagerAccess to everything in Email Studio except email content
AnalystAccess to tracking features in Email Studio.

Marketing Cloud Roles and Permissions

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.

FieldRecommended Setting
Session Timeout20 minutes
Login Expires After Inactivity90 days or less
Invalid Logins Before Lockout3
Count Invalid Logins Across SessionsYes
Minimum Username Length8 characters
Minimum Password Length8 characters or more
Enforce Password History8 passwords remembered
User Passwords Expire In90 days
Send Password Change Confirmation EmailEnable
Enable Audit Logging Data CollectionEnable

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.

Read more

  • Analytics & Reporting, Privacy & Compliance, Pro Tips

GDPR and Google Analytics Updates in 2022

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: 

  1. Notify your legal counsel that there is a potential risk.
  2. 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. 

Read more

Load More
No more posts to show