Zentrik keeps one clear Account record for each customer entity, connects that Account to the systems that know it, and lets you review related Accounts as a company group. Matching becomes easier to trust because names help people review candidates while durable source identities keep future imports on the right record.
Customer data rarely arrives with one perfect name. The same customer may appear as a Salesforce Account, a HubSpot company, a Pendo account identity, and several rows in a spreadsheet. Those records may describe one customer, or they may describe separate practices, regions, or subsidiaries that should remain separate.
Zentrik uses a small set of rules to keep that distinction visible:
- Account is the customer record your team manages in Zentrik.
- Connection is a provider record attached to an Account, such as a Salesforce Account or HubSpot company.
- Company group is the parent-and-child view for related Accounts. It does not merge them.
- Evidence keeps the original Account that produced it, even when you review the whole company group.
The result is a directory that stays useful for people, a matching system that gets more reliable over time, and Discovery context that remains traceable to its source.
The source record, the Account, the company group, and the Evidence scope each have a different job. Keeping those jobs separate prevents duplicates and preserves the path back to the original customer record.
The Account model
Start with the customer entity, not the provider record. Create or keep one Zentrik Account for each entity your team needs to address, measure, or make decisions about.
| Term | What it means | What it does not mean |
|---|---|---|
| Account | The canonical customer record in Zentrik. | A copy of every CRM row. |
| Connection | A known record from a connected system, attached to an Account. | A second Account that can drift from the first. |
| Company group | A parent Account and its related child Accounts. | A merge, a legal entity, or an automatic ARR rollup. |
| Evidence | A customer or product signal linked to an Account. | A free-floating note with no source attribution. |
Use separate Accounts when the records have different owners, contracts, products, locations, or customer relationships. Use a company group when your team needs to see those Accounts together.
Do not put provider IDs, domains, or parent names into the Account name. Keep those as connection data or separate fields so the name stays readable when a source changes.
Connect your systems
Connect the systems that hold customer identity and the systems that hold customer evidence. The source of an identity and the source of an insight do not need to be the same system.
Salesforce and HubSpot
Salesforce and HubSpot can provide customer identity, account fields, owners, contacts, deals, and revenue context.
When the provider exposes a readable parent relationship, Zentrik can use it to suggest a company group. Salesforce uses the Account parent relationship. HubSpot uses its standard company-to-company parent association. A custom label or a shared domain is not enough to create a parent-child relationship.
The connection keeps the provider and its record identity with the Account. A later sync can refresh fields on that same Account instead of creating another one. Zentrik reads these systems for matching and context; it does not write account changes back to the CRM.
Pendo and other sources
Pendo is mainly a source of product sentiment and feedback. Its account identity is scoped to a Pendo app, so the same text value in two apps should not be treated as the same customer until you review it.
Other sources can attach evidence to an existing Account without defining the company hierarchy. That is useful: the system that knows a customer relationship best can remain the source of identity, while the system that knows product usage or feedback supplies the evidence.
Matching and imports
Matching is safest when Zentrik can reuse a durable provider identity. Names and domains help find a candidate, but they are not a permanent identity key.
The review order is:
- A known provider record already linked to an Account.
- A mapping that someone has reviewed and approved.
- A provider identity that is unique and safe to attach.
- An exact domain or name candidate that still needs review when more than one Account could fit.
Zentrik does not silently merge two Accounts because they share a domain, a name fragment, or a parent name. A match that is not clear stays available for review. That protects separate locations and subsidiaries from being folded together by accident.
Choose the Account name
Use the name your team uses when discussing the customer. Keep it stable, readable, and specific enough to distinguish separate Accounts.
Good names usually follow these rules:
- Use the operating or customer-facing name that people recognize.
- Keep a legal suffix only when it distinguishes the Account.
- Add a location, product, or region only when it identifies a separate Account with its own customer relationship.
- Do not use provider IDs, URLs, repeated parent prefixes, or temporary import labels.
For example, keep Northstar Dental - Austin and Northstar Dental - Denver as separate Accounts if they are separate relationships. Group them under Northstar Dental only when the parent relationship is real and useful to your team. Do not rename both Accounts to the parent name.
Review before applying
For a normal integration import, preview the proposed matches, approve clear rows, and resolve the small set of ambiguous rows separately. Once a provider record is linked, later imports can use that durable link.
For a large workbook or a file that combines CRM IDs, billing IDs, family IDs, URLs, and proposed parents, use a staged review:
- Confirm what one row represents. It may be an Account, a location, a contract, or a revenue snapshot.
- Preserve every source namespace in its own column. A Salesforce ID, billing ID, and family ID are different keys.
- Propose the Zentrik Account, canonical name, parent, and action: link, create, keep separate, merge, or review.
- Check duplicate and parent claims in small batches before applying them.
- Keep the source file and the review decision so the result can be explained later.
Do not load a complex workbook as a list of new Accounts first. That creates duplicates before the source identities and row grain have been understood.
Company groups and Evidence
Company groups give you a broader review scope without changing the source data.
- The Account overview stays focused on one Account.
- Connections shows the provider records attached to that Account and the relationship to its group.
- In Evidence, choose This account for direct context or Company group to review the parent and its descendants together.
- Each Evidence row still shows the Account that produced it. A child Account does not become anonymous inside the group view.
This lets a product team ask both questions it needs: “What is happening with this customer location?” and “What pattern is visible across the company?” The group view is a scope for review, not a second copy of the evidence.
ARR and Discovery links
ARR remains an Account-level value. A company group does not merge Accounts, rewrite their ARR, or automatically sum repeated family-level revenue values.
This matters when a source export repeats one family total on every member row. Keep the value at the grain where the source defines it, and confirm whether it is contract ARR, family ARR, location ARR, or another measure before mapping it to an Account.
Discovery links remain tied to the Account that was linked when the signal was imported. A company-group Evidence view reads those existing links with a wider scope; it does not create new parent links or change the meaning of linked ARR on an insight, opportunity, idea, or initiative.
If a product decision needs company-level commercial context, review the group and its member Accounts together. If it needs a clean revenue total, use a source-defined rollup that has been checked for duplicate values.
Troubleshooting
Check these steps against what you see in your workspace. If something differs, note your workspace name and the screen, then contact us.
Why did two similar records stay separate?
Similarity does not prove that two customer entities are the same. Check whether they have different contracts, locations, owners, or provider records. Merge only when they represent one Account. Otherwise, connect them in a company group.
Why did Zentrik ask me to review a match?
The source did not provide one durable identity, or more than one Account could fit. Review the candidate using the provider record, domain, owner, location, and customer relationship. Your approved mapping makes later imports more reliable.
Why is a parent or company group missing?
The source may not provide a readable parent relationship, the parent record may not be linked yet, or the relationship may still need review. A shared domain or a repeated name does not create a hierarchy by itself.
Why does the company-group view show a child Account name?
Zentrik keeps source attribution visible. The row is still evidence from that child Account. The wider scope helps you see the group pattern without hiding where the evidence came from.
Continue from here
Related guides
Did this guide answer your question?
Your response helps us prioritize missing or unclear documentation.
Still stuck?
Send your question to Zentrik support. This guide will be included automatically.