摘要

  • 未加入指定主记录 ID 保留公测的账户，合并联系人会使两条原记录退出正在运行的工作流；公测账户保留主记录的流程进度，次记录仍退出。
  • 按最近更新选主记录，比较范围包含隐藏的内部属性，选出的赢家未必承载最该继续的客户跟进。
  • 重新进入工作流从头开始。合并记录无法拆回原状，历史完整与业务连续必须分别验收。

设想一个很普通的销售下午：同一位客户有两份联系人档案，一份正在等产品演示后的跟进，另一份正在等试用回访。管理员把重复项合成一个，名单漂亮了，销售却还得回答：两件没做完的事，接下来谁来做？

这是按公开规则构造的情形。它的刺点在于，合并按钮能完成自己的任务，客户跟进仍会出问题。数据治理的成绩来得很快，客户的沉默要晚一些才会显形。用“减少一条重复记录”给这次操作记功，等于只清点椅子，不管原来坐着的人还有什么事要办。

一份档案，两种时间

HubSpot 的合并说明写明，历史属性、活动和关联资料会汇入最终记录。人们容易顺着这张完整的时间线推断，后续动作也接上了。偏偏已经发生的事与准备发生的事走的是不同规则。

在适用工作流的 Professional 或 Enterprise 账户中，关键分界是是否加入 Primary ID Preservation for Merged Records 公测。未加入时，两条原记录都会退出当时正在运行的工作流。加入后，主记录的延时、分支与待执行动作继续，次记录退出其全部活动工作流。

因此，公测里的“保留主记录”保住了一条正在前进的业务路径。另一份档案里的旧活动可以搬过来，它尚未完成的任务却不会因此获得一张续程车票。上面的销售情形到了这里，变成很实际的选择：哪个跟进留在原队列，哪个需要重新安排。

这也解释了为什么客户档案看起来越完整，越容易让人过早放心。时间线上丰富的过去，会遮住空白的下一步。销售人员打开记录，看见沟通记录都在，合理地以为清理工作没有碰业务安排；管理员看见重复项减少，也有一份合理的完成证明。两份证明加在一起，仍缺一件东西：接下来的客户动作。

“最近”怎么就当上了裁判

逐对处理联系人时，人可以讨论保留谁。批量操作需要一个规则，规则又很容易披上一层客观外衣。

HubSpot 的重复记录工具提供按互动时间、创建时间或最近更新时间选择保留记录的方式。其中“最近更新”会检查所有属性，包括隐藏的内部属性。对系统来说这是一种可计算的顺序，对销售来说却未必是业务价值的顺序。

一条记录刚更新过，另一条记录有一项重要跟进在等待，两者完全可能同时成立。“最近更新”回答了时间戳的问题，没有替团队回答客户承诺的问题。在公测机制下，把这个排序直接用于主记录选择，就把一部分流程生存权交给了更新时间。

问题不在于每次都必须拉来主管签字。真正需要分流的是那些仍带着未完成工作的重复项。空闲档案与即将执行客户动作的档案，处理成本本来就不同。为了让批量任务跑得整齐，把它们都算作同一种垃圾清理，才是便宜得可疑的地方。

而且，“疑似重复”仍要先确认确为同一对象。选谁当主记录，是确认身份之后的下一道判断；最漂亮的保留规则，也救不了合错人的第一步。

重新进队，队伍从头排

HubSpot 另有合并记录进入工作流的设置。默认情况下，合并带来的数据变化不会自动使联系人进入新流程；可以按条件开启相应设置。这和保住原来的执行位置，是两回事。

重新加入工作流的规则把起点讲得很清楚：从头开始，再经过流程中的动作。业务上的危险于是换了一种形状。原先担心该做的没有做，现在还要防止已经做过的又被安排一次。实际动作是否执行，还取决于当时的条件，不能把重入等同于必然重复发送邮件。

手工把人放回去也没有秘密捷径。手动加入说明同样从起点开始；若只需要后半段动作，官方给出的办法是新建或克隆一条从所需动作开始的独立流程，再手动加入。修复因此需要知道“剩下什么”，而不只是知道“原来在哪条流程里”。

这份区别很像给一部看到一半的电影重新买票。票买到了，放映机未必从你离开的那一帧开始。把客户再次塞回完整流程，可能是最快的操作，却未必是最短的业务修复。

记录不会替你把事做完

判断有没有接续，得看后续动作。HubSpot 的工作流详情页提供活动记录、动作、事件和时间，可以把合并时点与退出、再次进入、实际执行的动作对起来。缺少具体账户合并前的流程位置与合并后的动作记录，就无法给这类问题算出实际损失。

即使找到了原因，也没有“拆回原来两份”这颗后悔药。HubSpot 明确不支持撤销合并；移除附加邮箱后新建联系人，是另建一份记录。看到旧 ID、查到合并时间，能帮助解释发生了什么，不能自动恢复原有的两条业务进程。

所以一次合并的完工点，应当落在客户下一件该发生的事上。档案数量降下来了，演示后的跟进也接上了，这才是一项完成的清理。否则，系统只是把两份待办收进了一个更整洁的抽屉。