Jun 25, 2020
Introducing the Architect Decision Guides
The Salesforce Platform offers a wide array of tools to build and deliver apps fast. It can be a challenge to understand how to combine these tools and fully unlock the power of the platform and know you’re delivering apps with the best speed, scalability, and features to empower your whole app delivery team to be productive.
How should you evaluate trade-offs and advantages of the wide array of tools available on the Salesforce Platform? How can an architect help their teams and customers choose the right tools for the right tasks? How are teams at Salesforce thinking about these choices and features, and what impact will this have on roadmaps?
We created the Salesforce Architect Decision Guides to help you answer these questions, with the latest information. Today, we’re launching two guides:
Why did we start with these particular guides?
When it comes to record-triggered automation, we’ve introduced many new options and capabilities within different tools. Today, Before-Save Record Change Flow now surpasses Workflow Rules, as the fastest tool for no-code field updates to a single record. And After-Save Record Change Flow addresses many of Process Builder’s greatest flaws, like poor list views, limited decision branching, and abilities to query for other data. We’ve also added transformational functional capabilities to Apex — like Security.stripInaccessible finally going GA, helping enforce field- and object-level data protection. Or, one more thing: you can now create a single invocable Apex action and accept any sObject type as input from a Flow.
When it comes to building forms, we’ve introduced a new low-code solution in Lightning App Builder: Dynamic Forms (available as a non-GA preview in Summer ‘20). With it, you can organize the fields on your record pages directly in your Lightning page, which means you can say goodbye to the page layout editor! Over in Flow Builder, we’ve seen innovation in the form of conditional visibility — supported on all components — and support for LWCs in flow screens. And the LWC framework has welcomed Lightning Message Service, which enables communication between Visualforce and Lightning components, and CSS-only components, which means you can set your styling rules once and use them everywhere.
You can learn all about these new features in the release notes. But the release notes won’t talk about what problems we built different features to solve, or how we recommend you approach integrating features into your overall strategy. That’s where the Salesforce Architect Decision Guides can help.
How to Use These Guides
The Architect decision guides provide up-to-date, transparent assessments of the various form-building and triggered automation tools on the Salesforce Platform from product teams. They also contain general recommendations from those teams about which tools we believe best address different use cases. Our hope is that the information in these guides empowers you to make better, more informed architectural decisions that will set you and your team up for success in the future.
We’ll talk about what you will find in these guides below. But first, let’s talk about what you won’t find:
- Rules that imply all of your choices to-date are wrong. The content in these guides should not be interpreted as a call to refactor existing implementations that work well or abandon architectural decisions you’ve already made. The speed of innovation at Salesforce can be daunting. We’re providing up-to-date information about capabilities that aren’t obvious from other kinds of documentation, combined with insight into the underlying technical choices made by product teams, near-term and long-term. This information should help you make more informed decisions as you move forward.
- Evaluations about troubleshooting, long-term maintenance or governance. We know these are essential parts of choosing the best tools or features to implement, and we hope to provide more resources about these topics in the future. In our first iteration of these decision guides, however, we don’t address them.
We want these guides to be a trusted resource to help you make informed decisions, and give you a clear view into how our product teams think about the capabilities and uses of various features. But it’s up to you to make the ultimate recommendations of what tools, what approaches will best suit the specific needs of the teams, the businesses, the environments, and toolchains you’re building with and for.
Our Approach
Both guides use the same decision-making approach to evaluate tools and make our top line recommendations about tool preference.
Step 1. Identify which tools offer the functionality or level of customization needed to meet your requirements.
Requirements can mean a lot of things. We use a few, specific categories for requirements to help focus this step:
- Functional requirements define what your solution must do. If you’re building forms, functional requirements might include “Create a single screen which allows a service agent to input both Account and Contact fields for new records to be auto-associated with a Case” or “A Guest user must be able access the form in a Community.” For triggers, functional requirements might include, “The record’s field is updated according to this formula” or “The record should not be saved if a valid email address is not included.”
- Performance requirements define how your solution should perform under certain conditions. Performance requirements tend to be top-of-mind for triggered automation use cases, and may include relative requirements like, “The trigger must not add more than a 5% CPU time overhead to a record’s preexisting save order CPU time consumption,” or absolute requirements like, “The trigger must not require more than 4 SOQL statements and 6 DML statements to be issued.”
- Scalability requirements define how well the solution should be able to handle increases in load without impact on performance. For forms, scalability requirements might include, “An end user should not perceive any difference in UI performance, even if 10,000 other users are also filling out the form in their own browsers.” For triggers, scalability requirements might include, “The trigger must support both UI-driven single record updates and API-driven 200 record batch updates.”
Step 2. Choose the tool that allows you to best leverage the available skillsets of your team (now and into the future).
App development and delivery takes a team. Maintaining and iterating on apps takes a team. Sometimes, these teams are made up of the same people. Sometimes they’re not. In order to set every team up for success, you need to evaluate the set of tools you could potentially use to build your solution (the outcome of step 1) with the skillsets on your delivery and maintenance teams. We know there are many ways to build a single solution. We recommend prioritizing the path that makes your teams the most productive.
Here are some things to consider when making your decisions:
- Specialized Skills: Do you know the skill sets on your delivery and maintenance teams? Are there significant differences between teams? What is the capacity for teams to take on new or unfamiliar technologies to gain more skills? Are there non-negotiable pieces of the solution that require teams to demonstrate new skills?
- Delegation of Delivery: Can the solution be broken down into modular requirements? Are you using code to solve complex problems that only code can solve, and using click-based tools to connect your code to a larger, low-code solution?
- Maintainability & Long-Term Ownership: Look forward a few months or a year. If requirements shift for this solution in the future, who do you see on the hook to make those changes? Will the best choice today cause a risk in innovating or modifying the solution in the future? Vice versa? Will your current production support model fit the solution you’re designing or will you need to make changes? What is the most acceptable tradeoff for the business?
A developer deeply skilled in Apex may be best suited to delivering (and maintaining) solutions that address server-side engineering problems. Meanwhile, an experienced Salesforce Admin will probably more deeply understand the needs of the business, and be best suited to deliver and maintain solutions translating business requirements into performant, out-of-the-box Salesforce configurations. A developer with a background in JavaScript might be best suited to delivering and maintaining a custom user interface that takes advantage of web standards, reducing the amount of custom code and streamlining the costs of maintenance. Ideally, how you choose to build your solution enables each team member to play to their greatest strengths — today and tomorrow.
Our Architect decision guides make use-case focused recommendations, using our perspectives on the kinds of skills each tool might require a team member to have, and offer insight into the rationale we used.
Now, let’s take a brief look at each guide.
Architect’s Guide to Building Forms
Salesforce offers a handful of tools to build interactive forms on the Platform, spanning the entire low-code to pro-code continuum.
Representing low-code, Dynamic Forms in Lightning App Builder and Screen Flows in Flow Builder. Hanging out in the middle of the continuum is the ability to extend Screen Flows with Lightning Web Components. And representing pro-code is Lightning Web Components.
The guide examines the functionalities and major considerations when designing a form and which tool works best for each consideration. For example, based on the high-level findings chart below, if you’re building a multi-page, cross-object form that needs to meet sophisticated UX requirements, then your best bet is a screen flow with embedded LWCs.
The guide goes deep into each of these considerations and weighs different options for various potential use cases and requirements. To find out what tool to use for your next form, read the guide here.
Architect’s Guide to Building Record-Triggered Automation
The tools you can use to automate logic on the Salesforce platform have blossomed. Life used to be simple when Workflow Rules were the go-to for a click-based solution and an Apex Trigger was your option for extending with code.
With Flow Builder now supporting almost all record-change triggers across both before and after save order, the ways you can optimize logic with clicks and code is more nuanced. The guide for record-triggered automation looks at the common automation use cases and explores which tool is recommended.
The guide goes deep into each of the tools and listed out some of the pros and cons for each of the tool when weighed against the consideration factors listed above. To find out what tool to use for your next record-triggered automation, read the guide here.
Resources and What To Do Now
- Architect’s Guide to Building Forms
- Architect’s Guide to Building Record-Triggered Automation
- Help us grow these guides! We want your feedback and ideas. You’ll find links at the end of each guide to share your thoughts and tell us about additional content and resources you need to #ReadySetArchitect
