10 Steps to Developing Salesforce Solution Designs

Solution design is a crucial part of Salesforce projects. Crafting well-architected Salesforce solutions is no small task, but it can be broken down into manageable steps. Structuring your solution design process can help you produce more thoughtful designs and streamline how your team collaborates throughout the discovery and design phases of work.

This article provides a ten-step roadmap for architects, providing a structured process to tackle Salesforce solution design. We’ll discuss the process from requirements elicitation through to solution validation, and all the interim steps you’ll need to successfully steer your team towards implementation.

After reading this article, you’ll be equipped with a practical framework to take into your Salesforce projects. 

1. Requirements Elicitation 

First things first: the client’s functional and non-functional requirements should be elicited and documented in common formats such as process flows and user stories. Requirements elicitation is the backbone of discovery and sets the stage for future solution design work. Without quality requirements, you cannot design solutions that add value to the business. 

Your set of business requirements should contain, at a minimum:

• Organogram/stakeholder map with managerial reporting lines
• Business process diagrams
• Conceptual models
• Personas
• Epics
• User stories
• User acceptance criteria

Be sure that your requirements are of high quality before proceeding to validate them with the client. Quality user stories that allow you to scaffold a well-architected solution should:

• Be mutually exclusive but collectively exhaustive. 
• Exhibit both utility and reliability.
• Follow consistent standards, such as the common user story “As a [persona], I want to [action], so that I can [objective]” syntax, and the INVEST framework.
• Contain comprehensive user acceptance criteria.
• Detail any assumptions that underpin the requirement.

Once your corpus of business requirements is complete (elicited and formally documented), you can move on to requirements validation!

2. Requirements Validation 

Equipped with a high-quality set of business requirements, you are ready to return to your client for validation. Requirements validation is a significant project milestone wherein the client agrees that you have correctly articulated their business needs. 

Once requirements are signed off, any evolution of, explicit changes to, omission of, or addition of requirements should result in a change of the implementation scope of work. Requirements validation also gives you – the solutions architect – confirmation that you can confidently begin solution design against the set of documented user stories. 

Best practices for requirements validation include:

• Validate process flows, personas, epics, and user stories: these critical artifacts will underpin solution design and influence all stakeholder’s understanding of the business. It’s crucial that service providers and client-side teams have a shared understanding of the process by which the business operates, who it serves, and what requirements will be met as a product of the service. 
• Expect and welcome feedback: Anticipate and welcome changes; they demonstrate that the client is engaged. Factor in time and budget to rework, and revalidate your requirements. 
• Track changes: Requirements traceability is an important part of resolving scope issues. It’s common for debates to occur during the validation process, and sometimes the outcome is contested. Ensure that important decisions are tracked on each user story ticket to mitigate future scope creep.
• Earmark show-stoppers: Have the client highlight requirements that are critical for going live. Understanding critical requirements from the start will help you weigh solution design options and plan for implementation. 
• Require written sign-off: Receiving sign-off in writing is an important contractual milestone that formalizes, for both parties, that the requirements are agreed upon. You should not proceed to solution design until you have signed off on requirements. 

3. Managing Scope 

Now that you’ve got a set of quality, validated requirements, it’s time to trim the scope, leaving only essential items for solution design. Pruning requirements at this stage in the process will ensure the team is laser-focused on the work that will add the most value to the business now. 

To manage scope pre-solution design, backlog any requirements that…

• Are explicitly out of scope (i.e. serve functional/technical areas that have been descoped).
• Do not directly support the mission or vision of the particular project.
• Are low(er) priority and liable to change (thus presenting risks to the project without adding significant value).

4. Solution “Matching” 

One of the beautiful parts of working on Salesforce is that the platform has developed significant off-the-shelf functionality to service a variety of use cases. We don’t always have to reinvent the wheel – and indeed we shouldn’t. The first phase of solution design can be thought of as solution “matching”. What can we accomplish with Salesforce out-of-the-box, with no – or very minor – configuration changes?

During solution matching, one should keep an eye out for requirements that can be mostly solved with Salesforce OOB functionality or may be solved by standard functionality slated for an upcoming major release. It’s worth asking if meeting 80% of the requirement for a fraction of the cost, or waiting a few months to meet the requirement makes sense for the client. 

Solution matching can be beneficial by:

• Reminding teams to work with a platform-first mentality.
• Platform improvements that are shipped consistently over time through Major Releases 
• Keeping solution design simple.
• Minimizing maintenance costs associated with custom features.
• Minimizing technical debt as the org matures by reducing redundancy between custom and standard features.
• Reducing the overall architect’s level of effort.

Here are some examples of solution matching in action:

If your team is short on solutions architect capacity, solutions matching could be executed by a technical business analyst with Salesforce platform experience. 

5. Gap Analysis 

Matching requirements with OOB Salesforce features could cover a significant portion of your user stories. However, there will likely still be user stories that require more attention. These requirements will need to be accounted for using third-party tools or custom designs. 

A gap analysis does not necessarily need to be performed by the solutions architect. A technical business analyst or consultant should be able to surface the set of user stories that require focused architect attention. 

6. Consider Third-Party Tools 

Composability is the process of creating complex systems by combining smaller, pre-existing components, instead of starting from scratch. Before opting to design and deliver custom solutions, it is in the client’s best interest for the design team to explore existing third-party tools and applications from the AppExchange that may meet their requirements. 

Leveraging existing managed packages presents a number of benefits:

• Potential cost and time-saving for the client, compared to the development and maintenance of custom solutions.
• Product improvements are shipped consistently over time through new releases. 
• Many third-party tools provide customer support options to assist with the administration of the product. 

As Salesforce professionals, we are lucky to have access to a vast array of products available in the ecosystem. Leveraging existing innovation is an important part of designing scalable architectures. AppExchange products may not always be the answer, but exploring and evaluating your options is an important due diligence step.  

7. High-Level Solution Design

Finally – custom solution design. Once requirements have been narrowed to a subset that actually requires custom development, solution design becomes a much more manageable task. 

Custom solution design is executed by the architect(s) and should remain at a high level at this point in the process. High-level solution design captures the tools (i.e. Flow vs OmniScript), critical metadata components, general logic, and overarching approach to fulfill the requirements. 

It should present contestable design decisions where applicable – complete the pros, cons, and assumptions of each option. It should clearly outline the limitations of the proposed approach(es), and provide estimated Level of Effort (LOE) estimates for implementation.  

Keeping custom solution design set at a high level gives the client an opportunity to provide feedback, consider limitations, and ultimately make informed decisions about their system before time and budget is spent on low-level design work. The purpose of high-level solution design is to equip the client to take ownership of a solution that meets their needs. 

Don’t forget to document your architectural decisions and use templates where possible to ensure the designs are consistently notated. 

8. Solution Validation

Similarly to validating your requirements sets the stage for solution design, validating your solution sets the stage for implementation. Equally, solution validation constitutes an important project milestone in which the proposed technical solution is approved by the client. After the solution has been signed off, any changes may result in a change to the implementation scope of work.

Solution validation can be approached via a “solution playback” – a facilitated session in which the client is walked through how the technical solution meets the functional requirements. 

Further technical details can be detailed in shared documentation. Generally, solution playbacks include both technical and business stakeholders.  A “perfect” design doesn’t exist, so slating time for questions, feedback, and potential revisions to the design is an important part of your workflow. 

Check out this template Narrative Salesforce Solution Proposal to save time on solution playbacks!

Some best practices for solution playbacks include:

• Tether the solution to the vision: If you set a vision at the beginning of the project, explain how the proposed solution speaks to the client’s vision for the system. 
• Focus on value delivery: Ultimately, the client wants to know how a solution meets their needs; save the ultra-technical details for your documentation. 
• Situate the solution in the roadmap: Explain how the proposed solution speaks to the client’s long-term development roadmap and why the solution is fit for purpose now. 
• Communicate assumptions: Clearly articulate any technical (i.e. data volumes) and business (i.e. process-oriented) assumptions that underpin proposed solutions.
• Communicate limitations: Don’t shy away from talking about limitations. Practice a transparency-first approach to discussing limitations, empowering the client to take ownership of their solution. 
• Expect and welcome feedback: Approach solution playbacks with a partnership mentality. Be open to workshopping ideas and changing tack. Don’t forget to give the client time to digest the proposed solution, and its pros and cons. 
• Track decisions: To support requirements traceability, ensure key decisions relating to solution design are tracked, including the considered alternatives, why a particular decision was taken, who was responsible for the decision, any possible risks, and the date the decision was taken. 
• Require written sign-off: Receiving sign-off in writing is an important contractual milestone that formalizes, for both parties, that consensus on solutions has been reached. Low-level solution design shouldn’t proceed until written validation has been received. 

Once the high-level solution has been validated, you are ready to move on to planning for an implementation phase of work. 

9. Implementation Planning

After your high-level solutions have been validated, planning for implementation can begin. Planning for implementation finalizing the scope of work and defining the project management and DevOps practices your team will leverage. 

During the implementation-planning process, requirements and their related solutions should be prioritized according to impact and effort. “Major Projects” and “Quick Wins” should be prioritized, and “Fill Ins” can be included should the budget allow, but can otherwise be backlogged. Any solutions that are difficult to implement and offer less value can be backlogged or eliminated entirely. 

The implementation-planning process is complete when an implementation Scope of Work (SOW) is drafted and signed. This SOW should outline the estimated budget, anticipated timeline, and the features that are agreed upon for delivery. 

Once the SOW is drafted and the project team has clarity on the exact requirements for inclusion, the architect(s) can do low-level solution design. 

10. Low-Level Solution Design 

While the purpose of high-level solution design is to equip the client to take ownership of a solution that meets their needs, the purpose of low-level solution design is to equip your team to deliver the solution. 

Your low-level solution design is the instruction manual for build. It should contain granular design specs for objects and fields, automation, object permissions, record access, etc. It should also contain a set of configuration notes for the technical consultant/developer to approach building. Remember that comprehensive testing steps should also be drafted against each requirement to ensure it meets users’ needs. 

Final Thoughts

Breaking down solution design into manageable components is the first step in simplifying what can be an overwhelming process. Take your solution designs step by step to ensure they are complete, thoughtful, and well conceptualized – and that you are only focused on what matters.  

Remember that at a high level, you can reduce the volume of requirements you custom solution design for by managing your scope early, engaging in a thorough solution “matching” exercise to leverage as much of the standard platform as possible, and considering third-party tools in lieu of custom features.

Following this ten-step framework should ensure that each aspect of your solution design is validated and leverages Salesforce best practices. By structuring the process in this fashion, you can also delegate certain tasks to non-architect resources (based on your team’s competencies) to make your team more effective. 

Keeping tabs on your team’s ability to advance through each step in this process can help project managers see where your team struggles and excels, ultimately resulting in improvements to the effectiveness of your team over time.