I'm refactoring 4 workflow rules into before-triggers, and one thing I noticed is that I'm not saving a lot of time.
I'm investigating the possibility that this has to do with all 4 trigger handlers executing every time a Contact is saved within an execution context, whereas the "field updates" for 2 of the 4 "workflow rules" have "Re-evaluate Workflow Rules after Field Change" un-checked.
Does anybody know whether "Re-evaluate Workflow Rules after Field Change" behaves as a single massive execution-context-wide recursion-revention Boolean
or if it behaves more like an execution-context-wide recursion-prevention Set<Id>
?
That is ...
If I data-load 3 Contacts and therefore my automations are processing 3 Contacts, but then within the execution context, each of them results in a related Contact getting updated, so "potentially recursive" automations end up having a Trigger.new
of size 6 ... do workflow rule field updates that already ran on the 3 original Contacts and have "Re-evaluate Workflow Rules after Field Change" turned off run again for the additional 3, or do they simply not evaluate again at all, because WR re-evaluation isn't that "clever?"
I want to avoid changing the way things actually work -- my admins and users shouldn't be able to tell that I did anything besides speed up the system.
I'd love to get away with a simple static Boolean
to track whether my WR-replacement trigger handlers already ran, but I'll static Set<Id>
if I need to.
allornone=false
(applies to API clients and some apex DML). If you have such use case, set<id> may not work for you in all use cases