Salty or sweet? Raiders or Niners? Facebook or Twitter? In the Salesforce community, the debate about “clicks or code” is a hotly contested one. One of the best things about Salesforce is that there are many different approaches you can use to solve your business requirements. On the other hand, one of the most challenging things about Salesforce is that there are many different approaches you can use to to solve your business requirements.
What does “Clicks or Code” mean?
For the uninitiated, Salesforce provides many ways to configure their platform, which allows administrators to create apps, automation, and user interfaces without writing a single line of code i.e. using “clicks”. In addition, Salesforce has also opened up their platform and allows developers to build completely custom user interfaces, logic, web services, and more i.e. “code”. There is some overlap between these two approaches, which is the gray area of debate amongst those who build and maintain Salesforce solutions for a living.
When should I use clicks?
The short answer to this is “anytime you can”. When designing and building any solution on Salesforce, the default stance should always be to use the point and click tools Salesforce provides if they can accomplish your requirement. These include things like page layouts, formula fields, roll up summary fields, validation rules, workflow rules, assignment rules, and the Salesforce1 mobile app (among many, many other features). The main advantages these features provide are in their speed to develop and their maintainability. They’re easy to locate, update, remove, or build upon as requirements change and evolve. It doesn’t take a computer science major to build very powerful applications. And one of the best parts – it’s difficult to make a mess of things like in traditional software development.
Why would I ever write code?
What about the gray area?
The crux of the problem revolves around situations where a configuration-based solution might achieve the requirement but would not be as elegant or user-friendly as what could be achieved by writing some custom code. To illustrate this point, take the example of a time tracking system for a project management application. The application uses three Salesforce objects – Projects, Assignments, and Time Cards. The requirement is that each Time Card record be related to an Assignment record, which in turn is related to a Project record. Each week, a user must enter a Time Card record for every Assignment record assigned to them. Without going much deeper into the requirements, this is a slam dunk for using all “clicks”. As long as you have the appropriate fields created on each object, all the user has to do is go to an Assignment record each week, navigate to the Time Cards related list, click the New button, and enter the data. Problem solved, right?
Well, let’s expound on this a little further. Most users actually manage multiple Assignments across multiple Projects, and on average they need to enter 4-10 Time Cards per week. Sometimes they forget to enter their Time Cards, so it would be nice if they were reminded when they were past due. And if they enter more than their allotted budget of time, we need to alert the Project Manager. There still isn’t anything in these requirements that can’t be accomplished with configuration only, however, we’re getting into an area where 1) the user experience would be sub-optimal, and 2) the configuration options we have will require what are commonly referred to as “work arounds”, such as creating fields on objects for the sole purpose of making OOTB functionality work. The latter is not necessarily bad, but the user experience could be a deal breaker for adoption of your application, making all of your hard work that went into building it for naught.
How to decide?
For simplicity’s sake, let’s say your options are 1) use all standard functionality with no code, resulting in a working solution with a less than optimal user experience, or 2) use mostly standard functionality but build a custom UI for Time Cards using Visualforce and write some Apex that automates the creation of Time Cards records for each Assignment every week. Which is the right approach? In this case, and in most situations like this one, asking a few questions will help guide you:
Do I or anyone else on my team have the skills needed to build and maintain a custom solution using Visualforce and Apex?
How would building a solution with Visualforce and Apex affect the timeline and budget of my project?
What is the most important factor in the success of my project – timeline/budget, user adoption, maintainability?
Can I start with a basic solution and improve the application in phases over time, or do I need to start with a polished solution in the initial release? (This is especially applicable in situations where you may be building a brand new app vs replacing an existing one)
Is the amount of code that I would need to write/have written (technical debt) worth the benefits I’ll receive by accruing said technical debt?
These questions all revolve around a few key premises:
Don’t write code if you don’t have the skills or capacity to maintain it.
Don’t ever write code where OOTB functionality will suffice.
Don’t underestimate the power of good (or bad) user experience.
Don’t assume you’ll make it better later if you know that you likely won’t.
Do exhaust all configuration options, even work arounds, before you consider writing code.
While this is not meant to be an entirely comprehensive list of all possible considerations, hopefully it will help you better weigh your options when faced with the “clicks or code” dilemma. It’s important to remember that just because you can write code doesn’t always mean you should, while also considering the users of your application and the long term implications of your solution designs.
Do you have other ways that you evaluate how you build solutions with Salesforce? Do you agree or disagree with the approach that I’ve proposed in this post? Leave your comments so that the Salesforce community can learn from your experience.
Happy clicking (and coding)!