Recipe For Happy Salesforce Org

Hello Ohana,

Hope you are all keeping yourself safe and healthy and taking some time out for yourself apart from your Salesforce Love.

I know there are many people like me who are always in constant search of Best practices and ways to keep your organisations' Salesforce Org/Orgs Healthy and scalable.

In this article, I will list down some practices which I follow and found super useful in keeping my company's Org tidy and scalable. I will cover the individual topics in detail if I get some support from the audience.

Sprint/Agile/Scrum

• Use any Agile tool like Jira/ Asana etc
• Prepare Backlog for your project
• Do Backlog Refinement Sessions, we use the poker technique and there are many free and paid software to support this. This technique I personally found very engaging and fun.
• Do a sprint planning session before you start your sprint and pull tickets from backlog to sprint based on capacity and priority
• Keep things simple and transparent

Project Documentation

• I have seen many projects where people just keep on building things without documentation and it haunts them later. People leave projects and organisations but Documentation stays. Detailed documentation is best but you can start with basic documentation at least.
• My personal favourite is Confluence but you can use any tool like Repository (bitbucket, GitHub), Word Doc, open-source documentation tools etc.

Release Guideline:

I know on this point every company struggles. Here are some tips

• Prepare a release calendar for 1 year and publish it within the team and to all stack holders
• Setup Daily Release (to cover Hotfix, Admin Changes), Sprint Release (For small implementations), Quarterly release/ Major Release (For Big project release)
• Communicate all changes which will impact users before deploying changes. This will prepare them for upcoming changes. Organise training if required.

Defined Development Lifecycle

Every company has some development lifecycle knowingly or unknowingly. Identifying and setting up a guideline can give you and your team a clear understanding of what to do and what not to do.

• Planning
• Designing
• Development
• Testing
• Release
• Post Release

DevOps Automation is a must

If you have not invested in DevOps yet, trust me it's time to do that. You can achieve very good DevOps at a very minimum cost and can go for expensive but highly customisable App exchange solutions.

I did set up DevOps multiple times for many organisations and I found that there is plenty of open-source or low-cost software which can fulfil almost all DevOps needs. You need to invest in research but it is worth it by all means. Some tools are (Teamcity, Jenkins, Sonarcloud)

Below is the flow that We are using in our project

System Admin profile is for only System Admins

No matter how you want to explain but there are no reasons for anyone except System admins to have System admin profiles.

There are several disadvantages and risks associated with assigning system admin profiles to Developers, BA's, Product Owners.

You can create these users in production as inactive System admin users and by using the Post sandbox refresh script you can make them active. This will give them the freedom to do development in the sandbox without exposing production.

Development Best Practice Guideline

By now everyone in the industry understands how crucial Best practice Guideline is. You can find plenty of documentation about it from Salesforce, Industry experts, Bloggers etc.

Some of my favourites are:

• Adopt a baseline architecture for Apex, Flow, Lwc. Some examples are Enterprise patterns, Solid Patterns. These patterns make sure that you do customisations in your system with scalability and maintainability in mind. These patterns bring all of your Developers and admin on the same page as to how to do customisations and increase understanding across the team.

Code Review Guideline

Code review is undoubtedly an integral part of any Development lifecycle. But making it consistent is equally important. some benefits of review guidelines include

• Clear expectations from reviewer and PR submitter
• Fix set of criteria against which PR gets validated.
• Clear guidelines prevent PR from being just a formality.

A few examples steps of guidelines include

• Verify if PR has been static code reviewed and no issues have been raised by the tool
• Verify if the Developer has implemented the agreed Design pattern for Apex, LWC and Flow
• Verify if the developer is covering his customisation for Apex, LWC, Flows with proper Test scenarios. Many times dev push changes relying on existing code coverage which is wrong on many levels.

You can include many other steps but I will suggest keeping it minimalistic.

Static Code Review

Static code review is scanning of code and running against some pre-defined rules to check some best practices like

• SOQL on for loop
• Naming convention
• Complexity
• Security violation
• DML statement in for loop

These tools keep the hygiene of your system with no effort after setup. You can configure them with

• Your local Development environment where you get real-time feedback if you are introducing any bugs, code smells etc
• On PR request where PR request code gets scanned and Developer can fix issues identified by the scanner before submitting PR to the reviewer.
• On the project level where you see overall statistics of projects sanity.

Test Code ( for Apex, Lwc, Aura, Flow ) should cover All (positive/negative) test case scenarios

In my entire journey with Salesforce, I have never seen a single org all Developers are writing Test codes to cover Test Use cases but they write as Salesforce doesn't allow them to push code without 75% code coverage.

We just being lazy while writing test code as we believe the QA team will cover actual scenarios. But trust me writing accurate test code gives you immense confidence in your system and also gives you chance to find issues which generally visible when things go wrong like bulk operations, record Locking etc.

By Using Stubbing and Mocking any team can create a Test framework that will speed up Test code coverage.

Use Gitflow as a branching strategy (you will thank me always for this)

How can I forget this gem sitting in all my DevOps implementations? I love it as its time tested and proven and covers the most complex DevOps and Release requirements.

You can search about it on the internet as there are many articles available.

When I started this article, I was not expecting it will require so much space. And I know I have not even scratched the surface of each topic.

I will try my best to write down articles to cover individual topics.

Please share your experience and tips to make Your system healthy and happy. Also, share which topic you want me to cover in detail.

Thanks