Creating an unmanaged package from a Sandbox to create a SalesforceDX project and Scratch org leaves countless errors (like DX doesn't know which order to create Objects/Fields/Classes in). Is there not a way to start a DX project from an existing org? It seems like everything I've found makes it really easy to build tiny features in isolation, but nothing to start a project from a mature org (which I would assume is the most common use case).

  • I ran into the same issue and still trying to find a solution. I'm thinking do a separate ANT deployment to scratch org all custom objects, flow, etc etc except VF pages and Apex classes. Then use DX for Apex and VF pages . This thread discuss the same issue. salesforce.stackexchange.com/questions/200185/…
    – SL man
    Jan 15, 2018 at 4:01
  • Instead of converting your metadata to dx structure then do a push to scratch org, you could try to deploy your metadata to your scratch org directly using mdapi or even ant, then do a pull locally. Never try but could work.
    – brovasi
    Mar 1, 2018 at 10:29

3 Answers 3


If you are still messing around with this and having issues, like I and a few others are, it'd be great to have some more people posting here: DX Salesforce Trailblazer Community

Personally I'm staying on our current MavensMate + Git + VSCode setup for as long as possible. I don't have the time or interest to work with the current iteration of DX. It's just too raw to be helpful when I've plenty of actual work that needs to be completed.

  • 1
    The url is not properly set it seems, can you fix it to point it to right location please. Apr 3, 2018 at 2:08
  • I agree. I was very excited for DX, but very quickly realized it is a half-baked product that is lacking compatibility with existing codebases. Jul 14, 2018 at 0:29
  • @PasanE It's one of those things that will require to you login with some Salesforce credentials unfortunately.
    – torpy
    Jul 16, 2018 at 16:15

I understand your frustration because I faced it a few months ago. SFDX does know how to push the components in the right order.

But sometimes, an object fail to deploy and hence, your classes and VFP that depends on it will fail. The logs produced by sfdx is sometimes truncated in the console when you have many errors and you miss some details on the fail reasons. I recommend to open the scratch org and check the deployment status to see the fail reason of components.

From My experience, you did it well by starting with managed Package. Here are some tips I would recommends:

  1. Avoid creating a monolithic sfdx project from your existing org: Salesforce recommends to start small. SFDX is design to build modular applications. Some components are not yet supported in sfdx. So check the metadata coverrage page for unsupported components. Otherwise you will have to deal with many dependencies errors as you saw. So start with a set of components of your org.
  2. Create an unmanaged package and pull it with metadata API: This will allow you to package components with their dependencies. One thing that can cause errors you are facing may be Listview with shareTo field set to a specific user from your org. As this user those not exists on the scratch org, the deployment will fail and all other object components will not deploy. You need to do some cleanup action on some components before you can deploy them on a Scratch Org
  3. Create a scratch org definition file that enables features that are available on your production org. This is a bit tricky as there is no way to build a Scratch org that has the same features enabled as on the production. The Org Shape feature of sfdx is still in pilote.

Hope this will help you kickoff with sfdx.


You can now start a Salesforce DX project from an existing org. The Salesforce DX Developer's Guide has the process detailed and I've included some of the relevant bits here:

Develop Against Any Org (Beta)

1. Create a Salesforce DX project
2. Authorize your non-source-tracked org. If connecting to a sandbox, edit your sfdx-project.json file to set sfdcLoginUrl to https://test.salesforce.com before you authorize the org. Don't forget to create aliases for your non-source-tracked orgs.

Once you've completed the above steps, you can use the force:source:retrieve command to retrieve source from orgs that don’t have source tracking, such as sandboxes.

You can retrieve metadata in source format using these methods:

  • Specify a package.xml that lists the components to retrieve.
  • Specify a comma-separated list of metadata component names.
  • Specify a comma-separated list of source file paths to retrieve. You can use the source path option when source exists locally, for example, after you've done an initial retrieve.

Retrieve Commands

All metadata components listed in a manifest:
sfdx force:source:retrieve -x path/to/package.xml

Source files in a directory:
sfdx force:source:retrieve -p path/to/source

A specific Apex class and the objects whose source is in a directory:
sfdx force:source:retrieve -p path/to/apex/classes/MyClass.cls,path/to/source/objects

Source files in a comma-separated list that contains spaces:
sfdx force:source:retrieve -p "path/to/objects/MyCustomObject/fields/MyField.field-meta.xml, path/to/apex/classes"

All Apex classes:
sfdx force:source:retrieve -m ApexClass

A specific Apex class:
sfdx force:source:retrieve -m ApexClass:MyApexClass

A layout name that contains a comma (Layout: Page, Console):
sfdx force:source:retrieve -m "Layout:Page%2C Console"

  • 2
    Can you add some relevant information from the linked article? Links tend to break over time making link-only answers not so helpful in the long run.
    – Matt Lacey
    Jan 16, 2019 at 1:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .