Table of Content
Alternatives to Apex in Salesforce
Salesforce has come a long way in recent years, advancing itself into a position as the most powerful CRM on the market. A big part of this success was due to Salesforce making its system adaptable to businesses as well as making it easy and inexpensive for businesses to make those adaptations. Salesforce achieved this success by gradually moving from a system that required a developer with knowledge of Apex to straightforward and user-friendly process building tools such as Salesforce Process Builder. Now, Salesforce admins can achieve far more when it comes to creating processes in Salesforce–almost equivalent to what developers can achieve with Apex.
In this article we’ll discuss these Salesforce tools and why you may want to use them instead of developing in Apex.
Why Not Apex?
We’re not saying you shouldn’t use Apex, as there are definitely times when there is no other way of achieving what you need in Salesforce than to write it in Apex. But there are many situations where, if possible, you should use some of the other options available. This has to do with the following three areas of concern.
Adaptability
When you create something using standard Salesforce customization options, you have a lot more flexibility to adapt or change the feature you’ve built. Although not advised, you can even make most Salesforce changes directly to your live org instead of being forced to develop Apex first in a sandbox before releasing. Of course, best practice dictates that you should always make customizations in sandboxes before releasing to a live org. But this fact alone shows that the negative risk of changing Apex to your system is a lot higher than that of a standard customization.
Updates
The processes that you’ve created in Apex don’t get updated or improved with Salesforce releases/updates. You’re the only one who can improve upon the features you’ve created in Apex. This means that they can get outdated very quickly and require updating regularly. There is then the issue of who is able to perform any updates to the Apex code that you’ve written.
As with any coding language, people write things in different ways according to how they learned to program or the approach they would normally take when developing. This can make it difficult to make changes or update code that someone else has written. In fact, many developers will often choose to rewrite code rather than update somebody else’s. So using Apex, instead of another more standard automation tool, reduces the number of people who are able to update a feature that has already been built.
Risk
Finally, the risk that Apex may result in a negative impact on your Salesforce system is drastically higher than that of the standard Salesforce features. This is because Apex doesn’t have the structure and restrictions that are built into standard Salesforce features to reduce the risk of such negative consequences.
Luckily, there are ways to help you avoid such negative impacts when you do have to resort to using Apex. Tools such as Salesforce ForeSight have been built specifically to help support developers when using Apex. But there are also standard automation features available within Salesforce that we’ll discuss here below.
Process Builder/Workflows
Process Builder, which was made to replace Workflows, is a fantastic tool to automate your business processes. Like Workflows, Process Builder can make changes to records–such as adding inputs to fields or changing the record type–based on certain criteria. The extra abilities of PB include sending alerts and emails, initializing time-based changes, and triggering other automation features such as flows, which we’ll talk about a bit later on.
Due to these features and many others, Process Builder is head and shoulders above Workflows. It guides you through the steps to building out the process. And as you progress, it will also only offer you options that are actually available to you, making it very difficult to create something that won’t work at all.
Below we can see all the options that Process Builder offers, with some key items such as creating records, that would have needed Apex to deliver the same results when Workflow was the only option.
Image Source: The Salesforce Platform
You also have the ability to order your processes, whereas with Workflows, you often ran the risk of overwriting other Workflows. This drove many developers to write scripts to prevent such unwanted changes from happening. But Process Builder allows you to choose which action and rule will be triggered in the order of your choosing.
Image Source: The Salesforce Platform
With all of its functionality and ease of use, Process Builder should ultimately be able to achieve 90% of the automation required for your business. That last 10% can then usually be obtained by using another automation tool that is invoked by Process Builder, called Salesforce Flow Builder.
Go With the Flow
Salesforce Flow Builder is yet another step above Process Builder, offering a lot more flexibility in terms of what you can create but still with the safety net of using a builder rather than writing code. Flows definitely take a bit longer to wrap your head around. But this is because you can do a lot more with flows than you can with Process Builder, such as creating loops and CASE-based formulas. The Flow Builder therefore offers you almost limitless options for the automation you’d like to develop, leaving you with the need to resort to Apex only in extreme cases.
As an example, below we are trying to update a billing address for an account dependent on whether there has been an account ID inputted. You can see that flows have the ability to draw out your process and also allow the process to take a certain path dependent on certain cases. You also can then loop elements of that process until the desired result has been achieved.
Image Source: The Salesforce Platform
I Need Apex
There will always be a need to use Apex in Salesforce for those really unique and complicated circumstances. And that’s fine, as long as you mitigate the risks we talked about earlier. There are a lot of great tools available, including Salesforce ForeSight to help you release and protect your system–and the data inside it.
Thoroughly testing your system is also a great way to avoid the risks of using Apex. You can check out this article to get a few tips on performing your functional and UAT testing.
Power Through With Processes and Flows
It’s always best to go by the motto “config before code.” As mentioned above, following this rule allows you so much more flexibility and opportunity for expansion than going with Apex. There will still be times when you have to use Apex to achieve what you need. Just bare in mind, although there is a risk of negatively impacting your system with any customization, the risk is considerably higher with Apex. And to learn more about how to better mitigate those risks, make sure to check out our article on the best practices for Salesforce customization.