I've found some time to return to an older project of mine, moving my org away from the org development model to the package development model to make better use of SFDX and CI/CD.

The issue I'm running into is with how to handle customizations to page layouts. Things like adding new fields, new detail buttons, new related lists, new list buttons on related lists. I'm not trying to add a new page layout here, I'm modifying existing page layouts.

The general idea I've gotten for handling this up to now has been "it's a common component used by multiple projects/packages, so it needs to live in a common project/package that become a dependency for other projects/packages"

Following that would end up polluting the common packages pretty severely, I'd think. Adding a related list, for example, would require adding the following to the "common" package:

  • The parent object page layout
  • The child object
  • The relationship field on the child object (pointing to the parent object)
  • The child fields referenced by the related list

At the end of it all, I can't help but see the "common" pacakge(s) just becoming a bloated mess with nearly every object, field, action/button/link in it. Effectively, I think that brings me back to the org development model. Not terribly useful for trying to use unlocked 2GP or build scratch orgs to hold just enough customizations to allow declarative work.


My assumption here was that any "common" package would be at the root of the dependency graph. That every other package would then depend on it.

End of edit.

The Layout metadata type does act as a container for things like fields, buttons, and related lists, but are we able to leverage those items in SFDX/2GP like we can for SObject fields?

Do we have a decent way to handle modifications to page layouts, or is this a use case that isn't addressed by SFDX/2GP?

If it isn't supported by SFDX/2GP, is a decent way to handle this to effectively maintain two groups of projects?

  • One contains bloated common packages that allow us to contain the "effective" page layout (contributions to the page layout from all downstream development)
  • The other contains common packages with only the base requirements so that scratch orgs can be built and unit tests can be run

1 Answer 1


The only reasonable way to handle a page layout setup, given the dependencies required, is to make the page layout a package that actually depends on all of the other packages. This has the unfortunate downside of potentially complicating issues, but the general format that I came up with, which seems to work okay, involves a three layered approach to the problem.

Layer 1 is the core metadata; objects, fields, validation rules, and anything else upon which everything else is built. Our Layer 1 package design includes a common core package (accounts, contacts, opportunities, products, and the like), a support package (cases, solutions, etc), a marketing package (leads, campaigns, etc), and a few other miscellaneous types.

Layer 2 is the code layer. It covers things like Flows, Visualforce pages, controllers, lightning components, and other things.

Layer 3 is the composite metadata layer, and is primarily composed of layouts, profiles, weblinks (because they typically depend on layer 2 package info) and things that will depend on everything else.

Of course, this is what worked for our org, you may need to find your own design. Hopefully this answer gives you a few hints on how to get started with your design.

  • Thanks fox, this does help give me an idea of where to go. Making the composite metadata the most downstream package (and depend on everything upstream of it) makes more intuitive sense than making layouts part of the "core" (as I was initially thinking). Reminds me of how I had to reverse my approach for a project in an image processing course, which I could regale you with if you care to stop by the office hours chat.
    – Derek F
    Apr 15, 2021 at 17:26
  • @DerekF I actually misplaced my login, not entirely sure how to get back there. But I'd love to hear more sometime.
    – sfdcfox
    Apr 15, 2021 at 17:43
  • Since you're still posting under your account, I assume just giving you a link should work. chat.stackexchange.com/rooms/53431/open-office-hours . It's a story I think would benefit from some visual aids, but I'll have to wait until after work before I can try to toss those together.
    – Derek F
    Apr 15, 2021 at 17:55
  • @DerekF Oh, that link. I'd forgotten about it.
    – sfdcfox
    Apr 15, 2021 at 18:15

You must log in to answer this question.

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