SFDX - Scratch Org Based Development - Use Case

Following my previous article SFDX - Scratch Org Based Development - Considerations, before starting our new project, we did consider using Scratch Org based development and below is the summary of our considerations: -

Team Skill Set

Even though our new team have never worked on Scratch Org Based Development, but we were quite confident to learn, implement and grow together. The Tech Lead was very excited to adopt this new development workflow. We understood that initially we may have to do hand holding with dev team but we as a unit were ready to work together and sail this tide.

Project Fit

In midst of the project - Even though the project we were about to start was new but customer has multiple project running in parallel.

Project Overview

Below is a quick summary of the project

• Case management for a new Business Unit
• Extend existing heavily customised customer community
• Integration with Robotic Process Automation

Environment Overview

Project may not sound complex until you understand existing Environment. Below is high level summary of existing environment: -

• Case Management is being used by 3 Business Units.
• Case object is highly customised and have hit almost all limits, so very minimal scope to customise and scale it further.
• Customer has almost 5 TB of Data Storage and almost 80 TB of File Storage limit. You can only imagine how much actual data it has at the moment and where it could lead up to.
• Due to nature and complexity of the customer business, a very complex object model.
• Heavily customised Customer Community.
• Multiple complex integration where Salesforce is mostly downstream system. No reward for the guess that SAP is source of master data in most of the integration.
• Tens of systems integrated (if not hundreds).
• Salesforce is being used as Reporting System (no Einstein Analytics yet) for some of the business use cases.
• In addition to on going business support, three more projects are running in parallel, and design & discovery for couple of more projects are going on in parallel.
• Version Control is being used, but the structure of repo is not as per SFDX format, again reason is that it was setup few years back when SFDX was yet to come out.
• Very agile environment where multiple deployments are happening almost everyday.

Consideration which influenced decision

Can we deploy Communities

With the existing structure, automation of community deployment is very challenging. Hopefully ExperienceBundle will become GA soon and it will help making DevOps more streamlined. Gearset has documented very well the challenges with community deployment and how ExperienceBundle will make it scalable and smooth.

Outcome - Being customer focus implementation, Customer Community is very important part of our project. Because of above mentioned challenges, if we can't confidently automate deployment of community from Source to Scratch Org then we can't truely trust our build either. We don't want to introduce set of manual steps post scratch org creation as it will defeat the original purpose of introducing agility, automation and process streamlining. After careful in-depth consideration we identify this as RISK.

Test Data

As explained earlier, we have a very complex object model. Most of the master data come from integration and are necessary to do unit testing. We could have created script to create set of master data, but we didn't have time to write script and get the data validated before using.

Outcome - Because of very agile environment and strict timeline we couldn't spend time to write script to create test data and we identify this as RISK.

Profile

Same as most of older orgs, we have profiles where most of the accessibility and permissions are managed.

Outcome - profile maintenance and deployment using version control is always tricky and challenging. Salesforce has suggested to use bare minimum profile with permission sets to manage accessibility and permission. I have documented it earlier in one of my article titled Permission Set with Bare Minimum Profile - DevOps Lens. After careful in-depth consideration we identify this as RISK.

Final Decision

We wanted to use Scratch Org Based Development for this project. After very carefully consideration, pros vs cons, benefit vs risk, we decided against using Scratch Org Based Development workflow on this project.

We may not be using Scratch Org Based Development Workflow on this project but we will keep evaluating our upcoming projects for the right fit. Until then I will keep exploring Scratch Org Based Development workflow and sharing my findings with community.