Go to portal
Introduction
One of the reasons why Salesforce has been successful in the SaaS space is its configuration capability which enables organizations to build solutions and maintain the platform without going through heavy development efforts. Customers can build workflows to support their business process with the out of box configuration elements that are easy to use, test and maintain to scale the platform as business grows over time. In the traditional software space, organizations had to write a huge volume of code to implement changes and build an interface between client and server whereas Salesforce’s cloud computing concept eliminated the need to manage hardware such as servers, network equipment, etc. Salesforce had the vision to help customers to focus on business growth and take away the heavy lifting part around the technology. This was a shift in the computing world where businesses adopted the concept of application development rather than building technology stack.
Salesforce is just not a CRM. Salesforce offers a platform capable of running enterprise applications. CRM is just one of the applications that run on the Salesforce platform. Salesforce has enabled other organizations to build applications on the platform by using configuration abilities and code.
There is a wide range of configuration options available such as creating a new data model, custom fields, validation rules, and approval processes. Customers often end up with building solutions using Apex code which enables them to extend the out-of-the-box Salesforce functionality. The challenge that comes with the configuration and coding capabilities is the technical debt which can impact operational efficiency in the long term. Businesses should consider the trade-offs while building solutions and revisit their vision to invest in the Salesforce platform.
Salesforce Configuration Vision
Since its inception, Salesforce has had a clear obstacle to overcome, which is clear to see in their first V2MOM: V2MOM it’s an acronym that stands for Vision, Values, Methods, Obstacles & Measures, a document to create alignment and common understanding across the organization.
Why was it an obstacle?
Well, by the nature of how businesses evolve, digital solutions have a lot to do as an enabler to support that growth. At the pace of change, we experience, the market can’t generate enough ready professionals for the exponential demand that is faced. A talk by ‘Uncle Bob‘ explains why and how that obstacle will continue, and also covers other interesting topics.
Over the years Salesforce narrative has evolved from No-Code to Low-Code and the never-ending story of citizen development vs programmatic development. Some pointers:
Salesforce customization: Drag & Drop
With the concept of citizen development, you have what is often called configuration, things that you can accomplish with clicks, not code. On the other side of the spectrum, you have the latter which requires tooling to get ready, in the right version, and synced to even start. A quick reminder here to our previous post on the importance of Version Control.
Maintained, Extended & Upgraded
One of the things Salesforce also had very clear from the start is burden reduction and unsync of the core version of its product, they achieved that with cloud computing.
With declarative development you have your salesforce instances maintained, upgraded, and extended not one, or two, but three times a year! Packaged up as major releases, full of enhancements and new functionality for you to use.
No need to upgrade, install… anything. With functionality that you develop programmatically, this may require more care & refactoring.
Framework
With the tools that Salesforce gives us to develop with clicks, they provide not only the functionality but the framework to do so. It comes with what we could call forced modularity, which is a good thing in many ways. All of this is including the UI and integrations.
Think about when you change a page layout or via the App Builder, everything keeps working automatically. Providing us with this is no small task.
Instead, when you are developing in code that modularity is something you bake, it’s DIY.
Simpler vs Challenging
The golden rule for me is, to seek the simplest way. If you can achieve it with the ready-baked tools or functionality, go for it. Else, code. With code you have a world of possibilities for customization, yet with clicks you have limitations. However, “just because you can, doesn’t always mean that you should”.
Watch out!
One of the things that often is called out as a benefit of declarative solutions, which I don’t particularly agree with, is the bypass of writing unit tests and worrying about test coverage.
Whilst I understand the thought that in the short term, it saves time to market, it’s quite narrow-minded and also sends out the wrong message.
Testing is essential, that includes unit and integration tests. You must care for your system landscape performance, and have a process in place to test your code continuously. I’d also argue that each functionality you touch should have ready-baked monitoring and alerts. So you can ensure that your applications work as intended as the system and data changes and evolves over time
Conclusion: Focus on Business Needs
Salesforce there are a ton of ‘ready to go’ things, aka Out-of-the-Box functionality. So don’t try to reinvent the wheel and always check what is readily available to you first. Seek native solutions. Don’t waste your time, effort, and IQ with things that already exist and/or are easy to get out of the door. Instead, focus on more interesting and challenging stuff. Over time minimizing technical debt and hassle.
One agile concept is ‘the art of maximizing the amount of work not done’. As a team, you should be asking yourself with every piece of work: What is the simplest thing that could potentially do the job? This is also about the tools and functionality we leverage in Salesforce.
Vivek Abraham is a Pre-Sales Solution Architect at Quality Clouds based in London, UK. Implemented CRM solutions for Recruitment firms in the UK, US and South Africa. Worked with Financial Institutions in the UK and Europe to understand the challenges within their lending, deposits and customer onboarding lines of business and recommended solutions to achieve better operational efficiency by adopting cloud platforms. He has been in the Salesforce ecosystem for over 11 years and has worked in various areas within the businesses such as Pre-Sales, Post Sales, Project Management and Solution Architecture. He has been an early employee at startups and helped the organisations in the Pre-sales and Delivery functions. Vivek earned a Master of Science in IT from the University of the West of England, Bristol and a Bachelor of Engineering from Anna University, India.
