[SalesForce] Should we use process builder at all

Forgive me if this isn’t an appropriate topic for this board but I would like to have an open and honest discussion about Process Builder.

We have a multi-tenant org (different business units using the same objects with different logic) that contains dozens of Process Builder processes. Many of the objects have multiple processes. I have many concerns about using process builder at all:

Governing Limits and Bulkification Concerns
- Process run much slower than equivalent apex
- Still not fully bulkified
- Are Process Builder workflow rules more likely to violate CPU Time limts than a standard/old workflow rules?
Complex Logic and no Testing Required
- Allows user to create complex logic with no testing at all – how are we supposed to maintain and extend systems when there are no regression tests?
- Complex logic built by people who are not developers or architects, little to no concern about implications to other parts of the system and since there are no tests there is no way to catch it.
- No control over order of execution – requires us to run all of our logic multiple times.
Source Control Nightmare
- Flow Definitions are saved as versions, thus each version is a new piece of metadata, and this makes it very difficult to track in source control even if you manually remove the version number.
- Almost impossible to simultaneously work on same process in multiple orgs and merge them at the end of the day.
Error Handling and Debugging
- Is honestly a complete joke. It seems to only send an email to the original creator of the process, the on screen errors are completely meaningless (‘Error in flow with Id: blahblah’ , and the Id isn’t even presented in the SF interface – you have to query to find out the actual failing process). I hear they are working on this.
- Apex is already light years behind other software stacks when it comes to debugging – Process Builder is even worst.
Documentation
- No internal comments to self-document. A single description field simply isn’t enough.
- Hard to maintain in the long run.

Because of all of this it is my opinion that Process Builder should simply never be used at all. Maybe in very small single use orgs that will not grow in terms of functionality – but in that case you are crippling a lot of what makes SFDC an amazing platform.

If you look at this salesforce article:
https://developer.salesforce.com/blogs/engineering/2014/12/forcedotcom-declarative-development.html

I would argue that the 3 points they make are far worst using process builder than Apex (this article is a bit dated for Process Builder but it is now GA and is being pushed hard as a click not code option).

Cost and time – Not much faster to implement then Apex with an appropriate trigger framework – still need a skilled resource either way.
Maintenance – who’s going to maintain the process after the initial development is done? Very difficult to hand off maintenance due to lack of documentation features.
Complexity and Scalability – All governing limits still apply and in fact are exacerbated when using Process Builder as opposed to apex.

I know this is very broad and in general we want concise problems with concise answers. So, given the problems listed above, should anyone every seriously consider using Process Builder?

Best Answer

I'll give this one a shot.

disclaimer: The only experience I have with process builder was helping my boss out in the Dev Zone at Dreamforce last year.

Process Builder is a tool that sits in between workflow and Apex in terms of what it can accomplish. Process Builder can be the best fit for the task at hand, but like all tools, it can be misused.

The big advantage to Process Builder is that it gives you a sizable portion of the power of Apex code without the need to actually write Apex code. You just need to have a somewhat programmer-ish mindset (knowing how to make use of loops, variables, and conditionals).

Having even a single developer on staff can be a big investment for a company. Process Builder allows some of the benefit of a dev, without the full cost of a dev. It saves money...for a time.

I'd argue that using Process Builder means that you start to accrue considerable Technical Debt. The numerous downsides that you mention are all technical debt.

The scenario you describe sounds like someone has (or several people have) succumbed to the Law of the Instrument, which, restated, is

When you have a golden hammer, every problem starts to look like a nail

Process Builder helped them out on problems x and y, so it should work for problem z too, right?

Well, after some ill-defined point, the processes start getting more complex. They also start to become more tightly coupled, and interact with one another more and more.

In your situation, it sounds like there's an issue of shared resource planning as well. One business unit may not have/want a dev to take care of this, but it will end up impacting the rest of the business units.

It is at that point where I believe you cross the line in the sand where a developer writing Apex makes more sense. Some of the value of a Good Dev™ is that they are able to manage the interactions required between the business logic in a way that scales well, is easy to maintain, and is easy to extend.

The takeaway

Process Builder can be used to solve a variety of issues, but it isn't always the right tool and is no substitute for a competent developer.

The situations where I'd consider using Process Builder are:

When you are only performing work on a single object
You aren't trying to work on more than a hundred records or so
The required logic isn't terribly complex (a couple of ANDs and ORs at most)
You can't afford to hire a dev right now, but will be able to in the near future (< 1 year)

Used correctly, Process Builder can serve as a replacement for simple triggers until your org needs to start considering code scaling. It even may be faster to develop than a trigger.

Moderately complex logic and interactions with other objects are a good way to quickly get over your head, and would require more up-front cost when a dev is brought in to untangle the unholy mess.

Related Solutions

[SalesForce] How invocable method and bulk behavior in Process Builder work

You can also create an @InvocableMethod that takes in a List of a custom class. By doing this, you can pass in parameters in the Process Builder

public with sharing class ActionForProcessBuilder {

    @InvocableMethod(label='Do Action')
    public static void doAction(Request[] requests) {
        // Process requests
        // Example: Query parents in bulk
        Map<Id, Parent__c> parents = new Map<Id, Parent__c>();

        for(Request request : requests) {
            parents.put(request.parentId, null);
        }

        parents = new Map<Id, Parent__c>([
            SELECT Id, Due_Date__c
            FROM Parent__c
            WHERE Id IN :parents.keySet()
        ]);

        for(Request request : requests) {
            final Parent__c parent = parents.get(request.parentId);
            if(request.adjustedDueDate != null && parent.Due_Date__c < request.adjustedDueDate) {
                // Do something
            }
        }
    }

    public with sharing class Request {
        @InvocableVariable(label='Record ID' required=true)
        public Id recordId;

        @InvocableVariable(label='Parent ID' required=true)
        public Id parentId;

        @InvocableVariable(label='Adjusted Due Date' required=false)
        public Date adjustedDueDate;
    }
}

[SalesForce] Process Builder – order processes run

There is no logic to what order they are executed, however if you can take some of the logic outside of the process itself and move them into Flows, you can daisy chain your flows in whatever order you wish from a single process. Really depends on your situation what what you're actually doing within your processes. You can reference this article for the order of execution provided by Salesforce just in case you didn't know already.

Best Answer

Related Solutions

[SalesForce] How invocable method and bulk behavior in Process Builder work

[SalesForce] Process Builder – order processes run

Related Topic