0

I am wondering if we have misused the Role Hierarchy...I have three roles like:

Manager
Team Leader
Team Member

These (and others) all belong (via their role) to the same Public Group and the same Queue. There are sharing rules to share the objects records between these public groups and queues using read/write. The users all have the same profile.

Anyway I have found that starting at the top the users can change the owner of any record including that of those belonging to their subordinates. Unfortunately at the bottom the team member can change the owner of their own records and those belonging to the queue. However they can not change the ownership of records owned by people above them in the hierarchy.

I hope that makes sense can someone suggest a way around this? (In this case all of the users should be able to change the owner of any record regardless of their role )

6
  • Role Hierarchy controls who can see and edit specific records. Try giving access using profiles and permission sets. Commented Feb 28, 2017 at 12:00
  • Thanks for replying - I thought about it but they have read/create/edit within the profile, I can't grant view all as I can't grant them access to records related to other teams...the OWD is also private, I didn't mention that above. The queue and public group are used in the sharing rules (read/write between each other)...the roles (and subs) are set within these.
    – n34_panda
    Commented Feb 28, 2017 at 12:03
  • I suspect this is happening because of OWD since it is private. I've faced similar issue for Activities, in my case changing OWD worked for me. Refer doc of Salesforce link Commented Feb 28, 2017 at 12:09
  • Ah...bu^&er. I'll take a look at the link. I have had a thought - I just tried adding a sharing rule so records owned by the top level manager's role and subs were shared to the same roles and subs...it didn't work either.
    – n34_panda
    Commented Feb 28, 2017 at 12:11
  • That would be great if it works Commented Feb 28, 2017 at 12:14

3 Answers 3

3

Delete permission in salesforce is always strictly per the role hierarchy. This is the case even if org wide defaults are set to public read/write.

The only exception is users with modify all data or modify all object level permission. They can delete any records.

See this help doc

Where it says

The ability to delete records in Salesforce is controlled by the role hierarchy. Setting a sharing model to ""Public Read/Write"" alone does not give users the right to delete others records. 

Those below you on the role hierarchy may have read/write privileges according to the sharing model rules, however, they may not delete information from those individuals above them in that hierarchy.

Note: If a user is assigned a profile that has "Modify All" on a particular object, then the user will be able to delete any record in that object. System administrator profile has "Modify all Data" giving them the privilege to delete any record in any object

UPDATE sorry thought this was about delete permission, but change owner follows same logic for most objects, though a couple can have org wide defaults that include transfer permissions

See this doc for the details, including

A record owner, or any user above the owner in the role or territory hierarchy, can transfer a single record to another user. With some objects, like cases, leads, and campaigns, a user may be granted access to transfer records through sharing. Depending on the type of object, there may be multiple ways to transfer records to another user:

5
  • Thanks the final part proves our hypothesis. If I read the part underneath your final quote correctly does it mean only some standard objects allow transferring of a single record? My object in question is standard but not listed. At the minute my only answer to resolve it is to assign everyone in the group the same role
    – n34_panda
    Commented Mar 1, 2017 at 0:47
  • Granting everyone modify all on the object would also allow transfer, but with delete. I'm surprised that being in the same role would allow transfer, haven't tested, but it shouldn't. You could use visual workflow or visualforce to code up a page that runs in system mode to allow anyone to transfer. If object isn't listed in the doc assume there is no special transfer perms. I think it's just leads and cases that have those.
    – gorav
    Commented Mar 1, 2017 at 0:54
  • Thanks will test those tomorrow to see a solution presents itself. Thanks for the help.
    – n34_panda
    Commented Mar 1, 2017 at 0:56
  • You were right gorav, having the same role didn't help. I think the easiest solution would be to grant Modify to the profiles - I'll do an assessment of how that could impact things today. Thanks for your help - I'm sure i'll get the permissions in Salesforce in 10-20 years time.
    – n34_panda
    Commented Mar 1, 2017 at 9:04
  • Needs some more testing but I have set the "Transfer Record" permission in the profile.
    – n34_panda
    Commented Mar 1, 2017 at 12:43
0

This question is a few years old, but if anyone else is trying to figure this out years later (like I just was), you can create a sharing rule underneath the Org-Wide Defaults in "Sharing Settings" that lets you give one role access to another role's records.

In my case, I had a VP of Sales that sometimes asks one of their directors to update their opps while they're on the road. I was able to create a sharing rule that gave that director read/write access to opps owner by the VP.

0

We have one more option in Permission set which we can use to give it to the user so he can easily change the ownership of a records "Manage Record"

1
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Oct 26, 2023 at 13:30

You must log in to answer this question.

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