How to retrieve Custom Profiles' objectpermissions using SFDX or MDAPI

Question

Problem

The <objectPermissions> tags are missing from my custom profiles when I pull from a scratch-org using SFDX or MDAPI.

Steps to reproduce

1. Create a new Scrach-org.
2. Create a custom profile, say "Support".
3. Add some Standard Object Permissions to the profiles. Looks like this:

4. Use SFDX pull or MDAPI Retrieve.

The Support.profile-meta.xml contains all the settings I added to the profile, except for <objectPermissions>. The missing tag should look like this:

    <objectPermissions>
        <allowCreate>true</allowCreate>
        <allowDelete>true</allowDelete>
        <allowEdit>true</allowEdit>
        <allowRead>true</allowRead>
        <modifyAllRecords>true</modifyAllRecords>
        <object>Account</object>
        <viewAllRecords>true</viewAllRecords>
    </objectPermissions>

If I now push the profile to a new scratch org, then the profile will be missing some permissions such as View All and Modify All since the tags are missing. Looking like this:

Questions

How can I use SFDX or MDAPI to retrieve the missing tags? Or, do some workaround exist?

Answer 1

Note: this works for api version 44.0

Turns out there's a trick to doing this with the Metadata API

If your package.xml file only contains

    <types>
        <members>Support</members>
        <name>Profile</name>
    </types>

Then it only retrieves user permissions, license information and whether or not it's custom. My best guess is because of the dependencies on the other metadata.

With that being said, simply add the remaining metadata components you're looking to retrieve that are related to the profile to the package.xml file:

    <types>
        <members>Account.Custom_Record_Type</members>
        ...
        <members>Task.Custom_Record_Type</members>
        <name>RecordType</name>
    </types>
    <types>
        <members>Account</members>
        ...
        <members>Task</members>
        <name>CustomObject</name>
    </types>

And the result of your profile metadata api retrieval will look like this:

    ...
    <objectPermissions>
        <allowCreate>true</allowCreate>
        <allowDelete>false</allowDelete>
        <allowEdit>false</allowEdit>
        <allowRead>true</allowRead>
        <modifyAllRecords>false</modifyAllRecords>
        <object>Account</object>
        <viewAllRecords>true</viewAllRecords>
    </objectPermissions>
    <recordTypeVisibilities>
        <default>false</default>
        <recordType>Account.Custom_Record_Types</recordType>
        <visible>false</visible>
    </recordTypeVisibilities>
    ...
    <recordTypeVisibilities>
        <default>false</default>
        <recordType>Task.Custom_Record_Type</recordType>
        <visible>false</visible>
    </recordTypeVisibilities>
    ...
    <tabVisibilities>
        <tab>standard-Account</tab>
        <visibility>DefaultOn</visibility>
    </tabVisibilities>
    ...
    <userPermissions>
        <enabled>true</enabled>
        <name>ViewRoles</name>
    </userPermissions>
</Profile>

All of the steps in how to do this are listed here in this article.

Answer 2

Kai Tribble answered nicely for metadata api.

If you are using source format, you should pull all other the metadata with the profile that aught to be in it. For example, this would get the Profile and any permissions for CustomObjects and Apex Classes:

sfdx force:source:retrieve -m "Profile, CustomObject, ApexClass"

Answer 3

On the whole, SFDX doesn't work well with profiles.

If you're using unlocked packages with SFDX to break your system into modules, the problem is that a single profile may need to have permissions relating to many modules. So each package would need to write to the same profile, and they can't all own the profile.

So, the usual approach is to use permission sets to handle the permissions on a per-module basis. Or ignore the permissions in SFDX and just set up the profiles after installing into the target org.

It's one of the areas where SFDX is a bit underdeveloped at the moment.