validation rules

best practices and examples

labeling convention

Properly labeling validation rules is extremely helpful when performing audits to your SFDC org. Without proper labels, the audit process can take hundreds of hours, wasting time and energy. Additionally proper labeling increases documentation efficiency. Just like with workflow rules, validation rules must follow a strict labeling policy and must include nearly identical properties. The object on which the validation rule is located on, what the validation rule does, and an abbreviated description of the rule must all be included in the label. 

Here is how I have determined to be the most efficient way to solve all problems of validation rule management. 

1. Include the abbreviated object name
   • For example I use opp for opportunity and acct for account
2. Include the action type(s) of the rule
   • Here are the valid action types and my abbreviations for them 
     • Prevents - these rules prevent a user(s) from editing or creating a specific type of record
     • Requires (Requirements) - these rules require a user to populate a field with a value
3. Include the action result

Here are some examples of validation rules names that follow these guidelines : 

• Opp_Require_Canceled_ReasonForLossChange
  • This rule, located on the opportunity, requires the Reason for Loss to be modified when the opportunity is moved to Stage Canceled
  • The error message / description will provide more details on which users, but those details are not mission critical for searching / sorting
• Opp_Prevent_PipeOpp_FromClosedRecycled
  • This rule, located on the opportunity, prevents users from moving an opportunity that is in pipeline into the closed recycled stage
• Opp_Requirements_IMStageComplete
  • This rule, located on the opportunity, lists all the requirements for moving an opportunity into the IM Stage of Complete

how to leverage the description field