1 Accepted solution
Hey there @jkim21 good question. It all depends on your needs and expected behavior of HubSpot. Bascially, their parent–child companies are purely a relationship/lookup layer. They don't automatically roll up activities or deals. And they do have some limited native automation between the records. Most of what you’re asking about still happens at the individual company/contact/deal level, and you have to design your process around that.
You asked about where the sales activity is logged. Activities (emails, calls, meetings, tasks, notes) are logged to a) the contact you engaged with, b) that contact’s primary associated company, and c) any explicitly associated deals/tickets, etc.
The parent–child link does not auto-share activities: if something is logged on a child company, it does not appear on the parent, and vice versa. But users can generally manage that. To see everything at the parent level, you typically:
- Use lists/reports filtered by “Associated company > Parent company is X”, or
- Manually/with workflows associate key records (contacts/deals) to the parent as well.
So in practice, outreach logs “on the company based on the contact’s primary company,” which will usually be the child, not the parent, unless you deliberately associate the contact to the parent.
As for Deals, they're always “owned” by the deal record itself, but they are associated with one or more companies. A deal associated to a child company does not automatically get associated to the parent company via the parent–child relationship, but that's something users can manage when working in Deals.
I looked up some common best practice if you want “deals only on the child.” Here are a couple that make the most sense IMO:
- Make the child company the primary associated company for the deal.
- Optionally associate the parent company as a secondary company on the deal if you want visibility at both levels.
So yes, Deals “live” on the child if that’s how you associate them; HubSpot will not move them to the parent unless you explicitly add that association.
Now, for your question on how data copies from parent to child... The parent–child relationship alone does not sync or inherit data; all company properties are independent. To copy values down (e.g., Owner, Contract type, Billing address), you need:
- Company-based workflows that use company–company association rules to copy properties from parent to child, or
- An external tool/custom code (e.g., Insycle + workflows, custom Ops Hub action) if you need more complex logic.
Out of the box with standard set-up, HubSpot does not let you easily use “parent company” properties as sources/targets in every workflow context, so more advanced inheritance often requires workarounds or third-party tools. So no, nothing “just copies” on its own as you asked. You design the inheritance pattern with workflows/integration.
And finally to your added question under @SamTassey's comment, BCC logging: parent vs child, when you BCC the HubSpot logging address here's what happens. HubSpot logs the email to the contact record based on the email address, then it associates that email with the contact’s primary company, and with the five most recent open deals for that contact (I bolded that because a lot of us miss that early in our usage - I know I did and it confused me.).
The company picked is not chosen by parent/child hierarchy, but by the contact’s primary company association (and, if enabled, auto-association by domain to create/associate a company). If the email logs to the “wrong” company and you want it under a child:
- Re-associate the contact to the correct child company (either change primary company or add associations and adjust primary).
- On the email activity itself, you can also edit associations and add/remove company records so the activity appears under the correct child company timeline.
You asked for some real world pros and cons of parent–child accounts in HubSpot. Here's what I'd say in my experience.
Pros
- Cleaner account hierarchy for multi-location / franchise / holding-company structures (I see this one as the most common, honestly).
- Easier reporting and list-building using “Parent company” filters (like roll up pipeline or activity across all children in a report, not on the parent timeline).
- Helps ABM/strategic account workflows where you need to group related companies.
Cons / gotchas
- No automatic activity or deal roll-up from child to parent timelines.
- Very limited native workflow actions specifically on “parent vs child” properties, so inheritance needs careful design or external tooling.
- Can create confusion if sales assumes the parent record will show “everything” for the group; in reality you need reports/dashboards for that view.
I hope that helps!
Did my answer help? Please "mark as a solution" to help others find answers. Plus I really appreciate it!
I use all tools available to help answer questions. This may include other Community posts, search engines, and generative AI search tools. But I always use my experience and my own brain to make it human.
| |||||||||||||||||||
Hey there @jkim21 good question. It all depends on your needs and expected behavior of HubSpot. Bascially, their parent–child companies are purely a relationship/lookup layer. They don't automatically roll up activities or deals. And they do have some limited native automation between the records. Most of what you’re asking about still happens at the individual company/contact/deal level, and you have to design your process around that.
You asked about where the sales activity is logged. Activities (emails, calls, meetings, tasks, notes) are logged to a) the contact you engaged with, b) that contact’s primary associated company, and c) any explicitly associated deals/tickets, etc.
The parent–child link does not auto-share activities: if something is logged on a child company, it does not appear on the parent, and vice versa. But users can generally manage that. To see everything at the parent level, you typically:
- Use lists/reports filtered by “Associated company > Parent company is X”, or
- Manually/with workflows associate key records (contacts/deals) to the parent as well.
So in practice, outreach logs “on the company based on the contact’s primary company,” which will usually be the child, not the parent, unless you deliberately associate the contact to the parent.
As for Deals, they're always “owned” by the deal record itself, but they are associated with one or more companies. A deal associated to a child company does not automatically get associated to the parent company via the parent–child relationship, but that's something users can manage when working in Deals.
I looked up some common best practice if you want “deals only on the child.” Here are a couple that make the most sense IMO:
- Make the child company the primary associated company for the deal.
- Optionally associate the parent company as a secondary company on the deal if you want visibility at both levels.
So yes, Deals “live” on the child if that’s how you associate them; HubSpot will not move them to the parent unless you explicitly add that association.
Now, for your question on how data copies from parent to child... The parent–child relationship alone does not sync or inherit data; all company properties are independent. To copy values down (e.g., Owner, Contract type, Billing address), you need:
- Company-based workflows that use company–company association rules to copy properties from parent to child, or
- An external tool/custom code (e.g., Insycle + workflows, custom Ops Hub action) if you need more complex logic.
Out of the box with standard set-up, HubSpot does not let you easily use “parent company” properties as sources/targets in every workflow context, so more advanced inheritance often requires workarounds or third-party tools. So no, nothing “just copies” on its own as you asked. You design the inheritance pattern with workflows/integration.
And finally to your added question under @SamTassey's comment, BCC logging: parent vs child, when you BCC the HubSpot logging address here's what happens. HubSpot logs the email to the contact record based on the email address, then it associates that email with the contact’s primary company, and with the five most recent open deals for that contact (I bolded that because a lot of us miss that early in our usage - I know I did and it confused me.).
The company picked is not chosen by parent/child hierarchy, but by the contact’s primary company association (and, if enabled, auto-association by domain to create/associate a company). If the email logs to the “wrong” company and you want it under a child:
- Re-associate the contact to the correct child company (either change primary company or add associations and adjust primary).
- On the email activity itself, you can also edit associations and add/remove company records so the activity appears under the correct child company timeline.
You asked for some real world pros and cons of parent–child accounts in HubSpot. Here's what I'd say in my experience.
Pros
- Cleaner account hierarchy for multi-location / franchise / holding-company structures (I see this one as the most common, honestly).
- Easier reporting and list-building using “Parent company” filters (like roll up pipeline or activity across all children in a report, not on the parent timeline).
- Helps ABM/strategic account workflows where you need to group related companies.
Cons / gotchas
- No automatic activity or deal roll-up from child to parent timelines.
- Very limited native workflow actions specifically on “parent vs child” properties, so inheritance needs careful design or external tooling.
- Can create confusion if sales assumes the parent record will show “everything” for the group; in reality you need reports/dashboards for that view.
I hope that helps!
Did my answer help? Please "mark as a solution" to help others find answers. Plus I really appreciate it!
I use all tools available to help answer questions. This may include other Community posts, search engines, and generative AI search tools. But I always use my experience and my own brain to make it human.
| |||||||||||||||||||
