SalesforceDX brings to the Salesforce ecosystem a new way of developing applications on the platform, and using a new form of metadata for that. This new development model is great for CI/CD and testing (with disposable environments).

However I'm having a difficult time on defining who the target audience is. Because every example, every tutorial, every video I've seen so far seems to be focused on teams developing applications to the market.

Everything is great, but how about customers that have highly customized applications, that will not get published (in-house development)? The organization that serves as production environment is also the dev hub? Can scratch orgs replace sandboxes? Will this new model replace the current model that is based on change sets? Can customers who do in-house development benefit from SFDX?


Yes, customers can use DX internally to develop and test their changes. Here's what I've gleaned after playing with it a bit:

  1. Production is the dev hub. This doesn't mean you are doing development in prod, it is just the org used to determine how many scratch orgs you can have at a time. (At this point, licensing is still unclear.)
  2. Scratch orgs will replace developer's sandboxes for building out new features. Sandboxes still have a place for UAT and release management.
  3. You can't use DX to push diffs to sandboxes or production orgs. You'll still need to use the metadata api. DX provides a tool to convert to and from the metadata API format.
  4. For release management, I still haven't quite figured out what I want to do. I'm leaning towards have a sandbox that gets all the metadata pushed in as it is checked into source control, and then doing a push from there to prod either using change sets or the metadata api.
| improve this answer | |
  • 1
    In the beta, a single production dev hub org is allotted 50 scratch org licenses. This means 50 scratch orgs may exist at a time for one dev hub org. For trials, it is 40. – pchittum Jul 14 '17 at 21:40

Customers can use DX does NOT mean they should.

In my opinion, DX is way overkill for enterprise customers. Enterprise customers purchase Salesforce products to use them, not to rebuild them. DX requires major investment in devops, pipeline and dependencies management. Purchase a Sales app then hire an army of devops engineers to build it seems wrong from every angles.

The investment in DX is only paid off if your core business is making and selling software. So if you are an ISV, sure go ahead. If you are an enterprise customer and find yourself getting stuck in the DX dependencies mess, you're better off getting on with solving real business problems.

| improve this answer | |
  • 1
    Any large-scale enterprise development process requires investment in devops. I think you are dramatically overstating the cost of Salesforce DX relative to, for example, the pre-DX continuous integration and lifecycle management pipelines my end-user enterprise must utilize. – David Reed Aug 15 '18 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.