I have put the following Validation Rule on the AssignedTo field on Task to avoid changing task owner if the logged in user is also the owner of the task

NOT(ISNEW()) && $User.ID = OwnerId && RecordType.DeveloperName = 'REC-TYPE-1'

I have checked the record type dev name and it is correct so I am thinking it could be due to the formula layout (although syntatically correct the parameters need to be in a different order?)

*I am trying to test this with the "login as" functionality - could it be that it doesn't trigger because of this? (reads my admin ID as the logged in user and not the user I am testing on)

  • RecordType.DeveloperName is the API name of the record type, so you have to use underscore characters instead of "-" characters. If you want to use the record type label, you have to use RecordType.Name. Commented Mar 29, 2021 at 5:29

1 Answer 1


Here is a possible answer to your question:

  1. If you are logged in as that user than I believe $User.Id should resolve to the logged in UserId. To reinforce this, if the logged in user can access dev Console, try running the following code in the Dev. Console execute anonymous:


    See which Id is outputted to the debug log.

  2. In validation Rule, I have experienced issues with Salesforce Ids being returned as different values. For example, it is possible that the $User.Id is returning the 15 digit Id while ownerId is returning the 18 digit Id which in context of the validation rule will not be equal. Try wrapping the Ids in the CaseSafeId() function and see if that triggers the validation rule.

  3. Another point you should look out for is that you don't explicitly look for the Owner changing. Your ValidationRule in principal, would be flagged for ANY modification to the task by the owner. You need to add a check that the owner is being changed (vs any other field) something like


The best way (aside from trial and error) is to set up a trace on the user and generate a debug log of the Save transaction and then find the execution of the validation rule in the debug log. This way you don't have to guess whats happening, you can see what is the problem and understand / fix it. Debug logs are not only useful in Apex / code and you can debug the validation rule using logs as well and see what the values are resolving as.

Hope that helps, let me know if you figured it out

You must log in to answer this question.

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