1

We have our most up-to-date metadata source in Git. When we create the new scratch org and deploy our code, it deploys correctly and the profiles have the correct access to all of the objects. However, when we change a field or layout that affects a profile, and pull all the metadata from the new scratch org, it tells us that there is a bunch of metadata in the profiles that has been changed or deleted. But this isn't the case!

For example, the Admin.profile-meta class says that all the tab visibilities are deleted: enter image description here

But when I go to Setup > Profiles to see if this is the case, I see all the tabs as DefaultOn. enter image description here

We can even continue to deploy metadata in this org with these changes, and the Admin can still see on the tabs.

This is creating a real headache for us when committing to Git, because if we commit these weird changes, the next time that we open a scratch org, the Admin user won't have visibilities to these tabs. We then have to revert commits and fix the accidental addition of this weird metadata. Has anybody come across a similar issue? I am noticing that it doesn't happen so much with custom profiles, maybe we should just duplicate the Sys Admin profile and work with it instead?

Improve this question
1

You're not meant to use profiles with Salesforce DX. Instead, you should be creating permission sets. There's some documentation on the matter.

sfdx force:user:permset:assign --permsetname <permset_name> --targetusername <username/alias>

By not relying on the profile having the correct settings, but instead using permission sets, you'll save yourself a lot of hassle in the future.

ISVs have been told for a long time that Permission Sets are the correct way to implement permissions for apps, and it's generally a best practice for everyone to start using Permission Sets. I can't say too much, but let's just say it's in your best interest to start using them in order to prepare for the future.

Improve this answer
5
  • Yeah, I saw this piece of documentation, but it didn't say not to use profiles. Do you know why we can't use profiles though? – Jon Duelfer May 14 '18 at 14:08
  • Ok, I guess we will try to implement some permission sets then. So whenever we create new fields, we should deselect the "visible" and "read-only" checkboxes, and only give access via Permission Sets? It doesn't seem like too big of a change. – Jon Duelfer May 14 '18 at 14:16
  • 1
    @JonDuelfer Profiles are approaching their 20th birthday; they were implemented for the needs of the day, but are now really just a relic. In fact, did you know there's a Permission Set for each profile (query the PermissionSet object and see for yourself). You could use custom profiles, but you're really just using a Permission Set under the hood anyways. Your DX experience will go a lot smoother if you use Permission Sets. – sfdcfox May 14 '18 at 14:17
  • I'm Starting off from Scratch. Which Profile do you start with. It looks like I'd have to have something more restrictive than the read-only profile. – Dan Jul 15 '19 at 16:35
  • @Dan I'm not sure I understand your comment. In many cases, either Read Only or Standard User should be sufficient for most use cases. The main point is that you should be setting field level security, Visualforce, Apex, and custom object access via Permission Sets. Aside from that, you should consider starting from the profile that "makes the most sense", which almost certainly will be either Standard User or Read-Only, although in some highly sensitive orgs, creating an empty profile with no settings and turning everything on manually may be an option. – sfdcfox Jul 15 '19 at 16:50

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.