> ## Documentation Index
> Fetch the complete documentation index at: https://docs.benefitflow.com/llms.txt
> Use this file to discover all available pages before exploring further.
# CRM Integration: Association Architecture
> How BenefitFlow creates and manages relationships between synced objects in your CRM.
When you sync data from BenefitFlow to your CRM, you get more than standalone records. BenefitFlow automatically verifies, creates, and updates the relevant relationships between Contacts and Accounts across your CRM — so your data reflects the real-world structure of the benefits industry. This article explains how those associations work across Salesforce, HubSpot, and Microsoft Dynamics.
## What BenefitFlow Syncs
BenefitFlow syncs five object types into your CRM, each with defined relationships:
| Object | CRM Record Type | Relationship |
| -------------------------- | ---------------- | ---------------------------------------------------- |
| **Broker** | Account (Parent) | Top-level firm record |
| **Broker Office Location** | Account (Child) | Linked to its parent broker |
| **Broker Contact** | Contact | Linked to the office location, not the parent broker |
| **Employer** | Account | Standalone account record |
| **Employer Contact** | Contact | Linked to its employer |
The broker hierarchy is the most important association to understand. Broker contacts are always tied to a specific office location — not the brokerage firm as a whole — because that is how broker mapping data works in practice. A producer at Mercer's Dallas office is associated with "Mercer - Dallas, TX," not with "Mercer" globally.
Employer associations are simpler. Each employer syncs as a standalone Account, and employer contacts are associated to their company's Account record by website domain. There is no parent-child hierarchy for employers.
If you want each employer linked to its primary broker office, you can set that up
yourself using BenefitFlow IDs. See [Linking Employers to Their Primary Broker
Office](/knowledge-base/crm-employer-broker-linking).
## How Parent-Child Associations Work
BenefitFlow models brokerages as a two-level hierarchy:
* **Parent account** — The broker firm itself (e.g., "Lockton Companies")
* **Child accounts** — Individual office locations under that firm (e.g., "Lockton Companies - Kansas City, MO")
This structure matters because benefits relationships are local. When you are prospecting, you need to know which producers operate out of which offices and which employers they serve in that market. A flat list of broker names does not give you that.
### Two-Phase Sync
To build this hierarchy reliably, BenefitFlow syncs in two phases:
1. **Parent accounts first** — All broker firm records are created (or matched to existing records) before anything else happens.
2. **Child accounts second** — Once parent account IDs are confirmed, office locations are created with the parent-child association already in place.
This ensures every office location is properly linked from the moment it appears in your CRM. No orphaned records, no manual cleanup.
You don't need to pre-create parent broker accounts in your CRM. BenefitFlow creates them automatically during sync if they don't already exist.
## Association Handling by CRM
Each CRM platform handles parent-child account relationships differently. Here is what you will see in practice:
| CRM | How It Works | What You See |
| ---------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| **Salesforce** | Uses the native **Parent Account** field on Account records | Office locations appear as child accounts in the standard Account Hierarchy view |
| **HubSpot** | Creates labeled **parent-child company associations** | Parent and child relationships are visible in the Associations panel on any company record |
| **Microsoft Dynamics** | Sets the **Parent Account** field via OData binding | Office locations display under their parent broker in the Account hierarchy |
In all three CRMs, associations use native platform features. There are no custom objects, junction records, or workarounds involved. Your existing reports, views, and automation that rely on account hierarchies will work with BenefitFlow-synced data out of the box.
## Automatic Sync Behavior
BenefitFlow uses a diff-based sync engine. On each sync, it:
* **Compares** current BenefitFlow data against the records already in your CRM
* **Inserts** net-new records that don't exist yet
* **Updates** records where data has changed (new fields, corrected values, updated broker mapping)
* **Skips** records that are already current — no unnecessary writes to your CRM
* **Flags** stale records that no longer match as deprecated
Associations are set at creation time and maintained through subsequent syncs. If a broker office location is created under "Gallagher" during the initial sync, that parent-child link persists through every future sync. BenefitFlow does not break or recreate associations unnecessarily.
Associations between synced objects are created and maintained automatically. You do not need to manually link records or re-establish relationships after syncs.
## Structuring Your CRM to Receive BenefitFlow Data
Before your first sync, a few CRM design decisions will make your life easier.
### Work with the hierarchy, not against it
BenefitFlow creates parent-child account structures for brokers. Make sure your CRM views, list views, and reports can surface hierarchical accounts. In Salesforce, confirm that your Account Hierarchy related list is visible. In HubSpot, check that your default company views don't filter out associated child companies.
### Consider account record types (Salesforce)
If you use Salesforce record types, set up distinct types for "Broker" (parent accounts) and "Broker Office" (child accounts). This lets you customize page layouts, fields, and validation rules for each level of the hierarchy and keeps your reporting clean.
### Build views around office-level contacts
Broker contacts are associated with the office location (child account), not the parent firm. When building contact reports or list views, filter by the child account level to see the full picture. Rolling up contacts to the parent broker level requires a hierarchical report or custom rollup, depending on your CRM.
### Map fields to your existing workflows
Use BenefitFlow's field mapping to populate the custom fields your team already relies on for lead routing, territory assignment, or reporting. Aligning mapped fields with your existing processes reduces the gap between sync and action.
### Prepare for deduplication
BenefitFlow matches accounts on **Website** (combined with City and State for office locations) and contacts on **Email**. Office location accounts will not be matched if they are missing either City or State — both are required. State can be matched by either state code (e.g., "TX") or full name (e.g., "Texas"). Before syncing, audit your existing CRM records to make sure these fields are populated. Records missing a website or email address cannot be matched and may result in duplicates.
## FAQs
No. BenefitFlow creates parent broker accounts automatically during the first phase of every sync. If a parent account already exists in your CRM (matched by website), BenefitFlow links to it rather than creating a duplicate.
BenefitFlow matches office locations using a combination of Website, City, and State. If a match is found, the existing record is updated with the latest data rather than duplicated. The parent-child association is preserved.
Yes. All three supported CRMs display the parent-child relationship in their standard account hierarchy views. Salesforce shows it in Account Hierarchy, HubSpot in the Associations panel, and Dynamics in the Parent Account field and hierarchy view.
The parent-child hierarchy (broker to office location) and contact-to-account associations are created automatically and cannot be disabled — they are core to how BenefitFlow structures broker data. Field-level data can be customized through the field mapping table in your integration settings.
BenefitFlow compares its current data against your CRM records and only pushes changes. Records that haven't changed are skipped entirely. Existing associations are preserved — re-syncs never break or recreate relationships that are already in place.
## Related Resources