function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Leah SchneiderLeah Schneider 

Apex v Lightning Flows

My company is moving a lot of business processes into Salesforce which means that we're going to have to build Salesforce processes to make them work.  BacWe have a small organization with very little Salesforce customization and as we add more, I'd like to make sure that we're doing it right.  I'm the main developer though we have two other people who deal with backend.

As always, Salesforce (the company) recommends no code solutions and flows and process builder will do everything faster and easier but I'm wondering if that's really correct and how you manage different automation processes.  We have a lot of apex (relatively, nothing close to limits) and if it's reasonable to rewrite all or most of it in process builder or flows, now would be a good time to start.

Does anyone have any advice or similar situations? 
Derrick Abbey 21Derrick Abbey 21
I'm generally with Salesforce on this one.  When you consider things like permissions, sharing settings, unit tests required for deployment, ability to update, the declarative tools that Salesforce provides are much easier to use and set up than writing code.  I also am a fan of creating things that an admin with no knowledge of code can manage.  All that being said, if it isn't broken, don't fix it.  
Leah SchneiderLeah Schneider

I think that not requiring unit tests is a pretty good reason to not use process builder.  I'm not sure how permissions and sharing settings factor into Process builder v Apex though.  
Derrick Abbey 21Derrick Abbey 21
I can see the reasoning behind trusting Apex more due to unit tests.  In my experience, I've rarely seen unit tests that are written to cover all possible scenarios of execution.  Mostly, they're just written to ensure adequate code coverage. So in that aspect, there's not much of an advantage due to the fact that Salesforce won't let you do things that would obviously break a process (i.e. deleting a field that is referenced in a flow or process builder).  For me, it really comes down to time to create/update and the ability for someone else to come along later and easily understand what the process is doing.  I can create a process in a process builder much more quickly than writing  a bunch of code, and the unit tests to deploy it.  Also, I know that it won't require a developer to come along later and update the process if needed.