0

I have an existing Validation rule on the Case that someone assisted me with earlier because it wasn't firing. Now that it's firing accurately, there is additional criteria I need to add to it but I'm getting tripped up on the context with the AND and OR's. Here is the existing rule:

AND( 
    ISPICKVAL(Status, "Request Approved"), 
    OR( 
       NOT(ISCHANGED(Status)), 
       NOT(OR(
              $Profile.Name = "HelpDesk User", 
              $Profile.Name = "System Administrator")
             )
          )
 )

This currently ensures that the only field that can be updated on the Case, when the current Status = Request Approved is the Status field and only users with Profile = System Admin OR HelpDesk User can make the updates. I need to also allow updating of another 2 fields: Current Approver and Approval Step Processed by the same 2 Profiles.

7
  • Should all users be able to change the status from Request Approved to another status? If not, this rule has problems.
    – sfdcfox
    Commented Aug 29, 2023 at 21:03
  • Please take some time to look through How do I format my posts using Markdown or HTML? You've asked enough questions that I'm starting to expect that you should be able to properly format your questions on your own.
    – Derek F
    Commented Aug 29, 2023 at 21:03
  • @sfdcfox: Only users with Profile of System Administrator or HelpDesk User should be able to change any of the 3 fields (Status, Current Approver, or Approval Step Processed) when the current status = Request Approved. No other fields should be changed by those 2 Profiles unless the status in NOT=Request approved, then anyone can change any fields.
    – user7417
    Commented Aug 29, 2023 at 21:08
  • 1
    Also, validation rules are not a great tool for handling things of the form "only allow fields X, Y, and Z to be edited". The usual result when trying to do that is that any number of restricted fields can be edited as long as one of the allowed fields is being edited at the same time. Making use of automation to change the recordtype combined with our ability to assign page layouts per recordtype is a much more reliable approach to solving that problem, imo.
    – Derek F
    Commented Aug 29, 2023 at 21:14
  • @Derek: I appreciate the comment and info but I'm honestly a little confused. I"m not sure Markdown is and it appears that it requires a download. Is this all to make my questions on here more intuitive? I'm not sure what I'm doing wrong. I do post semi-frequently (every few months) but I'm in no way an expert with this app. I am also not a developer so I'm not strong with developer tools and lingo but appreciate any resources to learn more.
    – user7417
    Commented Aug 29, 2023 at 21:15

1 Answer 1

2

First, I recommend using Custom Permissions. This would make it easier to write.

AND(
  ISPICKVAL(PRIORVALUE(Status), "Request Approved"),
  NOT($Permission.Edit_Approved_Cases),
  OR(
    ISCHANGED(Status),
    ISCHANGED(Current_Approver__c),
    ISCHANGED(Approval_Step_Processed__c)
  )
)

Here, we check if the status was previously Request Approved, if the user does not have the Edit Approved Cases permission, and any of the "protected" fields have changed.

However...

Do. Not. Do. This. Period.

This type of validation rule is hostile to the user. They can now violate validation of any of the three fields, but the system UI cannot highlight a specific field, so they have to spend extra time finding which field(s) broke the rule. This is a Bad User Experience™.

Instead, use three validation rules. This also makes it easier to update in the future, as you can just copy-paste a formula and change as needed.

AND(
  ISPICKVAL(PRIORVALUE(Status), "Request Approved"),
  NOT($Permission.Edit_Approved_Cases),
  ISCHANGED(Status),
)
AND(
  ISPICKVAL(PRIORVALUE(Status), "Request Approved"),
  NOT($Permission.Edit_Approved_Cases),
  ISCHANGED(Current_Approver__c),
)
AND(
  ISPICKVAL(PRIORVALUE(Status), "Request Approved"),
  NOT($Permission.Edit_Approved_Cases),
  ISCHANGED(Approval_Step_Processed__c)
)

See how much easier this is to read? And, as a bonus, the correct field can be highlighted, making errors more obvious. Always prefer more validation rules than fewer.

3
  • Thank you both for all the great information! I will put this knowledge to practice on my next questions and answers. It definitely looks so much nicer the way sfdcfox has theirs formatted.
    – user7417
    Commented Aug 29, 2023 at 22:45
  • The problem with these validation rules is that its still allowing the 2 Profiles (which I added the Custom Permissions to) to edit ANY field. The record should basically be locked down once the status is Request Approved except for the 3 fields (Status, Approval Step Processed & Current Approver) and then only for those 2 Profiles , no other Profiles should be able to update any fields on the record when the status = Request Approved.
    – user7417
    Commented Aug 29, 2023 at 23:16
  • @user7417 In that case, Derek is correct. You'd have to hard-code every field. It's not scalable. Instead, consider using record types with page layouts, or code.
    – sfdcfox
    Commented Aug 30, 2023 at 0:49

You must log in to answer this question.

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