Salesforce, Dynamics, Zoho CRM, and any other CRM mimicking the traditional CRM data infrastructure are hiding the truth about parent-child account relationships. In fact, most CRMs exaggerate the utility and underplay the limitations of hierarchies. This leads to misunderstandings, especially for executives who don’t live in the CRM but want reports pulled by RevOps.
When you first see how account hierarchies are visualized in Salesforce, you might assume that the organizational structure carries over into reporting.
Unfortunately, that’s not how it works—and it’s surprisingly hard to explain this limitation to stakeholders. For revenue operations, parent-child relationships are a big landmine waiting to blow.
Parent-child relationships show how one object record, typically either an account or campaign, relates to a different record in the same object.
While Salesforce allows you to nest several layers (like a grandparent, parent, and child account), you can only report on one layer of that hierarchy in the application’s reporting tool.
There are valid and invalid reasons that someone might want to use parent-child relationships. Let’s take a look at both.
Plenty of business structures legitimately have relationships between one company and its subdivisions or regional offices. While the corporate headquarters might be the ultimate authority for large purchases, other decisions are decentralized and delegated to individual branches, brands, or subdivisions.
One example is Johnson & Johnson, which produces everything from medical devices to baby lotion and has different arms and divisions for managing specific product families. If your company wants to sell to Johnson & Johnson, you could try selling to the corporate office but you’re more likely dealing with business units or individual facilities that have their own general manager.
Another example is the healthcare industry. Most hospitals in your city roll up to a huge corporation, like Kaiser Permanente or Sutter Health. These businesses manage hospitals, doctors, medical offices, specialty clinics, and more. Kaiser Permanente might choose which patient management software is used across its ecosystem while individual offices have the authority to order medications based on their patients’ needs.
Companies often try to use parent-child relationships in their CRM for product installations. Put simply, think about a website with multiple product offerings like digital marketing, social media management, and SEO management. Companies think that they can create a child account for each product as a way to separate products and assign specific support reps to their installation.
To further illustrate this example, think of a car dealership. OEMs, like Ford or General Motors, have extremely strict rules about how their brand is represented on a dealership’s websites. Each dealership needs a distinct website for the OEM, so in addition to a landing page for the physical location, you will see a CTA to navigate to sub pages depending on which OEM you’re interested in.
As a digital advertising vendor working with these dealerships, we were required to have support personnel dedicated to just one OEM brand. There had to be complete barriers between the reps that supported different brands. No information could pass through.
If you use parent-child relationships to manage this type of business setup, you end up triple or quadruple counting the number of dealerships you support. You’ll also under-represent how many dealerships are available to sell to.
For example, if there are 21,000 dealerships in the United States but your team only creates accounts and sub accounts once a product is sold, how do you know your total addressable market? How do you design territories? How do you calculate white space?
Creating accounts per brand is also very confusing when it comes to supporting the customer. You only have one point of contact at each dealership, but multiple accounts for each OEM brand. Since sales and support reps are limited to each OEM account, no one knows what is happening at the dealership level.
Your CRM is focused solely on managing your customer base and not on securing new customers. This makes your sales team’s job much harder. It also makes things confusing for the customer and creates a poor experience. No one wants to feel like the company supporting them doesn’t know what all they’ve purchased or to be transferred during a support call to deal with the same problem on their other website.
In this scenario, we created a custom object for each OEM website ID. This allowed us to have one account for each physical dealership location. We had indicators on the account to list all OEMs, so we could easily see if there were OEMs we were not covering as website providers.
The products still roll up to the account level and can be summarized while still being allocated to their respective website ID.
By using custom objects, you get your cake and can eat it too. You have one account for the physical location and can see how the products are split up without losing the summary capability within your CRM reporting.
Using that custom object, you can create unique assignments for support personnel where they own the custom object record, but they retain visibility into the total products that account has just in case they get a question unrelated to the product they are supporting.
When your CRM has dozens, or even hundreds, of child accounts rolling up to a parent account, territory management gets tricky. The likelihood that your sales rep embarrasses themselves because they didn’t know an account rolled up into an existing customer skyrockets.
Rules of engagement will become murky. Does every child account under a parent account roll up to just one rep? What if the child accounts are in completely different territories or are very different sizes?
Finally, you have to think about security concerns. Who has visibility into account products and contracts? If a sales rep is selling into one account, should they be able to see a related account’s product usage so they can negotiate better? Should accounts be assigned by where the decision maker is located and how do you determine where decision makers are located?
Let’s say that you’re selling into a car dealership company called Peyton Manning Dealerships. They have multiple dealership locations. One location sells Chevrolet and Ford vehicles, another sells Buick, and you have locations for Kia, Hyundai, and Honda. They all have different physical addresses.
In this example, a legitimate parent-child relationship would be to set the parent account as Peyton Manning Dealerships, which is the corporate office. They decide some things for all of the dealership locations but, in many ways, the dealerships operate as franchises with different managers and brands.
Each dealership location would be a child account of Peyton Manning. Since each of the dealership locations (which are child accounts now) has its own relationships with an OEM, they decide when to order more cars from Kia, Hyundai, Buick, etc.
Here is where some companies trip up. They start treating each OEM as separate accounts in the Peyton Manning Dealerships account hierarchy. No account can have multiple parents in any CRM. Each of the dealership locations is aligned with only one OEM, but they are not owned by the OEM. They order and sell the cars, but they don’t share profit.
Instead of relying on parent-child accounts, create a new field for the OEMs that relates to the dealerships. You can run summary reports by OEM and see all of the dealerships associated with that OEM. You can also run summary reports by dealership that show the related OEMs.
Alternatively, you could create a custom object so you can relate multiple OEM records to a single dealership and then run a report based on that object relationship. We outlined this scenario above and recommend using this structure only if you have products or a support/personnel assignment structure that makes the object worth having beyond reporting applications.
Software and hardware companies often have resellers and distributor relationships. The end customer that’s using your product doesn’t have a relationship with your company directly, but with another company that’s distributing and installing your product. That being said, the customer is still entering into a contract with your company.
To properly track your end customers, resellers, and distributors, you’ll need different account types. Distributors and resellers would have their own account type. While they have the relationships with the end customer, they’re not the parent account, so rolling up each customer as a child account to the distributor doesn’t make sense.
Use customer lookup fields to attach the reseller or distributor to the opportunity. This gives you all of the reporting you need and allows you to give your partners access to opportunities that they’re involved in. It also allows for flexibility, so if your customer doesn’t want to work with the same reseller during your next opportunity engagement, you can reflect which reseller they choose accurately.
Start by working with your leadership team to clearly define what an account is in your CRM. Typically an account will have its own physical address. Next try to determine where the decision-makers are based. This aids in territory planning and account allocation. Next, explain to your GTM organization and leadership team what is and isn’t possible when it comes to Salesforce reporting.
Be clear that you can only report one layer down in parent-child relationships. Summaries don’t roll all the way to the top level if you use more than one parent. For large corporations, like with healthcare, you might have a national office, regional subdivisions, and then physical hospital locations. There is no way to pull a report in Salesforce that rolls up the hospital locations to the national office.
The more layers you introduce, the less visibility you have. You’ll need to consider data visualization tools like Looker or Tableau.
