Let’s face it, as Salesforce developers we aren’t really all that different from other developers – we love to write code! And just because we can, we sometimes write code for things that could have easily been solved without coding, or we use our skills to address even the last tiny functionality or usability gap in a standard page… and end up writing a complete new custom user interface and maybe even framework along the way.

While custom development sure is a lot of fun – after all we’re developers and that’s what we do – the question is whether it’s really such a great idea to always dive straight into code when customizing Salesforce or building a new app on the Salesforce platform. Force.com started out as a declarative development platform in its early days and continues to provide a rich set of declarative development features to this day, so let’s dig in and find out what we can (and should) do with clicks instead of writing code.

Write Code for Everything?

At first sight it might sound like a really good idea. If everything is implemented in code, everything is in one place, easy to find and it follows the same basic approach and methodology. We get to build trigger frameworks, helper classes, service layers, etc. and we get to build it exactly how we want it. Sounds great, doesn’t it?

But let’s consider a few things on the flip side:

Cost and time – what will the resources for all this custom development cost and how long will it take?
Maintenance – who’s going to maintain the code after the initial development is done?
Complexity and Scalability – code can introduce various degrees of complexity. More code typically introduces more complexity and complexity can be hard to manage in terms of scalability. E.g. if your implementation heavily depends on business logic coded with Apex code, you are more likely to run into governor limits.

As you can see, there are quite a few things to consider here. But let’s flip the argument around again and see why we maybe wouldn’t want to write a single line of code at all.

Clicks not Code!

And by clicks I really mean Salesforce native functionality or declarative development features that allow us to build new functionality or customize without writing any code. With this approach we are a bit more limited in terms of building exactly what we want, but the reasons why this approach is so powerful are quite simple – let’s first use the same dimensions as above again:

Cost and time – using declarative development features is fast! It doesn’t involve writing code, writing test classes, worrying about checking in code into a repository, version control your code, etc.
Maintenance – probably one of the biggest differences. There is no code and test automation needs to be maintained when using native features and declarative customizations
Complexity and Scalability – we can still build a lot of complex things without writing a single line of code, but there is less to worry about in terms of governor limits as they don’t apply to declarative customization. There are of course limits to keep in mind for declarative customizations as well, but the main difference is that these are design limits (e.g. total number of workflow rules on an object) rather than execution governor limits (e.g. total number of SOQL queries issued), so they’re easier to handle with a thoughtful design approach.

And I will add two more things to the list above:

Update Path – Native features and declarative customizations will automatically update hand-in-hand with each Salesforce release. Whenever Salesforce improves a native or declarative features, we get to take advantage of the improvement without really having to do anything.
While code customizations will never break after a Salesforce release, there’s might be some level of effort required to work newly released Apex features into our code, or – if we used code to customize a native feature – to adapt our code to fit the new and improved native feature.
Usability and User Productivity – Sometimes using standard features and declarative customizations can keep the usability of the application more consistent. One example is using a standard Edit page vs. overriding it with a building a custom Visualforce Edit page. On the Pro side for building a Visualforce page is that we can build the Edit page exactly the way we want it. But there are also trade offs for overriding a standard Edit page that aren’t always considered and that can have a big impact on the consistent usability of the app and user productivity:
- We lose the ability to easily change the page layout using the Page Layout Editor
- We lose inline editing capabilities in list views

So let’s find out what we can all do with clicks!

Examples for Declarative Development versus Code

Here are some use cases and examples for functionality that can easily be build declaratively, without writing a single line of code:

Instead of writing Triggers, we can automate Field Updates using Workflow – automatically populating a field with a default value or updating a field based on the value of another field is a pretty common requirement. Workflow can address the basic use cases just as well as writing an Apex Trigger.
Use Formula Fields and Roll-Up Summary Fields for field calculations instead of writing a Visualforce page and calculate the field values in a controller extension – a good example is a simple Order Management app. On the Order Lines, the order line total is calculated by multiplying the item price with the ordered quantity. A formula field can easily achieve this. And if we want to have the sum of all order line totals on the order header, we can use a Roll-up Summary field, as long as there is a Master-Detail relationship between the order and the order lines object.
Enforce Business Rules with Validation Rules whenever possible instead of Triggers and code
Don’t want to allow users to save the order if a piece of information is missing? Validation Rules is a fast and easy-to-use alternative to writing custom Visualforce pages and controllers or Apex Triggers.
Use Approval Processes and Flows to implement logic and processes
A lot of complex custom business logic and business processes can be defined using these two powerful tools. And probably the nicest benefit is that Approval Processes and Flows visualize the process, which makes it much easier to understand what’s going on than looking at lines and lines of Apex code.
Using Standard vs. Custom Objects
We see this more often than one would think. Before creating a new custom object, check if there’s a standard object available that can address the functional requirements and/or can be customized to close the gap. Not only will this potentially save a lot of time, but also help control the number of custom objects in Salesforce, which is limited as we all know. A great example here is the Orders object that was released with Salesforce Spring ‘14. Before the Orders object was a Standard object, developers spent a lot of time and resources building functionality that is now available out-of-the-box. Keep in mind that there are three major Salesforce releases per year, so Salesforce is constantly adding new features and functionality. It’s always a good idea to check both the Salesforce1 Platform Release Notes and the Force.com Release Pages here on Salesforce Developers for new standard objects and/or new features that may have required custom building in the past.

Summary

The main point I’m conveying is that as Salesforce developers we should not always dive straight into coding just because we can. Salesforce offers a rich set of declarative development features and before implementing customizations or new functionality, we should always make sure that we are familiar and keep up to date with Salesforce’s native capabilities and that we have exhausted all native options before we start to code and reinvent the wheel.

Using native functionality or declarative development features has many benefits from time and cost savings to easier maintenance and sometimes better usability.

Of course not everything can be built without coding, and there is a time and plenty of places when writing code is the right approach to build something. Make yourself aware of the native and declarative-development features in Salesforce before you code, and evaluate them in your design before you consider coding.

Additional Resources

Here are some more useful sites and blog posts that talk about Salesforce development without writing code:

An Introduction to Point-and-Click App Building with Force.com
You Can Build Apps: No Code Required
Force.com Workbook – Chapter Add App Logic with Clicks, Not Code
Force.com Platform Fundamentals – An Introduction to Custom Application Development in the Cloud
Point-and-Click App Logic

About the Author and CCE Technical Enablement

Markus Spohn is a Technical Enablement Architect within the Technical Enablement team of the Salesforce Customer-Centric Engineering group. The team’s mission is to help customers understand how to implement technically sound Salesforce solutions. Check out all of the resources that this team maintains on the Architect Core Resources page of Developer Force.