function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
HarryLemonHarryLemon 

Preventing Change of Record Ownership

Not sure how many here this news comes as news to, but it sure came as news to us when we learned recently that, irrespective of how restrictive a user's given Profile may be, they will always still be able to change the record ownership on a record belonging to another user to themselves if they wish!

This was acknowledged by the Salesforce tech support team and management, and the only solution we were given was the use of the following validation constraint:

ISCHANGED(OwnerId)

This, however, has the unfortunate side effect of provoking the exact opposite problem accross all users: that of disabling the ability to modify ownership on any record even if you're the Administrator!

Neither situation being acceptable, I figured if I could adjust the formula to apply itself only to those users belonging to the appropriate ProfileID, then all other profile members would continue to be able to modify the ownership of records belonging to other users, and so attempted the following validation constraint instead:

AND (ISCHANGED( OwnerId ) , $User.ProfileId = "00e30000000evEUAAY"

==> By the way, that winking smilie face is supposed to be just a ')' <==

The ID shown is the ID for our sales team's custom profile, but this code - despite passing the syntax checker - provides no constraints whatsoever, even for members of the listed profile! Essentially, this code takes me back to square one, i.e. - as if I had no validation constraints entered to begin with.

Can someone please help us with this?

It's mind-boggling that a program as sophisticated as Salesforce would ommite such an essential function as the ability to restrict users from changing the ownership of records not belonging to them!

Please help...

Thanks,
Philip
jrotensteinjrotenstein
I love a challenge!

Here's a validation rule that gives an error if:
  • Owner has changed
  • Was not previously owned by the current user
  • Current user does not have the System Administrator role

KevinLaurenceKevinLaurence
Philip,

Your statement

"... irrespective of how restrictive a user's given Profile may be, they will always still be able to change the record ownership on a record belonging to another user to themselves if they wish!"

doesn't ring true to me because I've had exactly the opposite problem -- one of my clients has found the default settings too restrictive.

The SF User Guide states:

"Administrators and users with the "Modify All Data" permission can transfer any record that has an owner.

To transfer ownership of any single record in an organization that does not use territory management, a user must have
the appropriate "Edit" permission and either own the record or be above the owner in the role hierarchy."

So I don't understand how your users can change records owned by others, unless every user has been given the "Modify All Data" permission.

Kevin
jrotensteinjrotenstein
True, this reminded me of my Admin training course...

Organization Wide Defaults
These can be configured to allow full access to everyone. It sounds like this is the current setting of your system. Giving Public Read/Write access is the most "Open" setting.

Role Hierarchy
This allows you to restrict access/modification of information to record owners and to people in a role hierarchy. For example, the manager of the record owner could access/modify the record, but not somebody in a different department.

Sharing
This allows people to override the above settings and provide access to other people on a case-by-case basis.


So, you have a choice... Remain on the Public Read/Write settings and try to restrict certain behaviours via Validation Rules (as above), or limit access in general and the create Role Hierarchies to determine who is allowed to access/modify information.

Personally, I work for a company that is very "open" in nature, so the choice is simple. I still restrict access to records based on department (so one department does see the opportunities specific to another department), but otherwise all access is public so that people within a department get read/write access to everything.
HarryLemonHarryLemon
That's what's crazy about it: the "Modify All Data" checkbox is unchecked and they are STILL able to do this! The ability for them to modify any other field in another user's record is prevented with an appropriate system message, as you would expect, except if they should happen to try changing the owner! =O




HarryLemonHarryLemon
jrotenstein:

Thank you for this - I will test this rule out today and see how if fares! =D

Back soon...

Philip
HarryLemonHarryLemon
John, that did it! THANK YOU! But now I just need it to allow the 'Sales Manager' and 'National Account Exec' profile the ability to modify ownership unhindered as well... Here is the modified version of your validation rule that I tried:

AND (ISCHANGED( OwnerId ) , PRIORVALUE( OwnerId ) <> $User.Id , OR($Profile.Name <> 'System Administrator' , $Profile.Name <> 'Sales Manager' , $Profile.Name <> 'National Account Exec'))

But unfortunately it rendered all profiles unable to modify ownership. How would you word this statement to allow for the multiple profiles that should not be affected by the restriction please??

Thank you again for your help! =)

Best,
Philip


Message Edited by HarryLemon on 05-23-2008 10:16 AM
HarryLemonHarryLemon
Actually, John - never mind please; I worked it out!

I just changed $Profile.Name <> 'System Administrator' into $Profile.Name = 'Account Executive' (the profile of the limited, sales team) and that did the trick!

Again, thanks a whole bunch for your excellent help - I greatly appreciate it! =)

Best,
Philip