Manage Learn to apply best practices and optimize your operations.

When you need custom Salesforce code -- and when you don't

As the Salesforce saying goes: clicks, not code. But is that always the case? An expert offers insights into which issues will require custom code to address.

For Salesforce developers, code is the coin of the realm. But just because you know how to program Salesforce doesn't...

mean you should.

Coding from scratch can be time-consuming, difficult to manage and complex. The more Salesforce code there is, the more customization you introduce. While coding from scratch may look elegant on the Salesforce developer side, it may not promote user-friendly applications or a smooth upgrade path. Customized code almost always creates snags and manual rework for the upgrade process.

But with Salesforce's "clicks, not code" motto, you may not need to code much. Over the years, Salesforce has introduced greater functionality that requires minimal technical knowledge and is possible for an admin to roll out rather than requiring a developer. For companies that use Salesforce as a CRM tool and do not use the platform functionality, these declarative tools may eliminate the need for a developer. For companies using complex integrations or more of the high-quality platform features through Force.com, a developer with knowledge in Apex, Visualforce and now Lightning is needed. It is important to use declarative code whenever possible. So take heed, Salesforce developers: To code, or not to code, is the question.

By knowing when to use clicks rather than code, your system will be better equipped for easy changes created by your company and by Salesforce. Custom code always runs the risk of degradation over time, especially when the platform upgrades regularly, which Salesforce does three times a year. Whether you are considering staffing resources for your Salesforce team or prioritizing developer time, it is important to know what some of the core functions each time of build requires.

Below are five issues that do not require code and five that do, to give a better sense for when to allocate for developer hours and when it is not needed. I have left out some of the more basic aspects of Salesforce functionality in the declarative space because that is Salesforce's claim to fame and is widely known to be easy to change without code, like page layouts and fields.

No custom Salesforce code required

1. Blocking bad data. Data maintenance is the largest hurdle in any large database, especially one that is updated regularly by multiple users who are on the go, such as sales reps. With the creation of tools like validation rules and duplicate record checking, Salesforce has given administrators the means to force data integrity in users' data entry. Code is required only if validation rules on a record must be "soft," or should be able to be bypassed after one reminder of the potential data integrity issue. This is not often a good business practice, so it isn't often needed. Validation rules will work just fine.

2. Integrating with AppExchange applications. The Salesforce application marketplace, AppExchange, gives companies many options to enhance Salesforce and provide connections to other systems. A large majority of the AppExchange products are built to easily install and set up without Apex or Visualforce and can be used very quickly within the environment.

3. Using buttons for URL hacking. Salesforce admins can create robust custom buttons that allow for greater flexibility when creating records. For instance, there is no need for code when a custom field is created on an account page and needs to be added to every opportunity. With URL hacking, it is possible to make a New Opportunity button on an account that matches all custom fields automatically, no longer requiring manual entry. But note that Salesforce's Lightning user interface doesn't currently accommodate custom buttons, one of the most widely used pieces of Salesforce Classic. This non-code is not available in Lightning at all, and it is to be determined how buttons will be used in Lightning going forward.

4. Updating and creating records automatically. Using the new Process Builder that debuted in 2015, admins now have much more flexibility to create and update records than the usual workflow allows. Before Process Builder, in order to create a full process flow it was necessary to create multiple workflows and then Apex triggers to join them. Now, with a few clicks, admins can update any related record (former capabilities included only records and parent records), create new records and join information across them. There are limitations to this tool, so some processes may require code that I will discuss in the code section below.

5. Building wizards and multipage prompts through flows: Flow is a Salesforce tool that bridges the admin and developer roles. It's as close to code that clicks can get, and usually requires practice to understand and use. But its learning curve is rewarded by its power. With flow, it is possible to create an entire process in wizard format, which can guide a user through the steps of creating a record using a page layout.

For example, a call center rep can use a flow with multiple screens to walk through a call with a customer. Admins can configure all the scenarios of a call, guide the rep through the proper questions and gain the correct information, creating the correct record in the background without the rep needing as much training. This gives the ability to ask full questions, rather than having a user guess the meaning of a field. It also provides pertinent information based on each answer, rather than enlisting a slew of validation errors that lead to user frustration when creating or updating a record.

Custom Salesforce code required -- for now

1. Complex record updates. While Process Builder, workflows and flows allow great flexibility within Salesforce to automate business processes, the most complex business processes will likely still require code. A creative admin can circumvent this by combining Process Builder and flow scenarios, but this can overwhelm the system based on the process.

Process Builder does not enable you to process large amounts of data at a time, so the process could fail. For example, if you're loading a few thousand leads every morning for your account executives to act on, Process Builder will likely fail if the data load triggers a process on all these leads. In this instance, Apex would be the better solution, but it's likely Salesforce will continue to improve process builder and this will be available soon.

2. Branded experiences. Visualforce or Lightning is required in order to brand Salesforce or create custom pages within an instance. This is the case for anything that doesn't use the standard page layouts available in the application.

3. Web to case. While Salesforce provides a snippet of code for Web-to-case, this code is not complete or usable in its current state; it is a merely a guide to how it should be formed within the website. In order to add the code to a website, it is necessary to make revisions to it by someone who is knowledgeable in at least HTML code.

4. Force.com applications. Force.com is a clue to this piece. If you are creating customized community experiences or applications for desktop or mobile that don't use standard Salesforce, code is required. This gives you the flexibility to create experiences that do not feel like Salesforce but retrieve and visualize the data from the CRM on the back end, without needing complex extract, transform, load (ETL) or API connections.

5. Non-AppExchange integration. Any integration to databases within a company, like financial systems or back-end servers, requires knowledgeable developers and data specialists that can make the connections via API or ETL to Salesforce. Even if some systems have AppExchange plug-ins, the company likely has customizations to that application that require more advanced development to make the most optimized experience for users.

As Salesforce continues to expand the declarative aspects of its CRM, less development will be needed, which will enable greater flexibility within the platform and faster fixes to issues. It is important that it is the company's strategy to use custom Salesforce code as little as possible to maintain the integrity of the system long term. With that in mind, Salesforce will be a great system for the investment long term because it will be adaptable to every change and there will be less fear of resource constraints for those changes.

Next Steps

Data quality and CRM

Salesforce development tips for nontechies

Cleaning up your Salesforce data to get results

Learn about Salesforce Idea Exchange ideas

 

This was last published in May 2016

Dig Deeper on Salesforce Application Development

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What is your strategy to minimize custom Salesforce code?
Cancel
Great article - totally agree on limiting code. We refer to it as "code sprinkle" for just the really special stuff!

Recommend also look at the Appexchange App - Skuid - https://appexchange.salesforce.com/listingDetail?listingId=a0N30000009wyDjEAI. We have assembled many wildly capable and cool apps very quickly.
Cancel

-ADS BY GOOGLE

SearchCRM

SearchManufacturingERP

SearchSAP

SearchFinancialApplications

SearchDataManagement

SearchBusinessAnalytics

Close