3

How does one maintain consistent user profiles between scratch orgs and production? For example, I create a scratch org with the following config:

{ "orgName": "mycompany", "edition": "Enterprise", "features": ["AuthorApex"], "orgPreferences" : { "enabled": ["S1DesktopEnabled"] } }

Then I clone the System Administrator to create My System Administrator profile. I give that profile access to a custom field on the opportunity object. When I try to install a package in my partial copy or production, I encounter various Unknown user permission: xxx errors.

I can remove the permissions causing these errors, but then end up in a state where I get the error: Permission ViewAllData depends on permission(s): ViewAllForecasts, ViewPublicDashboards, ViewPublicReports

I am aware of the Org Shape Pilot and have attempted to sign up. Would creating a scratch org from a shape address the issue I'm having?

Improve this question

1 Answer 1

Reset to default
2

I think that the emerging best practice for DX and permissions is to use permission sets instead of modifying profiles. It adds the extra step of assigning permissions sets in production, but makes sure that all the dependencies run in one direction i.e. scratch org doesn't need to know about production permissions.

I foresee us ending up in permission set hell one day where we have hundreds of permission sets to manage, but this is the best anyone has come up with so far.

Improve this answer
4
  • 1
    That could be helpful. I've been unable to figure out how to manage page layout assignment via permission sets. Is there a way to do that? Assuming not, it seems like the overall workflow would be something like.... 1. Manually assign users to the built in profiles in prod 2. Manually assign permission sets to users in prod 3. Remove permissions from prod profiles as needed & document 4. Create scratch org 5. Remove permissions from profiles in scratch org per what was documented 6. Leverage SFDX to develop & configure the scratch org 7. Deploy changes to production #3 concerns me
    – user2270837
    Commented Aug 7, 2018 at 17:07
  • 1
    I attempted the steps above, and item #3 is a big issue. It seems as though any time I wish to modify the field level security for a non-custom field, I'm going to have a problem as when you modify field level security, you're actually modifying the profiles. Thus, if I modify such a field in a scratch org, perform a pull, I end up with profiles in my source tree that won't work in a production org. Does this sound correct, or am I missing something?
    – user2270837
    Commented Aug 9, 2018 at 5:26
  • 1
    If I follow you correctly, you just need to create a .forceignore file in your sfdx project to say you don't want profile changes in your source tree. See developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/…
    – Aidan
    Commented Aug 9, 2018 at 6:42
  • 1
    Thanks, I was unaware of that. That will help if I can't do what I'm trying to do in code. As an example, only certain users should be able to change the owner of an opportunity, so that field should be read-only by default and then enabled for some users via permission sets. However, I can't figure out how to automate making that field read-only in both scratch orgs and production because the information is embedded in profiles which are not compatible between scratch and production. I don't necessarily need to do this in a .profile-meta.xml file if there's another way to script this.
    – user2270837
    Commented Aug 9, 2018 at 14:56

You must log in to answer this question.

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