In a prior blog we discussed how to decide between custom development (“code”) and using native Salesforce Force.com configuration (“clicks”). Practically speaking it’s not a decision of using one or the other but a question of
degrees. This post illustrates three Perficient client examples, each highlighting varied amounts of custom development ranging from high to medium to non-existent. Each custom development project fit the need and each client was happy with the outcome. But each also took a very different approach to accomplish their goals.
[ws_table id=”1″]
What are the takeaways?
- It’s not a given that custom development is requiredSalesforce.com had thousands of successful projects and applications before it introduced the ability to write code! Even today, the vast majority of projects do not require custom development.
- Writing code does not mean starting from scratch. Take the best of both worlds.Both examples above illustrate exactly where standard features were used (workflow approvals and opportunity management respectively), but these standard features were enhanced by a process to get a closer fit to the clients’ needs.
- Make a compelling business reason for custom developmentClient 1 and Client 2 had compelling business reasons for custom development, such as lost sales due to slow approvals and bad business decisions that resulted from poor revenue predictability. The value was quantifiable. “It would be nice,” or “The application should work this way,” are not enough on their own to warrant custom development. Perform a gap analysis of what you need versus what Salesforce solutions can provide natively. Then quantify the value of bridging that gap using code.
Happy clicking — or coding — as the case may be!
