View the session live or catch the replay here. You’ll find the recording and all related resources on this page once available.
Our live discussions are happening over in Slack. That’s where you can connect with speakers, join session threads, and chat with other attendees in real time.
Implementing Pardot Business Units (PBUs) is like putting together a very intricate puzzle where you have to analyze each piece before putting it into place. There are a lot of moving pieces in a PBU implementation, so understanding how PBUs work and planning each step of the implementation is vital to success.
In this session:
Overview of how PBUs work
The key items you will need to plan for before implementation
Hello, everyone. My name is Amber. I’m going to be moderating the session today. Uh, we have Erin Duncan. She’s going to present planning for your Pardot business unit implementation. Um, you can use the Q&A in the chat if you have any questions, but we’re going to wait till the end to answer them. Um, so take it away, Erin.
Speaker 1: Thank you. Hey, everyone. I’m Erin Duncan. Um, we’re going to talk a little bit about Pardot business units and how to understand them today. Um, before I get started, I do have to start with a disclaimer. Salesforce highly recommends implementing Pardot business units, and you may hear me refer to them as PBUs, uh, during this session as well. But highly recommend you implement them with a partner. Um, business units are a little complicated. It’s easy to break something, and if you break something, you can fix it, but you need to know how. And that is the main reason why you should go into this with a partner. This session will kind of explain business units to you so you know how to plan and you understand the steps that you have to go through to implement this, but it’s by no means going to make you, you know, you can’t tomorrow start a business unit implementation. So let’s start with what are business units. Pardot business units are essentially their own Pardot orgs that are connected through the same Salesforce org. So they’re partitioned Pardot databases. They do not have any connection with each other and especially not a hierarchical relationship. They’re only connected by the Salesforce instance that they all share. So there’s a couple different ways to split up your Pardot business units. You can do it by country, product, service, industry verticals, anywhere where you’re going to have separate, um, marketing teams, email templates, branding, prospects, prospect journeys, anything like that, um, you’re going to want to split up into business units as your business grows. I’m going to use a couple examples in our session today. So just for the examples that I’ll give, I’m going to say that we have three business units split up split up by regions. We’ve got a Europe, a United States, and a Canada, um, business unit. So each business unit has its own Salesforce connector. Um, they the Salesforce connectors can use the same connector user or they can all use a B2B Marketing Integration User, um, but they’re each PBU will have its own connector, its own settings. They can be paused separately. They’ll all function, um, separately. Each business unit also has its own prospects, marketing assets, automation rules, settings, Salesforce campaigns. I mean, it’s pretty much its own Pardot database. Access to the different business units is going to be controlled by Salesforce user sync. That is one of the requirements to have business units. And then access can be controlled by your Salesforce profiles. You want to map those to your Pardot roles. And then you can grant individual Salesforce users access to the Pardot business units in three different ways. You can use public groups. So if they’re a member of, you know, maybe you create a Pardot US users public group, and if they’re a member of that, um, that group gets access to the US PBU. You can grant them access by their role in Salesforce, or you can go in and grant individual users access under your Pardot user assignment in Salesforce. I do recommend going with the public group option because you can automate that. You can say, if someone has this Salesforce profile, automatically add them into this public group, and the public group is tied to the Pardot user assignments, so they automatically get added to that, uh, business unit. There are two types of Pardot business unit implementations. Um, there’s the typical implementation where leads and contacts exist in one PBU at a time. So if you need a lead or contact to exist in multiple business units, they have to be duplicated in Salesforce. So this is what we’re going to talk about today. This is the most typical one that, um, users use. There is also the newer cross-PBU implementation. Um, it’s also called the single view of the prospect. This came out earlier this year, um, and it allows you to have leads and contacts in multiple business units without needing duplicates in Salesforce. This does prevent regular syncing of package fields, so those fields that say, like, Pardot created date, Pardot hard bounced, Pardot score grade, all of those fields in Salesforce that appear when you integrate Pardot and Salesforce, those will no longer sync when you have a cross-PBU implementation. So if you’re going to go with a cross-PBU implementation, um, it requires custom objects and a thorough understanding of the Pardot API. So I always recommend you have someone who understands the the Pardot API on your team when doing this type of implementation. So a couple of requirements to have, uh, business units. You have to be on Pardot Advanced or Pardot Premium. You have to enable Pardot User Sync. You have to have the V2 connector, and you have to have Pardot Lightning. Um, I’ve linked more information on each of these requirements. So this PowerPoint should be available on Monday. You can click into all the additional info. Um, you can do the Pardot User Sync and the V2 connector as kind of your PBU implementation. I’ve definitely done that before, so that’s always an option. Alright. Let’s talk about how prospects sync with, um, PBUs. This part is a little little confusing, um, but prospects, opportunities, and custom objects can only be in one PBU at a time by default with the typical implementation. And you can control this in two different ways. You can use org defaults and sharing rules. So this is set up on the Salesforce side, and it essentially says, if this user, that’s your connector user, can see these records, then they can sync to Pardot. That’s a good solution when you have one business unit and you only have, like, one connector user. But when you have multiple business units or multiple connector users, it gets very messy very quickly. The other option is to use Marketing Data Sharing. Um, this is definitely what I recommend. It does require the V2 connector. And if you’re not familiar with Marketing Data Sharing, it essentially restricts what can sync between Salesforce and Pardot based off of criteria. So you create one field in your Salesforce instance that controls your Marketing Data Sharing syncing. What I typically do is I create a field called Pardot Business Unit, and then I create a picklist value for each of my business units that are available. And what Marketing Data Sharing does, it says, if this lead contact opportunity matches this rule, then it syncs to Pardot. If it doesn’t match this rule, it either doesn’t sync or it goes to the recycle bin. The reason why you want this Marketing Data Sharing field to only be in Salesforce is because if you put it in Pardot, you run into the issue where a new prospect is added to Pardot. They haven’t had a chance to get a Marketing Data Sharing value, and so they immediately go to the recycle bin. So you kind of get stuck in a loop of people not, you know, joining the Pardot and then getting kicked out. So make sure this is only only in Salesforce. I have written a blog post on Marketing Data Sharing, all the things you have to know, and how to set it up, so that’s linked here as well. So prospect syncing to BUs and moving between BUs. When a prospect moves from one BU to another, their activity history does not come with them. Only the fields that are synced to Salesforce will come with them to their new PBU. So this was something that was a little tricky for me to wrap my head around, so I created a visual. Um, so let’s say we have a prospect in the US, but they don’t belong in the US. They belong in, um, the Europe PBU. So they need to, uh, get over here. But, basically, there’s no connection between these Pardot business units. There’s no way for them to just hop over here. Um, so what they need to do is they need to go up to Salesforce and then down to the Europe, uh, Pardot business unit. So they can only they’ll only travel with whatever gets up here will come down here. If it doesn’t get into Salesforce, it doesn’t come down here. So that’s the best way I can kind of visualize this syncing. Connected Campaigns are a whole different different syncing methodology. Marketing Data Sharing doesn’t touch campaigns. Campaigns sync through record types and record types alone. So when using business units, you’re going to want to create a record type for each of your Pardot business units, at least one record type. So you might have something like this where you have, you know, a sales and admin campaign record type, and those don’t sync to Pardot at all. And then you’ve got your marketing record types in one for each business unit. If you try to sync campaigns to multiple business units, your reporting is going to basically be unusable. So I wouldn’t suggest trying to sync one record type to multiple business units. Alright. So let’s talk about the setup a little bit. So when you’re implementing Pardot business units, you’re going to have to look at your users to make sure you can automate the setup of your users and their permissions into the business units easily. So what I like to do is create a giant spreadsheet that has all of my users, their Salesforce profile, their Pardot role, and which business unit they either have access to or need access to. Once you have all of this data, you want to look at your users and say, okay. Can I tell what Salesforce profile and what Pardot I’m sorry? Can I tell what business unit and what Pardot role they’re going to have by the Salesforce profile alone? If you can’t tell that, you’re probably going to need to create additional Salesforce profile, uh, Salesforce profiles. Because what you want to do is you want to get to a point where you can automate and say, if this person has, um, the Salesforce profile of Marketing User US, we know they’re going to get this Pardot role, um, in their Pardot BU, and that’s set up with user sync, and we know they’re going to get access to this PBU. So if someone’s a Marketing Admin, we know they’ll have admin access in Pardot, and we know they’ll have access to all three of these PBUs. Another thing you’ll need to do is decide what’s going to be universal between your PBUs. Um, I definitely recommend you make your naming conventions and folder structures universal between your business units because if users are going to switch between different business units, they are still going to need to know how to find stuff, what items are, all of that just from looking at the naming conventions. You don’t want it to be a completely different world between each business unit because it’s going to slow users down, and it’s going to cause confusion. I do also recommend adding your PBU name to your naming conventions. Unless you’re on the Pardot Settings tab, it is not clear in Lightning which business unit you are currently in. So if you add your PBU name to your naming conventions, then you can tell which PBU you’re in just by looking at assets. You can also tell which PBU a campaign belongs to without looking at its record type. It just makes things a lot more clear. You’re also going to want to standardize your fields, field values, and field syncing, um, because prospects are going to move back and forth between the different BUs. And if you have, you know, one PBU has a field that is a number field, and in Salesforce, it’s a text field, and then another PBU is a picklist, you’re going to run into sync errors when prospects try to move back and forth between the different PBUs. I’d also recommend standardizing your connector version and settings, um, your connected campaign setup, and custom user roles just to make everything easy to use for your users, especially with custom user roles. If you have a custom user role called, you know, Marketing Sender or, um, Marketing Approver, you’re going to want to make sure everyone knows what permissions that custom user role is going to have in every PBU. There’s also a couple of optional things you may want to consider standardizing, um, email and layout templates. I mean, your PBUs may have different branding, but you may want to create, like, the same core set of templates. Maybe you have one for autoresponders, one for events, one master template. Um, consider standardizing your preference centers so the experience is the same for your prospects. Um, any engagement programs, automated processes, or rules that you use for admin, um, stuff or cleanup in in Pardot, you’ll want to standardize across the PBUs as well. And then Courtney, who hosted the demo jam this morning, she just put out, uh, a blog post about standardizing the business units. It’s really good, so I’ve linked that in here as well. There’s a couple things you’ll want to prep before you turn on business units and start moving your prospects around. Um, you’re going to want to enable Pardot Lightning for all of your Pardot users. Um, if users don’t have access to Lightning or they don’t have access to the Pardot Settings tab, they cannot switch between the BUs. So you’ll get a when you have multiple business units, you’ll get what is called the business unit switcher. It only shows up on the Pardot Settings tab, and it’s essentially a dropdown where you can switch back and forth between units. And this only shows up to users who have access to multiple. If I only had access to the United States, it would just say United States up here with no dropdown. You’re also going to want to stamp your existing leads, contacts, and opportunities that are syncing with Pardot with their Marketing Data Sharing value if you are using Marketing Data Sharing. The reason why you want to stamp them beforehand is if you turn on Marketing Data Sharing without all of these existing objects being stamped, then everything will go to the recycle bin. You can bring it back out of the recycle bin, but it will definitely cause some panic. And then the last thing you want to do is clear and review your sync errors because Marketing Data Sharing can’t move prospects that are not syncing to Salesforce. And then there are a couple of considerations to keep in mind. If you are planning on consolidating or moving Salesforce orgs, do this before your Pardot, uh, business unit implementation. Because once a BU is created in Salesforce, it can’t be deleted or moved or renamed. So if you’re going to do any migrations with Salesforce, just make sure you do that first. Tracker domains can’t be shared between your PBUs, but root domains can. So what that means is my US PBU could use https://www.google.com/search?q=www2.cercante.com. My EU PBU could use https://www.google.com/search?q=www3.cercante.com, and so on. So the https://www.google.com/search?q=cercante.com can be shared, but the w w w’s can’t. Dedicated sending IPs cannot be shared, so you’re going to want to warm up your sending IP in each of your PBUs. The PBUs can share the same domain sending domain. So if you want all your emails to come from @https://www.google.com/search?q=cercante.com, you can do that. The support has to enable it for you. If you try to enable it yourself, you’re going to get an error message that you can’t do it. So a lot of people think you can’t do it at all, but support can absolutely enable that for you. And then the last consideration is that Pardot assets cannot be shared between business units, but platform assets can be. So what that means is if you build an email or landing page in the, you know, the typical classic builder, um, if you want to build that asset in another business unit, you’re going to essentially have to recreate it. You’re going to have to go into that new business unit, name it, do your layout, um, do all of your settings, all your completion actions. You just completely rebuild it from scratch. Platform assets refer to assets built with the new email Lightning Builder or landing page Lightning Builder. There, you can copy an existing asset and point it at another PBU, and you don’t have to recreate the asset. So if you’re going to have multiple business units, I would recommend looking into those Lightning Builders and enabling them for your users as soon as possible because that’s going to make the make using the same assets in all of your business units much easier. So I know I threw a whole bunch of information at you guys. Um, I wanted to leave a little bit of time for questions because I know business units are a little complicated.
Speaker 0: We have a lot of questions here. I’m going to start with the oldest ones. Um, this is from Sam Chack. Um, what if we are new to Pardot and don’t have experience with syncing the information between both Pardot and Salesforce?
Speaker 1: Say that again. Sorry. I was trying to fix my screen.
Speaker 0: Oh, sorry. Um, what if we are new to Pardot and don’t have experience with syncing the information between both Pardot and Salesforce?
Speaker 1: So, essentially, just how to get familiar with with how the information syncs back and forth. Yeah. I mean, if you’re going to use multiple business units, I would and you don’t have Pardot right now, I wouldn’t just jump into multiple right away. I’d set up your one, fine-tune it, make sure you get set everything set up like you want it to, set up your fields between Pardot and Salesforce, and make sure everything is exactly how you want it before you duplicate it across the BUs. Because if you are trying to fine-tune everything and set up everything all at once without knowing exactly how you want to go forward, you’re essentially making yourself do it, you know, two or three or four times.
Speaker 0: Cool. Uh, the next one we have is from anonymous. Is there an alternative to Marketing Data Sharing? For example, doing the validation in Salesforce instead.
Speaker 1: Yeah. The only the only other item is is sharing settings. Um, so you can you would need I would recommend you need separate connector users, and then you have to use sharing settings to essentially say, okay. This set of leads and contacts can be seen by this connector user, and that means they can sync to that BU and same with your other BUs. It’s possible. It’s just messier, and you do have to get a lot of help from your Salesforce admins, which I know some Pardot admins we we try to avoid, and we try to do it all ourselves. So
Speaker 0: Great. Um, let’s see. Next question. If a prospect is created in a Pardot BU, then how will the how will field be used in Marketing Data Sharing get populated in CRM so that the prospect doesn’t go to the recycle bin in Pardot?
Speaker 1: Yeah. Actually, one thing I left out, when you set up your Marketing Data Sharing field, you also want to set up, like, a process I like Process Builder, but I know it’s going away. So you really should set up a Flow to say to look at the prospect data and stamp its Marketing Data Sharing, um, field. So if you are going with the country region separation that I used in my example, you’d want to say you’d want to have a process that looks at their country and stamps their Marketing Data Sharing value based off of their country. So prospects that live just in Pardot, it’s it’s fine that they don’t have a Marketing Data Sharing value. They’re not going to go to the recycle bin. As soon as they start syncing to Salesforce, that’s when they need to have that value, and that’s when Marketing Data Sharing will move them if if it’s needed.
Speaker 0: Cool. Next, we have business units don’t have to be just geographical. Correct?
Speaker 1: Correct. Yeah. You can do it by I’ve seen people do it by industry, by product or service, um, any anywhere where you’re going to have different assets, processes, teams, all of that is how you can separate it. I just find that, um, region and country is the most common.
Speaker 0: Makes sense. Uh, next we have do we need to get set up with business units when we first get into Pardot?
Speaker 1: No. You can migrate it migrate to it later, which is what most people do. They’ll they’ll run with a single business unit for a little bit, and then they’ll outgrow it and decide that they need multiple.
Speaker 0: Great. One last question. Can we share email templates and landing pages if we set them up in the new email and landing page builders?
Speaker 1: You can. Um, I think there are some limitations around the new builders and templates though, so that would be the only restriction I would look into. But so in the new Lightning Builder, you wouldn’t just have one template and say this belongs in all of the business units. You would have one template that you could essentially copy and point to the different business units. And it would be the same template, but you can easily recreate it for the other BUs. Cool.
Speaker 0: Well, that is all of our questions, and we are just at time. So, uh, thanks everybody for joining the session today. And thank you, Erin. That was great. Thanks. Make sure you get to the end, uh, keynote today. We have Slack as part of when workflows relationships grow. Um, that should be a really good one. Uh, so thank you, everybody. Thank you to our sponsors. Uh, have a great rest of your day. Thanks. Bye.
Speaker 2: Bye.