在 Salesforce 中防止重复预订
验证规则看不到其他记录。正是这一个限制，让大多数 Salesforce 预订系统总是晚一天才发现冲突。
重复预订是一个时机问题。等到标准 Salesforce 中的任何功能能告诉您会议室已被占用时，用户早已选好了它，填完了表单的其余部分，并转去做别的事了。
为什么常见的工具都不管用
| 工具 | 能做什么 | 不足之处 |
|---|---|---|
| 验证规则 | 检查正在保存的记录上的字段 | 完全无法查询其他记录 |
| 重复规则 | 按字段值相等匹配 | 9:00 到 10:00 和 9:30 到 10:30 有冲突，但并不匹配 |
| 记录触发的 Flow | 保存时查询并阻止 | 在用户提交之后才触发；写法随意时无法安全处理批量数据 |
| 自定义代码 | 完全可控，重叠判断逻辑正确 | 仍然是在保存时拒绝，而且代码要由您来维护 |
它们的模式都一样：在用户做出选择之后才拒绝。即使是正确的自定义方案，结果也是“该时间段已被占用，请重试”，这种体验远不如一开始就不提供这个时间段。
重叠不等于相等
很多人会想到用重复规则，所以先把规则讲清楚。两个预订冲突的条件是：一个在另一个结束之前开始，并且在另一个开始之后结束。9:00 到 10:00 的预订和 9:30 到 10:30 的预订重叠了半小时，但没有任何一个字段值完全相同。任何基于值匹配的方法每次都会漏掉这种情况。
冲突和容量是两个不同的问题
它们常常被混为一谈。
冲突
两项预订争用一个只能容纳一项的资源。比如一间会议室、一位面试官、一辆车。
容量
一个可容纳多项的资源，问题在于还剩多少。比如有二十个座位的课程、需要四名护士的班次、有六十个工位的办公区。
把容量型资源当成冲突型资源，就永远无法预订第二个人。把冲突型资源当成容量为一的资源，技术上可行，但会丢失您很可能需要用来做报表的数量统计。
三种合理的处理方式
“一律阻止”并不总是对的。当有人选了十二个日期而其中两个有冲突时，拒绝整个提交很不友好。好用的系统会提供选择：
阻止
拒绝保存并报告冲突。适合每个日期都不可或缺的场景。
跳过
保存空闲的十个，报告不空闲的两个。对于批量选择，这通常是最体贴的默认方式。
允许
有意允许重叠。有些企业就是故意超订的。
真正的解决办法在更早的环节
上面所有机制都在保存时起作用。解决办法是把检查提前到选择的时候：日历加载时查询已有记录，把它们画到网格上，绝不提供已被占用的时间段。保存时的检查仍然保留，作为两个人同时看中同一空闲时间段这种真实竞争情况的兜底，但不再是第一道防线。