We currently plan to make the move to pure SFDX and try to come up with a solid strategy to divide our metadata into unlocked packages. The main problem we encountered so far is that we don't know how to properly handle single-file shared metadata, like user profiles.

Putting single-file shared metadata into a separate "base" package might be tricky, in the case of user profiles without having all objects available in that package. Not packaging them essentially means not being able to track them in git. Are we missing something here?

3 Answers 3


One viable alternative is start converting the profiles into permission sets as a part of the DX move .

With permission set you can easily group them with relevant objects .

Salesforce did a blogpost on this and you might find the blog helpful.


  • Thanks! That would be a way for user profiles I suppose. But what about an object's object-meta.xml file, like Account.object-meta.xml?
    – Wolfi
    Jan 25, 2019 at 15:00
  • 1
    With DX source format you can break them up and should be no issues .Look into the DX source format for objects. Jan 25, 2019 at 15:16
  • I'm aware the DX source format splits up an object into a lot of xml files, one for each field for example - which is great. However, for each object there's still at least an unsplittable object-meta xml file, that might have to end up in several packages. Also, objects and profiles were just examples for kinds if meta data we're struggling with.
    – Wolfi
    Jan 26, 2019 at 14:04
  • The object metadata can be duplicated in your source repo and should do no impact. Jan 26, 2019 at 14:05
  • But the object-meta could change. How would having duplicates of it have no impact? Just to make sure we're having the same thing in mind, this is what I mean by object-meta xml: github.com/dreamhouseapp/dreamhouse-sfdx/blob/master/force-app/…
    – Wolfi
    Jan 26, 2019 at 14:35

I don't recommend moving EVERYTHING into unlocked packages. Create unlocked packages for individual projects that can stand alone, be tested in a scratch org, and are related to a development team. There is always going to be a sea of unpackaged metadata, many of those standard objects are related to Salesforce CRM functionality. Here is a detailed white paper on this issue...


(I am the CTO of Metazoa, this is a link to our website)

  • I've read this article before. But how would you handle unpackaged metadata then? Not git it...?
    – Wolfi
    Feb 1, 2019 at 9:24
  • Why put things in Git? I can think of two reasons. One, for backup, compliance, and audit trail. And two, for merging code, and maybe for merging other XML assets. The metadata api does a good job of merging most XML assets, and these are cumbersome to merge by hand. Merging code from developers is a useful thing to do with a repo. So I think the best practice here is to put developer projects into Git and let the metadata api handle other assets. For large orgs, you will have difficulty storing all the metadata in Git anyway... Feb 1, 2019 at 11:13
  • The reality is that "individual projects that can stand alone" don't exist in any real-life Salesforce org. These projects will talk to custom objects, custom fields, Apex classes, etc. that are not part of that project. The only way that that is possible is to package those objects and classes into a "child" unlocked package and have a dependency between the project package and the child package. In fact, any viable packaging strategy would start with packaging stuff that everything else depends on and then building packages on top of that.
    – Frans
    Jan 30, 2021 at 19:33

Currently looking at doing something similar myself - you actually don't need the object.xml in both packages - you can define just the custom fields.

You might have found it hard to deploy becuase sfdx push does not currently correctly merge the object.xml from multiple second-generation packages.

Can see this demonstrated here: https://github.com/JonnyPower/sfdx-push-bug-20190124

I have a case open with salesforce to try and report this as a known issue.

  • Thanks for working on that, it really is an issue.
    – Wolfi
    Feb 1, 2019 at 9:25

You must log in to answer this question.

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