小心驶得万年船。
整理一些Salesforce相关的陷阱。慢慢补充。
发布相关
- 同时有多个审批流(Approval Process)通过更改集(Change set)发布的时候,审批流间设置的顺序并不会一同发布。
比如在某Object A中设置了审批流1、审批流2、审批流3,并且执行顺序分别设置为3、2、1。
当通过更改集部署到生产环境后,顺序可能就会变为,1、2、3。
- 权限集(PermissionSet)中设置的Recordtype不会通过更改集(Change set)发布。
首先权限集的部署与简档的部署不同,是不需要将相关组件放到更改集中的。
即使是将相关的Recordtype一起放到更改集中,Recordtype的权限依然不会随着更改集发布。
开发相关
- 自动化流程执行顺序
触发器(Trigger)
工作流规则(Workflow Rules)
进程构建器(Process Builder)
例如,对数据A的某项进行了更新。于是首先触发的是该Object关联的所有的触发器。
触发器执行完毕后,开始执行工作流规则。如果在Workflow Rules中又对数据A的进行了更新,则会再一次触发触发器。
接着处理进程构建器的操作。如果在进程构建器中还有对数据A的更新操作,则会再次触发触发器。
此外值得注意的是,工作流规则和进程构建器一般只执行一次。不过进程构建器的判定条件中如果勾选了递归判断的话,则会对判定条件进行最多5次判定并执行,触发器也随着数据更新而被触发5次。
例如,再同一次事务(transaction),因为没有满足数据流规则A的条件,所以直接执行到了进程构建器,并在进程构建器中对数据A进行了更新,然后触发器随之触发。
恰巧此时数据A满足了工作流规则A的条件,如果工作流规则中的数据域更新可选项中也恰巧勾选了对该条目再此判定的条件的话,则工作流就会被触发。
但是,工作流规则仅能被触发一次。比如工作流A曾被执行过,即使在进程构建器中对数据A更新且更新后的结果满足工作流规则的判定条件,工作流规则也不会被再次触发。
接着上面的例子,工作流因进程构建器的操作而被触发,并在工作流的操作中对数据A再此修改,触发器再次被触发。然后一般情况下,就会继续向下执行。
可是如果在进程构建器的判定条件中勾选了递归判定的可选项的话,则进程构建器会再次对数据A进行判定,如果被更新后的A依然满足了进程构建器的执行条件,则该进程构建器会被再一次触发。且类似的触发最多会发生5次。