Mercury Collective
We were brought into help a client’s early Salesforce implementation just as it was struggling badly and facing significant delays. The project was extremely code-heavy, with hundreds of Apex classes, Lightning Web Components, Visualforce pages, and triggers managed by a developer team.
At the time, the company was attempting to test, validate, and deploy everything to production…but was stuck in an endless cycle of failed test cases, validation errors, and insufficient test coverage.
On top of the technical issues, the client was targeting a pretty aggressive launch date. The deployment required urgent fixes, extensive testing, and coordination. To make matters worse, key developers began quitting suddenly, leaving gaps in knowledge and capacity.
We quickly assessed the codebase and architecture to identify which components truly required custom code and which could be transitioned to Salesforce’s declarative, point-and-click features.
We discovered that a particularly complex and critical decisioning process… involving dozens of criteria, actions, and third-party API calls… could actually be transitioned to Process Builder.
We built a small proof of concept in just a couple of days. The client reviewed it, loved it, and agreed to move forward with this as a temporary solution to help them hit their launch date… with the understanding that it could later be rewritten in code.
The client successfully launched their Salesforce implementation… months later than originally planned, but still months ahead of where their original approach was heading.
The Process Builder solution we created ran smoothly, supporting their critical decisioning process. Interestingly, several years later, our client is still using the same process… although now migrated from Process Builder to Flow Builder…without ever needing to convert it back to code.
One key lesson from this project: when an implementation is led by code-centric developers, the solution tends to be code-centric…often unnecessarily so.
When using Salesforce, the best practice is to fully leverage the platform’s declarative capabilities first. If code is required, it should supplement declarative functionality, not replace it entirely.
Every implementation or project is different, but we recommend aiming for a ~90% declarative and ~10% code approach… if code is even necessary, which many times it is not.
Efficiency is crucial for a nationwide field services company, where every minute matters. We helped our client create a streamlined timecard process that saves time while improving accuracy. Our approach transformed how field employees log hours, reducing administrative burdens and allowing teams to focus on their strengths.