Skip to content

Custom Coding

Custom coding versus setup and configuration

Many customers struggle with the question: "should we accept or implement custom solutions, or do we need to stick to the functions Salesforce offers through standard admin configuration and setup?" There is no easy answer, however getting a clear picture of what the exact differences are — and what the potential consequences are — is needed to define a clear decision and policy on this subject.

Standard configuration features and setup can be defined as "anything you can change in your Salesforce org directly in production." When your Salesforce profile has 'System Administrator' privileges, the setup options within Salesforce provide a rich palette of tools to adjust, extend and configure your org. Starting with changes to the database schema, adding objects, fields and relations, setting up various types of workflow automation, data validation rules, data access, etc. — all of these tools can be used through an intuitive user interface within your own Salesforce org using a web browser.

When it comes to custom coding, also known as Bespoke work, it is not possible to apply this directly in your production environment. Custom coding needs to be developed within a Salesforce Sandbox environment, and once it is compliant with the Salesforce governance constraints you can deploy the custom code to production.

With every major release of Salesforce — three releases per year — both changes performed by standard configuration and custom coding remain valid and active. Even when custom coding is implemented, there is no need to worry about whether your custom solution will fail with a new release. However, it is always good practice to check and validate within your sandbox to make sure you are prepared for the unexpected. All custom coding is based on a so-called API version, and every major Salesforce release introduces a new API version while the previous versions remain unchanged and provide true backwards compatibility, even when running several API versions behind.

Every Salesforce release comes with new and improved tools for Salesforce administrator heroes to use in adjusting your org through configuration and setup. But these releases also bring new custom coding features by introducing new and improved functions, development tools and deployment tools.

Often the argument against custom coding is complexity — suggesting it should only be applied to support complex business requirements. Well, it strongly depends on who is making that argument. A configured flow can be very complex and difficult to manage and maintain.

Both standard configuration and custom coding can be complex. However, when it comes to custom coding there are several best-practice coding patterns designed to reduce complexity, prevent inefficiency and make solutions more generic so that a custom component can be used in multiple ways.

Developing and dealing with custom coding requires a different skillset compared to a Salesforce super-hero admin customizing Salesforce to support business requirements.

Looking closer at the concept of custom coding — the Salesforce AppExchange is loaded with custom-developed solutions that rapidly provide functionality your Salesforce admin can install in a few clicks. Some of these solutions are paid and others are free. Some are managed packages and some are not. All AppExchange solutions exploit the platform capabilities of Salesforce using configuration and setup in combination with custom coding wrapped in an installation package. The managed packages are protected by the publisher, while unmanaged packages install predeveloped functions allowing access to the actual source code to adjust or extend.

The journey towards custom development usually starts by exploring standard customization and setup capabilities. If that fails or becomes too complex, the next option is often the AppExchange. If no suitable solution exists there, then custom coding is explored.

As mentioned, Salesforce provides a strong governance model when it comes to custom development — in fact, stricter than for configuration and setup. When you create a flow to update a bulk set of records you can activate it in production right away. But when you do the same with custom code, you need to ensure the solution is compliant with the governor constraints.

Another argument against custom coding is often the duration. Some assume that implementing a custom solution is always time-consuming — but 'easy' configuration changes made in a live production environment put the stability of your system at risk. These changes should also be implemented in a test environment, validated by users and then deployed to production. In many cases the timelines are comparable.

To summarize: comparing standard customization and setup with custom coding, they are both supported with new releases, can be equally complex and time-consuming, and both come with your license. Your license fee is not affected by whether you use custom code or not.

It all starts by defining clear design principles as the basis for implementing any change. For example:

  • User-friendly interfaces. The user interface shall be easy to use, consistent, and any analogies used should be simple. Wording, labels and text messages including error messages shall be directive, unambiguous and easy to recognize.

  • Exploit standard and code-less functionality. This is a fundamental ground rule. Custom development should only be considered if standard functionality is not available or is considered complex and/or high maintenance.

  • Easy to support, based on best practices, consistent and properly documented.

  • Robust, scalable and easy to adjust with the right skillset.