This is going to be one of those posts that states the obvious; that is, it will make perfect sense once the object relationships and functionality are understood. The catch for a relatively new and excited administrator is that the power of SFDC seems endless (translation: you can do almost anything without code). Of course, even this platform has limitations.
Challenge 1
All managers should be able to add members to any opportunity team.
The role hierarchy in this case is very basic. Each sales manager is in charge of a group of sales representatives. The sharing model for this object is read only. By default the sales representative who created the opportunity can add to the team. This permission applies to her manager as well.
Challenge 2
All sales representatives should be able to transfer “unassigned” accounts.
Assume that accounts are routinely imported from an external source. The owner is initially set to a generic integration user. If a sales representative is interested in working an account then he needs the ability to transfer the account to himself only if the current owner is the generic user.
As with the first challenge, only the sales representative who created the account and those above the owner in the role hierarchy can transfer ownership.
Opportunity teams are unique
There are two traps I fell into with this one. I thought I had “Challenge 1” solved after watching Shell Black’s video on role hierarchies.
Intoxicated by the power of sharing rules I created a public group of all managers and shared with this group read-write access on opportunities created by any user. Now I could edit opportunities … but not the teams.
Trap #1: There is a difference between opportunity details (the opportunity record itself) and the related lists. Okay, very obvious.
Trap #2: The opportunity team is not a standard related list. If it were to be one, we would expect to have the opportunity team object exposed in profiles so that CRED permissions could be set. Not quite.
Transferring ownership is not equivalent to editing
Overcoming my misunderstanding of opportunity teams I really thought I had this one nailed. Returning to sharing rules, I created a public group with all sales representatives and shared with this group read-write access on all accounts owned by the integration user.
Great! So now all the sales representatives could edit all accounts and this includes transferring ownership … it’s just editing the account, right?
Of course not.
This makes sense, though. If we look at the organization-wide default sharing settings only leads and cases have transfer as an option.
Regardless, there are no sharing rules that offer transfer as a choice. The options are only “Read Only” and “Read/Write.”
Solution
The optimum permissions for the manager or sales representative are read, create and edit. We do not want users associated with either profile to have the ability to delete opportunities or accounts. Unfortunately, the edit permission does not extend to opportunity team assignment or ownership transfer.
What is interesting is that a System Administrator is able to perform both of these functions. The magic permission is Modify All.
While this is not the optimal solution it appears to be the “least of all evils.”
Challenge 1
- Grant Modify All access for Opportunities in the Sales Manager profile.
- Create a “before delete” trigger for the opportunity object. Do not allow the deletion if the user has the Sales Manager profile.
Challenge 2
- Grant Modify All access for Accounts in the Sales Representative profile.
- Create a “before delete” trigger for the account object. Do not allow the deletion if the user has the Sales Representative profile.
- Create a validation rule on the account object that denies the transfer of ownership if the user profile is not “System Administrator” and the current owner is not the integration user:
1 2 3 4 5 |
AND( ISCHANGED( OwnerId ), $Profile.Name != “System Administrator”, PRIORVALUE( OwnerId ) != “005L0000001RPYo” ) |
Summary
The challenges presented in this post are fairly uncommon and were presented only as a launching point for the broader conceptual discussion. In my experience it is the journey that is more valuable than the solution. With a little extra effort we are able to grasp the concepts behind the behavior and knowing these concepts will invariably help us with future challenges.