Pardot to Marketing Cloud Account Engagement: What Changed and What Broke
Salesforce changed the Pardot name in 2022, but the name change is only one part of the story. Teams that remember forms failing, users losing access, integrations stopping, or campaigns behaving differently often connect those problems to the rebrand. The timing makes that assumption understandable. Several product and security changes landed before, during, and after the move from Pardot to Account Engagement.
The key distinction matters. Pardot to Account Engagement was mainly a naming and product-positioning change. It didn’t replace every Pardot object or force every customer into a new database. The real disruption came from changes to authentication, the Salesforce connector, domain security, the Pardot API, campaign management, user permissions, and tracking. Some of those changes were mandatory. Others only caused trouble when an older setup relied on behavior Salesforce later retired.
That difference is useful when you’re reviewing an older org. Calling every problem a Pardot migration issue sends the investigation in the wrong direction. A login failure needs a user and SSO check. A broken embedded form needs a domain and JavaScript check. A custom integration needs an OAuth and API version check. The fix depends on which change actually affected the setup.
This guide explains what changed in Account Engagement, what stayed familiar, and what commonly broke in older implementations. It also shows where the Account Engagement Lightning app fits, why older Salesforce Pardot documentation can still appear in live systems, and how to review an org without treating the 2022 rename as a technical migration that never happened.
TL;DR
• Pardot became Marketing Cloud Account Engagement in 2022. The rename itself didn’t require customers to rebuild their marketing database or Engagement Studio programs.
• Many failures blamed on the rebrand came from separate changes to SSO, domains, APIs, connectors, permissions, consent handling, and tracking.
• Older forms served from the default go.pardot.com domain were exposed to new security limits that could stop some JavaScript from working as expected.
• Older custom integrations could fail when legacy authentication or email-based prospect assumptions met newer Pardot API rules.
• The safest review method is to trace each symptom to the specific Salesforce change that affected it rather than treating the whole period as one Pardot migration.
What The Pardot Rename Actually Changed
Salesforce announced the new Marketing Cloud naming model in April 2022. Pardot became Marketing Cloud Account Engagement, Datorama became Marketing Cloud Intelligence, and other products were grouped under clearer Marketing Cloud labels. Salesforce described the change in its 2022 naming announcement as a vocabulary shift tied to its wider Marketing Cloud direction, and Account Engagement was identified as the product formerly known as Pardot. The product name changed, but existing customers didn’t wake up to a replacement database or a forced rebuild of every automation asset.
That point gets lost because the rebrand happened during a busy period for Salesforce Pardot. Authentication had already moved toward Salesforce SSO. The Lightning experience was becoming more important. Connector v2, campaign alignment, enhanced builders, API changes, and domain security updates were reshaping how admins maintained the product. When several changes land close together, users naturally remember them as one event even when they came from separate release decisions.
Marketing Cloud Account Engagement also created a naming problem of its own. Some teams read “Marketing Cloud” in the new name and assumed Pardot had been merged into the older Marketing Cloud product now called Marketing Cloud Engagement. Salesforce’s current product comparison still treats them as different products, with Account Engagement using prospects and Engagement Studio while Marketing Cloud Engagement uses subscribers, data extensions, and Journey Builder. Marketing Cloud Next is another distinct product line in that same comparison.
Old and new names can still appear around the same feature. Salesforce documentation uses “Pardot” in some URLs, API paths, permission names, package labels, and legacy references. A remaining Pardot label doesn’t prove the org is outdated. Check whether the feature is supported and configured correctly in the current Account Engagement setup.
The phrase Pardot to Account Engagement is therefore best understood as a naming transition with related platform changes around it. A true Pardot migration usually means moving data or processes between products, business units, orgs, or architectures. The 2022 rename by itself didn’t do that.
What Stayed The Same After The Rebrand
The core operating model stayed recognizable for existing users. Marketing Cloud Account Engagement still centers on prospects. Teams still use lists for segmentation, Engagement Studio for nurture logic, automation rules for background processing, completion actions for asset-level responses, forms for lead capture, and scoring or grading for qualification. Those concepts didn’t disappear because Pardot was renamed.
That continuity matters when reviewing a Salesforce Pardot implementation created years ago. An Engagement Studio program built before the rename didn’t become invalid because the logo or navigation label changed. A prospect record didn’t need to be converted into a Marketing Cloud Engagement subscriber. A list didn’t automatically become a data extension. The objects and automation model remained tied to Account Engagement.
The rename also didn’t mean every customer had to move into Marketing Cloud Engagement. Salesforce continues to document Account Engagement as its own product with its own data model and automation tools. That separation is why long-time users still recognize the system after years of interface changes.
What did change was the amount of Salesforce platform administration surrounding those familiar marketing objects. More user access decisions moved into Salesforce. Newer builders depended on Lightning and Salesforce permissions. Campaign connections tied more marketing work to Salesforce CRM. The connector became more central to identity and data movement. So the marketing concepts stayed familiar while the administration around them became more Salesforce-centered.
This is also why a team can say, “Pardot still works,” while another user says, “Everything changed.” Both can be describing the same org from different roles. A marketer may still see lists, prospects, forms, and Engagement Studio. An admin may now be dealing with permission sets, Salesforce licenses, connector settings, tracker domains, OAuth, and user sync to keep those features available.
Why The Lightning Shift Felt Like A Migration
The Account Engagement Lightning app changed where many users did their daily work. Salesforce moved newer capabilities into Lightning and made the Salesforce shell more important for access, campaigns, reporting, and newer content experiences. That shift could feel like a migration even though the underlying product wasn’t replaced.
The access requirements explain part of the confusion. Salesforce’s Lightning app requirements say Lightning Experience must be enabled and the Account Engagement business unit needs a verified Salesforce connector. Users also need an eligible Salesforce or Identity license plus an appropriate permission set. A Salesforce Platform license alone doesn’t provide the required access, so a user can exist in Salesforce and still fail to open the Account Engagement Lightning app.
This creates a common support pattern. A marketer who could previously use a familiar Pardot route gets moved into Lightning and sees a missing app, missing tab, or access error. The instinct is to blame the Pardot to Account Engagement change. The actual problem may be a license type, permission set, connector verification issue, or Salesforce-side user assignment.
The Lightning app also became the place where Salesforce put much of its newer work. That included deeper campaign alignment, Engagement History, business unit access, newer email and landing page experiences, and other features tied closely to Salesforce records. A team that stayed mostly in the standalone classic interface could keep familiar workflows, but it wouldn’t see the same feature set.
Authentication And User Access: What Broke
One of the biggest access changes happened before the 2022 rename. Salesforce ended Pardot’s own direct authentication model and required Salesforce SSO for Account Engagement users. According to the user migration notice, users who weren’t connected to Salesforce SSO by February 15, 2021 could no longer log in until they were linked to a Salesforce user. That was an authentication change, not a feature removal, but it could look like the product had stopped working.
This is an important timeline detail for anyone investigating an older Salesforce Pardot org. If a team remembers the rebrand as the moment old credentials stopped working, the dates don’t line up with the 2022 rename. The login change had already happened. It also affected API planning because integrations tied to old authentication patterns had to move toward Salesforce OAuth.
User Sync pushed access management further into Salesforce. Synced Account Engagement users inherit key identity information from Salesforce, and their Account Engagement user records can become read-only for fields managed through the sync. That reduces duplicate user administration, but it changes where an admin fixes a user problem. Editing the old Pardot-side record may no longer be the right action.
Access problems also became easier to misdiagnose because several layers can produce similar symptoms. A user can have a valid Salesforce account but lack Account Engagement access. Another user can have the right permission set but point at the wrong business unit. A third can open Salesforce but lack a supported license for the Lightning app. Those failures need different fixes.
When a user says “Pardot is gone,” start with identity. Confirm the Salesforce user is active, SSO is valid, the user is assigned to the correct Account Engagement business unit, and the required permission set is present. Then confirm the user is opening the supported interface. That sequence is more useful than treating the incident as a generic rebrand failure.
Domains And Forms: The Breakage Many Teams Actually Saw
The go.pardot.com security update is one of the clearest examples of a real technical break that happened near the rebrand. Salesforce introduced new limits for Account Engagement content served from the default domain. Its default domain guidance says admins could activate the update from April 22, 2022 and that it was scheduled for automatic activation for most customers on August 12, 2022. Content could remain reachable while certain JavaScript stopped behaving as expected.
That distinction matters. A form can still load and still be broken. An embedded form may render inside an iframe while a script that resizes the frame stops working. Custom JavaScript may fail to make an expected external call. A reCAPTCHA flow or submission helper can stop behaving as it did before. To the marketer, the form “broke after Account Engagement.” To the admin, the root cause is a domain security policy applied to content served from the default Pardot domain.
Custom tracker domains were the safer path. They let a company serve Account Engagement content through a domain it controls, such as go.example.com, instead of relying on the shared default. That also makes it easier to align tracking and hosted content with the company’s web presence. The change didn’t require rebuilding every form from scratch, but it could require updating iframe URLs, landing page links, form references, or other assets that still pointed to go.pardot.com.
A useful audit starts by inventorying every live Account Engagement form, form handler, landing page, custom redirect, and hosted file that appears on public pages. Check the domain in the live URL, not only the asset record in Salesforce. Then test submission, confirmation behavior, iframe sizing, and any custom script that runs around the asset. That catches real breakage instead of assuming every old form is safe because it still appears on screen.
Pardot API Changes That Broke Integrations
Custom integrations are another place where the rebrand can hide the real cause. The Pardot API changed its authentication model and later introduced version 5 behavior that differs from older code. A Pardot API integration written years ago can fail even though the same prospects and marketing assets still exist in Marketing Cloud Account Engagement.
For current integrations, Salesforce documents the required model in its API authentication rules, which require Salesforce OAuth and an SSO-enabled Account Engagement user. Requests also need the Account Engagement business unit ID in the Pardot-Business-Unit-Id header. Older scripts built around legacy credentials or an API key model need more than a renamed endpoint. Their authentication flow has to be rewritten around supported Salesforce OAuth behavior.
The API also changed how prospect identity should be handled. Salesforce’s version 5 transition guide states that an update in version 5 must identify a prospect by Account Engagement ID. It also notes that a query by email can return all prospects that share that email address when Allow Multiple Prospects with Same Email Address is in use. Code that assumes one email address always maps to one prospect can therefore select the wrong record or fail when several records are returned.
That is a serious integration risk because email-address assumptions often sit deep inside old middleware. A custom enrichment job may search by email, update the first result, and never confirm which prospect ID belongs to the intended Salesforce record. A lead-routing script may have worked for years in a simpler database and start producing inconsistent behavior after duplicate-email support or API changes expose the flaw.
The safer model is ID-based. Use the Account Engagement prospect ID when a workflow updates or deletes a specific record. Store the relevant Salesforce and Account Engagement identifiers when the integration needs to move between systems. Treat email as contact data rather than a guaranteed primary key unless the business unit’s rules and integration design make that assumption explicit.
Connector V2 And User Sync Changed The Admin Model
Connector v2 is a better example of a true configuration transition than the 2022 rename. Salesforce’s connector v2 guidance says the upgrade makes permanent changes and can’t be reversed. It also warns that the Salesforce org connected to the Account Engagement business unit can’t be changed after the upgrade. Those are decisions an admin should treat as architecture choices rather than routine cleanup.
Version 2 also changed the role of the integration user and how teams think about record access. The dedicated integration user can simplify connector administration, but its access may differ from the older connector user. Marketing Data Sharing decisions matter because they control which Salesforce records should sync into Marketing Cloud Account Engagement. A careless connector change can widen or narrow the dataset in ways that later look like random prospect sync failures.
User Sync moves user management in the same Salesforce-centered direction. Salesforce’s User Sync basics explain that Account Engagement access settings move into Marketing Setup and synced user records inherit information from Salesforce. Once a team adopts that model, the source of truth for user identity is no longer the old Pardot user screen.
This shift affects troubleshooting. If a user name, email, role mapping, or access assignment looks wrong in Account Engagement, the fix may belong in Salesforce. If the connector is paused, user data can still behave differently depending on connector version and sync configuration. If a business has several Account Engagement business units, assignments become more important because the same Salesforce user may need access to specific units.
Connected Campaigns Changed Campaign Ownership And Reporting
Connected Campaigns changed how Salesforce campaigns and Account Engagement campaigns relate to each other. Once a team enables Salesforce campaign management for connected campaigns, Salesforce becomes the main place to create and manage the campaign record. The old model, where marketing could treat Account Engagement campaigns as a separate campaign system, no longer describes the full setup.
For existing orgs, Salesforce’s current Connected Campaigns guidance recommends deciding which existing Account Engagement and Salesforce campaigns should continue, mapping them carefully, and controlling which Salesforce campaign record types are connected. It also notes that once Connected Campaigns is enabled, Account Engagement-only campaigns can no longer be used in the same way. That can expose weak campaign governance very quickly.
A marketer may interpret the change as missing campaigns or broken reporting. The real issue can be ownership. If campaign creation now belongs in Salesforce, a user who keeps trying to create or edit the old Account Engagement record will run into read-only behavior or a different workflow. If campaign record types weren’t planned well, sales campaigns that were never meant for marketing can also enter the connected model.
Reporting changes follow the same pattern. Engagement History and Salesforce campaign reporting can bring marketing activity closer to CRM records, but the quality of that reporting depends on campaign mapping and member processes. A rebrand label doesn’t explain duplicate campaigns, unmapped legacy campaigns, or record types that sync too broadly.
Teams should document the campaign source of truth and enforce it. Define where campaigns are created, which record types connect to Account Engagement, how naming works, who owns campaign member status values, and which legacy campaigns remain only for history. That prevents campaign problems from being mistaken for general Marketing Cloud Account Engagement instability.
Mailability And Consent Changes Altered Sending Logic
Email eligibility became another source of confusion when Salesforce updated Account Engagement’s mailability model. The important change is that Opted Out and Do Not Email are separate fields with different purposes. Salesforce’s mailability guidance says the updated model was enabled for all Account Engagement accounts by Winter ’22 and that the fields operate independently.
That matters because an old process may have treated the 2 fields as interchangeable. A marketer can clear one value and still find that the prospect isn’t eligible to receive email. An automation rule can change one field while leaving the other untouched. A Salesforce sync rule can also influence the value seen on the CRM side, depending on field mapping and sync behavior.
The safest interpretation is functional. Opted Out represents the prospect’s marketing email consent state in Account Engagement. Do Not Email can be used as an operational suppression control. If an old Salesforce Pardot process used Do Not Email as the main consent field, the team should review the logic before copying it into newer automation.
This becomes even more important when companies run Marketing Cloud Account Engagement beside Marketing Cloud Next or another sending platform. Consent models may not line up field for field. The team needs a clear source of truth for each type of subscription and an explicit rule for how changes move between systems. Otherwise, a record can appear eligible in one platform and suppressed in another.
A mailability audit should trace a prospect through the actual send decision. Check the prospect’s fields, suppression lists, public list choices, automation rules, Salesforce field mappings, and any external consent system that feeds the record. The goal is to explain why a specific prospect is mailable or blocked, not to rely on a single checkbox or an old migration document.
First-Party Tracking Changed Attribution Assumptions
Tracking changed for reasons that extend beyond the Pardot to Account Engagement rename. Browsers have tightened how cookies and cross-site tracking work, and Salesforce added first-party tracking to keep Account Engagement visitor tracking tied more closely to a company’s own domains. That change affects attribution design when a business uses several websites or tracker domains.
For older and newer business units, Salesforce’s first-party tracking guide says business units created after February 13, 2023 use first-party tracking by default. Older business units must enable it. The same guidance says tracker domains need a default campaign after first-party tracking is enabled, which makes domain configuration part of the attribution setup.
First-party tracking can also expose old assumptions. A team may expect one visitor cookie to follow a person across unrelated domains because an older setup appeared to provide that view. First-party behavior is bound more closely to the domain context. If a company runs several unrelated root domains, it needs to plan how campaigns, forms, redirects, and tracker domains support the measurement it expects.
This is especially relevant for older Marketing Cloud Account Engagement accounts with years of accumulated web assets. A business may have tracker domains that were created for a campaign and never retired. Another domain may point to a previous website. Some forms may use one domain while email links use another. Tracking data can still arrive, but attribution can become hard to trust if the domain map isn’t intentional.
The fix is an inventory, not a naming change. List every tracker domain, confirm DNS and validation status, identify the default campaign attached to it, and map which websites or assets use it. Then test the path from anonymous visit to known prospect activity. If the tracking story can’t be explained with the current domain setup, the org needs cleanup regardless of whether users still call the product Pardot.
Retired Legacy Features Explain More Than The Rebrand
Several legacy features were retired around the same period, which made the rename feel more disruptive than it was. Drip Programs are a good example. Salesforce’s Drip Program retirement directed customers to move legacy drip programs to Engagement Studio for the Summer ’22 retirement. A team that ignored that retirement had a workflow problem, but the cause was feature retirement rather than the new product name.
The Classic app inside Salesforce was another visible loss. Salesforce states in its Classic app retirement FAQ that the embedded Pardot Classic app in Salesforce was retired on October 17, 2022. The standalone classic experience at pi.pardot.com remained available, while customers who wanted Account Engagement inside Salesforce were directed toward the Lightning app. Bookmarks, training material, screenshots, and navigation habits tied to the embedded app therefore stopped matching the live product.
These retirements make old Salesforce Pardot documentation risky when it’s used without a date check. A five-year-old setup guide can describe a login path, app surface, API pattern, or automation option that Salesforce no longer supports. It may still rank well in search because the old terminology remains common. That makes source date and release context essential during troubleshooting.
A modern Account Engagement review should therefore separate 4 categories: renamed features, moved features, retired features, and features whose security or authentication rules changed. Those categories lead to different actions. Renamed features may need no technical work. Moved features need access and navigation changes. Retired features need replacement. Security changes may require code or domain work.
What Teams Should Do Now
Start by dropping the idea that every older org needs one large migration project. Most teams get better results by auditing the current Account Engagement setup in layers and fixing specific risks. The aim is to find old dependencies and verify that each one still matches current Salesforce behavior.
Begin with access. Confirm the users who need the Account Engagement Lightning app have the right Salesforce or Identity license, business unit assignment, permission sets, and SSO path. Document who owns user provisioning so future access problems have a clear owner.
Then inspect public-facing assets. Search the website for old go.pardot.com references, embedded forms, form handlers, landing pages, custom redirects, and hosted files. Confirm that custom tracker domains are valid and that forms still submit correctly. Test the full user path rather than checking only whether the asset loads.
Next, review integrations. Inventory every job that calls the API, including scripts that marketing may have forgotten about. Confirm Salesforce OAuth, business unit headers, supported API versions, prospect ID handling, and error monitoring. Pay special attention to code that searches or updates prospects by email because duplicate-email behavior can expose unsafe assumptions.
Review the Salesforce connector before making architecture changes. Confirm the connector version, integration user, Marketing Data Sharing rules, sync behavior, and target Salesforce org. Connector v2 choices can be permanent, so changes should be documented before they’re applied. User Sync should also have a named owner because identity problems often look like marketing application failures.
Campaign governance comes next. Confirm that Connected Campaigns are configured as intended, campaign record types are controlled, legacy campaigns are mapped where needed, and marketers know where campaign creation belongs. Then review consent logic and make sure Opted Out and Do Not Email aren’t being treated as the same field by old automations.
Finish with tracking and retired features. Map tracker domains to websites and campaigns. Check whether first-party tracking is enabled where appropriate and whether attribution behaves as expected across the company’s domains. Search old operating guides for Drip Programs, the embedded Classic app, legacy authentication, old API examples, or other controls that no longer match the supported product.
The main conclusion is simple. Marketing Cloud Account Engagement didn’t become unreliable because Salesforce renamed Pardot, and Marketing Cloud Account Engagement still needs the same kind of disciplined administration as any connected Salesforce system. The risk comes from old dependencies that were never updated as Salesforce tightened security, moved administration into Salesforce, changed APIs, and retired legacy surfaces. Treat each dependency as its own system. That approach makes an older-org review smaller, more accurate, and easier to test.
FAQs
Is Pardot The Same As Marketing Cloud Account Engagement?
Yes. Salesforce renamed Pardot to Marketing Cloud Account Engagement in 2022. The product kept its familiar prospect model and core B2B marketing features, although Salesforce also made separate changes to access, integrations, tracking, campaigns, and older features around the same period.
Did Salesforce Force A Pardot Migration In 2022?
No. The rename itself didn’t force customers to move Pardot data into Marketing Cloud Engagement or rebuild every nurture program. A migration may still be needed for other projects, but the 2022 name change wasn’t a forced platform move.
Why Do Some Salesforce Screens Still Say Pardot?
Pardot remains in some URLs, API terms, package labels, permission names, and legacy documentation. Those references don’t automatically mean the feature is unsupported. Check the current Salesforce documentation for the specific feature before changing a working setup.
Is Marketing Cloud Account Engagement The Same As Marketing Cloud Engagement?
No. They’re separate Salesforce marketing products. Account Engagement uses prospects, lists, and Engagement Studio. Marketing Cloud Engagement uses a different model built around subscribers, data extensions, and Journey Builder.
What Is The Account Engagement Lightning App?
The Account Engagement Lightning app is the Salesforce Lightning surface for Account Engagement. It gives users access to Account Engagement inside Salesforce and is where many newer features are available. Access depends on supported licenses, permissions, and a verified Salesforce connector.
Why Can’t A User Open The Account Engagement Lightning App?
Common causes include an unsupported Salesforce license, missing permission sets, incorrect business unit assignment, or connector problems. Check the Salesforce user and Account Engagement assignment before assuming the marketing data is missing.
Why Did Old Pardot Login Credentials Stop Working?
Salesforce retired Pardot’s separate authentication system and required Salesforce SSO beginning in 2021. Users who weren’t connected to a Salesforce user could no longer log in until their identity was linked correctly.
Why Did An Embedded Pardot Form Stop Working?
Forms served through the default go.pardot.com domain were affected by security limits introduced in 2022. The form may still appear while custom JavaScript, reCAPTCHA behavior, iframe logic, or related actions fail. Check the live domain and custom scripts first.
Do We Need A Custom Tracker Domain?
A custom tracker domain is strongly worth reviewing for live Account Engagement content and tracking. It gives the company control over the domain used for marketing assets and avoids depending on the shared default Pardot domain for important public-facing content.
Why Did A Pardot API Integration Break?
Older integrations may rely on retired authentication patterns or assumptions that changed in newer API versions. Current Account Engagement API access uses Salesforce OAuth and a business unit ID header. Version 5 also expects ID-based handling for certain prospect operations.
Can The Pardot API Still Find Prospects By Email?
Yes, but code must handle the possibility of multiple prospects sharing the same email address. With duplicate-email support, an email query can return several prospects. Updates in API version 5 should target the specific prospect ID.
Is Connector V2 Reversible?
No. Salesforce states that upgrading the Account Engagement Salesforce connector from version 1 to version 2 can’t be reversed. The connected Salesforce org also can’t be changed after that upgrade, so teams should verify the architecture before proceeding.
Did Connected Campaigns Replace Pardot Campaigns?
Connected Campaigns tie Account Engagement campaign activity to Salesforce campaigns and can make Salesforce the main place for campaign management. Existing campaigns need careful mapping, and teams should define which Salesforce campaign record types are allowed to connect.
Are Opted Out And Do Not Email The Same Field?
No. In the current Account Engagement mailability model, the fields are separate. Opted Out represents marketing email consent while Do Not Email can act as an operational suppression field. Old automations should be checked if they treat the fields as interchangeable.
What Should We Check In An Older Salesforce Pardot Org First?
Start with user access, live forms and domains, API integrations, connector settings, campaign ownership, consent logic, and tracker domains. Then compare old operating guides with current Salesforce documentation so retired or moved features don’t keep shaping today’s processes.
