Custom Settings are a powerful tool for Salesforce admins and developers to make org configurations more flexible and manageable. Whether you’re excluding users from validation rules or toggling them on or off, Custom Settings can help you streamline processes, reduce friction, and gain granular control over your org.
In this post, we’ll walk through two key examples—user exclusion and rule toggling—and share additional creative ways you can use Custom Settings to enhance your org’s flexibility.
1. Excluding Admin or Operations Users from Validation Rules
How It Works:
- Create a Hierarchy Custom Setting with a checkbox field (e.g., ExcludeFromValidations__c).
- Reference this setting in your validation rule to bypass logic for certain users or profiles.
Validation Rule Example:
$Setup.ValidationExclusion__c.ExcludeFromValidations__c = TRUE ||
AND(
ISPICKVAL(StageName, 'Closed Won'),
ISBLANK(CloseDate)
)If the ExcludeFromValidations__c checkbox is checked for the current user or profile, the rule is skipped.
Why This Is Useful:
- Flexibility: Lets system or operations users work around strict validations when cleaning or importing data.
- Better UX: Reduces friction for admin users managing bulk or exception-based records.
- Scalable: You can adjust settings per user or profile as needs evolve.
Risks to Watch For:
- Bypassing validations too often can lead to inconsistent data.
- Consider logging or auditing these exceptions for accountability.
2. Toggle Validation Rules On or Off with Custom Settings
Per-Rule Toggle
How It Works:
- Create a List Custom Setting with fields like ValidationRuleName__c and IsActive__c.
- Use the IsActive__c field in the rule logic.
Validation Rule Example:
$Setup.ValidationRules__c.IsActive__c != FALSE &&
ISPICKVAL(StageName, 'Closed Won') &&
ISBLANK(CloseDate)If IsActive__c is unchecked, the rule is disabled.
Master Toggle
How It Works:
- Create a Hierarchy Custom Setting with a checkbox field like EnableValidationRules__c.
- Use that field across multiple rules.
Validation Rule Example:
$Setup.ValidationControl__c.EnableValidationRules__c &&
ISPICKVAL(StageName, 'Closed Won') &&
ISBLANK(CloseDate)Benefits:
- Quick Troubleshooting: Disable rules without modifying them directly.
- Environment Flexibility: Useful for toggling rules in sandbox vs. production.
- Granular + Global Control: Combine per-rule and global toggles for full flexibility.
Risks:
- Risk of accidentally leaving rules disabled.
- Requires clear documentation and coordination.
Additional Creative Use Cases for Custom Settings
1. Dynamic Feature Toggles
Enable or disable features without code changes.
if ($Setup.FeatureToggles__c.ShowCustomComponent__c) {
// Display component
}2. Controlling Record Visibility in Reports
Use List Custom Settings to define valid filters (e.g., regions, products).
3. Managing Workflow and Flow Logic
Activate or deactivate automation elements conditionally.
if ($Setup.ProcessControl__c.ExecuteWorkflow__c) {
// Run workflow
}4. Dynamic Email Templates
Store subject lines or body text in Custom Settings for use in Apex or Flows.
5. Default Field Values
Store default values by role, region, or profile.
Example: Default Close Date for a profile.
6. Exception Management
List exception conditions for business rules or integrations (e.g., exclude certain Leads from syncing).
7. Dynamic API Configurations
Store non-sensitive integration settings like API URLs or keys.
String apiKey = $Setup.ApiConfig__c.ApiKey__c;
String endpoint = $Setup.ApiConfig__c.Endpoint__c;When You Should Avoid Using Custom Settings
1. When You Need Relationships
Custom Settings are flat; use Custom Objects for parent-child structures.
2. When You Need Deployment
Custom Setting data isn’t included in change sets. Use Custom Metadata Types for deployable config.
3. For Sensitive Data
Never store passwords or secure credentials here. Use Named Credentials or Protected Metadata.
4. For Large Data Sets
Custom Settings are capped at 10MB org-wide. Use Custom Objects for scale.
Best Practices for Custom Settings
1. Document Everything
Keep a clear record of what each setting controls and how it’s used.
2. Group Related Settings
Use naming conventions like ValidationControl__c or FeatureToggles__c for clarity.
3. Always Test First
Before rolling out changes in production, verify behavior in a sandbox.
4. Combine with Metadata Types
Use Custom Settings for quick, non-deployable values, and Metadata for structured deployments.
5. Monitor and Audit
Regularly review usage and clean up outdated settings.
Conclusion
Custom Settings are one of the most flexible tools in a Salesforce admin’s toolkit. From bypassing validation rules to toggling logic and managing exceptions, they enable dynamic, admin-friendly configurations without deploying code.
Used wisely, they help you build an org that adapts quickly to business needs, minimizes friction for power users, and reduces technical debt.
But like any powerful tool, Custom Settings require discipline. Document their purpose, monitor their impact, and know when to choose Custom Metadata or Custom Objects instead. When applied thoughtfully, they can become the hidden backbone of a clean, configurable Salesforce org.