Unlock the Full Potential of your Salesforce Org with Modularisation and DX@Scale

Streamline your Salesforce application lifecycle by enhancing the experience of your developers and admins.

Trusted and used on more than 150 Salesforce production orgs

Open-source and battle-tested.

We have been early adopters of Salesforce DX and saw it as a massive step towards improving the developer/admin experience. The version control system was finally the source of truth, and we loved it.

We wanted to take it to the next level and apply Continuous Delivery principles to Salesforce. We have defined an approach and a set of practices, and we have developed a set of tools to support them.

We have open-sourced all of that. DX@Scale is now used on more than 150 Salesforce Production Orgs worldwide. We are grateful that some of these users allowed us to use their logos.

There is no trade-off between quality and speed

DX@Scale is a different approach to Salesforce development.

We had several sessions like this one where we talked about our approach to building modular Salesforce Orgs: when we focus on sane Software Engineering principles like modularisation, trunk based development, continuous integration and the right tooling, we can build and maintain any org at any scale, with consistency, confidence and high level of quality.

Results observed in the trenches

What it could look like for you.

We use DX@Scale on a multi-year Salesforce program involving Sales Cloud, Service Cloud, Revenue Cloud and several integrations with Front-End and Back-End Systems. This is what we have observed so far.

Our community users achieve similar results when they follow our approach and use our open-source tools.

0Severity 1 or 2 defects in production since the first go-live in 2020.
99%Success rate for our deployments in production.
3xVelocity: one of our community users reported this improvement when using DX@Scale compared to other methods.
On DemandRelease capability: when a fix or a more important feature is ready, it goes to production: no need to wait.

Since we adopted DX@Scale, it has been the best time and effort investment for our Salesforce delivery pipeline. To make it even more precise: I can't imagine working with other CI/CD solutions on this platform in the future. Roughly, our team's velocity has been multiplied by 3.

Ruslan Kurchenko
Salesforce Technical Architect, K-Health

The business benefits of modularisation

What is modularisation? Why should you care?

Breaking your Salesforce implementation into components or modules leads to a more streamlined development process, faster time to market, and a more flexible and adaptable platform for the business.

Increased Efficiency

By breaking up a your Salesforce Org into smaller, independent modules, developers can work on specific project parts simultaneously, speeding up the overall development process.

Better Maintainability

Because your modules are smaller and independent it is easier to identify and fix bugs or issues that may arise. Additionally, it is easier to update or refactor individual parts without affecting the entire codebase.






















  "packageDirectories": [
      "path": "force-app",
      "default": true
  "name": "happy-soup",
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "56.0"

DX@Scale led us to scale from one release every two weeks to release daily. Salesforce Development has an ocean of know issues and trade off, DX@Scale cover all of them, saving a lot of time of scripting/hacks development. Salesforce Modularity is possible, It takes time, It pays off; DX@Scale help us to achieve it.

Diéffrei Tiepo de Quadros
Salesforce Technical Architect, Expereo

Not just another tool

DX@Scale is about simplifying your Salesforce development experience.

DX@Scale is not just another tool. We advocate for sane enginering practices applied to Salesforce, and we have built and open source all the tools to support them.

The first step that we recommend is to assess the level of technical debt in your Salesforce org. Then start modularising it. We know this is a painful exercise, but it is really worth it.

The more modular and composable your Salesforce org is, the faster you'll become. No module is too small...

Be mindful that depending on the size of your org, this exercise could take several months. Take tiny steps, extract, assess, rinse and repeat.

Learn more



















    "packageDirectories": [
      "path": "packages/billing/products-pre",
      "package": "billing-product-catalogue-records-pre",
      "versionName": "billing-product-catalogue-records-pre-1.1",
      "versionNumber": "",
      "dependencies": [{
        "package": "Salesforce Billing"
        { ... }
    { "path": "packages/billing/products-post", ... },
    { "path": "packages/case-management/case-config", ... },
    { "path": "packages/case-management/case-entitlements", ... },
    { "path": "packages/case-management/case-management-core", ... },
    { "path": "packages/case-management/web-to-case-api", ... },

DX@Scale provides the foundation for us to tame Salesforce’s enormous variety of capabilities and functionalities resulting from it’s high degree of flexibility in configuration. It allows us to combine state of the art approaches to software development with Salesforce, and in particular to implement CI/CD pipelines across multiple customers. We are looking forward to the future with DX@Scale and try to become even more a part of the DX@Scale community.

Nils Schuch
Senior Developer, Valantic

A journey ahead of you

Not ready to embrace Unlocked Packages? Don't worry, we got your back, and more...

A "Well Architected" Saleforce org enables your business to adapt to change and release new capabilities faster. The end goal, where feasible is to embrace unlocked packages.

However some times, they may seem overwhelming; they may not be the right fit or they lack some capabilities like the support for data-driven packages like Revenue Cloud.

We faced the same challenges and developed capabilities we think you'll appreciate.

Source packages bridge the gap between metadata deployment and unlocked packages.

They are a construct which wraps Salesforce Metadata with meta-information (such as version number, commit id, branch, tag, ...)

We use them, and recommend them in the following cases:

  • Metadata not supported by Unlocked Packages
  • Dealing with metadata that is global or org-specific in nature (such as queues, profiles, etc or composite UI layouts, which doesn't make sense to be packaged using unlocked package)
  • Development teams who are starting to adopt package-based development and want to organize their metadata
Learn more


      "path": "packages/case-management/case-config",
      "package": "case-config",
      "versionName": "case-config-1.0",
      "versionNumber": "1.0.6.NEXT",
      "dependencies": [{
          "package": "case-management",
          "versionNumber": "3.2.0.LATEST"
  }, {
      "path": "packages/quote-recalculation-batch",
      "package": "quote-recalculation-batch",
      "versionName": "quote-recalculation-batch-1.2",
      "versionNumber": "1.2.0.NEXT",
      "default": false
  }, {
       "path": "packages/sales/opportunity-management",
       "package": "src-sales",
       "testSynchronous": true,
       "versionNumber": ""

DX@Scale has been a game changer for our salesforce CI/CD processes. With its streamlined pipelines, automated processes and modularisation, we have been able to deliver faster and more efficiently. The integration of DX@Scale into our workflow has not only saved us time, but has also improved the quality of our deployments. I highly recommend DX@Scale to anyone seeking to improve their salesforce development lifecycle.

Enea Gjoka
B2B Solution Architect

Stop fiddling with custom CI/CD scripts

Meet our declarative orchestrator.

As you modularise your application, you would need to update regularly your CI/CD scripts. We know it, we faced the same issue! That's the reason we have created the Orchestrator .

Just modularise your solution, the orchestrator will auto-magically take care of the rest for you.

The orchestrator understands your sfdx-project.json file, and builds your modules in parallel when it is possible:

  • You don't have to fiddle with custom CI/CD scripts anymore, just focus on your modules and their dependencies, the orchestrator takes care of everything else.
  • Get faster build: if there are no dependencies, or the dependencies have already been met, several modules can be processed at the same time.
Learn more


  "packageDirectories": [{
    "path": "./es-base-objects",
    "package": "ESObjects",
    "versionName": "Base Objects - Winter '22",
    "versionNumber": "55.0.0.NEXT",
    "default": false
  }, {
    "path": "./es-base-styles",
    "package": "ESBaseStylesLWC",
    "versionName": "Base Styles LWC - Winter '22",
    "versionNumber": "55.0.0.NEXT",
    "default": false
  }, {
    "path": "./es-base-code",
    "package": "ESBaseCodeLWC",
  }, {
    "path": "./es-space-mgmt",
    "package": "ESSpaceMgmtLWC",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "55.0",
  "packageAliases": {
    "ESObjects": "0Ho4W000000CaeJSAS",
    "ESBaseCodeLWC": "0Ho4W000000CaeTSAS",

DX@Scale is a powerhouse. It gives Salesforce architects a rich devops framework that uses design patterns and pipeline actions more familiar to software engineers who have worked in “regular” devops. While focused on its own development methodology, DX@Scale has components of value to any software engineer working in Salesforce. With this suite of tools and capabilities, DX@Scale helps enterprises leapfrog into a modern app development methodology.

Vernon Keenan
Senior Industry Analyst, SalesforceDevops.net

Build, measure, assess, rince and repeat

You can only improve what you measure.

Metrics should be a key part of any development process. That's the reason why DX@Scale is instrumented.

DX@Scale exposes metrics that track counts, duration, success rate for all the phases of your CI/CD.

By monitoring these metrics you can than identify the bottlenecks in your process and act accordingly.

For instance:

  • Is your build taking too long? Perhaps there is a dependency that you can invert.
  • Are your unit tests taking too long? This is usually an issue with your tests not being isolated enough.
  • Are your deployments failing too often? Perhaps you are missing some automation when deploying to the downstream systems.
Learn more

Production Install Time

PackageInstall TimeAverage Time
Metadata Count
428 metadata type
Metadata Count
210 metadata type
Metadata Count
28 metadata type
Metadata Count
8 metadata type
Metadata Count
132 metadata type
Metadata Count
48 metadata type
Metadata Count
26 metadata type
Metadata Count
8 metadata type

Last 7 days

# Pull Requests
137 from 118
Improved by 16%
Validation Time in mn
14.41 from 15.13
Improved by -4.1%
Success Rate
60.87% from 70.62%
Deteriorated by -13.8%
Feedback Time in mn
11.9 from 13.2
Improved by -9.8%

Speed up your workflow

Provision scratch orgs in seconds not hours.

As you automate more of your business processes in Salesforce, you cannot avoid adding third party managed packages as a dependency to your configuration metadata and code in your repository.

The time required to spin up a new CI or a developer environment increases, diminishing the value of using scratch orgs. We have seen teams avoiding scratch orgs for that.

We think scratch orgs are amazing, and we solved this problem with Scratch Org pools.

Pools are created of the back of your version control system, meaning extra time saved...

As a developer, you are going to love this (we hope!).

How long does it take to spin up a new scratch org? Install the managed packages required for the new feature you need to build? Minutes? Hours?

Think seconds, no matter how complex your set up is... Simply fetch a new scratch org from the pool and start your new feature. Take the time to grab your favourite drink though!

This is as simple as:

sfdx sfpowerscripts:pool:fetch -t [POOL_NAME] -v [devhub-alias] -a [scratchorg-alias]
Learn more