I have been reaching out to projects that utilize flxbl. One thing they all have in common is that these teams deploy changes to their Salesforce org more frequently and consistently.
The Numbers Speak for Themselves. Let’s dive into some organizations that shared their metrics and their development composition for their latest quarter (Calendar year):
- A leading financial organization deployed 192 times in production, with a success rate of 93.75%, delivering over 400 work items in the last quarter (~50 member team)
- A financial organization in ANZ utilizing Sales/Service Cloud and Q2 CloudLending deployed in production over 53 times during the last quarter, with a 100% success rate, delivering over 300 work items. (~10 member team)
- A leading web portal that utilizes Sales/Service/Experience/Revenue Cloud deployed over 43 times with 1 failure
- A large retailer had 170 deployments, delivering 385 work items with a 100% success rate. (~60 member team)
While these numbers are exciting in itself, I looked at the composition and maturity of the teams. What if they were all senior people? Part of the no-flow gang? All clean coders? I found no consistent pattern that I could figure out, so I further probed.
- The teams are not composed of senior developers only; the skill level within the team is well distributed, from junior low-code developers to senior developers.
- Perhaps it’s their level of maturity. One would assume that these organizations have got it all right in terms of modularization (considering they are all on the flxbl framework), but it is not that either. Some have very few packages, and some have way more than 200 packages.
What also struck me is they are at different levels of adoption of the framework, but they all bought into the approach. None of them asks for a UI to abstract git or allow cherry-picking of metadata. Their team members are relatively happier, have increased confidence in their deployments, and are releasing their changes faster.
So what would it be then? What are the elements that allow a team to move faster?
The Secret Sauce: Eliminating the ‘Right’ Chores
What sets flxbl apart is its ability to eliminate the time-consuming chores that often hinder teams.
Here are the key concepts in no particular order.
1. Repository organized into folders promoting ownership
Organizing the repository using folders for domains and packages reduces cognitive overhead, making it easier for teams to navigate and understand the codebase.
This clarity is essential for Salesforce repositories where those verbose XML configurations can otherwise become overwhelming, leading to errors and inefficiencies.
This organization allows teams/individuals to own parts of the repository and drive localized improvements.
2. Simplified Branching Model (Scaled Trunk-Based Development).
We discussed this in a previous article: you branch from the trunk (main) and merge to main—that’s it.
It keeps things simple and reduces overhead. Couple this with #4 (Isolated testing of change requests). You merge to the trunk, and when your change has been accepted, any other testing, such as performance and integration, can be done after the merge. If the trunk breaks due to a defect from that test, you fix it as a priority.
3. Individual Developer Environments with forced expiry
flxbl emphasizes the use of individual developer environments with a forced expiry. It ensures that each team member’s work is isolated, reducing conflicts and dependencies. flxbl provides an easy mechanism to provision developer environments — scratch orgs and sandbox pools — which reduces drift from the mainline, encouraging experimentation and enforcing good practices like frequent local commits and more automation in general.
4. Isolated Testing of Change Requests
Testing each change request in a dedicated environment might seem resource-intensive, but it’s crucial for the early detection and resolution of deployment errors. This “shift-left” approach, where testing is performed early in the development cycle, ensures that issues are identified and rectified earlier. The idea is one should be able to do acceptance testing before merging in and do it fast!
5. No magic diffs, No Org comparison overhead
Deploying the contents of the entire package, rather than incremental changes, ensures consistency across environments. Someone has manually changed a component in an environment, no problem! When the environment gets updated with a new package version, it gets synced up with all the package components. The incremental diff package type in flxbl only gets reset when it gets to production, so syncing is relatively easy.
For regulated organizations, this ability to track package versions, their content, who modified what, when, and which user story or business requirement the change is linked to facilitates their audit obligations.
6. Framework-Enforced Tooling
This is a big one: flxbl, with its pros and cons, enforces an opinionated development approach that many of our community users find more efficient and reliable.
If you adopt flxbl, you need to buy into this development approach. Our tools are the incarnation, not the other way around: if you follow this approach, they will make it a breeze. Compared to other DevOps solutions you may build or buy, there is a proven and specific way to use the tools to reap the benefits.
7. Smart Automation keeps you in the flow
flxbl was built from the ground up, and we returned to first principles. We automated mundane but time-consuming tasks, such as automatic test class identification, coverage validation, flow state management, profile reconciliation, etc. All are built-in and turned on by default, so you don’t need to worry about them.
8. Extensibility of CI/CD Platforms
flxbl’s primary toolkit, sfp, can be deployed on CI/CD platforms like GitHub, Gitlab, etc. These platforms are inherently extensible, as they support various use cases within the enterprise. GitHub, for instance, has a large marketplace with a collection of actions to enhance/simplify the workflows.
This extensibility allows teams to customize and optimize their development processes to suit their specific needs without waiting on vendor releases.
9. Community
The community is our biggest asset. If you are stuck, there will always be someone who experienced the same challenges and is willing to share a solution.
You have an idea, discuss it, there might be someone who has already experimented with it.
If you are facing a challenge you think the tool should resolve, let’s discuss it. We want to solve real problems real people encounter on actual Salesforce implementations.
So chores eh? Yes, that’s it! It’s not just git or metadata selection that is slowing you down, it is everything else
If you want to learn more or share your story, please head out to the flxbl community.
