#Pardot B2b Marketing Automation31 debatiendo

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!

1. User License: Our Pardot users currently have a Chatter/Chatter Free-type license. What license is actually required for Pardot Lightning access — will Chatter-licensed users work, or do they need to be upgraded first? 
   If you are referring to an "identity" license, these still work, but it still retains the limitations in that you can't access certain necessary features, like Salesforce campaigns. Ideally admins should have full salesforce licenses. 
2. Pre-Migration Checklist: What key things should we check or prepare before starting the switch — any pre-migration steps people often overlook? 
   Normally what trips people up is getting the visibility of the app to the correct profiles.  Follow the setup instructions carefully.  Also the user/role mapping if you migrate Account Engagement user management to Salesforce is quirky.  You still map profiles to roles in AE, but there's a whole different mapping in Salesforce. This article has some good tips.  
3. Existing Assets: Will our current email templates, forms, prospects, scheduled email for campaigns, and email domains carry over automatically, or do some need manual migration? 
   There's really no change. It's just looking at the same data in a different interface. However, going on lightning also gives you access to the new CMS, landing page and email builders (which also have to be configured and access given to your users). These are in addition to, not replacing, the current Pardot resources. 
4. Sales Cloud Impact: Does this migration affect our existing Sales Cloud (Lightning) production data in any way? 
   Only that there's a new Account Engagement App for the people that use it. 
5. Classic Access Post-Migration: After Lightning is set up, will pi.pardot.com (Classic) still be accessible, or is it fully deprecated at that point? 
   Yes. 
6. Nonprofit Cloud Compatibility: Is Pardot Lightning compatible with Nonprofit Cloud orgs? Does the setup/migration process work the same way as it does for a standard Sales Cloud org?  
   I would think so but I am not certain of that. 

hello  

I find this articles 

may be it's going to help you. 

regards