#Pardot B2b Marketing Automation30 discussing

That does not look like one of the Sender merge fields that you can use. Here is a list of the Sender merge fields: 

{{Sender.Email}} The sending user’s Email field 

{{Sender.FirstName}} The sending user’s First Name field 

{{Sender.LastName}} The sending user’s Last Name field 

{{Sender.Name}} The sending user’s full name; displayed as: First_Name Last_Name 

{{Sender.Phone}} The sending user’s phone number 

{{Sender.Signature}} The sending user’s text signature, available to edit in the user’s profile 

{{Sender.Title}} The sending user’s job title 

{{Sender.URL}} Link to your company’s website from assigned user’s URL field 

Found here: 

https://help.salesforce.com/s/articleView?id=mktg.pardot_handlebars_merge_fields.htm&type=5

@Maria Giulia De Angelis

Yes — a custom connector user is supported on Connector v2, and the connector syncs exactly the set of Leads/Contacts that user can see, so restricting its record visibility (role + sharing) does scope what syncs. But for "sync only records where a flag = true", the purpose-built and much lower-maintenance tool is Marketing Data Sharing (MDS) — a field-based rule you set in Salesforce (Account Engagement setup) — rather than engineering sharing rules around the connector user. Common pattern: custom user for the security/permission posture, MDS for the actual selection criterion. 

On a record later falling out of scope (flag removed / sharing changes): an already-synced Prospect is NOT deleted — it just stops syncing and stays in Account Engagement with its last values (no manual step needed). If it qualifies again, syncing resumes and re-matches the SAME Prospect by its CRM record id, so you don't get a duplicate. Switching the connector user from B2BMA to a custom user likewise doesn't touch existing Prospects — it only changes sync scope going forward. One caveat: while out of scope a Prospect silently stops receiving updates, so design the flag so records don't churn in/out unintentionally. 

If this helps, please mark it as the Best Answer so it helps the next person — thanks 🙂

Hi Saad

Yes, there is. Under Marketing > Emails > Sent, click on the Name of the email you've sent. On the top right of the page that just opened, there's a "View Report" button. Click on that. Then you will see the report of the email sent, including Unique HTML Opens which are all the unique prospects that opened your email. 

If the email was sent as an email template, you could search for it through Reports > Marketing Assets > Email Templates. Then Navigate to Unique HTML Opens and click the hyperlink. This will take you to the page of all the prospects that opened your email template. 

Hi Sreemanth — this one is almost always the sharing-settings step on the Inventory objects rather than a problem with your Commerce licenses. Things to try, in order: 

1) Set up the Inventory sharing manually instead of using Retry. Click the "Set up manually" link on the Inventory row, then go to Setup → Sharing Settings → Organization-Wide Defaults → Edit. Set Default Internal Access for Location and Location Group

to Public Read/Write, keep "Grant Access Using Hierarchies" checked, and Save. Sharing recalculation runs asynchronously, so wait for the confirmation email before going back to the assistant. 

2) Don't hit Retry while a sharing recalculation is still running.

If the assistant tries to change org-wide defaults while another recalculation is in flight, the step fails with exactly that generic "We couldn't set up all of the features" message. Wait until it finishes, then Retry so it can continue to steps 4–6. 

3) Check Setup → Deferred Sharing Maintenance and Setup → Background Jobs.

If deferred sharing calculation is suspended in the org, the assistant can't update org-wide defaults at all. 

4) Confirm the Inventory objects are actually provisioned.

Location and Location Group come with Inventory Management / Omnichannel Inventory, and a plain new Developer Edition org isn't always fully provisioned for Commerce. If those objects are missing, spinning up a Commerce-enabled trial org (B2B/B2C Commerce trial signup or Environment Hub) is the fastest route. 

5) Check the running user's permissions.

Make sure whoever runs the assistant has the Commerce Admin permission set plus Modify All Data / Manage Sharing. 

Once Inventory sharing is set manually, the assistant should treat the step as complete and let you finish the rest. If it still sticks at 3 of 6 after recalculation completes, check the Setup Audit Trail around the failure timestamp and raise a support case — the generic message doesn't tell you which object failed, but Support can see it. 

Hope that helps.

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!

@Adam Erstelle makes sense! I tried rewording this post/question to make more sense 😅 Few other questions...

1. I assume I can use the "Assign to queue" Completion Action instead of "Assign to user"? 
2. Can I set up two conditional completion actions (can I even set up conditional completion actions or will this impact the external action being related to a new Lead that wasn't assigned/in the system before the form submission?) on the form? Any concerns here as I know Completion actions execute randomly (not in order)? An Engagement Studio Program is recommended and I've done that in the past, but due to needing to assign new Leads to a User on the form Completion Actions for the External Action to relate the form submission detials to the record (Contact or Lead), that's not a possibility.
   • Reason/Goal: I want to assign new Leads (not assigned) to a Queue and not create a SF Task (the external action will relate the form submission details to the Lead record). I want to create SF Tasks for existing records (Lead or Contact) and route them to a Queue (the external action will relate the form submission details to the existing Lead or Contact record). Similar to this set up here as far as new Leads vs. Re-Engagements. Creating a Task for every new Lead, like in that example, duplicates effort and makes it harder to tell re-engagements apart from new Leads.
   • Here are the Queue's:
     1. Not yet assigned → "Assign to Queue"
     2. Already assigned → "Create a SF Task"
     • Note: we’ll only have one Lead Queue to start + the SF Task Queue (a Flow is created to route SF Tasks from a dummy User to the Queue).
   • Testing Findings: I tested the conditional completion actions listed above and here is what I found: 
     • New Lead: if it's a new Lead (not assigned) and they submit the form, then they are assigned to the Queue and no SF Task is created. 
     • Existing Record (Lead or Contact): If they're an existing record and assigned, then a SF Task is created. 
     • The form submission detail external action would fire in each scenario.

I'm also considering adding logic in the form submission detail autolaunched Flow to create a Task for records older than a specific timeframe (day, hour, minutes, etc). 

• New Leads (not assigned in Pardot before form submission): added to a Lead Queue in Salesforce with the form submission details related.
• Existing Records (Leads or Contacts assigned in Pardot/Syncing prior to the form submission): create a SF Task and assign it to the SF Task Queue. Form Submissions details related to the Contact or Lead record.

Thoughts?  

Thanks!