Back in 2009, on one of our very first Salesforce projects, we started a partnership with a well-known Bay Area energy company in need of custom enhancements for its Salesforce org. We looked over the existing system, made estimates, outlined a proposal for the project, and began work. The client was excited about the new interfaces under development, and we were excited to deliver them.
Following our standard process, we built the intended enhancements in her team’s sandbox and presented them to our client, who approved them for deployment. We were ready for launch! And that’s when we learned one of our first big Salesforce lessons.
Oversight #1: Skipping a Deep Dive into the Org
It turned out we were not the first custom developers to build castles in this sandbox; other kids left some of their toys behind buried in the sand. When we attempted to deploy our code, we found the org littered with hidden undeployed Apex code. We couldn’t deploy our own code due to failing test classes in the sandbox. As we were on the hook for the project, we had to fix all of the other issues without access to the previous developers. It was a huge mess, and we lost the trust of our client, who had put her faith in us to handle her deployment smoothly.
Oversight #2: Failing to Check for Outdated Resources
In 2017 (ouch! you read it here), we received another gift from the ghosts of Salesforce developers past. A dynamic East Coast media organization approached our team, seeking new Visualforce pages for its Salesforce org. Far wiser now, we studied the company’s system carefully. We realized early on that in order to deliver the pages successfully, we’d need an increased budget and the opportunity to refactor existing work within the org. Our client went to bat for us when presenting the issue to their management and earned a budget increase for the project. We were off to the races. And then…
We realized that the client’s Salesforce API hadn’t been kept updated by previous developers, an uncommon and unexpected problem. In other words, the plans we’d made to refactor their code would not be viable without, you guessed it, another budget increase and additional project risk.
This was a huge error on our part and a terribly unfortunate situation for our client. Not only could we not get the work accomplished, but the client had to return to their own management team after advocating for our work and deliver the bad news. Explaining how we missed this minor detail didn’t go over well. We lost the client’s trust, and we completely understand why.
An Evolving Salesforce Consulting Process
It’s important that my team and I learn from our mistakes quickly and use these lessons to enhance our consulting and development on the platform — Salesforce is a massive platform. Our team has worked in orgs dating as far back as 2003, and we’ve encountered our fair share of complexities and challenges. As we aim to take great care of each and every one of our clients, we take every lesson learned seriously.
Over the last nine years, we’ve developed a strict business analysis and estimation process for our projects: We investigate and plan carefully for new custom code, and we talk with prospective clients about any pitfalls we perceive. These challenges can include undeployed code, deprecated features like S-Controls, API version risks, outdated security protocols, and more. We carefully document all relevant assumptions and excluded areas of functionality in our proposals, and we encourage open communication with clients when these need further explanation. As a result, our mistakes on the platform have led us to greater success and more transparent client relationships.
What’s the biggest mistake you’ve made in Salesforce, and how did you overcome it? Share your story in a comment below.
