10

I was reading docs and was surprised by the following sentence:

Warning For a given object, use either workflow rules or processes — not a combination of the two. If you use both, you can’t predict the order in which they’re executed.

I thought that the order of execution is quite definite and WF rules are followed by processes. Isn't it?

PS. The question is not about best practice, I understand that if you have a trigger, WF rule (+ field update), and PB (+ field update) on the same object, then you can suffer from up to 6 (six!) trigger calls in the same context.

before/after => WF (then again before/after) => PB (then again before/after)

So the question is more about the order of execution in such a complex (poorly designed, legacy) environment.

4
  • 1
    There are a bunch of things that strike me as questionable about that doc. For instance, the bullet points above and below the warning box are nearly identical. And it should be fine to disable rather than delete. I suspect that that warning is in error. Now, I'd agree that it's a best practice to use one or the other. But not that it's forbidden because order of ops is unknown. Feb 8, 2017 at 23:16
  • 2
    Yes, I also understand that it's better to use one of this declarative tools in terms of future maintainability, but the order of execution should be well defined in my mind.
    – edelrabe
    Feb 8, 2017 at 23:22
  • @ThomasTaylor you guys are missing the fact that WF or Process actions can retrigger all the operations and at this point you won't be able to tell what is caused by what.
    – o-lexi
    Feb 8, 2017 at 23:33
  • No, WF cannot refire all actions - the order of ops doc is very specific about what happens and what doesn't on a WF field update. It doesn't offer the same specificity about Processes. But that still goes to best practices . That the two documents present contradictory information is clear. Feb 8, 2017 at 23:53

1 Answer 1

2

I would think of a scenario where workflow flow field update as an action and process builder post action should not be used on same object.

According to order of execution, if we update a field via workflow and if before/after trigger exists, then trigger will fire on that object.

Now, if on the same object process exists and updates a field then again it will fire before/after trigger again.

So, unnecessary triggers are firing twice (one for w/f & other for process) and bringing the complexity of execution.

I think we will not mix same operations in both workflow and process.

Like, in the same object, if I need to update field, send email, I can either use one of them.

For fresh development, I will look for process builder which gives me lot of flexibility. For earlier developed code which is running on production where workflows exist, there either I will disable all the workflows and transform all the workflows in process or I will continue to use workflows.

Actions of Workflow and Process Builders

workflow process comparison

If I need to work on time-dependent action which not supported by process builder, I will go for workflow.

Likewise, for those actions which are not supported by workflow, I will go for process builder.

This is my understanding.

1
  • 5
    I will always go WF or trigger over PB until they bring PB CPU usage, error handling, and reliability on par with them. From an ISV perspective PB has been a nightmare and dumped a lot of support that SF should be handling on us as PB chokes on simple stuff and the error is not surfaced until the unlucky code base is entered. Can't tell a customer it is not our problem so we end up doing basic SF support and has increased our support calls noticeably
    – Eric
    Feb 9, 2017 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.