Choose which system owns each customer detail

First decide which records refer to the same person or company. Then decide which source governs each field on that record. Those are different questions. A possible duplicate may need identity review, while two valid systems may each own a different field. Combining both decisions into one vague rule such as CRM wins can overwrite a correct value.

Review possible duplicate records separately before using this map. Here, assume the contact or company has already been identified and focus on the meaning and authority of its individual fields.

Make one row for every field that affects a customer handoff or decision. Name the system or maintained record that is authoritative, the role allowed to update it, and the reason it owns that value. For example, a finance team might own a billing email in an approved billing record, while a service team owns a support preference in its current service notes.

These are proposed company policies; a CRM does not determine them for you. If a value is shared across tools, decide whether the other copy is read-only, manually refreshed, or changed only after confirmation.

A useful conflict rule tells a teammate what evidence to check and who can make the decision. It might say that a new address from a verified customer request is reviewed by the field owner before updating the authoritative record. Avoid rules based only on which timestamp is newest, because a recent import or signature can contain stale or incidental information.

If the team cannot tell which value is correct, mark the conflict for human review and pause that field's update. Record the chosen value, the source checked, who decided, and when. The rule should make uncertainty visible instead of silently turning a guess into a permanent record.

HubSpot's documentation describes deduplicating contacts using email addresses and companies using domain names. It also documents record IDs and unique custom properties for matching records during import. These are HubSpot-specific matching mechanics. Your team still needs a policy for billing email ownership and cross-system conflicts.

HubSpot's multi-object import guide also describes creating associations between records and requiring a unique identifier to update existing records in relevant import paths. Use this as a prompt to inspect identity keys and relationships before changing data. Verify the keys and conflict behavior separately in every platform you use.

In this fictional example, the CRM lists alex@northwind.example as the primary contact address, while an invoice request arrives from billing@northwind.example. The team does not overwrite the contact email or merge the sender into the contact just because both addresses use the same domain. The invoice owner checks the request, confirms which address should receive billing documents, and records that decision in the field map.

The primary contact email and the billing email may both be valid fields with different purposes. If the team cannot confirm the request, the billing email remains under review and no automated update is assumed.

Review field rules when a system changes, a data owner leaves, a new form begins collecting information, or the same conflict returns. Keep the review focused on fields that matter to active work. A person should be able to find the current rule before editing or importing a record.

The map records a decision for people to implement and test in each system. If the software cannot enforce the rule, assign someone to check affected fields until a safer process is available.

Give Areinum Assistant a field list and your existing ownership decisions, then ask for a draft map of authoritative sources, editors and unresolved conflicts. The people responsible decide the rules before any synchronization.