0

This Validation Rule formula on Contact works and fires when a Case Manager tries to edit the record. So far so good; they should not have access when the picklist value is as shown. But two Users with that same Profile do need access, and they have the Role of Lead Case Manager. I've tried this formula, but the VR is still firing for them and they cannot edit.

$Profile.Name = "Case Manager"
&&
$UserRole.Name <> 'Lead_Case_Manager'
&&
CONTAINS(TEXT(Case_Status__c), "Submitted for Review")
1
  • To the person who downvoted: How would you have asked this question better? Commented Jul 8, 2021 at 21:52

2 Answers 2

3

The Name corresponds to the label of the role in the UI. You can see that type of information in UserRole.

Required. Name of the role. Corresponds to Label on the user interface.

What you're looking for is DeveloperName

$Profile.Name = "Case Manager"
&&
$UserRole.DeveloperName <> 'Lead_Case_Manager'
&&
CONTAINS(TEXT(Case_Status__c), "Submitted for Review")

3
  • Thanks. I was hopeful, but I tried exactly that and the Lead Case Manager still cannot edit the record.
    – sna
    Commented Jul 14, 2021 at 3:22
  • Have you double checked your API name for the role is correct? When you go to Setup --> Roles and click into the role in question - what do you see for Role Name? You can edit your question to add screenshots as well. Commented Jul 14, 2021 at 15:08
  • 1
    I didn't realize I hadn't returned to say, but your solution DID ultimately do the trick. Wanted to make sure I said so for those who come later, thanks so much.
    – sna
    Commented Aug 3, 2021 at 1:31
2

The name should be as written in the role, likely Lead Case Manager.

However, I present to you an easier alternative, namely using Custom Permissions.

First, create a new Custom Permission, then create a new Permission Set, and then assign the Permission Set to the users should be allowed to edit the record. Finally, you can reduce your validation rule to just:

NOT($Permission.CanEditSubmittedCases)
&&
CONTAINS(TEXT(Case_Status__c), "Submitted for Review")

Now, to allow someone access, you just need to add the permission set to their user account. You can even automate this with triggers, processes, flows, etc.

This means that you no longer have to try and squeeze more exceptions into your validation rule, which will become increasingly more difficult to work with as your requirements change.

1
  • Thank you so much! I'd completely forgotten about Custom Permissions and had only seen them once before. I was ready to go this route and then realized I cannot. Something I failed to mention is that the Case Managers are the only users for whom it should be locked. I just need to allow the Lead Case Manager Role. So I'm back to the VR. I landed at this and it's still not allowing the Lead to edit. $Profile.Name = "Case Manager" && $UserRole.DeveloperName <> 'Lead_Case_Manager' && CONTAINS(TEXT(Case_Status__c), "Submitted for Review")
    – sna
    Commented Jul 14, 2021 at 3:18

You must log in to answer this question.

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