Apex Code Development You need to sign in to do that
Don't have an account?
waylonatcim ownership change and the hierarchy
my company has 2 different departments that we like to keep separated, as far as the data in the system is concerned. As a result, we have sharing rules setup for Accounts and Contacts that keeps this separation. We also have a role hierarchy setup for each respective department, to allow for the local admins to modify the data. The issue is that the local admins on side A need to be able to modify records that are owned by other local admins on side A. This cannot be done since they are on the same level in the role hierarchy, and one would need to be higher up in order to make changes. But since all of the 'local admins' need equal access to modify records, there is no way we can setup a role hierarcy to match this.
Has anyone run into this type of issue or have any idea how we can solve it? it doesn't just stop with being able to modify records, they would need the ability to change the ownership as well, which is the real gotcha here since I don't believe account teams or individual account sharing (which would be a pain to setup anyways) would fix the problem.
Thanks
Hi,
You can try the following workaround
1) Try creating two Groups for Local Admins in Dept A and Local Admins in Dept B.
2) Create two sharing rules, whenever Group A creates records it should be shared to Group B and Vice-Versa.
Let me know if this suits your requirement
Thanks for the reply,
I am essentially doing this by just sharing group A with group A on the necessary objects. The problem is that the owner cannot be changed, nor can records be deleted by anyone in that group A. What I'm looking for is full-ownership rights for the non-owners (local admins).
Groups have a limitations. You need create QUEUEs instead of groups and via workflow rules make queue to be owner of records. All users would be added to one of these 2 department queues as queue members.
Can queues own Accounts? I thought they were limited in what they could be the owner of.
Even so this does not solve the issue. That would mean I would have to have most records in my system be owned by queue's, which is not what I want. All I want is for certain users to have admin privileges over the records that they can see (via sharing rules). I would still like to be able to have individual users own records.
If thats the case, you can give "modifyall" previlege to a new profile, and assign that profile to those particular users that needs admin permissions to the records within that object. A simple way is to clone existing group A profile and add an extra permission of modifyall to it nameas groupA_admins. with yet, they would not work on admin of the entire application.
yes, queues can own records and they are best/quick solution on how to implement security with SF. A queue assignment on the fly can easyly managed by workflows. In our organization we have queues created for all departments and all users are grouped under queues. For all applications the record owners are set as queues via workflows. Each department users would see only the data they are supposed to see pertaining to their departments, how many users join/leave/or jump among departments.
By setting the "modify all" permission on an object in profile A, that opens up every record of that type of object to whatever users have profile A, including all records in the B group. Modfiy All trumps sharing rules.
As far as queue's owning accounts, can you link me to some documentation showing this? This is something that would be extremely usefule for me but I have never seen anything showing that queue's can own accounts, and in fact I have seen postings suggesting otherwise: http://sites.force.com/ideaexchange/ideaView?c=09a30000000D9xt&id=08730000000BrESAA0
Yes, you are right on account object wrt queues.
I tried to create queue on account object but not listed.
I tried other work arounds but no luck.
Here is some work around I used as a trigger that would delete a manual share and re-insert a new share every time a record is updated based on some conditions...
Just modify this to fit for your need. Good luck!
trigger update_sharing on mytableobject__c (after update)
{
List<mytableobject__Share> ctShares = new List<mytableobject__Share>();
List<mytableobject__Share> ctdels = new List<mytableobject__Share>();
for(mytableobject__c c:Trigger.new)
{
if (---some condition---)
{
oids.add(c.id);
}
}
ctdels = [SELECT id FROM mytableobject__share where Rowcause = 'Manual' and parentid in :oids];
for (mytableobject__share obj : ctdels){
delete obj;
}
for(mytableobject__c ct : trigger.new)
{
if (--some-another-condition---)
{
mytableobject__Share ctShare = new mytableobject__Share();
ctShare.UserOrGroupId = Ct.user__c ; // change as per logic
ctShare.ParentId = ct.Id;
ctShare.AccessLevel = 'Edit';
ctShare.RowCause = 'Manual';
ctShares.add(ctShare);
}
}
insert ctshares;
}
}