9 Rules to Follow When Customizing Salesforce
This is the third post in a three-part series that describes our approach to customizing apps on the Salesforce Platform.
Introduction
The first post in this series sought to clarify what constitutes customization and why organizations struggle with the decision to customize. The second post provided guidance on when customization is warranted. This article provides the guidelines necessary to arrive at a sound customized solution.
Rule 1: Don’t automate everything in the first version of your solution
Adopting the Salesforce platform brings with it a host of incredible new capabilities. Simply recreating your legacy solution on Salesforce (“lift-and-shift”), misses the opportunities for 1) improvements to business processes and 2) learning force.com features that can help your organization do its work. Taking time to learn the new platform and new product features can lower costs by allowing you to do things in a new way.
Rule 2: Don’t use customization to “fix” a business process
Automation is best suited to speeding up a well-designed process or processing lots of data quickly. However, if the process itself isn’t effective, then automating it actually compounds problems rather than solving them. As a test, first, define how you would do a given process on paper. Only once it makes sense on paper should you try to automate it.
Rule 3: Look out for customizations which compete with the base product
Certain customizations seem useful at first, but later complicate the operation of the base product. If a company wishes to implement new features into a Salesforce app, it should consider whether the base version of the app might include those features in the near future. Otherwise, a custom feature may soon come into conflict with a native one, creating two confused data sets. This can also complicate support from the software vendor. Partnering with another company, such as CLD, that has extensive experience implementing the product can provide clarity into which kinds of customizations should be avoided.
Rule 4: Don’t use flows and code on the same object when possible
When adding functionality, avoid mixing code and flows on the same Salesforce object. If you are defaulting field values and/or syncing from other objects, do this all in either flow or code, but not both. Mixing the two makes it harder to maintain and control operational order (e.g. which updates happen before/after the update and when are flows triggered in relation to before/after code firing). It also becomes difficult to troubleshoot, because developers will have to check multiple places to trace the flow of execution.
This rule tends to get broken in larger organizations when multiple teams work on shared objects. For example, CLD often works on PSA projects, which are related to the Salesforce opportunity object. A common directive for many new implementations is to use flows where possible instead of code for any customizations. However, when the Salesforce objects involved are already customized using code, it’s important to have a conversation with the client about the long-term maintenance issues that will occur with mixing flows and code.
Rule 5: Don’t break the data model
Existing out-of-the-box fields should only be used for their original purpose. If you need to store information, don’t simply use a field in the product that your organization doesn’t happen to be using right now. Instead, create a new field for your purpose. This approach avoids potential future issues should the software vendor choose to change or use in a different way the original out-of-the-box field.
Rule 6: Temper security & control restrictions
Many companies like to default to a state of high data security. However, customizations built to limit access to internal project data can complicate business processes and impede the smooth flow of information. We advise companies to consider carefully the business need to restrict access to certain data. While it is sometimes necessary, our experience is that many companies are comfortable sharing more information with their employees when they realize the simplification benefits of beginning customization from a position of openness. Sometimes it is helpful to re-consider: “Why do we want to keep this material private from some teams?”
Rule 7: Curb controls & notifications
It takes about six to twelve months for a business to familiarize itself with a Salesforce app. If a business, before that time, restricts the ways its employees can use the app, it serves to bog down the process with inefficiency. Such preordained controls promote stagnation or stifle natural process maturation. Alternatively, a business that starts with an emphasis on reporting learns how to properly interface with its sales software, and thereby promotes growth. A good rule of thumb is to, when possible, report on exceptions rather than to restrict functionality.
Rule 8: Implement an “off switch”
Businesses often find it useful to deactivate certain customizations. Sometimes they need this feature to troubleshoot, and other times because of base software updates. To accomplish this, CLD recommends using a custom setting with individual fields for each trigger/flow context that you wish to control separately.
For example, you might create a custom setting called “Flow Control,” with a custom field called “Disable Timecard Header Before Insert.” When checked, this field would disable the corresponding logic in the appropriate flow via a check in the Set Entry Conditions of the flow. The same approach can be used in triggers: one field per context that you wish to control, and corresponding logic to check the value of the field prior to running that logic.
One benefit of this is you can turn off code and flows without deploying changes to production.
Rule 9: Know when to stop
Customization can only bring so much new value to an app. If a business replaces too much of an original Salesforce app, it loses the value of customized software. Heavy customization comes only with extensive work, and the advantages of a managed, supported product disappear. After a certain point, a business should build its own software from scratch rather than customize an app it doesn’t want.
Don’t fear customization – but be thoughtful about it.
We’ve helped clients implement and, when valuable, extend Salesforce and Certinia for 12+ years. CLD is available to perform a health check/assessment of your solution, just email us.
