Mike Fazio, Author at The Spot

Supercharge sales ‘speed to lead’ with clean Pardot data

Mike Fazio — Thu, 10 Jun 2021 15:08:40 +0000

When speed to lead is important, clean Pardot data is key.

In sales, a lot can be said about timing. Catching a prospect on a good day, at the right time and with the right question or topic can fast-track a deal you’ve been chasing for months. And as marketers, we are in the unique position to ensure that we start the lead process off with the best timing by focusing on ways to increase, what sales calls, our ‘speed to lead’.

What does ‘speed to lead’ mean in sales & marketing?

Speed to lead is defined as the amount of time between someone expressing interest in your company and your sales team’s first response. You’ve probably seen it happen (the Salesforce sales team does too good of a job at this): you fill out a form on a website. As soon as the confirmation hits your inbox, your phone rings with a salesperson asking if you have any questions.

This behavior is known to produce good sales outcomes if it’s done sincerely and with tact (so you don’t become annoying and badger potential clients). A lot of ‘speed to lead’ discussion is had with companies that measure first responses in single-digit minutes. But every organization benefits from decreasing the time it takes for a hand-raiser to get to the sales team.

Get clean data and improve speed to lead time

Now, let’s put our marketing operations hats back on. What happens if the data you’re receiving about Pardot Prospects is incomplete or incorrectly formatted? You might get “U.S.A.” and then have a sync error because Salesforce has “State and Country Picklists” enabled. On the other hand, you might be fighting the battle between needing more complete data for routing versus not deterring prospects from completing a form.

You can take action from the Pardot side before the data gets into Salesforce. Utilize completion actions, automation rules, and engagement studio programs to clean up known and recurring issues with data. Depending on the tool you use, there will be some delay in processing the data. But if sales isn’t clamoring to measure speed to lead in minutes, then you should be okay. Those automations all have their pros and cons. However, you should be able to use them to clean up a certain amount of data automatically. One of the biggest hurdles you’ll have to address the growing complexity of trying to add a new automation for each field (and cleaned field value) you want to fix.

One note when making these data cleaning rules: make sure you think through how you’re using the “Contains” filter because “Country CONTAINS ‘DE’ will match “DE” (Germany) AND “Denmark.”

Send incomplete lead records to Salesforce first

If your data rules are less stringent, then you might be able to get the data into Salesforce before cleaning. We like to assign the not-yet-clean leads to a marketing queue. But you have a lot more options for cleaning data than we do in Pardot if you can sync incomplete or incorrect data to Salesforce and hold off on assigning leads to a queue. AppExchange products, Flow, and custom Apex classes can all work to help you normalize, standardize and enrich the data. Once you have clean data, then you can use a Flow/Apex/AppExchange product to re-route the lead to the right spot.

Clean Pardot data at the source

Another place to look for cleaner data is at the source. Optimize your conversion points to ensure data fits your needs as it enters your org. For example, make sure your web form state and country fields are picklist/dropdown fields. Then verify that the values match what is in your Salesforce org’s state and country picklists. Bonus points if you can restrict the state to the selected country. Also, we’ve found that some lead generation vendors have ‘standardized’ their data to meet their own set of standards. For instance, they may be using employee count ranges instead of the exact value. Since you’re essentially paying them for data, then you should be able to convince them to format their data to YOUR standards.

It’s also worth a note here on where to look for data problems to begin with. The first place to check (regularly) is your Sync Errors list in Pardot Settings. This will give you a list of every Prospect who was unable to sync to Salesforce and the reason why. Occasionally these reasons can be cryptic, so get your Google-fu ready and go find your Salesforce Admin (if that’s not also you). Bucket the list of errors together, and look for commonality and patterns. See if you can then determine the root cause of the errors and if they are one-offs or repeatable issues you need to resolve.

Find data issues in Salesforce Reports

Another place to look for issues is in Salesforce Reports. I love seeing a freshly created dashboard because of the data story it tells. It’s usually an eye-opening story about bad or incomplete data.

Here’s an example of something to look for in these types of reports:

Open a lead report.
Look for leads that have met your stated ‘assign to sales’ threshold.
Identify the ones that have met the threshold but are still assigned to the Pardot connector/integration user, or they are still in your marketing queue.

Why aren’t those leads assigned to sales? They’re growing mold and you’re losing money. If it’s one or two, it might be a fluke. It’s still worth it to take a look. If it’s a lot of leads, then it’s time to roll up your sleeves and figure out what’s going wrong — quickly.

Improve speed to lead times with Pardot tools

Clearly we’ve seen these situations happen in many Pardot orgs and have felt this pain (and continue to feel this pain). So, you’re not alone. Over the years, our Sercante Labs team has found ways to automate this pain away for ourselves and our customers. It’s turned into a tool that we simply call Prospect Updater for Pardot.

Prospect Updater helps us do advanced data cleanup and enrichment inside Pardot. That means data is cleaned BEFORE prospects are assigned and in Pardot. The tool works wonders with clamping down on spam-bot submissions on your forms.

Where have you seen the biggest data issues arise and how have you dealt with them? Ping us on Twitter or add a comment below. And reach out to us to learn more about using Prospect Updater for Pardot in your org. Here’s to good leads and clean data!

Original article: Supercharge sales ‘speed to lead’ with clean Pardot data

The post Supercharge sales ‘speed to lead’ with clean Pardot data appeared first on The Spot.

Single Pardot Form, Multiple Completion Actions

Mike Fazio — Mon, 25 Jan 2021 19:06:00 +0000

Have you ever wished you could have multiple conditional form completion actions in a single Pardot form?

If you answered “OF FREAKIN’ COURSE I HAVE”, you’re in luck because I am going to teach you how in just 5 easy steps.

As you know it is super easy to add a single completion action to a Pardot form. But what would you do if you wanted to add multiple completion actions to a form and tie those actions to specific form elements.

I know, it’s a head scratcher right (and you’ve probably heard: “Nope, can’t do it”)? Never fear I’ll guide you through the dragon’s den.

When we combine the magic of Pardot together with the superpowers of JavaScript anything is possible.

But, before we take our first step down the path to knowledge, let’s set the scene. Imagine that we are promoting multiple webinar events with a single registration form.

In this scenario, we want to have one landing page that has a list of upcoming webinars. Visitors can choose one or more of those webinars to attend and only need to fill out one Pardot form. Then, we need that registration information to register the visitor (now a Prospect) in the appropriate GoToWebinar sessions.

So where do we start?

Step 1: Configure the Custom Fields.

Our first step is to identify the field(s) we will use on the form and to which form elements we will apply the conditional completion actions.

We need to note the API field name (field ID) for the field(s) we’ve selected. These can be found with one of the following navigations depending upon your chosen experience:

In Pardot (classic), navigate to Admin | Configure Fields | Prospect Fields.
In the Pardot Lightning app, click the Pardot Settings tab, then click Object and Field Configuration | Prospect Fields.

For our scenario we’ll create 4 custom fields for 4 upcoming webinars so our future prospects can register for any or all of our webinar options.

Our list of the unique Field IDs:

Webinar_topic_1
Webinar_topic_2
Webinar_topic_3
Webinar_topic_4

Keep these IDs somewhere you can access them easily. They’ll be needed in our final step.

Step 2: Create a Pardot form (or edit an existing one).

Make sure to select the fields that you wish to use for your completion actions and make sure they are checkbox fields, text fields, or radio buttons. If they are Checkbox fields, they must have EXACTLY ONE selection option. When selecting your inputs make sure to uncheck the required option.

For our scenario, I’ve created 4 custom checkbox fields and added each to the form. Each has exactly one value, and was step up like this:

First select the Prospect Field “Webinar Topic 1”, select type of Checkbox and Data Form of “Text”.

Now click on the Values tab. Enter the Value that you want to display on the form (in this case, our Value is Webinar Event 1). Keep a record of this value handy. We’ll need it in step 5 when we start customizing our JavaScript.

Note that for each form field value on which you want to apply a unique completion action, you will need to create a unique form handler. In our example we’ll be using 4 completion actions and therefore 4 form handlers.

These are our Field ID and Value pairs so far:

FieldID: Webinar_topic_1
Form Value: Webinar Event 1
FieldID: Webinar_topic_2
Form Value: Webinar Event 2
FieldID: Webinar_topic_3
Form Value: Webinar Event 3
FieldID: Webinar_topic_4
Form Value: Webinar Event 4

I know the naming is not 100% awesome. I want to keep it generic though so Fields can be reused as needed. If we gave each one very specific names our solution would be too brittle (meaning easy to break, hard to scale).

Step 3: Create a Pardot form handler for each field value you’d like to apply completion actions.

Start by only adding the email field to the form handler. Then, add the corresponding completion action for each value. Save. Take note of the form handler endpoint URL (specifically the HTTPS version) as you’ll need this in step 5 and match it to the related Values from the form.

Note: make sure that the “External Field Name” is: “email” (all lower case), and make sure that “Disable Visitor Activity throttling” has been checked (so that multiple submissions of the form all work flawlessly)

As we continue with our multiple webinar example, I’ve repeated the step 4 times and created a form handler to use for each of the 4 custom fields created in step 2.

Here is a list of the 4 form handlers and their endpoint URLs and how they map to the field values set up above:

FieldID: Webinar_topic_1
Form Value: Webinar Event 1
Form Handler URL: https://sercante.com/l/876401/2020-11-30/gny9d5
FieldID: Webinar_topic_2
Form Value: Webinar Event 2
Form Handler URL: https://sercante.com/l/876401/2020-11-30/gny9df
FieldID: Webinar_topic_3
Form Value: Webinar Event 3
Form Handler URL: https://sercante.com/l/876401/2020-11-30/gny9dk
FieldID: Webinar_topic_4
Form Value: Webinar Event 4

Form Handler URL: https://sercante.com/l/876401/2020-11-30/gny9dh

Step 4: Copy this script and paste into your Pardot form’s Thank You Code.

Copy the code below and paste it directly into the Thank You “Code” in Pardot’s “Completion Actions” tab.

Note: remove the commented console.log statements to observe how it works

After pasting the code into the thank you code input area make sure the “Always display form after submission” checkbox is checked — otherwise this method will not work and the script will run in a loop! Which will cause a total computer meltdown and all pictures of cats on the internet to disappear. Ok that last bit is a small exaggeration but seriously don’t forget the checkbox. You’ve been warned.

Step 5: Time to modify some JavaScript

The code we pasted into our thank you content in step 4 is a bit of boilerplate to get us started. It will need to be updated for each unique use. I know it’s a bit daunting but we’ll take it slow and be very mindful of the characters we adjust.

For our webinar scenario I’ve duplicated the first code block two additional times for a total of 4 blocks of field/value/url. This is a necessary step because we have 4 form handlers and custom fields to match up. If we were only working with 2 we would not need to duplicate this code block.

Notice how each code block is contained in a set of curly braces and separated by a comma. There is no trailing comma on the last block:

{//this block of lines is for option 1
    fieldValue: '%%your_field_id_1{js}%%',
    checkboxVal: 'VALUE_1',
    endpointUrl: 'FORM_HANDLER_1_URL'
},
{//this block of lines is for option 2
    fieldValue: '%%your_field_id_2{js}%%',
    checkboxVal: 'VALUE_2',
    endpointUrl: 'FORM_HANDLER_2_URL'
},
{//this block of lines is for option 3
    fieldValue: '%%your_field_id_3{js}%%',
    checkboxVal: 'VALUE_3',
    endpointUrl: 'FORM_HANDLER_3_URL'
},
{//this block of lines is for option 4
    fieldValue: '%%your_field_id_4{js}%%',
    checkboxVal: 'VALUE_4',
    endpointUrl: 'FORM_HANDLER_4_URL'
}

First thing we need to update is your_field_id_1. Let’s replace that with the Pardot field ID that you want to perform completion actions on. A couple of things to note:

the name must be wrapped in %%, and
a {js} modifier must be added at the end of the name.
For example, if your field id is custom_field_1, it should look like %%custom_field_1{js}%% not %%custom_field_1%% or %custom_field_1{js}%

Now that we know what to watch out for let’s start making edits. First we’ll replace the “your_field_id” placeholders with the values of prospect field IDs (step 1):

%%your_field_id_1{js}%% = %%Webinar_topic_1{js}%%
%%your_field_id_2{js}%% = %%Webinar_topic_2{js}%%
%%your_field_id_3{js}%% = %%Webinar_topic_3{js}%%
%%your_field_id_4{js}%% = %%Webinar_topic_4{js}%%

Next, we replace the placeholder values for “VALUE”. Using our example, the values are what we used in the Pardot form checkbox value tab – Please note that if there are special characters like ampersands (&) in the form values, they MUST be replaced with HTML entity code like: & (that’s the & symbol followed by the letters amp and ended with a semicolon. Probably best to avoid special characters in the Values if at all possible):

VAULE_1 = Webinar Event 1
VAULE_2 = Webinar Event 2
VALUE_3 = Webinar Event 3
VALUE_4 = Webinar Event 4

Finally, each value that we’re searching for in our form will trigger a unique form handler. So, each code block will need to be updated with the correct endpoint URL. Make sure to match the correct endpoint URL with the correct form field.

Here the endpoints created in step 3 are used in place of the FORM_HANDLER_1_URL variables.

FORM_HANDLER_1_URL = https://sercante.com/l/876401/2020-11-30/gny9d5
FORM_HANDLER_2_URL = https://sercante.com/l/876401/2020-11-30/gny9df
FORM_HANDLER_3_URL = https://sercante.com/l/876401/2020-11-30/gny9dk
FORM_HANDLER_4_URL = https://sercante.com/l/876401/2020-11-30/gny9dh

The final block of code from our example looks like this:

Step 6: Just kidding there is no step six

While it’s technically true for the purpose of this blog post, there is no step 6, but if there was it would look something like this:

Test, Test, Test.

Make sure to thoroughly test your landing page, form and JavaScript to ensure everything is working as expected.

And there you have it. Our future prospects will be able to select multiple webinar events with our form checkboxes. Then our unique form actions will run based on the prospect action of selecting one or more of the form elements.

Let’s take a moment to recap what we’ve learned today

We created a custom solution that allows multiple completion actions to fire based on a value recorded by Pardot form in 5 easy steps.
In our imaginary situation we want a user to be able to register for multiple webinar events in one simple form.
We started by creating Prospect Fields and connected form inputs to them.
After linking all the values and Prospect fields we created Pardot form handlers for each form element we want to interact with.
Next we copied a bit of boilerplate JavaScript into the forms Thank you content section and updated the code replacing the generic values with our real content.
Finally we made sure to test all the things and confirm everything is working correctly.

Huge congratulations for making it all the way through with us. Give yourself a big pat on the back and make sure everyone at your company knows how awesome you are with your newly gained wizardry. Come back to visit any time.

If you have any questions or would like help solving other interesting ideas, let us know about it in the comments.

Original article: Single Pardot Form, Multiple Completion Actions

The post Single Pardot Form, Multiple Completion Actions appeared first on The Spot.

How to Test in Pardot Sandboxes, Training Orgs… and Even Production

Mike Fazio — Thu, 21 May 2020 21:58:19 +0000

One of our recent posts outlined the need-to-knows about Pardot Sandboxes. In this one, we’re going to go a bit deeper on how to put this to work in your organization.

But first, a very important call out — Sandboxes are a core part of building cool things in Sales Cloud, but the current Pardot equivalent is slightly different. The biggest difference is a Pardot Sandbox doesn’t provide for passing data or metadata between production and the sandbox or vice versa (at least not yet).

And really, that’s OK. A lot of the functionality in Pardot can be safely and effectively tested in production.

I know, I know, this scares the living daylights out of most Salesforce admins who wouldn’t be caught dead doing that in Sales Cloud — but I promise it’s not as terrifying as it sounds. In this blog, I’ll cover:

What to test in a Pardot Sandbox
What’s okay to test in production
Where more advanced testing MAY be required

Let’s dive in.

What to test in a Pardot Sandbox

The most important things to actively test in a Pardot Sandbox are the items related to the flow of data between Pardot and Salesforce — the things that could change records or cause data to be lost.

If you don’t have access to a Pardot Sandbox, you can request a Pardot Training Environment — and most of the same logic of what to test in Sandboxes applies in those as well.

1. Test the lead/contact/prospect sync between Pardot and Salesforce

The trigger for Pardot to sync prospect records to Salesforce is simple: as soon as it is assigned to a user, queue, or via active Salesforce assignment rule, a Pardot prospect will be linked with a lead or contact in Salesforce.

The process for determining what records sync from Salesforce to Pardot is more nuanced. The default syncing behavior between Salesforce and Pardot is determined by the connector user’s permissions and role. Any records that aren’t shared or “visible” to the connector user don’t sync into Pardot.

With the introduction of the V2 connector in early 2019 came another tool for Pardot Advanced Edition users: the ability to use Marketing Data Sharing. Marketing Data Sharing allows you to further refine your sync behavior by choosing one field on Leads, Contacts, Opportunities and custom objects to determine which records are synced to Pardot. (This is also what dictates syncing to multiple Business Units.)

For example, if you only want U.S. Leads synced to Pardot, you can create a custom field named Region and set the rule to be “If Region equals United States,” then sync the record.

There can be a lot of moving pieces to make sure that the records you want to share between the systems are correctly managed. Since this process could potentially involve making data changes to leads/contacts, this is a good candidate for Sandbox testing.

To test this in a Sandbox, I would recommend pausing the connector while you’re building. Once you’ve defined the business logic for what records sync from Salesforce to Pardot, then configure the profile, permissions, roles, and Marketing Data Sharing.

Run a few reports to get a list of records that you would expect to sync to Pardot and turn the connector sync back on. Give it a day to catch up and then compare the lists to identify anything that may need tweaking and troubleshooting.

2. Test sync behavior with large volumes of records

An issue that can come up in larger orgs with complex automation on the Salesforce side is hitting Salesforce governor limits and/or record and object access issues when large volumes of data are changed all at once.

I would recommend doing a test of large scale changes to see if you may need to rework any lead or contact triggers/automations in Salesforce. To test this, export all of your prospects, make an arbitrary change to a field that is synced to Salesforce on all of the records (i.e. add a period to a text field or something that won’t corrupt all the data), and then import them back into Pardot.

Pardot breaks up its changes into batches of 50 records at a time in order to minimize the load on Process Builders, workflow rules, triggers, etc… but every environment is different, and it’s ideal to know if there are issues to anticipate before moving to production.

If you do get errors, export the error list and look for clues as to what is causing it. Pardot will capture the error message that Salesforce sends for each failed record. In some cases those errors can be fairly common, standard errors (like too many SOQL queries) that you can usually drop into Google to find more info.

Or you’ll see a specific Process Builder named as part of the problem, which indicates where to look next. Sometimes the error is a custom error coming from Apex or a custom validation rule or field validation, in which case doing some sleuthing through your validation rules, field settings or Apex classes/triggers is required.

3. Test field mapping & field-level sync behavior

As part of the implementation process, you should be reviewing your Lead, Contact, Account, and Opportunity fields to determine which to bring over to Pardot. Any fields needed for personalization, segmentation, and training should be set up in Pardot.

With Lead and Contact fields, you can configure sync behavior one of three ways:

Use Salesforce’s value as the master
Use Pardot’s value as the master
Use the most recently updated record

Accounts and Opportunity fields sync one way — from Salesforce to Pardot.

I would recommend focusing Sandbox testing efforts on Lead and Contact fields. You will want to compile a data dictionary outlining which Salesforce field names map to Pardot prospect fields to ensure the data that is passing back and forth is correct.

Review any synced fields that are required at the field level (vs. required on the page layout) or restricted picklists — these are frequent sources of sync errors. To test the sync behavior on these fields once they’re configured, create an import file and observe the behavior. Are the correct values overwritten? Is key data retained? Do you get any sync errors?

4. Test user sync

When you enable Salesforce User Sync with Pardot, you will go through a process of mapping Salesforce profiles to Pardot roles. These roles (Sales, Sales Manager, Marketing, Administrator, or custom roles) dictate what your users will be able to see when logged into Salesforce or viewing Pardot data from the Lead or Contact record in Salesforce.

I would recommend configuring this in the Sandbox and verifying that this behaves as expected. Try using the “log in as” functionality in Salesforce to view Pardot information as different types of Salesforce users and confirm that the expected level of access is present.

What’s okay for Pardot Admins to test in production

Unlike in a Salesforce instance, many of the changes you make in Pardot are pretty simple to delete without major repercussions, especially when first starting out.

Once you have live data in the Pardot production org, though, you will want to be careful of starting automations that change data or trigger communication to a large portion of your database.

These are the items that are low risk and should be built in production, along with some quick testing tips for each type of asset:

1. Email templates & drafts

QA email templates before sending by running a Litmus render to preview on devices/browsers and check that you’ll pass spam filters.

Then, when it’s good to go, get final approval by sending yourself a test email and/or by sending to a test list. Double check the subject line, pre-header text, images, content, and click every link.

2. Forms

QA these before publishing on your website by filling out in incognito mode and verifying that the completion actions fire as expected. Once embedded in a landing page, test using a few different browsers or even a cross-browser testing tool like Browserling.

3. Form handlers

Similar to forms, QA these by filling out in incognito mode and verifying that the completion actions fire as expected. Try “messing up” on required fields and verify that the expected behavior is taking place.

(Side note: In general, I would recommend making fields required on the front end form, and make nothing – except email address – required in the form handler in Pardot. This ensures that no submissions accepted by the front end form get “rejected” by Pardot and lost.)

4. Static lists

There’s not a whole lot to test here.

5. Dynamic lists

Set your filter criteria, then test your logic by clicking the “Preview” button:

This will then generate a preview that looks something like this:

6. Custom redirects

To test, create your link and access it from an incognito browser. Verify that Pardot registers a link clink and you’re in business. You can also test it as a cookied visitor to make sure your completion actions fire as needed.

Build right in Prod — these don’t really require testing.

8. Page actions

After you add tracking code to your website, set up Page Actions where appropriate and then visit those pages as a cookied prospect to make completion actions are firing as expected.

9. Dynamic content

Testing dynamic content depends on where the content is located. If it’s in an email, go through your normal email testing procedures. If it’s on a landing page, add it to the page before it’s live and visit the page as a cookied prospect. Then change that user’s profile to match a different variation of your dynamic content.

If you’re using dynamic content on your website, I recommend working with your web developer to get a staging site where you can test how the dynamic content will work within the website (check mobile, a few desktop sizes and various browsers).

10. Email preference centers & unsubscribe page

Similar to testing the other links in your email, you can (and should) test your EPCs and Unsubscribe Pages. Just make sure to re-subscribe your user after you click the “unsubscribe” button.

11. Scoring

The scoring model in Pardot works retroactively when changes are made, so if you want to try out a certain model today and then revisit and make changes in a month, you can do that and the values will update automatically.

The one caveat here is that the changes you make directly to a prospect’s score (with completion actions or automation rules) are not retroactive, so if you clear a score, the only score you can get back is from the scoring rules.

12. Grading

In Pardot, grading is controlled by a series of automation rules and can be updated and changed as your business needs change. I would consider testing the automation rules that control grading just like other automation rules (see the next section).

As you can see, a lot of what you build in Pardot is self-contained and can be staged, tested and ‘deployed’ all from within your production Pardot instance. However, like I mentioned at the beginning of this section, there are a few things that require a bit more intentional testing to avoid issues in production.

Things to consider for more advanced testing

In a perfect world, there would be a “push to production” button where we can build large Engagement Studio Programs and complex Automation Rules in a Pardot Sandbox and then move them to our live org.

But we don’t have that yet — although according to Pardot, it’s coming. There are some assets in Pardot that you may be tempted to build first in a Sandbox, but where doing so would require the team to spend hours manually rebuilding.

The following items would require a lot of time and effort to build in a Sandbox and manually rebuild. Admins need to weigh the risk/reward of building these types of things in Production directly, or first in a Sandbox (or a mix depending on the complexity). Keep in mind that rebuilding a second time in a new system opens the door to additional mistakes and human error.

1. Automation rules

Automation rules are powerful — and with great power, comes great responsibility.

The hardest part about automation rules is getting the logic correct. So, one idea is to build your logic for the ‘criteria’ first as dynamic lists in Production first. Then you can let these dynamic lists run for days and inspect the membership frequently. If the criteria is pulling in the prospects that you would expect it to pull in, it’s pretty safe to then use that same logic in the criteria for your automation rule and build live in Production.

As a final test, preview the automation rule before turning it on (and take one more look at the actions section to make sure it’s what you want to happen). Yes, this sounds like a royal pain in the keyboard, but automation rules can make massive changes to your data permanently so we want to really look hard at the logic of the criteria.

2. Engagement Studio

Engagement Studio Programs have the widest range of functionality and can edit data, send emails, create tasks and campaign members in Salesforce, assign prospects, and send notifications. So, we need to be intentional with how we build and test our programs.

A few ideas: First, keep it simple. Branching logic is good but can quickly get out of hand, if you need to, split up the logic into multiple, more focused programs.

Second, double check your dates and your logic gates.

Third, create test prospects and add them to the program first. Make sure they meet all of your rules so you can watch how they flow through the system. Depending on your program, you might have to shorten your wait times so you can test in a reasonable amount of time, but keep the program as true to the final as possible.

3. Lead assignment rules/processes

If you’re handling lead assignment in Pardot, you will most likely be building it using completion actions, automation rules, and/or Engagement Studio programs. As such, I would test these using the other suggestions we have for those features. The one difference is that it might be worth creating a few test prospects and running them down various paths to watch how they are assigned.

4. Third-party integrations

There is a wide range of features and functions that outside integrations have and, as such, need to be handled on a case-by-case basis based on the integration.

Some integrations are simple and won’t directly affect Salesforce data, like the Google Analytics and Adwords connectors. But others, like webinar connectors, can make changes to Prospect data — so you’ll want to be sure to test those integrations using test Prospects to watch the data flow to see how and when data is changed. The Sandbox uses a different URL (pi.demo.pardot.com) which might not be supported by the 3rd party integration, so testing compatibility with the Sandbox may vary.

Testing & change management in Pardot

What questions do you have about best practices for testing Pardot assets and automation? What barriers have you run into? Any questions about Pardot Sandboxes?

Let’s hear it in the comments!

Original article: How to Test in Pardot Sandboxes, Training Orgs… and Even Production

The post How to Test in Pardot Sandboxes, Training Orgs… and Even Production appeared first on The Spot.