* MC Account Engagement (fka Pardot) *

@Emily Grefer

If you want reps to send these from Salesforce with Account Engagement tracking, use the Engage feature. Reps send via the "Send Account Engagement Email" button on the record, which does show your 1:1 Account Engagement templates and tracks engagement (opens/clicks) back to Account Engagement. This is the intended path and probably what you're really after. 

If you want the templates in the native Salesforce email composer (the standard Email action), you'd have to recreate them as Salesforce email templates. There's no sync that carries them over. Keep a parallel set for that if you want. 

So, the checkbox just doesn't do what it sounds like.  

If you want these usable from Salesforce,  Engagement is the route. Native Salesforce templates are a separate thing. 

Hi @Devendra Kinage,  

Please check: 

Setup → Manage Connected Apps → b2bma_canvas → Edit Policies

Set Permitted Users to “Admin approved users are pre-authorized”, then under Manage Profiles/Permission Sets, provide access to the required users.  

Please refer this official doc as well-

Hi Blaire (we crossed paths on your dynamic-list question!) both of these come down to how Account Engagement landing pages are built. There are two paths: classic Layout Templates (HTML/CSS you control) and the newer drag-and-drop Landing Page Builder. The Layout Template route gives full control, the drag-drop builder is easier but more limited on both fonts and responsiveness. 

1. Custom fonts: 

Yes, but through a Layout Template, not the drag-drop builder. Edit the template's HTML and in the head either link/import your web font (a Google Fonts link tag, or a font-face rule pointing at a hosted font file), then reference it in the template CSS via font-family. Forms follow the same idea through the form's Layout Template. The drag-drop Landing Page Builder only offers its built-in font list, so for a true custom font you want the Layout Template approach. 

2. Responsiveness / margins not adjusting on phone: 

That is expected if the template uses fixed pixel margins, a px margin set for desktop will not shrink on mobile by itself. Landing page responsiveness lives in the Layout Template's CSS, so: 

- Use CSS media queries in the template to set different margins/padding at mobile and tablet breakpoints, and/or use relative units (percent, rem, max-width) instead of fixed px so things flex. 

- If you are in the drag-drop builder, check its device preview and any per-device spacing settings, but for real control over each breakpoint, edit the Layout Template CSS. 

Net: for custom fonts and true responsive control, build on a Layout Template (or have your web person tweak the template CSS with a font-face rule plus media queries). The drag-drop builder is fine for quick pages but caps you on exactly these two things. 

If this helps, please mark it as the Best Answer so it helps the next person. Thanks :)

Hi Akshay - great write-up, and the good news is most of this traces back to one root cause (your #4), with #2 being expected behavior. Taking them in order: 

#4 first, because it explains 1 and 3: yes, the Incognito/private testing is absolutely skewing your data. Pardot identifies visitors with a first-party tracking cookie. Incognito starts with no cookie and throws it away when the window closes, so every private session looks like a brand-new anonymous visitor - and view/click tracking is often blocked entirely in private mode (and by ad blockers, Safari ITP, and Do Not Track). Submissions still record because a form post is a hard server hit, but the passive view/click pixels may not fire. That one fact drives most of the weirdness below. 

1. Views (3/1) lower than Submissions (7/5): this happens when the view pixel is blocked, or the page is served from cache, while the submission still records. Incognito plus repeated testing is the classic cause. Two other contributors: if you submit the form directly (or via an embedded/iframe form) instead of loading the landing page each time, the submission counts but the landing-page view doesn't; and a cached reload won't always re-fire the view tracker. Test in a normal browser without clearing cookies and the numbers line up much better. 

2. Score climbing on every resubmission: that's expected, not a bug. If you're scoring through the form's completion action (adjust score), it fires on every submission. The standard fix is to move that scoring to an Automation Rule instead - Automation Rules match a given prospect only once by default, so points are awarded on the first submission and not again on repeats. (Alternatively, zero out the per-submission points and lean on grading/engagement.) That gives you the 'first real engagement' behavior you're after. 

3. Two-button click data not matching: plain HTML links on a landing page aren't reliably attributed on their own. To measure which link people prefer, wrap each one in a Pardot Custom Redirect - each gets its own trackable URL and its own click count, so 'Click Here' vs 'Contact Us' becomes clean and unambiguous. (The same Incognito cookie issue was mangling the association here too.) 

For clean testing going forward: use a normal, consistent browser profile, don't clear cookies mid-test, use a dedicated test prospect with a unique email, exclude your internal/team IPs from tracking, and give Pardot a few minutes since activity processing isn't always instant. 

Do that and 1, 3, and 4 largely resolve themselves, and 2 becomes a one-time Automation Rule. Hope this helps!

In Pardot, the "Bounced" activity type indicates that an email was not delivered to the recipient's inbox. However, Pardot does not explicitly distinguish between "Soft Bounces" and "Hard Bounces" in the VISITOR_ACTIVITY.TYPES table. To differentiate between these two types of bounces, you'll need to consider additional information and logic.

Here's a general approach to deriving "Soft Bounces" and "Hard Bounces" from Pardot tables in Power BI:

1. Identify Bounces:

   First, filter the VISITOR_ACTIVITY table to include only records with the activity type 'Bounced'.

2. Gather Additional Information:

   In order to differentiate between "Soft Bounces" and "Hard Bounces," you'll need to analyze the information available in the VISITOR_ACTIVITY table. Look for any relevant fields that might indicate the nature of the bounce.

3. Determine Soft Bounces and Hard Bounces:

   You might need to examine bounce codes, error messages, or any other relevant fields to categorize bounces as "Soft Bounces" or "Hard Bounces." Typically, "Soft Bounces" are temporary delivery failures (mailbox full, server temporarily unavailable, etc.), while "Hard Bounces" are permanent delivery failures (invalid email address, domain doesn't exist, etc.).

4. Create Measures:

   Once you have identified the criteria to differentiate between the bounce types, you can create custom measures in Power BI. These measures will count the occurrences of "Soft Bounces" and "Hard Bounces" based on your categorization.

For example, assuming you've identified that certain bounce codes correspond to "Soft Bounces" and others to "Hard Bounces," you could modify your SQL query like this:

SQL QUERY:-

SELECT

,

    CASE

        WHEN va.type = 1 THEN 'Click'

        -- other activity type cases

        WHEN va.type = 13 AND va.bounce_code IN ('soft_bounce_code_1', 'soft_bounce_code_2') THEN 'Soft Bounce'

        WHEN va.type = 13 AND va.bounce_code IN ('hard_bounce_code_1', 'hard_bounce_code_2') THEN 'Hard Bounce'

        ELSE '?'

    END AS VA_TYPE,

    COUNT(*)

FROM

    VISITOR_ACTIVITY va

    INNER JOIN EMAIL e ON

= va.EMAIL_ID

    INNER JOIN LIST_EMAIL le ON

= va.LIST_EMAIL_ID

WHERE

= 'xxxxxxxxxxxxxxxxxx'

GROUP BY 1, 2

ORDER BY 3 DESC;

Please note that the specific bounce codes and criteria will depend on your Pardot instance's configuration and the information available in the VISITOR_ACTIVITY table. You'll need to adapt the query accordingly.

Remember to replace the placeholder `'soft_bounce_code_1'`, `'soft_bounce_code_2'`, `'hard_bounce_code_1'`, and `'hard_bounce_code_2'` with actual bounce codes that you identify as indicative of "Soft Bounces" and "Hard Bounces.

Hi Blaire - your read is exactly right: Pardot's 'prospect time' and activity-based rules only track Account Engagement activity (email opens, form submits, page views, etc.), not Salesforce sales-rep activity (Tasks, Calls, Events). Pardot doesn't see CRM activities as prospect activity, so no dynamic-list rule reads them directly. The way around it is to bring that CRM activity into Pardot as a synced field, then filter on the field. 

The pattern: 

1. Surface 'last sales activity' as a date field on the Lead in Salesforce. Two options: 

- Standard Last Activity Date - quickest, but it reflects all activities (and check it's mappable in your Pardot field config); or 

- A custom 'Last Sales Activity Date' field (recommended) that you populate with a record-triggered Flow stamping the most recent sales Task/Call/Event date. That lets you define exactly what counts as 'sales rep activity' and excludes anything you don't want. 

2. Map/sync that field to a Pardot custom prospect field (in the Salesforce-Pardot field mapping). 

3. Build the dynamic list on that field: 'Prospect custom field [Last Sales Activity Date] is before 6 weeks ago' - Pardot supports relative-date rules on date fields. Add an OR for 'is empty' to also catch leads that have never had any sales activity. 

The key idea: do the 'no recent activity' logic in Salesforce (where the Task/Call/Event data actually lives) and let Pardot just consume the resulting date field - trying to make Pardot evaluate CRM activities directly won't work. Your drip then runs off that dynamic list. 

Hope that gets the re-engagement campaign going!

In that case, I don’t think there is a dataset currently available that would support this directly.

The most practical option would be to bring the required data into Salesforce on the Lead and Contact records and then use recipes to join the datasets.

For the Lead records, you can join the pdProspect dataset to the Lead dataset using a Left Join, where:

• crm_lead_fid (from pdProspect) matches Id (from Lead)

For Contact records, the join would be:

• crm_contact_fid (from pdProspect) matches Id (from Contact)

You may also want to add a Transform node to combine the Lead and Contact Hard Bounced fields into a single column. Within the same Transform node, you can use a Custom Formula to replicate the Account Engagement Mailability Status logic. This should make it easier to apply consistent filtering in your dashboards.

case  

  when CRM_Hard_Bounced == 'true' then 'Undeliverable' 

  when is_opted_out == 'true' then 'Opted Out' 

  when is_do_not_email == 'true' then 'Do Not Email' 

  else 'Mailable' 

end 

I think this should do the trick here.