Timeline for Workflow versus Process Builder. How to choose which to use?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 30, 2017 at 21:03 | comment | added | Eric | And PB is immune to CPU time limit but the next line of code that runs will throw error. If PB takes 30 seconds it won’t throw an error but your code will. If no code then a 30 sec PB will not throw error. PB should be avoided in general. Also IIRC it is not bulkified either unless they fixed that. As Adrian said, PB is approx 8-15x less efficient than WFR or same process in a trigger | |
| Nov 30, 2017 at 19:26 | history | edited | Adrian Larson♦ | CC BY-SA 3.0 |
added 1034 characters in body
|
| Nov 30, 2017 at 17:22 | comment | added | Adrian Larson♦ | My contention is that Workflow Rule is faster. That's what I am checking now. Takes a while to run the numbers and put them together. | |
| Nov 30, 2017 at 17:20 | comment | added | AlwaysThinkin | @toby, I see your point that Process Builder has features that Workflow will never get. But for something like a single-condition field update, is there an advantage to one or the other? | |
| Nov 30, 2017 at 17:00 | comment | added | sfdcfox♦ | @Toby Workflow isn't on the same engine as Flows and PB, as it predates either technology by at least a decade. Workflow "sometimes" counts against CPU time, but only when it's already in a CPU-using context, like a trigger. It's inconsistent. PB and Flows, on the other hand, always use CPU time, even when the request was initiated by the UI or API. | |
| Nov 30, 2017 at 16:56 | comment | added | gNerb | Flows, Workflows and PB are all built on top of the apex engine and impact your governor limits (per SF Architects I met with at Dreamforce). @AdrianLarson do they have to explicitly say they are reducing support for workflows? Of course they can't stop supporting them altogether, but process builder is quickly outpacing workflows. Their intent is pretty clear. | |
| Nov 30, 2017 at 16:52 | comment | added | Adrian Larson♦ |
@sfdcfox If you add a workflow to your object, transactions interacting with that object will take longer to complete (and your Limits.getCpuTime() will show higher values). It increases your CPU usage.
|
|
| Nov 30, 2017 at 16:50 | comment | added | Mr.Frodo | It means that we should first consider the workflows instead of PB? | |
| Nov 30, 2017 at 16:50 | comment | added | sfdcfox♦ | Workflow doesn't use "CPU time" but Process Builder shares the 10,000 ms governor limit with Apex Code. sigh Someone screwed up. | |
| Nov 30, 2017 at 16:46 | comment | added | Adrian Larson♦ |
I have never heard any mention anywhere of dropping support for Workflow Rules. That's like saying the Queueable interface is meant to replace the @future annotation. They're just different tools with different impact on your org.
|
|
| Nov 30, 2017 at 16:45 | comment | added | gNerb | Because process builder is actually called Lightning Process Builder and is essentially the replacement for workflows? I dont watch release notes as closely as I should but I haven't noticed many updates to workflows but I have noticed updates to the PB. | |
| Nov 30, 2017 at 16:42 | comment | added | Adrian Larson♦ | Will run some profiling to get some concrete numbers as of this release. Maybe it has changed. | |
| Nov 30, 2017 at 16:42 | history | answered | Adrian Larson♦ | CC BY-SA 3.0 |