How to Use Custom Settings in Validation Rules in Salesforce

Using Custom Settings in Salesforce validation rules is a powerful technique for creating flexible, easily manageable, and dynamic validation logic without requiring code deployments. This approach allows administrators to modify validation criteria directly through the user interface, making system maintenance much more agile.

What are Salesforce Custom Settings?

Custom Settings are a type of custom object that allows developers and administrators to create custom sets of data, as well as associate custom data for an organization, profile, or specific user. All custom setting data is cached, which means you can access it very efficiently without the cost of repeated queries to the database. This makes them ideal for storing configuration data that needs to be accessed frequently, such as thresholds, flags, or lookup values, especially within validation rules, Apex code, or Visualforce pages.

Why Use Custom Settings for Validation Rules?

Integrating Custom Settings into your validation rules offers significant advantages:

• Dynamic Configuration: Adjust validation logic (e.g., minimum/maximum values, required fields based on conditions, active/inactive flags) without modifying or deploying code.
• Reduced Deployment Cycles: Changes to validation criteria can be made directly in the Salesforce UI by an administrator, bypassing the need for development and deployment.
• Granular Control: Define different validation behaviors based on users, profiles, or the entire organization.
• Improved Performance: Custom Setting data is cached, leading to faster access times compared to querying custom objects or metadata.
• Simplified Maintenance: Centralize configuration data, making it easier to manage and update rules across your org.

Types of Custom Settings

Salesforce offers two types of Custom Settings:

1. List Custom Settings:
   • Stores a reusable set of static data that can be accessed across your organization.
   • The data is not associated with a specific profile or user; it's available to everyone.
   • Useful for storing lists of countries, error messages, or static limits.
2. Hierarchy Custom Settings:
   • Stores hierarchical data that can be customized for specific profiles or users, overriding the organization-wide defaults.
   • Salesforce automatically determines the correct value based on the current user's profile and then by the user's ID.
   • Ideal for storing user-specific or profile-specific thresholds, feature flags, or permission overrides.

For validation rules, both types can be beneficial, but Hierarchy Custom Settings often provide more flexibility for user or profile-specific validations.

Step-by-Step Guide to Using Custom Settings in Validation Rules

Follow these steps to implement Custom Settings for dynamic validation:

1. Create a Custom Setting

1. Navigate to Setup: Go to Setup (the gear icon) > Service Setup (or Setup directly).
2. Search for Custom Settings: In the Quick Find box, type Custom Settings and select it.
3. New Custom Setting: Click New.
4. Define Details:
   • Label: A user-friendly name (e.g., Validation Controls, Approval Limits).
   • Object Name: Automatically generated (e.g., Validation_Controls__c).
   • Setting Type: Choose List or Hierarchy. For most flexible validation rules, Hierarchy is often preferred.
   • Visibility: Keep as Public unless there's a specific reason for Protected (Protected means only Apex code in the same namespace can access it, which is rare for standard admin-configured validation).

2. Define Custom Fields within the Custom Setting

After creating the Custom Setting, you need to add fields to store your configuration values. These fields will hold the data that your validation rules will reference.

1. Click on the Custom Setting: From the Custom Settings page, click on the Label of the Custom Setting you just created.

2. Add New Fields: In the Custom Fields section, click New.

3. Choose Data Type: Select the appropriate data type for your configuration value. Common types include:

   • Number: For thresholds (e.g., Minimum_Order_Amount__c, Max_Discount_Percentage__c).
   • Checkbox: For boolean flags (e.g., Enable_Validation_Rule__c, Bypass_Approvals__c). A checkbox can be a simple yet effective way to toggle specific validation logic on or off for certain users or profiles.
   • Text: For error messages, specific values, or lookup keys.

4. Field Details: Provide a Field Label, Field Name, and any other required details for the chosen data type.

   Example Field:

   • Field Type: Number
   • Field Label: Max Discount Percentage
   • Field Name: Max_Discount_Percentage__c
   • Length: 18, Decimal Places: 0

   Another Example:

   • Field Type: Checkbox
   • Field Label: Enable Lead Assignment Validation
   • Field Name: Enable_Lead_Assignment_Validation__c

3. Manage Records (Set Values)

Now you need to populate your Custom Setting with data.

1. Go to the Custom Setting: From the Custom Settings page, click Manage next to your Custom Setting.
2. New Record: Click New to create an organization-wide default record.
   • Fill in the values for your custom fields (e.g., Max Discount Percentage = 20, Enable Lead Assignment Validation = TRUE).
3. Override for Hierarchy Settings (Optional): If you chose Hierarchy as your setting type, you can create override records:
   • Click New again.
   • Select Profile or User and choose the specific profile/user.
   • Enter the values that should override the organization-wide defaults for that profile/user.

4. Access Custom Settings in Validation Rules

In your validation rule, you will use the $Setup global variable to access the values stored in your Custom Setting.

Syntax: $Setup.CustomSettingName__c.FieldName__c

• CustomSettingName__c: The API name of your Custom Setting (e.g., Validation_Controls__c).
• FieldName__c: The API name of the custom field within that Custom Setting (e.g., Max_Discount_Percentage__c).

Example Validation Rules:

Let's imagine you have a Custom Setting named Deal_Config__c with fields Max_Discount_Percentage__c (Number) and Require_Approval_Below_Cost__c (Checkbox).

• Validation Rule 1: Limit Discount Percentage

  • Object: Opportunity
  • Rule Name: Discount_Limit
  • Error Condition Formula:

    AND(
        NOT(ISBLANK(Discount_Percent__c)),
        Discount_Percent__c > $Setup.Deal_Config__c.Max_Discount_Percentage__c
    )

  • Error Message: "The discount percentage cannot exceed the configured maximum."

• Validation Rule 2: Conditional Required Field

  • Object: Lead
  • Rule Name: Require_Marketing_Source
  • Error Condition Formula:

    AND(
        $Setup.Validation_Controls__c.Enable_Lead_Assignment_Validation__c,
        ISBLANK(LeadSource)
    )

  • Error Message: "Lead Source is required when lead assignment validation is active."
  • Explanation: This rule only fires if the Enable_Lead_Assignment_Validation__c checkbox in the Validation_Controls__c Custom Setting is checked. This is a practical example where a checkbox in a Custom Setting can act as a simple flag to toggle validation logic.

• Validation Rule 3: Profile-Specific Bypass (Hierarchy Setting)

  • Object: Account
  • Rule Name: Account_Name_Format_Validation
  • Error Condition Formula:

    AND(
        NOT(REGEX(Name, "^[A-Za-z0-9 ]+$")),
        NOT($Setup.Validation_Bypass__c.Bypass_Name_Validation__c)
    )

  • Error Message: "Account Name must only contain alphanumeric characters and spaces."
  • Explanation: Here, Validation_Bypass__c is a Hierarchy Custom Setting with a checkbox field Bypass_Name_Validation__c. If this checkbox is set to TRUE for a specific user or profile, that user/profile can bypass the name format validation.

Best Practices and Considerations

• Meaningful Names: Use clear and descriptive labels and API names for your Custom Settings and their fields.
• Data Security: While Custom Settings are excellent for configuration, avoid storing highly sensitive data that requires complex sharing rules, as Custom Settings don't adhere to standard sharing models. They are generally for configuration parameters rather than transactional data.
• Performance: Custom Settings are inherently performant due to caching. Utilize them for frequently accessed configuration data.
• Deployment: Remember that Custom Settings themselves are metadata and can be deployed, but their data records are data and must be migrated separately (e.g., using data loader, API, or change sets if they are part of the change set).
• Clarity: Document the purpose of each Custom Setting and its fields to ensure future administrators understand their function.
• Avoid Overuse: While powerful, don't create a Custom Setting for every single configuration item. Balance flexibility with simplicity.

By leveraging Custom Settings, you empower administrators to make immediate, impactful changes to validation rules, significantly enhancing the agility and maintainability of your Salesforce instance.