For reference, I am modeling my sfdx directory structure after sfdx falcon and I was wondering if it is possible or wise to split an object directory up.

For example, let's say I have a module called module1 with object Account and in it, weblinks/Something.weblink-meta.xml and in another module2, it has object Account with weblinks/Other.weblink-meta.xml and weblinks/SomethingOrOther.weblink-meta.xml.

Is it wise or even possible to split it up like this or keep them all in the same object directory? I've tested doing a "sfdx force:source:convert" command to metadata format, that although the package.xml is set up correctly to see these weblinks, the actual resulting Account.object file will be missing the weblinks in module2. But I did not know if this was because of some setting I missed.


It depends on your deployment method. If you're just going to convert back to MD API format, consider keeping each object in a single folder. If you plan on using unlocked packages and/or force:source:deploy, feel free to split them up appropriately.

The advantage of splitting them up in packages is that you can spin up scratch orgs that don't copy full functionality, thus reducing the time it takes to set up an environment. Unlocked packages ultimately minimize deployment time to your sandboxes and production orgs.


You can easily have a custom folder structure like below. From personal experience organising metadata by module or by feature is really helpful from maintenance perspective and of course for order. You can create custom folder structure as long as you keep the metadata folder name as it is. For example for sObjects your metadata folder must be named objects doesn't matter the root. For apex folder name should be classes etc.

  • force-app
    • main
      • default
        • objects
          • your_object__c
    • feature1
      • objects
        • your_object_2__c
  • feature2
    • objects
      • your_object_3__c
    • classes
      • customApex.cls

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.