HubSpot合并后的值留下哪一份：主记录规则之外还有字段例外

把HubSpot合并记录的结果概括成“主记录全部覆盖次记录”，会漏掉官方帮助页明确列出的例外。《Merge records》先给出一般属性规则，再分别说明记录ID、创建日期、公司、联系人和工单属性。对CRM资料整理者，合并结果应按这些具体字段解释，而不是替所有字段套一个保留方向。[1]

一般属性优先使用主记录的值；但如果主记录在该属性上没有值，例如null或空值，就使用次记录的值。于是，即使是同一套普通规则，也包含主记录有值与没有值两个分支。最终某字段取自次记录，并不单独证明主次身份被倒置；它可能正是这项空值例外的结果。这里说的是文档定义，没有读取或合并实际客户记录。

记录ID另有默认与公开测试版之分。默认说明为合并后的记录产生新的唯一Record ID；加入Primary ID Preservation for Merged Records公开测试版的用户，则保留主记录的ID。两种行为在同页并列，不能删去测试版参加条件，写成所有账户一律生成新ID，或一律沿用主ID。Merged [record] IDs属性记录此前被合入的记录ID，又与结果记录当前采用的ID承担不同角色。

Create date的规则也不跟随普通主值优先：它保留较旧记录的值。创建日期与ID因而需要分别阅读；结果取得哪个ID，不能代替创建日期比较。这两项规则解释的是不同字段的保留依据，不是本文对现实人物最早建立联系的证明，也不以系统日期替某次实际活动作认证。

联系人Email保留主联系人的邮箱为主邮箱，次联系人的邮箱成为辅助邮箱。公司域名采用类似的主次安排：保留主公司的域名为主域，把次公司的域名加入为辅助域名。但公司段又补充，若主公司原先没有域名，就采用次公司的域名值。主次标签与是否缺值共同决定这里的描述，不能只转抄“域名保留”而省略最终处于哪一个位置。

Lifecycle stage在联系人和公司两处都按漏斗中较后的阶段保留。页面举Lead与Customer的组合，结果取Customer。此处依据的是该字段所表达的阶段顺序，而不是哪条记录被选为主记录；同一个合并动作因此可以在普通属性上取主值，在生命周期属性上遵守另一条次序规则。

联系人的Number of conversions和Number of unique forms submitted则把两条记录的值相加。原文的表单例子是主联系人三次、次联系人两次，结果的表单提交数量为五。这里数的是文档所命名的字段值，不能把相加结果转成五名现实用户、五个独立客户或已验证的业务成效；它也不是前述取较后阶段的排序规则。

工单Ticket owner还有自己的条件：工单关联多个会话时，保留最近更新会话的负责人。比较对象是会话的更新时间，保留对象是对应负责人，不能把它简化成无条件沿用主工单负责人。由这些定义可见，属性类型与对象类型都参与了保留规则；读取一个具体结果，需要知道正在说明哪一项字段。

本篇采用该页当前正式文字，HTML的datePublished标为2025年4月18日，dateModified及页面更新标记为2026年9月5日，二者分别记录。以上仅解释默认、公开测试版与各字段例外，不采用Cookie、法律依据、营销或工作流段落，也没有执行任何客户数据操作。

资料：[1] https://knowledge.hubspot.com/records/merge-records