Why You Shouldn’t Fear Customization on Salesforce
This is the first post in a three-part series that describes our approach to customizing apps on the Salesforce Platform.
What is Customization?
Our clients are often concerned with the consequences of customizing force.com applications such as Certinia PSA and FFA. The term “customization” can mean different things to different people. It’s important to note that products from Certinia are already locked down by virtue of being managed packages. This means – the contents of the package can’t be changed. However, the force.com platform allows CLD and our clients to augment products and tailor them to their specific needs by:
- Adding objects and fields
- Creating flows and approval processes
- Creating standards-based user interfaces using Lightning Web Components
- Writing code in Apex to efficiently handle complex needs, including integrations with other systems
- Utilizing additional packages/products that provide the needed functionality.
Most organizations need some combination of the above. However, the extent to which such additions are needed depends on the extent to which the organization wants to change its existing business processes to the processes that Salesforce and Certinia use out of the box (“OOTB”). It can vary from a few additional objects and fields to extensive augmentation for large, complex organizations with an existing collection of enterprise systems to which Certinia is being added.
Should You Fear Customization?
In short, no. Organizations sometimes enact a general policy against customizations with good intentions. They seek to:
- Avoid the time and cost of building the functionality and/or supporting it (This can be especially true if the organization lacks Salesforce developers)
- Avoid issues with upgrading products that they fear customizations may introduce
- Force their organization to adopt the “best practices” they believe are inherent in the product and abandon complex business processes developed over time.
Let’s examine each one of these in turn.
Time, Money, and Resources
Building and maintaining customizations takes resources who know how to do it, time, and money. There is really no way to avoid this. Software, on the force.com platform or otherwise, requires expertise to build and maintain, including uncustomized software in managed packages. The good news is that the force.com platform was designed from the start to easily support augmenting product functionality. This is very different from other ERP software and is a primary driver of Salesforce’s growth.
Why do organizations use software at all? To reduce the work of resources whose labor is expensive. This may seem obvious, but it helps to clarify the value of customizations. Without customizations, organizations have to force their employees to use OOTB processes to accomplish their work in ways that are slower than they would otherwise be if tailored to the organization’s needs. Building customization once is generally cheaper than expensive resources doing things slowly forever.
Salesforce admins and developers who support software are necessary to support your organization should it decide to move any of its vital systems onto the force.com platform. Some organizations will permit non-code (“declarative”) customizations because they lack Salesforce developers, but have Salesforce admins. In our experience, a good admin can learn to code on the force.com platform. A bad admin can’t, but then a bad admin won’t build declarative customizations well, either. By the same token, a bad Salesforce developer won’t do you any favors. If you are going to entrust your business to software, you need expertise to support it. If you can’t hire that expertise easily, CLD can augment your capabilities with our long-term support service, Concierge.
Furthermore, one should not assume that using declarative tools will always be simpler, faster, and less costly than code. Code is often the simplest and cheapest way to address certain requirements. 100 lines of code can often do what 100 nested flows cannot and be easier to understand and troubleshoot.
Upgrades
Many organizations that have experience with other ERP software upgrades are wary of customizations because they can make upgrades much more costly and complicated. CLD has done multiple analyses and tests for our clients who have the same concern. In every case, no CLD customization has ever prevented a Certinia upgrade.
At CLD, our long experience as the first Certinia implementation partner and best partner for enterprise clients has led us to a key insight – we do not make changes to the core parts of the system. As noted above, the managed package – the product itself – cannot be changed. So, if a particular customization were to present a problem, it would likely be indirectly and as a result of data being generated rather than something in the customization itself. Our deep knowledge of Certinia has given us insight into which areas of the system to avoid meddling with (for example – the time entry user interface) and which are great opportunities for customization (one example – a custom UI for managing large numbers of milestones that doesn’t touch the underlying data at all).
Encouraging Best Practices
Certinia embeds assumptions about how companies work into it’s out-of-the-box functionality, but every organization is different and has different needs.
Adopting a policy of “no customizations” doesn’t really force your organization to adopt best practices – it simply hamstrings your ability to augment excellent software to help your resources save time and money. It blindly accepts the premise that the business practices Certinia has embedded into its software will work for your organization without exception. This assumption tends to break down quickly in the design phase when we hear from our clients both, “no customization” and “we need it to do this.” Augmenting software can save your resources’ time – thus freeing up more time for activities that increase revenue.
To put it another way, the software should encourage best practices that help you work faster and with higher quality. Those practices are different at every company. If your resources believe that the software doesn’t help them work, they will find a way to get their work done without using the software. “No Customization” often leads to “Poor User Adoption.”
Conclusion
A “no customizations” policy distorts the software design process and leads to higher costs, more complexity, and worse user adoption. It’s best to consider each piece of needed functionality on its own terms. Our next post in this series will show you how. Read it now.
Ready to extend Certinia’s base features? Read these 9 Rules to Follow When Customizing Salesforce
