Default Record Types & Profiles With No Access To Object Settings

Matt/ February 16, 2016/ Salesforce

I came across something Friday regarding default record types and Profiles with no access to Object Settings (the three Chatter profiles).

I setup a new record type on a custom object and without thinking made it the default record type for all user profiles.  A few days later I went to delete the record type, and was presented with an error telling me I had to pick a new default record type for the profiles it listed.

I know I can use the Migration Tool to do this:

  1. Download and configure Migration Tool
  2. Download all Profiles
  3. Open each XML file and fix the entry:
  4. Upload the new metadata

But we have few enough profiles that configuring the Migration Tool would take longer than the manual labour.  I edited each profile but there were a few I couldn’t access the Object Properties for:

  • Chatter External User
  • Chatter Moderator User
  • Chatter Free User

Some research revealed it’s apparently possible to URL-hack your way into accessing the Object Settings pages for those three profiles.  Cool!

The commenter to the post gave the following incorrect formula:

(I’m not going to link him here because I don’t want to boost SEO on wrong information.)

I tried this and it didn’t work, and it was immediately clear as to why (explained below).  So I edited the formula to this:

This gave me the following three URLS:


Keep in mind, you will have to sub your own values into the formula I provided!  Clicking these links will not give you access to our instance either 🙂

By navigating to the URLs you’ve built, you will arrive at the Object Settings page for each of the desired profiles.  Go ahead and change the default record type to something else so you can then delete the desired record type.

Why was the commenter wrong?

Salesforce runs in a multi-tenant environment, meaning there are many instances of Salesforce hosting in the same database on each of their servers.  As such, the ID of records, objects, etc. must be unique between among all other instances.

So while everybody has an Account object, the ID of that object will be different in each instance.  That’s why using OBJECTNAME will not work, and why OBJECTID must be used instead.


Remember, tables are not objects.  They are SObjects.  A salesforce table doesn’t exist.  What exists is a metadata layer describing the layout.  That meta data is made up of objects, and that is why it is called SObject.

Share this Post

About Matt

Matt is a seasoned Salesforce Developer / Architect, with implementations of Sales Cloud, Service Cloud, CPQ, Experience Cloud, and numerous innovative applications built upon the platform. He started coding in grade 8 and has won awards ranging from international scholarships to internal corporate leadership awards. He is 37x Certified on the platform, including Platform Developer II, B2B Solution Architect and B2C Solution Architect.