2

I'm fairly new to Salesforce and am having trouble wrapping my brain around all the different permissions settings. So far the other guys on my team have been handling that stuff while I've been having fun with Apex. But, lucky me, they just handed me a requirement involving permissions. Two related requirements actually. And I'm a bit stuck.

First I should provide a little background: We're using Enterprise Edition. We have 50 offices and have structured our role hierarchy to look something like this (sorry about the spacing):

  • OverallCompanyAdmin

    • Office1Admin
      • Office1Manager
        • Office1User
    • Office2Admin

      • Office2Manager

        • Office2User

        • etc.

The first requirement is to make it so that users in the OfficeManager role can change the account owner for any record where the account owner is a user in their office, but not in other offices ("Office" is a custom field on the user record). So, if there is an account owned by Office1UserA or Office1UserB, etc., Office1ManagerA should be able to change the account owner. But, Office2ManagerA should not be able to change the owners on those accounts. We have a number of sharing rules in place, as well as profile definitions, but it seems like we can only achieve all or nothing -- either the OfficeManager role can't change the owner on any accounts but his own, or can change owners on all accounts.

The second requirement is for dealing with "unassigned" accounts. We created a user named "Unassigned" who is in Office51. If an account is owned by "Unassigned," then any Office Manager in any office should be able to change the account owner (the idea being that if an account is unassigned, any office manager can reassign it). We created a sharing rule for the Unassigned user, but it's not working.

Is it possible to achieve these two requirements with the standard security tools in Salesforce? Or would I need to create an Apex sharing rule? By the way, I have read the Salesforce documentation, have read a bunch of other articles, and have pored through forums to try to get a handle on this and find a situation similar to mine, but I'm still not sure at all how to approach this. Any pointers would be greatly appreciated. Thanks.

Edit/Update:

I've spent some time digesting your responses and going over our security settings, and I've found that with the role hierarchy in place and the users assigned to the proper roles and the correct profiles, the OfficeManager role is able to transfer record ownership for users in his office. An OfficeManager is not able to transfer record ownership for other OfficeManagers in his office, but we can live with that.

However, I'm a little unclear on the suggestions about how to handle the "Unassigned" accounts. It appears that sharing rules do not confer the right to transfer ownership, and because in our company all users can see all accounts, we have not given that permission to the non-SysAdmin profiles. So I think that creating an "Unassigned" role and sharing it wouldn't achieve the desired result of allowing any OfficeManager to transfer ownership of an "Unassigned" account...unless we could somehow put "Unassigned" at very bottom of the role hierarchy. Is this possible?

3 Answers 3

2

Depending on how your permissions are set, then yes, this should be doable. A user can only transfer record ownership of records to which they have access, so people in Office 1 should be able to transfer their records around.

If people in Office 1 do have access to Office 2's records then you'll have problems. You could circumvent this with custom coding that enforces your business rules or (my recommendation) train users to not transfer records from outside of their office (and you could use field history to maintain an audit trail of ownership.)

The second part, for "Unassigned" accounts would be easy; just give every office manager access to those records via sharing rules.

4
  • 1
    To clarify, just set up the role hierarchy at Setup > Manage Users > Roles. Make sure each user is assigned to their correct role, and the manager-employee relationship will automatically allow managers to transfer records from any employee they manage. The sharing rule is under Setup > Security Settings > Sharing Settings. Just assign "Unassigned" to a role, and share that role with "Entire Organization".
    – sfdcfox
    Commented Jul 26, 2013 at 13:30
  • Thank you for your suggestions, Mike, and for your instructions, sfdcfox. I believe my first issue is now resolved, but I'm still having trouble with the "Unassigned" issue. Please see the Edit/Update portion of my original post for details (which wouldn't quite fit in the comments because I'm too wordy).
    – djackiem
    Commented Jul 27, 2013 at 10:08
  • I'll have to test it out in a Dev Org and get back to you.
    – Mike Chale
    Commented Jul 29, 2013 at 10:23
  • Update: We ended up creating an "Unassigned" user for each of our offices and assigned that user the OfficeUser role for that office. This way, if another OfficeUser wants to claim that account, he can request that the OfficeManager make the change for him. This is a primitive solution, but it works from a procedural perspective.
    – djackiem
    Commented Aug 2, 2013 at 18:48
0

@djackiem I think I do have a solution for your remaining problem. But unsure if you still want it - your question is 1 year old. If yes, just comment here and I will respond with my idea. cheers.

1
  • sorry for the slow response. Yes, I would be most interested in your solution!
    – djackiem
    Commented Mar 16, 2015 at 9:47
0

@djackiem No problem at all. I dont remember my solutions exactly right now. But this should work - you should give your office manager's profile "Modily All" on the accounts object. This will let them transfer them.

PS. you can still use private as OWD on accounts if you dont want to give your managers access to edit any records.

Do let me know if this works for you. or if it doesnt.

You must log in to answer this question.

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