If you have asked yourself this question recently here are some tips that can help you decide which path you should take. Imagine you have to implement the following scenario:
Use Case: Users are signing up online and filling out a form. They have to provide contact information for 4 additional Contacts at their organizations. For each additional Contact they will enter a First Name, Last Name, Email, Phone and Role. All this information will be automatically fed to Salesforce in the form of an online subscription record.
For each additional Contact you are required to first determine if it exists in Salesforce and if not then create it. If you find the contact in Salesforce (based on Last Name and Email) then you have to update the Phone, set the mailing address and create an Affiliation to the Account/Organization with the specified role.
(Please note that this use case uses Affiliations which are a custom object specific to the SF Non Profit Starter Pack. An Affiliation is a junction object between a Contact and an Account.)
The PROCESS BUILDER AND FLOW ROUTE
It is possible to go the process builder route for this one. You can write an Autolaunched Flow that does the lookup of the Contact by Last Name and Email, creates it if it doesn’t exist or updates the information if it does. The Flow can also create the needed Affiliation if it doesn’t exist.
You can then invoke this Flow from Process Builder on the insert of an online subscription record, whatever that might be.
This is a point-and-click approach that can be easily modified by an administrator and there are no unit tests required in order to deploy. Sounds very tempting, right?
However, it took me several iterations and many hours to get this to work correctly. The process broke down and hit limits when I went from 1 to 4 additional contacts. Also, in case of an unexpected exception the error ended up preventing the users from submitting the online form.
At that point I had to let go of this approach, granted I could have spent more time and try to either optimize the Flow or add some error handling to the Flow.
Why I would still advocate for Apex code
In contrast, it took only a few hours to write a batch job in Apex to handle all the post-processing cleanly and with proper exception catching/error handling which did not stop online form submission.
For a use case of this complexity I would still advocate for writing Apex code:
- Unit tests are good! I think there is so much value in unit tests. You can really ensure your implementation has not regressed by running your unit tests. Since there are no unit tests in Flow you really can’t tell if you’ve broken anything when you change something in your logic. Also, unit tests allow you to test specific parts of your logic, which is impossible with Process Builder/Flow (It’s an all or nothing test).
- Easier to optimize: It’s much easier to optimize your code to work in batches than it is to accomplish that in Flow.
- Easier to debug: I found it particularly hard to debug a Flow. I missed the ability to set breakpoints or at least log things to the debug log.
- Easier to read: I found it very difficult to read the Flow because of the small boxes and of having to click on each one to see what functionality it contains. I still prefer to view all of my code on one screen and rely on the IDE to do string search and replace if needed.
- All in one place: All logic can be contained in one class. With the Process Builder and Flow combination, the logic is split between the two which is a bit awkward especially when you need to debug.
Hopefully this comparative analysis between Process Builder + Flow and Apex code will help others who are wondering, just like I was, which path to take. The complexity of your use case should tell you if you are ready to give up the benefits of Apex code.
Posted by Nineta Martinov
DaizyLogik 