Here at TerraSky we often encounter people who are fairly new to working with Salesforce and are looking to turn the platform into something that meets their business needs. The Salesforce platform is a powerful tool that is highly configurable and extremely customizable. Usually, people use those terms fairly interchangeably, but in the Salesforce ecosystem, they mean very different things. I wanted to take some time to help explain what the difference is between configuring Salesforce and customizing Salesforce.
What’s the Difference Between Configuration And Customization?
Configuration and Customization are terms you will hear thrown around in the Salesforce space frequently. Since the Salesforce platform is designed to handle those two things so well it happens at a really high percentage. I would dare to say 90%+ of the companies who use Salesforce have done some form of configuration or customization.
Let’s start by defining what we mean when we use the terms configuration and customization. Configuration is anything you can do through the point and click environment of Salesforce. Using the declarative tools they provide you can configure the platform to do quite a lot for your business. Customization is anytime you need to start digging into code to accomplish your business objectives. This might mean that you have reached the limits of what can be done in the declarative tools and you need to use custom code to accomplish your objectives. Below are a few things that can be done within the Configuration and Customization categories.
Configuration
Adding Objects/Fields
Adding Tabs/Apps
Creating Profiles/Permission Sets
Workflows
Reports
Validation Rules
Email Templates
Page Layouts/Record Types
AppExchange Apps
Customization
Apex Classes
Apex Triggers
Visualforce Pages/Components
Visualforce Emails
Integrations With 3rd Party Systems
Creating Lightning Components
Building Sites.com/Force.com Sites
Using CSS to alter the look of pages
Using JavaScript to add capabilities
Your Salesforce Team
One major consideration when you’re determining if you should do anything with configuration and customization is to understand your Salesforce team’s capabilities. The Salesforce ecosystem is vast with knowledge, tutorials, documentation, and guides on how to do things in the realm of configuration and customization. Configuration is less problematic to dabble with than customization, but one should still understand the capabilities of what they are doing before changing the platform. For example, deleting a picklist value might have unexpected problems if you don’t fully understand how things work.
Your Salesforce team will be primarily centered around your Salesforce administrator. Does your administrator know how to code or are they a point-and-click kind of admin? Understanding this is the very first step that needs to be taken. 2nd: Do you have development resources in house, this could be your Salesforce administrator or it might be a separate team altogether that is willing to help, or will you need to outsource your development work? This is critical to understand what would happen if you reach the end of the road for configuration and you still find yourself needing more.
As mentioned earlier, there are a plethora of resources for you to develop any internal resources into a Salesforce administrator or help someone learn to code, but will it be worth the time investment to do so? If the answer is no, you can certainly use the scores of implementation partners that exist within the Salesforce ecosystem.
Does the Out-of-the-Box Functionality Meet Your Needs?
When changing the Salesforce platform you should look at the importance of each change to determine if it really needs to be done. Is the change a must-have for business or is it a nice-to-have? The difference might not be so obvious since most users who make requests make things seem like the end of the world if they don’t have that new shiny toy. We will look at two questions we can ask ourselves to help figure this out.
If your business process is in place: If this is so important, how have they been doing business without this? What has changed since the first implementation?
If your business process is not in place: Will they be able to do business without this change? What is the business impact if this change is not made?
I’m sure there are more questions you can ask to go along with those two questions, but those will at least get the conversations moving in the right direction when you discuss changes with the stake holders. Understand that changing the system, since it is so easy to do, can eventually become problematic. We have seen many companies who significantly over-complicate their Salesforce environment because the implement any and every request that comes in exactly how the user asks for it without thinking through things. Is there a better way to do what the user wants? A Salesforce administrator or developer needs to understand how to take the requests of a user and filter those things through the lens of their training. Remember, your users don’t know how the platform really works, they just have a business need that must be solved. It is our job to translate that need into a solution that will work long term.
Can your business process be accomplished with configurations?
To really understand the answer to that question you need to understand what options are available in your configuration tool belt. Customization offers you a wide range of things that can be done behind the scenes with pure code, but it isn’t necessary to start there. In fact, it is a poor choice to start there. Do a deep analysis on how to break your business process down into the various options you have at your disposal for configuration first. What can be added as an object/field, what can be turned into a workflow, what validation rules must be in place, etc.? Once you break down your business process you can begin to identify what gaps exist. When I say “gaps exist” I simply mean you can identify if your business process requires you to dabble in customizations in order to implement that part.
When Do We Customize?
When you break your business process down into the portions that can be handled via configuration and the portions that must be handled by customizations. Don’t attempt to customize something unless you’ve done this. It is a rookie mistake to go the path of code simply because a developer is more comfortable with that than learning how to implement the same thing through configurations. Let’s travel back to the part where I asked the question “is the change a must-have for business or is it a nice-to-have?” Once you’ve figured out which parts need to be customized you can now begin to evaluate the importance of each feature. Begin looking into what would go into implementing the must-have’s first. Will it require a Visualforce page to create the UI that is needed? Will it require an Apex Trigger to accomplish some backend functionality? Will it require scheduled Apex code to process every 12 hours? There are hundreds of reasons to customize the platform, but I’ll list out a few common ones we see and hear about:
The business process cannot be accomplished through workflows and validation rules
We need a 3rd party integration
We cannot use the standard reports to view the necessary information
Users still aren’t using the platform even after it has been configured
People are using things like Word or Excel to manage data outside of Salesforce because it is too time-consuming to do it in Salesforce
We are building our Sites.com, Force.com Sites, or Communities
I will state this again, this is nowhere close to an exhaustive list of reasons why a company would customize Salesforce, but it does depict common things TerraSky staff hears when we ask about this. If you’re going the route of creating Apex code or triggers you can do this with an implementation partner or by using a developer in house. If you are going with something that requires Visualforce you’ve got more options: you can use AppExchange apps, like SkyVisualEditor, to build your UIs for you, you can hire an implementation partner to build your UIs, or you can use an in house developer.
If you are going down the path of creating custom Salesforce pages, you may want to check out another blog post we wrote about 6 Practical Salesforce Design Tips. When deciding to customize this should be done after careful consideration. Since this is static code, if Salesforce changes something on their side it could negatively impact your code’s functionality. In addition to that if your users ever want to make a business change it could also require an update to your customization. The world of customizations is fantastic, but should be done after configuration options have been exhausted.
Summary
Configuration and Customization are equally important in the world of Salesforce when it comes to accomplishing business objectives for the companies that use the platform. Take a good look at the staff you have on hand, the staff you’re developing, the partners that are available to you, and the applications that you can leverage to turn Salesforce into a platform that will guide your company from where it currently is to where it needs to be.
Comments