Salesforce offers us a plethora of options when designing solutions on the Salesforce platform; the challenge lies in choosing the right solution and the right tool. When there are multiple options, how do we ensure we choose the one that allows us to build a scalable futureproof environment?
For example, if we were to take a simple requirement of updating a child record upon editing the parent, we could go down two routes: Flow or Apex. They are both viable – but how do we know which is best? Until now this decision has been the sole responsibility of the System Admin/Consultant/Architect based upon previous knowledge and understanding of the platform.
In this post we’re going to break down a new initiative from Salesforce called ‘Architect Decision Guides’ which makes deciding which road to go down much easier.
Legacy Salesforce Restrictions
Over the past few years Salesforce has undergone many changes and enhancements; we are now a long way from the Classic experience many are familiar with. Back when Classic was the primary focus, the biggest automation challenge was deciding whether to use Workflow or Apex (all that existed).
Here’s a little throwback to Classic if you don’t know what i’m referring to:
In Classic there was a need for a lot more custom development and Apex, resulting in code which is now obsolete and hard to maintain. Salesforce recognised this gap and has empowered non-developers to declaratively achieve much functionality that used to be exclusively available using Apex.
Prior to Lightning, if you mentioned Flow to someone, they would either pretend they didn’t hear you or run away and hide (this has actually happened). This was because Flow was so difficult to understand and very technical with a confusing interface and terminology that wasn’t familiar such as “variables”, “loops”, and “collections”. Now, Flow is easier and more powerful than ever before, removing the need for unnecessary Apex. , bridging the gap between declarative and programmatic builders (low-code vs. pro-code).
To support you further, Salesforce has introduced Architect Decision Guides, to help you follow best practice and consider all potential scenarios which may arise.
What are Architect Decision Guides?
Currently there are three decision guides available from Salesforce: Architect’s Guide to Building Forms, Architect’s Guide to Building Record-Triggered Automation and An Architect’s Guide to Migrating Changes Between Salesforce Environments. Each guide goes into great depth around all the functionality available on the platform for each topic and the best feature to use depending on your requirement.
As a Solution Architect it’s very easy to make decisions under pressure that may have unintended consequences you hadn’t anticipated. These guides are continuously updated, enabling you to remain up to date with the changes in each Salesforce release. You might think simply reading the release notes would navigate this, but this isn’t the case as Salesforce explains:
“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.”
Source: Introduction to Architect Decision Guides: Design Scalable, Futureproof Solutions
Whilst these guides are designed to help us make the most informed decision, they do not remove the need for you to understand your clients requirement or your environment. There are other factors highlighted by Salesforce such as performance and scalability requirements which should always be in the forefront of your mind when designing solutions. This, alongside the guides, will allow us to deliver world class solutions for our clients.
Architect’s Guide to Building Forms
Usability and user experience are currently at the forefront of our minds. Lightning experience has opened up a whole new world with features such as lightning pages, flows and lightning components that mean we can deliver great solutions that also look great! The Classic user interface was extremely limited, with Lightning, we have far greater flexibility and attractive design options.
The Architect’s Guide to Building Forms focuses on building forms within the platform using features such as Dynamic Forms (Lightning Pages) and Lightning Web Components. Let’s look at the example table:
Each table is presented in matrix format, from Low Code through to Pro Code, and explains what each functionality allows in terms of requirements.
You can see at a glance we are able to make a decision fairly quickly on the best approach just by using this. If I need pixel-perfect styling then Dynamic Forms and Screen Flow wouldn’t be an option. I could either use Screen Flow plus LWC or just LWC.
Including future features on the roadmap is also a welcome addition.
A Diving Deeper table on the guide goes into even more depth if required. There are also some useful charts which will be great to assist conversations with clients.
If your client is continuously talking about UX, then having these tables at the ready will be a great asset to explain the trade-offs and effort involved if they’re not willing to accept alternatives.
As well as this base level information, there are questions included in each guide that should be part of your requirements gathering. Do I need to integrate with external systems? What are the reusability requirements? What are the validation requirements? All great, thought provoking points, that need to be a staple for all requirements gathering.
Architect’s Guide to Building Record-Triggered Automation
An area I have personally struggled with in the past is record automation. I don’t write code so I have typically swayed away from Apex, but as an architect, it is important to understand the abilities of declarative vs code in order to make the right decision. As I mentioned above, Flow has become a much more powerful tool, allowing Admins and non code writers to achieve results that previously only Apex could do. This guide breaks down a lot of common use cases and advises which tool would be best.
The guide offers some key take-aways which are important for all:
Salesforce have stated Flow is the de-facto for process automation on the Salesforce platform, especially with their plans to retire Workflow Rules and Process Builder. The guide covers some great points which highlight current flaws with Workflows and Process Builder.
The guide also offers great content around bulkification and best practices if you’re familiar with Flow. If you’re not then I fully suggest looking at some additional resources around Flow such as Trailhead. There also some great blogs and posts covering all that Flow is capable of.
The guide is not only focused on Flow but also the use of Triggers and Apex as shown in the matrix table below:
From Low Code through to Pro Code, these tables are great at helping you ask the right questions and select the right tool for the job.
Architect’s Guide to Migrating Changes
It’s great that we can develop and build all this amazing functionality within the Salesforce platform, but how do we deploy it? How do we ensure that everything we’ve built migrates to various environments and ends up in production without any issues? The “Architect’s Guide to Migrating Changes” focuses on the multiple ways of migrating changes and the pros/cons of each approach. Gone are the days of spending hours staring at the deployment fish through change sets as we push towards a more DevOps orientated approach. Again, whilst this guide offers pros and cons, each architect should assess their own approach after reviewing their environment and make their own decision.
Each migration option is broken down into the spectrum below:
The guide explains that as you move from left to right on the spectrum, you:
- give up some simplicity but gain more scalability
- move into areas of the platform that are changing faster
- increase the level of technical skill required
- spend more time on the process than the product
- encounter barriers to further motion rightward on the spectrum
This guide will be very useful for those undertaking large projects; typically the larger the project, the more focus there will be around deployment and DevOps. If you’re running a 10 day project, you are much more likely to be on the left hand side of scale, as the time and effort required to go down a full DevOps approach cannot be justified.
Salesforce has taken great steps to improve the ways in which we develop on the platform and push those changes through to production (scratch orgs for example which are mentioned in the guide). I’m sure most of you reading this will have worked very late nights trying to fix change set errors, but the future is bright. I truly believe that all projects going forward should include basic DevOps and this is one area to upskill if you’re a Salesforce Admin or haven’t learnt about DevOps yet. As always, Salesforce has a great Trailhead on this topic here.
Each approach on the scale is fully detailed within the guide and breaks down the following areas:
- Limitations
- Why you might not choose it
- Why you might choose it
- Risk mitigation
I highly recommend giving this guide a read if you have not yet ventured into the world of DevOps or are looking to step up your deployment game. I have seen first hand on larger projects the benefits that a streamlined deployment strategy provides, especially at scale. There are also some handy tips around sandbox uses, as well as working examples which are worth a look. If you can take a step away from manual changes and change sets, you’ll see the benefits.
Summary
Whilst these guides are great, there are only a few available, and I can think of many enhancements I would like to see in the future.
The guides are aimed at experienced users of the platform and more examples of real life requirements or case studies would better help newer Admins and Architects.
Having examples of failed delivery, or where the most optimal approach wasn’t taken and the subsequent consequences of that decision, would further help others avoid making the same mistake.
In addition, it would be good to include video content, as there is a large amount of text, which is not ideal for everyone and definitely not for the visual learner.
Some guides I would love to see:
- Integration Approaches (The best integration approach depending on your requirement and the data required)
- Permissions (Choosing the best permission setup for your requirement and Permission Set Vs Profile)
- Which Cloud (Useful at the very beginning of discovery, highlighting key requirements and indicating which clouds/licenses would be needed)
I think Salesforce is 100% on the right track with these guides and can’t wait to see more of them in the future. If you’re new to Salesforce, these guides will provide a great starting place to get you on the right track. I’d love to know what you think of these? Are they useful?
Comments: