I removed references to a deprecated object's layout from profiles.

Basically removal of the following:

        <layout>Deprecated Object Layout</layout>

results in a failure and looking at the logs I see 3 culprits:

1). Guest License User.profile

Error: You may not modify the permission Remove People from Direct Messages while editing a Standard Profile

I know that it is referring to API name 'RemoveDirectMessageMembers' but I dont see that anywhere in the profile.

2). CMManager.profile

Error: You can't create, edit, or delete records for this permission set parent because it's associated with a standard profile. Parent ID: JKF15000000Ob7e  

I googled this and while there were a few articles on this type of error, I will be honest I am not fully clear.

3). SMManager.profile

Error: You can't create, edit, or delete records for this permission set parent because it's associated with a standard profile. Parent ID: JKF15000000Ob7e

Same as above.

I did :

select Id, name, label from permissionset where id = 'JKF15000000Ob7e' or id = 'JKF15000000Ob7e'

And I see two permission sets like :

X00ex00000018ozX_128_09_43_34_5 and X00ex00000018ozX_128_09_43_34_7

Yet I do not see them in the UI. I researched further (https://help.salesforce.com/articleView?id=000339288&type=1&mode=1) and read that permission sets that start with an X do not exist and are actually profile ID's. But X00ex00000018ozX_128_09_43_34_5 and X00ex00000018ozX_128_09_43_34_7 do not look like ID's to me.

I have not seen these errors before. I guess I just need to understand what the problem is because the error messages dont really tell me anything actionable. Any tips?

  • I'm trying to recreate your problem. You should not be able to remove the layout assignment while the object still exists in your org. You're editing the profile.xml, correct? Can you include a screenshot of your deployment script and a screenshot of one of the above-referenced profile xmls? Apr 18, 2021 at 6:57
  • Not remove layout assignment while object exists in org? But when you try removing an object it complains about references. What is the order of operation if you want to just remove a deprecated object? Yes these are edits to profile and permissionset xmls. I will try to add a screen shot.
    – kratos
    Apr 18, 2021 at 12:37
  • 1
    what's the goal here? Are you deleting the object manually in the UI or are you trying to delete the object through a deployment through the metadata? If you deleted it manually in the UI then the layout references just simply need to be pulled from the org (as Salesforce handles its removal when the object is deleted). Apr 20, 2021 at 14:09

1 Answer 1


All Profiles are also stored as PermissionSet records that can be identified by the IsOwnedByProfile boolean field. This is how the Permission Model is handled behind the scenes to reference all user permissions in one place.

The IsCustom field shows you whether it's a custom or standard Profile. Note: Profiles are still tracked in the profile-meta.xml files. The corresponding PermissionSet record is used internally by the system but you can query and find all sorts of useful information in there (even down to Object, Field, Application permissions included for each).

Query all Profile-owned Permission Set records

SELECT Id, Name, Profile.Name, IsCustom FROM PermissionSet WHERE IsOwnedByProfile = true ORDER BY IsCustom

Query All Permission Sets together (both "Profile" and regular Permission Sets)

SELECT Id, Name, Profile.Name, ProfileId, IsOwnedByProfile, IsCustom FROM PermissionSet ORDER BY IsOwnedByProfile DESC, IsCustom

Profile metadata is weird. Even in SFDX, you can't retrieve the complete file by retrieving the individual Profile by itself (it will retrieve a very small subset of the larger file, and I suspect your errors are coming from you inadvertently trying to overwrite the complete file in your org with a condensed version- thus "removing" those permissions you don't currently see.)

You need to retrieve all metadata together (Objects, Layouts, Classes, Settings, etc) along with the Profile metadata files so that all of those dependencies are recognized and retrieved together. Are you using SFDX? You would normally do this at the beginning when generating a package.xml, or setting up your force-app/main/default source folder for everything you want to track.

Also, unless you're actively assigning Standard profiles to Users, I would suggest removing them from your source to avoid some of these common errors that otherwise aren't relevant to your org (except for the System Admin profile).

You must log in to answer this question.

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