Profiles

What is a profile?

A profile is a collection of permissions and settings that is instrumental in determining a user’s functional access (apps, tabs, object-level permissions), how information is displayed to the user (page layouts, record types, field-level security), and a wide range of other permissions.  Each user must be assigned one profile.

[twocol_one][table id=29 /][/twocol_one] [twocol_one_last][table id=30 /][/twocol_one_last]

[link id=363] settings will be expanded upon in detail later in this guide.

What’s the difference between standard and custom profiles?

Standard profiles are included with Salesforce.  Object-level and user permissions cannot be changed on these profiles.  Standard profiles cannot be deleted.

Custom profiles are created by an administrator and can be fully customized.  Custom profiles can be deleted.

When should I create custom profiles?

Generally speaking you’ll want to create custom profiles prior to assigning users to profiles.  As you have limited ability to change standard profiles, it is generally a best practice to assign all users (with the exception of the system administrator) to custom profiles.

If users are assigned a standard profile and you later need to change their permissions (e.g. add read access to a custom object), you’d have to create a custom profile and then migrate all of those users to the custom profile.

35 thoughts on “Profiles”

  1. Hey John,

    I don’t get what the grid at the top of this page is trying to show… “Security” “User Interface”, is it just showing what Profiles include? Do profiles include Page Layouts?

  2. Hi John,

    I have aquestion with regard to App access.
    We have a free source app installed on our live environment that allow MERGE for various objects (incl. custom). It was not installed by me and I see that it is not limited to number of licences.
    I allowed access to that app for a certain profile – successfully. However, when the user try to use that app she gets an error message that the app is not accessible for her.
    What am I missing here?

    Thank you,
    Gil

    1. There is probably a visualforce page or something like that contained within the app that they need access to as well- check the components in the managed package.

      Also check the docs in the managed package for advice. Lastly, see if there is a permission set included in the managed package that can easily assign the permissions without having to track all that down.

  3. John – What is user permission on a profile regards to that they cannot be changed on standard profile. What are you referring to when you say user permissions

  4. Need help with setting up profiles / users

    I am on a test Dev environment trying to create some users on my Org and mapping them to some Custom profiles

    On None of the user records I create, I get an option to choose “Salesforce” user license. Is this a limitation on the Dev Org ?

    Only Options I see are “Salesforce platform” , “Force.com-Free” …. These Licenses do not let me choosed Custom profiles I created.

    Need advise please !

    1. You are limited to only two user license in dev org as its a free account. Note that two includes your admin profile too. So ideally you can create only one more user. Either you would have already used the license and that’s why you don’t see anymore. Try to disable the active user and then create a new user and add content. That’s how we do workaround. Hope it helps.

      1. Agree that’s a limitation.

        But curious to know what’s the workable alternative to set up a test org with a few users, profiles, roles for trying a lot of scenarios / quizzes hands on

  5. Hi Jon
    Couple of question

    1) If on profile level for the opportunity I have “Modify All Data” and on OWD it is Public Read only Only. Would I be able to edit the opportunity records I do not own ?

    2) I have enabled the role hierarchy .On Sales Rep Profile for opportunity CRED is enabled and I want that Sales Manager should only view(not edit and delete) the opportunity of the subordinate. How can I achieve this.?

  6. Hi John, Great website!
    Under the first paragraph of this page, “What is a Profile?”, what are the two columns describing? For example, in the second row: is it showing that configuring the Object-Level Permissions is a way to control permissions to the Tabs in the User Interface?

  7. On the salesforce video:”Who Sees What: Object Access”, they assign a custom profile to Karen Adams. They then assign it to all members on the inside sales team. I did not see how they assigned it to all the members of that sales team?

  8. Its mentioned as “Object-level and user permissions cannot be changed on standard profiles”. Does it mean we cannot apply sharing or field level security and override default security in standard profile? So in real life, ideally the admin will always clone standard profile and create new one instead of directly using the standard profile?

    1. “Sharing” (meaning record sharing) is typically applied via the role not profile, minor point of clarification. But yes, the admin can only modify a small portion of the standard profile permissions (e.g. field level security and/or object level security), so it is customary to create custom profiles.

  9. Just when I thought I was pretty good at security settings, I find out how limited my knowledge is. I can definitely eliminate some of my org’s profiles and create more permission sets to apply.

  10. Hi John,
    For the statement: “If users are assigned a standard profile and you later need to change their permissions (e.g. add read access to a custom object)…” can’t we use permission sets to assign more permissions instead of having to create a custom profile and migrate all the users? Which of these two methods is more preferable?

    1. I still like the recommendation of assigning users to custom profiles. While permission sets can add permissions, I don’t think they can remove them. And permission sets need to be applied individually to each user. Custom profiles allow you to add (or remove) a permission globally. More efficient, imho.

      1. It is a best practice to use custom profiles because you cannot modify most of the standard profiles. Yes you could use permission sets for everything, but you would end up with a lot of overhead managing all of the permissions on a per user basis. Generally I agree with Alex- start off while a profiles that meet the majority of the users needs. Then add permission sets to handle the ad-hoc or less frequent scenarios.

    1. One user record can only be assigned to one profile. It is possible to create more than one user with the same email address – however, the username (which is typically the user’s email address) must be unique across all orgs.

Leave a Reply