5 Quick Validation Rules – Cleaner Service Cloud Data Guaranteed!

If you found the article about Sales Cloud Validation Rules helpful, here are some more rules that will also make your Service Cloud data cleaner. As you know, Validation Rules are your allies when it comes to data quality and the more accurate your data is, the better your business decisions will be founded. A very important thing to keep in mind before activating a Validation Rule, though, is to write very comprehensive error messages so that your users know what to do and do not get frustrated.

Remember to create a checkbox field (ex. OverpassVR__c) on the User object and add the condition && NOT(OverpassVR__c) to every Validation Rule you create in your org. Doing so, you’ll be able to check that field in exceptional situations when you need Validation Rules not to apply to a specific user.

1. Cases cannot be edited when owned by a Queue

Queues are an easy way to cluster Cases into different categories and manage access to them. However, if you have decided to set them up, your Case activity reports could be less accurate if users work on Cases owned by queues without having taken ownership first.

Luckily, a simple Validation Rule can prevent a user from editing a Case owned by a Queue unless they first change the Case Owner to themselves.

Validation Rule Example:

LEFT (OwnerId,3) <> “005”

Additional Use for the Sales Cloud: If you have set up Queues on the Lead object, you can use exactly the same validation rule to ensure users cannot edit Leads owned by Queues.

2. Case Origin cannot be edited once a Case has been created

If users are allowed to create Cases manually in your org, you might want to stop them from changing the value they chose in the Case Origin field when they created the record.

Modifying the access to a field after certain criteria are met can be achieved in different ways; for example, you could instead update the page layout to lock the field. But you might not want to create one more page layout to change the access to just one field. If that is the case, the following Validation Rule is enough to prevent users from editing the Case Origin once the record is created.

Validation Rule Example:

ISCHANGED (Origin)

&&

NOT( ISNEW() )

3. Once Case Status is updated from ‘New’, Contact cannot be blank

Once the support agent dealing with a Case gets to know which customer or potential customer has made the support request, the Case should be linked to the respective Contact. If the Contact does not exist in Salesforce, it will first need to be created.

To ensure the Case is linked to a Contact as soon as a support agent starts dealing with a Case and updates the Case Status from ‘New’ to a different value, you can use the Validation Rule below.

Validation Rule Example:

NOT (ISPICKVAL (Status, ’New’))

&&

ISBLANK (ContactId)

4. Required fields to close a Case

When a Case is closed, you will need at least certain fields to be filled to report on data such as how many Cases were closed by Type or which the most common reasons why your support team is contacted are. A Validation Rule is very useful at this point to ensure that the minimum information required to close a Case has been saved in Salesforce.

Validation Rule Example:

IsClosed

&&

OR(

ISPICKVAL (Reason, “”),

ISPICKVAL (Type, “”),

ISBLANK (Subject),

ISBLANK (Description)

)

Additional Use: You might want to make mandatory certain fields when certain statuses are selected instead, since a lot of the Case information is usually known way before the Case is closed. In the following example, you can see how to use a similar Validation Rule for it:

OR(

ISPICKVAL (Status, ‘Working’)

&&

OR(

ISPICKVAL (Reason, “”),

ISPICKVAL (Type, “”)

),

IsClosed

&&

OR(

ISBLANK (Subject),

ISBLANK (Description)

)

)

5. Closed Cases cannot be modified

Once a Case has been solved and closed, its details do not usually need to be modified. Remember you can link Cases through the Parent Case field, so, if a support issue needs to be reopened there is no need to edit the Case that is already closed; you can simply create a new one and link it to the previously closed Case. Creating a child case every time an issue is reopened is also useful to save a more detailed Case History, especially if a Case is reopened multiple times. However, if, for any reason, you have decided to let your users reopen Cases, you will not need this Validation Rule.

Validation Rule Example:

IsClosed

Summary

If activated, Validation Rules like the ones listed above can help in many ways: they can prevent users from modifying certain data, ensure users provide the required information at the right time, and much more. Avoiding user errors will always improve the quality of your data and will empower you to make the decisions your business requires to succeed.

Subscribe To The Monthly Newsletter

No Spam. No Rubbish. Just great content from the Salesforce Industry.

You have Successfully Subscribed!

Add Comment