I am excited to see my Idea listed as one of the ideas to be delivered in the near future at Parker Harris’ True to The Core Dreamforce 17 session and to be in the pilot for referencing custom metadata types in validation rules. Thank you, Vlad!
Note: The blog post will cover a description of functionality currently in pilot. This is not a feature that will be available with the Spring 18 release out of the box. In fact, there is no published date for when this feature will be generally available or at all. #ForwardLookingStatement.
Here is more information about the pilot: Custom Metadata: Easy-to-Use Referencing of Custom Metadata Type Records in Validation Rules (Pilot)
If you are interested in participating in this pilot yourself, please contact your Account Executive to nominate you for the pilot. The pilot will be enabled in a Spring 18 sandbox or a Spring 18 personal developer edition.
I have mentioned in previous blog posts that you should refrain from hardcoding IDs, such as record IDs, userIds, etc. Instead, you use custom labels or using hierarchy custom settings in validation rules. With this pilot, you can now reference custom metadata types too! The best part about using custom metadata types is that the CMDT records are meta too! That means they are deployable and will appear in a sandbox creation and refresh with no additional effort.
In this post, I will use two examples of how to use custom metadata types in validation rules.
Business Use Case: Addison Dogster is the system administrator at Universal Containers. Sally Sunshine is the Operations Manager. She has requested that users be restricted from making any updates to a specific account.
Solution: Addison typically will rely on referencing something that has less likelihood to change, such as a API name. However, in the case, she needs to reference a specific account and she knows account names are subject to change. The last thing she wants to do is reference the account name and one day the account name changes and the validation rule no longer works. Looks like she has to reference the account ID. So, rather than do that in the validation rule, she’s referencing it in the custom metadata type.
Quick Steps:
1.Create the custom metadata type. In Classic, go to Setup | Develop | Custom Metadata Types | New or in Lightning, go to Setup | Custom Code | Custom Metadata Type | New. Let’s call this Validation Rule Reference. We will use one custom metadata type to house our references for ease of maintenance.
Best practice tip: Don’t forget to provide a description so you and other/future admins know what this custom metadata type is used for.
A. Create one custom text field called Criteria and this will hold your IDs or whatever else you want to reference.
Best practice tip: Don’t forget to provide a description so you and other/future admins know what this custom metadata type field is used for.
B. Create a custom metadata type record to house the accountID. Enter the 15 character AccountID in the criteria field. Note: Do not enter the 18 character account ID. This, for whatever reason, will not work in the validation rule.
2. Create the account validation rule that prevents the account from being updated. In Classic, go to Customize | Accounts | Validation Rules | New or in Lightning, go to Object Manager | Account | Validation Rule | New.
Best practice tip: Don’t forget to provide a description so you and other/future admins know what this custom metadata type is used for.
Business Use Case: Addison Dogster is the system administrator at Universal Containers. Sally Sunshine is the Operations Manager. She has requested that Directors cannot updated the account rating field.
Solution: Addison typically will rely on referencing something that has less likelihood to change, such as a API name. However, in the case, she needs to reference a specific job title, which can change at any point in time. Rather than update the validation rule with any title changes, she’s referencing it in the custom metadata type and will update the custom metadata type record.
Quick Steps:
1. Create the custom metadata type in Steps 1-1A of the previous use case.
B. Create a custom metadata type record to house the job title.
2. Create the account validation rule that prevents a user of a specific title from updating the account rating field. In Classic, go to Customize | Accounts | Validation Rules | New or in Lightning, go to Object Manager | Account | Validation Rule | New.
Signup for the pilot and give this a whirl today!
Thank you to the Salesforce CMDT Product Management team – Vladimir Gerasimov, (the inventor of custom metadata types) Avrom Roy-Faderman and Aaron Slettehaugh for bringing us these custom metadata type features.
What would be the more efficient route if they were 5 accounts?
LikeLike
Not allow updates to 5 accounts? Create a CMDT record for each account and add them to the validation rule.
LikeLike
Hello Jen
When i try to reference a Custom Metadata Type record in a validation rule i get a java.lang.NullPointerException error. are you experiencing the same behavior ?
i’am in a sandbox envir.
thanks
LikeLike
The Salesforce product team is aware of this issue (identified last week), fixed it and are waiting for the patch to be deployed to get this fixed.
LikeLike