I have unlocked package with some profiles. As of now I cloned those profiles from Minimum access - Salesforce and Customer Community Plus Login and it doesn't contain any of the extra permissions.

I have 3 sandbox available. Sandbox1, Sandbox2 are having some of their own set of profiles with different names and sandbox3 was clean sandbox.

Now, I am able to install the package, but profiles are not getting added in Sandbox1/Sandbox2[event with Mixed/Deprecate/Delete way].

So, I thought some issues with package, I tried installing same package in Sandbox3, there I am able to see newly created profiles.

I have few questions with profile deployments with Unlocked package -

  1. How I shall deploy the profiles in Sandbox with Guaranteed way(for the CICD purpose)?
  2. What is root cause for this behavior?
  3. Do I need to perform any other steps to update existing profiles? If I have profiles with same name, will it append the existing profile or override the existing profile?
  4. How I shall have it for multi-unlocked package. E.g. Profile p1 is having permission for Object o1, o2 and o3 which are part of Package pckg1, pckg2, pckg3 profiles. And pckg1 is root/dependent package for pckg2 and pckg3. What will be the best strategy in this case?

Clarification with current setup -

  1. I have unlocked packages with no namespace.
  2. Profiles will be having of 2 types - Salesforce/Customer Community Plus Login
  3. Able to create package and install package without any deployment issues.
  • 1
    As per a comment from @DavidReed on my Q&A, CLI installation of the package doesn't install Profiles yet installation through the Salesforce Setup UI or the Tooling API (with a specific mapping) does.
    – Phil W
    May 24, 2021 at 14:51

1 Answer 1


You shouldn't be trying to package profiles in Unlocked Packages. Salesforce has recommended that you use Permission Sets instead. This is even recommended in the trailhead project Create Permission Sets for Unlocked Packages. Permission Sets cover all the problems you're having.

  • Yes I agree, however due to time crunch we are not in position to change the Design. We are trying to have with profile as base release. Once done in lateral release, we can try to reduce dependency on profile.
    – Ysr Shk
    Jul 30, 2020 at 2:10
  • 1
    @YsrShk Converting to a Permission Set should be a mostly copy-paste operation, actually. That said, I don't have a good answer as to why the profiles aren't lining up like they should.
    – sfdcfox
    Jul 30, 2020 at 4:07
  • 1
    This answer fails to consider Page Layout Assignments that can only be contained in a Profile and not a Permission Set.
    – Phil W
    May 24, 2021 at 14:45
  • 1
    @PhilW To be fair, I've never gotten layout assignments to work correctly in packages, our strategy was manual assignment after installation. Regardless, the bulk of permissions should still be contained in Permission Sets. Salesforce has been advocating this design model for many years now. Presumably, in the future, we'll have a way to deal with layouts easier.
    – sfdcfox
    May 24, 2021 at 15:04
  • 1
    I guess it's fair to say that there will be a new approach, especially given that Salesforce are moving away from page layouts to dynamic forms, so it will be a case of permission to access various Lightning Pages in the end. I don't disagree with putting all CRUD/FLS and other permissions in one or more permission set, it's just that I needed to package (and could) the page layout assignments, yet these profiles fail to install. @DavidReed believes this is a difference in behaviour between CLI and Setup UI package install behaviour, related to Profile mapping.
    – Phil W
    May 24, 2021 at 15:15

You must log in to answer this question.

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