Apex Code Development You need to sign in to do that
Don't have an account?
Ken Koellner 1 Mixing Workflow Field Updates and Triggers on the same object, thoughts?
I know in the order of operations, triggers fire before workflows, then if there are field updates, the record is updated and triggers fire again.
Most SF developers and admins are of the opinion that you should do as much declaratively via Workflows, Process Builder, etc. and not use triggers and Apex code unless the use case is such that it cannot be implemented via declarative features.
But when you do need triggers, if you have field updates, you have to be very careful that they don't interfere with each other and have to consider any bad effectst that could happen from a trigger fireing more than once.
So I'm wondering if perhaps it's best to implement with a pattern that once triggers are needed, then avoid doing field updates via declarative features and do all field assignments in the triggers. The downside is admins can no longer define simpler features. But the upside is that all the record assignments are then in one carefully controlled stream of code executed by the trigger.
Thoughts?
Most SF developers and admins are of the opinion that you should do as much declaratively via Workflows, Process Builder, etc. and not use triggers and Apex code unless the use case is such that it cannot be implemented via declarative features.
But when you do need triggers, if you have field updates, you have to be very careful that they don't interfere with each other and have to consider any bad effectst that could happen from a trigger fireing more than once.
So I'm wondering if perhaps it's best to implement with a pattern that once triggers are needed, then avoid doing field updates via declarative features and do all field assignments in the triggers. The downside is admins can no longer define simpler features. But the upside is that all the record assignments are then in one carefully controlled stream of code executed by the trigger.
Thoughts?
In my opinion - I think it is a function of org size and skill set. If all you have is the Admin skill set, and your org is - say - less than 50 or so - stick to the flows and point and click development. If you have both skill sets (Admin and Coding Developer) or a larger org (ie 100+) - stick to the flows for simple updates. Complex solutions, or solutions involving multiple other records - use APEX triggers for.
There are many functionalities that require code, but I also want to avoid having too much in Apex which would limit their admins' ability to make changes in the future. Is mixing a Process Builder and Trigger (on the same trigger event for an object) a big no-no, or can it be acceptable with careful design?