Make Solutions Easy
Learning Objectives
After completing this unit, you’ll be able to:
- Explain the importance of building an easy solution.
- Follow Salesforce Well-Architected best practices for building a solution that is easy to use, easy to maintain, and easy to adopt.
Why Is Easy Important?
In this unit, you explore the key elements of creating a Salesforce solution that delivers value fast. That said, the flexibility of the Salesforce Platform and the various automation tools available can make finding the right balance between simplicity and functionality tricky.
To create architectures that are easy to use (and easy to maintain), you must understand your business priorities and your users' needs, preferences, and daily tasks. You must also know the strengths and weaknesses of your delivery and maintenance teams.
Be prepared to have difficult trade-off analyses and conversations with your users. The architecture you design should be easy to use, but that doesn’t mean that your job is easy!
An easy solution enables businesses to operate more efficiently and effectively on the Salesforce platform by behaving in ways that are intentional, automated and engaging.
Intentional Solutions Deliver Business Value Immediately and Over Time
To build an intentional solution prioritize three dimensions: strategy, maintainability, and readability. Intentional architectures are planned and delivered strategically, can be maintained effectively, and are easy for humans to read and understand.
Automated Solutions Meet Goals and Objectives Faster, at Scale
Automation plays a pivotal role in simplifying tasks, allowing work to be completed faster and on a larger scale. To build an automated solution prioritize two dimensions: efficiency and data integrity. This not only conserves time and resources but also empowers businesses to adapt to rapidly evolving market demands.
Engaging Solutions Delight Users and Drive Adoption
Your solution only delivers value if it’s being used! To build an engaging solution ensure your design is streamlined and helpful. When you do, your solution has a greater chance at achieving higher adoption. This only comes with a thorough understanding of business priorities, user requirements, and team capabilities.
You might be wondering how you know if you’re thinking about the dimensions highlighted above in the right way. Never fear, Salesforce Well-Architected has you covered here. There are a series of key concepts architects need to consider when designing easy solutions. In the next section we’ll cover the patterns you can follow to ensure you’re considering all the right things!
Follow Well-Architected Best Practices to Build an Easy Solution
Below is a list of best practices for building an easy solution. This isn’t an exhaustive list, but something to help get you started. Always refer to the easy patterns and anti-patterns as you roadmap and design your solution.
Intentional Patterns
This table shows you a few examples of what good looks like when designing a solution that delivers business value immediately and over time. It also shows you the location where you can look for the presence (or absence) of the pattern, and how this pattern maps to the dimensions, linked first, and considerations, linked second, in the Well-Architected white papers where you can learn more.
Patterns: What Does a Good Pattern Look Like? |
Location: Where to Look? |
Resources: Learn More About Dimensions | Considerations |
---|---|---|
Requests for features are prioritized based on business impact, amount of new work required to deliver, and amount of work required to maintain. |
In your company |
|
Roadmaps show prerequisites and dependencies. |
In your roadmap |
|
Hot-fixes have a clear path to production. |
In your business |
|
Code and declarative customizations have consistent, human-readable names. |
In your org |
|
Diagrams for business capabilities and technical implementation details exist for all solutions. |
In your business |
|
No code exists to override standard page view mechanisms. |
In your org |
|
KPIs for pre/post tech debt remediation are clearly documented. |
In your decision records |
Automated Patterns
This table shows you a few examples of what good looks like when designing a solution that delights users and drives adoption. It also shows you the location where you can look for the presence (or absence) of the pattern, and how this pattern maps to the dimensions and considerations in the Well-Architected white papers where you can learn more.
Patterns: What Does a Good Pattern Look Like? |
Location: Where to Look? |
Resources: Learn More About Dimensions | Considerations |
---|---|---|
Each flow serves a single, specific purpose |
In your flow |
|
SOQL statements are selective. Comparison operators use positive logic ( `INCLUDES`, `IN`) as primary or only logic in SOQL statements. |
In your Apex |
|
Outputs for every automation are measurable and timebound. |
In your documentation |
|
All flows launched in user context abstract all system context transactions to subflows, which are consistently placed after a Pause element, to create a new transaction. |
In your flow |
|
Code wraps all DML, SOQL, callouts, and other critical process steps in try-catch blocks. |
In your Apex |
Engaging Patterns
This table shows you a few examples of what good looks like when designing a solution that operates efficiently and dependably. It also shows you the location where you can look for the presence (or absence) of the pattern, and how this pattern maps to the dimensions, linked first, and considerations, linked second, in the Well-Architected white papers where you can learn more.
Patterns: What Does a Good Pattern Look Like? |
Location: Where to Look? |
Resources: Learn More About Dimensions | Considerations |
---|---|---|
No generative responses are sent directly to end users without points of human involvement. |
In your apps |
|
The setting for Delay Between In-App Guidance uses the default value or a custom value that is longer than the default (24-hour) period provided by Salesforce. |
In your org |
|
Path celebrations are enabled only with user consent. |
In your org |
|
No apps have “Disable end user personalization of nav items in this app” set to true. |
In your org |
|
Data entry errors appear before users navigate away or submit data. |
In your apps |
In the next unit, you learn about what it means to make an adaptable solution.