Lattice Squad was involved in developing a custom app on Salesforce for a healthcare provider. Many business processes were done manually: documenting what changed and notifying the required stakeholders using chatter. It was loud and clear that this was an automation heavy project.
The most significant decision of the project was staffing the project with the right technical skillset. The dilemma we faced on this project was to recruit apex-heavy programmers(code) or declarative programmers(clicks)
Code or Clicks: Salesforce Flows provides a declarative interface called Flow Builder to automate business processes. Flow Builder is used to building code-like logic without using programming logic. Apex, on the other hand, is a Salesforce programming language. It provides a more rich feature set than Flows. The majority of the automation tasks can be done using Flows. Learning to code in Apex has a steeper learning curve than learning Flow Builder. At the end of 2022, Salesforce will retire Workflow Rules and Process Builder automation. Depending on the technical demands of the project, we might have to use both.
Begin with the end in mind (Stephen Covey’s Habit 2): The SOW of the project should give you a general understanding of the skill set required for the project. During the end of discovery and design, we get a better understanding of the precise technical skillset. This project had a heavy dose of automation that could be done with Flows. A few complex automation required apex batch jobs and apex triggers. It was clear that 80% of the skillset revolved around a thorough understanding of Flow Builder and the rest 20% around apex for more complex processing. Ideally, we would need two candidates, both very good with Flows and Apex. Since 80% of the work revolved around Flows, we wanted both candidates to be good in Flows, but one should have a thorough Apex experience. Having this clarity helped us in finding suitable candidates.
Client-Centric Approach to selecting suitable candidates: What we have seen in interviews is candidates respond well to scenario-based challenges. We always ask open-ended questions like what Gotchas they look out for in Flows. This gives insight into the practical problems they faced with the development and how they went about solving them. Before Winter 23, the IN clause was not supported. Due to this, apex invocable action was called to perform this action using SOQL. Perspectives like these make selecting a particular candidate less subjective.
Conclusion: A good understanding of the technical demands of the project goes a long way in selecting suitable candidates. The attitude of the candidates matters immensely as well. At Lattice Squad, we think carefully about what we develop and who we recruit. Developing Apex code when it’s not required adds budget to future maintainability. Selecting suitable candidates for automation-heavy projects requires your staff to ask thoughtful scenario-based questions. We get to know how a candidate responds to a challenge they might likely face in the project, and the candidate also appreciates what he can expect to solve in the project.
