What is Custom Settings in Salesforce

When developing on the Salesforce platform, developers and administrators often encounter scenarios where they need to store application data that should not be tied to a specific user or record. For such cases, Salesforce provides a powerful feature known as Custom Settings. These are similar to custom objects but are designed specifically to store configuration and application-level data that can be accessed efficiently and without the need for SOQL queries.

In this blog, we’ll take a deep dive into custom settings in Salesforce, exploring what they are, how they differ from other data storage options, how to create and use them effectively, and some best practices to follow.

1. What are custom settings in Salesforce?

Custom settings in Salesforce are similar to custom objects and are used to store configuration data that can be accessed across the entire org. This data is cached, which means it can be retrieved without querying the database, making it faster and more efficient.

They are primarily used to avoid hardcoding values in Apex classes, triggers, and validation rules.

For example, you might store an API endpoint URL or a default discount percentage in a custom setting rather than hardcoding it.

2. Types of Custom Settings

Salesforce provides two types of custom settings:

A. List Custom Settings

• Behavior: Similar to a custom object.
• Access: Data is visible to all users.
• Storage: Stores data in a table-like format, with multiple records.
• Use Case: When you want to store multiple rows of configuration data (like records in a table).

📌 Example: A list of supported countries for your application.

B. Hierarchy Custom Settings

• Behavior: Allows for personalized data at different levels (organization, profile, or user).
• Access: Hierarchical data can be defined globally, per profile, or per user.
• Use Case: When you need user-specific or profile-specific configurations.

📌 Example: Setting different tax rates for different user profiles or users.

3. Custom Settings vs. Custom Metadata Types

4. When to Use Custom Settings

Use Custom Settings when:

• You need to access configuration data repeatedly and quickly in Apex.
• You want to avoid hardcoded values.
• You need user-specific or profile-specific settings (Hierarchy Custom Settings).
• You do not need to deploy the data across orgs.

Do not use custom settings when:

• You need to package and deploy configuration data (use custom metadata instead).
• The configuration is related to records or objects.

5. How to Create Custom Settings

Step 1: Create the Custom Setting

• Go to Setup > Custom Settings.
• Click New
• Choose the type: List or Hierarchy
• Define the name, label, and visibility (public or protected).

Step 2: Define Fields

• After creating the custom setting, define custom fields just like a custom object (e.g., Checkbox, Text, Number, etc.).

Step 3: Add Data

• Go to Manage to add records for List Custom Settings.
• For Hierarchy Custom Settings, add records for Organization, User, or Profile levels.

6. How to Access Custom Settings in Apex

Custom settings is that you can access them without using SOQL, which does not count against governor limits.

A. Accessing List Custom Settings

MySetting__c setting = MySetting__c.getValues('Record_Name'); System.debug(setting.API_URL__c);

B. Accessing All Records in List Custom Settings

Map<String, MySetting__c> settingsMap = MySetting__c.getAll(); for (String key : settingsMap.keySet()) { System.debug(settingsMap.get(key).API_URL__c); }

C. Accessing Hierarchy Custom Settings

MyHierarchySetting__c settings = MyHierarchySetting__c.getInstance(UserInfo.getUserId()); System.debug(settings.Default_Discount__c);

7. Custom Settings and Security

• Visibility Settings:
  • Public: Accessible everywhere.
  • Protected: Only accessible by code in the same namespace (useful for managed packages).
• Custom settings do not respect sharing rules but do respect object-level security.

🧠 Be cautious about storing sensitive data (like API keys or credentials) in public custom settings.

8. Real-World Use Cases

✅ Use Case 1: API Configuration

Store API keys, endpoints, or versions in custom settings to avoid hardcoding them.

✅ Use Case 2: Feature Toggles

Use Boolean fields to enable or disable features dynamically.

if (MySettings__c.getInstance().Enable_Feature_X__c) { // execute feature X logic }

✅ Use Case 3: Environment Detection

Set a value Environment__c = "Production" to tailor logic for different environments.

✅ Use Case 4: User-Specific Settings

Allow certain users to access features based on hierarchy custom settings.

9. Limitations of Custom Settings

• Limited to 300 fields per custom setting
• Cannot store relationships (no Lookup or Master-Detail fields)
• Data is not included in packages.
• No direct support for validation rules or workflow (unlike custom metadata)
• Can’t be deployed with data (unless using data loader or scripts)

10. Best Practices

✅ Use naming conventions: Use __c suffixes and consistent naming for clarity.

✅ Keep it lightweight: Only store config data. For complex logic, use Apex.

✅ Document your settings: Add descriptions for each field to improve maintainability.

✅ Avoid sensitive data: Never store passwords or credentials in plain text.

✅ Use protected settings for managed packages to secure your logic.

✅ Use custom metadata for config data that needs to be deployed or version controlled.

11. Conclusion: Custom Settings in Salesforce

Custom settings are a simple yet powerful tool in a Salesforce developer’s toolbox. Whether you’re building scalable apps, managing runtime configurations, or enabling personalized settings, custom settings offer a fast, SOQL-free solution to store and retrieve application data.

However, as Salesforce continues to promote custom metadata types for newer projects, it’s essential to understand the right use case for each tool. Stick with custom settings for runtime or user-specific settings, and use custom metadata for deployable configurations.

12. FAQs

Q1. Can I use custom settings in validation rules?

Yes, you can reference hierarchy custom settings in validation rules, formulas, and workflows.

Q2. Are custom settings subject to governor limits?

No, accessing custom settings does not consume SOQL limits.

Q3. Can I deploy custom settings data using change sets?

No, custom settings data cannot be deployed. You’ll need to migrate data manually using tools like Data Loader.

Q4. Can I track field history on Custom Settings?

No, custom settings do not support field history tracking.

Q5. Should I use custom settings or custom metadata for a new app?

If you need to deploy the configuration with your package or between orgs, go with Custom Metadata Types.