SF踩坑集锦

SF很高大上，但是做久了还是会踩出一些坑，本文总结了日常工作中遇到的一些让自己哇哦的时刻。 当然不一定真坑，只是个人记录。

• 关于Phone数据类型的字段 ：
  #接受吧#： Phone数据类型‘竟然’可以接受字符串的输入。

一个令人困惑的地方是，在salesforce的官方文档中，其实已经明确的指出了说：

This data type accepts 15-digit strings and removes non-digit characters

但是事实上当你在Phone数据类型的字段中输入英文字母竟然是可以被接受的。。。困惑，这大概是一个系统Bug吧。

https://help.salesforce.com/articleView?id=mc_es_data_extension_data_types.htm&type=5

看到也有人在投票这件事情，当然大概率这个是不会salesforce接受的，毕竟每个国家的输入习惯不一样，
可能这个设计也就考虑了能输入（010-888888）的需求吧。
另外Phone这种数据类型应该是在后台被salesforce当做String来处理的吧。

Idea Vote: https://trailblazer.salesforce.com/ideaView?id=08730000000LiHCAA0

• 关于Workflow的Evaluation Criteria ：
  使用workflow的时候，一共有3种可选的evaluation criteria，如下图：
  
  – 第一种是指创建的时候，才会评估条件；
  – 第二种是指创建以及每次编辑的时候；
  – 第三种是指创建以及每次编辑的时候，并且编辑之前不满足条件，编辑之后满足条件。

最容易弄错的就是第二和第三种的，主要区别就是第二种并不会考虑记录的变化。比如一条记录之前满足所有条件逻辑，但是你变更了此条记录的一个和条件本身不相关的字段，系统会认为此条记录被编辑了，于是会出发workflow的action动作。

所以第二种条件的使用很危险的，尤其是对于邮件触发类型的action。可能目标收件人会莫名其妙的收到很多邮件。当然也根据具体的业务场景来设计使用。毕竟千司千面。

第三种就不会，他会考虑记录的变化。之后变化之前的记录不满足条件，变化之后的满足，才会触发action。 有一点额外需要注意的是，第三种条件不支持PRIORVALUE function的使用。
以上。

关于Opportunity Team Member
当启用了opportunity team之后，在opportunity下change opportunity owner的时候，页面会popup弹框，默认‘keep opportunity team’ 是不会勾选的，此时如果不手动勾选，opportunity team members会被全部清掉，然后只插入新建的一个opportunity owner作为member。

但是当opportunity的状态是closed的时候，此时即便不勾选‘keep opportunity team’， team members信息也不会被清掉，因为salesforce 的逻辑会认为一个已经被结束的opportunity 不应该被清理members信息。

Idea Vote: https://trailblazer.salesforce.com/ideaView?id=08730000000koIqAAI

18位的ID在Validation Rule中不生效
最近创建Validation Rule,对于Object的Record Type判断上使用了18位的ID做判断，但是发现rule写的没问题，但是Record Type并不生效。查阅了才发现，这可能也是salesforce的一个bug,就感觉很奇怪，rule校验也不会出错，按理说15位和18位转换也是唯一值，但就是不生效。所以最后改用了DeveloperName来做为判断条件。

Idea Vote: https://trailblazer.salesforce.com/ideaView?id=08730000000DrUyAAK