+ Start a Discussion
Ken Koellner 1Ken 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.

I consult on a large org that has this exact same issue.  Several flows are on the same object.  Some triggers also.  Most of what we run into are bulkification issues.  Meaning - if 200+ records are updated at the same time - - the triggers are all bulkified - but many of the flows are not, therefore, the flow might update/create other records - not associated with one that fired the trigger/flow.  And thus starts the complex web of more flows and triggers getting called.

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.

I'm facing this dilemma right now. I'm a consultant and trying to clean up a messy (and very large) code base. However, the internal team does not have much developer support and most of the resources are not equipped to manage code or develop new functionality in the future.

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?