Best Practices for Continuous No-Code Development in Salesforce
Introduction
In a recent podcast with Miry, we talked about the best practices for continuous no-code development in Salesforce. She used Salesforce extremely well and had a lot of expertise.
Podcast (audio media) isn’t as googleability (searchable), so I’ve compiled my own essentials.
Best practices
As her company’s business has grown, she has leveraged Salesforce to grow her business systems. The three best practices are summarized below.
- No-Coding Rule
- Documentation
- Refactoring
Below, I describe each practice in detail.
No-Coding Rule
As with Pro-Code, it’s important to make design guidelines for No-Code as well. There are various things to be included in the no-coding rules. For example, the order of priority for trigger processing.
The priority order of the trigger processing is as follows.
- mathematical expresssion
- workflow rule
- Process
- Flow
- Apex Trigger
The reason for this priority order is so that Salesforce Admins, who is not a Salesforce developers, can understand and setup. This will allow business personnel who cannot program to change settings. Persons who understands the business can setup requirements quickly and appropriately.
Why do we need these rules?
Because if you don’t define these rules, developers will develop in pro code. This would limit the area that Salesforce Admin can understand and setup. Therefore, it’s important that members understand this policy, including its background, and define specific rules.
Documentation
Sometimes they get changed to sub-optimal settings because Salesforce settings are so easy to change. Continuing to use suboptimal settings will cause a negative chain of events.
You won’t know the current settings of your Salesforce organization. If someone with a good memory knows everything and handles it all, you can still keep it manageable. But when that person can’t remember or another person has to manage it, the problem comes to the surface.
In this situation, you can’t easily change the current settings because you don’t know how it was set up. And the following problems occur.
Firstly, it takes time to change the settings because you need to review the history and investigate the scope of impact to change the existing settings. Unfortunately, it’s hard to find the relevant settings in Salesforce.
Secondly, such research and review is skipped. Often they are too busy to investigate enough and end up setting up sub-optimal settings, leaving them to optimize. However, these remaining tasks will never be completed.
Finally, the more you repeat the sub-optimal settings, the more complex the settings become. The more complex settings are less maintainable and the performance is degraded.
In this way, the setup grows in size and complexity every day. So how can you avoid this situation?
There is no one-size-fits-all “silver bullet” solution to this problem. There is only steady engineering.
This problem is less likely to occur if the documentation includes settings and past history. Also, once the document is written, we can share our knowledge by reviewing and sharing the document.
We are busy working every day. And before we know it, the setting becomes bloated and complex. To prevent this from happening, we need to document and organize our settings on a daily basis.
Without documentation, we would have a lot of wasteful settings because we wouldn’t understand our current settings. But with documentation, we can understand our current settings and optimize it.
As a result, we can keep our settings organized.
Refactoring
As I mentioned in the documentation practices above, it’s important to keep a high maintainability in order to continue no-code development.
However, even if you are careful on a daily basis, you will need to organize your settings. That happens due to changes in the external environment, such as business changes and new features being released.
Therefore, we need to take the time periodically and review our existing settings and items, called “Refactoring”.
Refactoring involves the following
- check for settings and items that are no longer needed
- consider whether the bloated and complex settings can be fixed with simple settings.
- consider whether new features are available
Salesforce settings need to be fixed as you run with the business. It’s better to optimize your setup once the business changes have settled in. It’s important to balance maintenance and speed of development by refactoring at the right time.
Future Issues
There are two future issues to continuous no-code development in Salesforce.
Testing
As Miry-san mentioned, In no-code development, testing is limited to manual testing. The more features you develop, the more scope of regression testing you will have to do. As a result, the workload is increasing rapidly.
It’s important to replace some of the manual testing with automated testing through the use of test automation tools.
Software Configuration Management
There are challenges in how to implement software configuration management of Salesforce settings. SalesforceDX is enabling metadata handling and source code management. However, it’s still a feature for salesforce developers and is difficult for salesforce administrator to use.
As SalesforceDX expands, Salesforce Admin will become easier to use as well. But until then, we’ll have to be creative to get through it.
Conclusion
In this post, I instroduced no-coding rules, documentation and refactoring as best practices for Continuous No-Code Development.
The consistent idea is to empower Salesforce Admin by adoptiong an engineering approach. As Salesforce Platform becomes more and more powerful, business requirements will be easier to develop. Therefore, Salesforce No-Code Development with Salesforce Admin will become more prevalent.
However, the development model for no-code development is not yet mature. I think it’s important for these best practices to accumulate.
This post is a translation of the following post.
