9

I am confused about the hierarchy of settings

1) I have a profile A and it has a read only access. I have a permission set specific to an user and the permission set grants the user access to edit the opportunities in the system.

2) The Org wide default is private and the role says the user can view all data.

When I login as the user with the permission set that grants edit access, I see the edit button but when I edit I get " Insufficient Access"

Is there any setting that can override the permission set/is it because of the OWD I am being thrown off ?

Is there any way to find out why the "Insufficient privilege " shows up?

Improve this question

4 Answers 4

Reset to default
13

Your permission set will grant the user the permission to edit opportunities, but they will still need write access to individual opportunity records in order to be able to exercise that permission and edit them.

I'm slightly confused by the "role says the user can view all data" aspect, as roles don't give access in that way. Profiles can have view all data permission, or the users position in the role hierarchy may allow them access to the opportunities owned by other users below them, depending on your org-wide defaults.

If you want that user to have edit access to all opportunities in the system, I can think of a couple of ways that should do it:

  • Put them at the top of the role hierarchy or
  • Put them into a public group and create an ownership sharing rule for opportunities owned by your top level role and subordinates (i.e. every user in the system) with that public group

The latter is better IMHO, as it only shares opportunities, whereas putting a user at the top of the role hierarchy gives them access to all objects configured to allow access via hierarchy.

Improve this answer
1
  • I understood that the OWD is the critical piece that I missed. I created a public group assigned the users to can edit and granted them access to all users records :)
    – Rao
    Commented Oct 31, 2012 at 16:58
7

It does sound like the OWD.

  1. To start, you have your OWD set to private, so users can only see the Opportunities they own.

  2. You then gave the user View All for Opportunities, which overrides the OWD for visibility, but that doesn't grant Edit to all records.

  3. The Permission Set granting Edit access allows the user to see the Edit option, but the user still needs some kind of sharing rule to allow them to edit that particular record.

There are a few ways to share out edit access; Role hierarchy, object sharing rules, sales teams, etc. . . You may want to review the Overview of Sharing Settings.

Improve this answer
5

Profiles and Roles are 'different' for want of a better word. Complementary even.

Roles :

OWD is the foundation which decides whether our data is setup in Private / Public Read Only or Public Read Write. This is the most restrictive data setting.

When the OWD is Private, Sharing Rules become available to open up the OWD data restrictions to groups of users or roles and subordinates. These can either be ownership based or criteria based(with some limitations)

Another way to share data is through Apex sharing where you can programmatically insert share records based on custom logic too complex to encapsulate as Criteria Based Sharing Rules.

Profiles control what you can do with the data that is visible to you, certain administrative permissions and of course which objects in the schema you have access to.

Field Level security for example lets you control at a Profile Level which fields are visible or read only to certain profiles.

The View All Data and Modify All data permissions on the Profile are exceptions because they bestow 'SuperCow Powers' on the users with that Profile. Hence why they are normally granted only to Full System Admins.

Permissions sets are a way to provision profile permissions in a modular fashion so you can group a bunch of related permissions. Permission sets supplement the permissions already granted to a user by virtue of their user profile.

Additionally Profiles also control which Apex Classes and Visualforce pages you have access to.

In summary, unless its via Custom Visualforce, an Insufficient Privileges error when trying to access data will be down to the Role Hierarchy.

Improve this answer
9
  • 3
    My quick reference for this is Profiles=permissions, Roles=records.
    – Bob Buzzard
    Commented Nov 1, 2012 at 9:13
  • 1
    Except for ViewAllData and ModifyAllData which mixes things up. Does this sound right? Tempted to turn this into a lazy blog post ;)
    – techtrekker
    Commented Nov 1, 2012 at 9:22
  • 1
    Outstanding answer @techtrekker !! I like it!! The sharing PM and I did a session at dreamforce the year before last that helps put this difficult topic into perspective: youtube.com/watch?v=uc13wsQJzz0. You can think of profiles answering the question 'what can a user do' and sharing answering the question, 'what records can a user work with'. For each object, Profiles/Permission Sets control Object CRUD for no specific record and Column access with Field Level Security. Sharing Roles, Groups, and Rules control record access only but scale really well.
    – Adam Torman
    Commented Nov 1, 2012 at 20:23
  • 1
    The model is meant to be complimentary, allow you to scale record access out while keeping functional access (CRUD/FLS/Apex access, etc...) relatively simple. For the most part, it's a layering model where you lock down record access through OWD and then open it up through a dozen different tools like roles, groups, rules, manual or apex shares, etc... Profiles and Permission Sets also control other user access rights outside of object and field access - they control apex pages/classes, assigned apps, tab settings, service providers, functional user permissions.
    – Adam Torman
    Commented Nov 1, 2012 at 20:25
  • 1
    Profiles and Permission Sets are essentially the same container with only one key difference - a user may have one and only one profile but that same user may have 0, 1, or many permission sets. Since permissions layer in positive fashion between a user's profile and all assigned permission sets, there shouldn't ever be a conflict. But because of this relationship, you can think of a user's basic access through their profile but extending out their functional access by industry, region, app, or whatever other business segment using the modualarity of permission sets.
    – Adam Torman
    Commented Nov 1, 2012 at 20:27
1

It may be the OWD. Try this - Login with a user that has the normal profile permission same role as your permission set user and edit the same record. Make sure neither user is the owner of the record.

If you get the same error chances are it's the OWD. Try the same test with a record being owned by the user.

Another option - on the permission set give the user view all and Modify all on that object. That should also remove the permission error. It'll mean they'll be able to edit and see any record regardless of owernship.

Improve this answer
1
  • Modify all opens up delete permissions to the user!!!I want to give them only a edit access. So irrespective of the mentioning on the profiles/permission sets OWD preceeds the 2. One other interesting thing I saw was when I give access through sharing rules the users are able to edit the opportunities!!! Am I understanding the hierarchy right now?
    – Rao
    Commented Oct 31, 2012 at 16:37

You must log in to answer this question.

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