Custom Settings and Custom Metadata in Salesforce

Custom Settings

Custom settings are like custom objects that allow app developers to create custom sets of data for an organization, profile, or user. This data is cached for easy access and can be used in formula fields, validation rules, flows, Apex, and SOAP API. It saves the expense of redundant database queries.

Note -

All custom settings data is exposed in the application cache, which enables efficient access without the cost of repeated queries to the database. However, querying custom settings data using Standard Object Query Language (SOQL) doesn't use the application cache and is similar to querying a custom object. To benefit from caching, use other methods for accessing custom settings data such as the Apex Custom Settings methods.

Code Snippet -

List< Application_Configuration__c > mcs = Application_Configuration__c.getall().values();

boolean execute = false;

if (mcs[0].Type__c == 'Cloud') {

  execute = true;

}

Application_Configuration__c myCS1 = Application_Configuration__c.getValues('Cloud');

String appType = myCS1.Type__c;

Here are some examples of how Salesforce Custom Settings can be used:

Application Configuration:

Storing application-wide settings such as default values, email templates, or notification preferences.

Example: A custom setting named "Application_Configuration__c" with fields for the default email template, notification preferences, and other application settings.

Feature Toggles:

Enabling or disabling specific features or functionalities within the application.

Example: A custom setting with boolean fields indicating whether certain features are enabled or disabled.

User Preferences:

Storing user-specific preferences or settings that need to be applied across sessions.

Example: A custom setting to store user preferences such as language preference, timezone, or display settings.

Integration Configuration:

Storing configurations for external integrations, such as API endpoints, authentication credentials, or connection settings.

Example: A custom setting to store integration-specific configurations like API endpoints, username, password, and security tokens.

Custom Metadata Mapping:

Mapping between Salesforce objects and external systems, fields, or metadata.

Example: A custom setting to store mappings between Salesforce objects and fields with corresponding API names in an external system.

URL Redirects:

Managing URL redirects or custom links within the application.

Example: A custom setting to store mappings between custom URLs and their corresponding Salesforce pages or external URLs.

Pricing or Discount Rules:

Storing pricing rules, discount percentages, or special offers applicable to different customer segments or products. Please read here - Hierarchy Custom Setting

Example: A custom setting to store pricing rules for different product categories or customer types.

Localization:

Storing translated labels, messages, or picklist values for multilingual applications.

Example: A custom setting to store translated labels and messages for different languages supported by the application.

Batch Processing Configuration:

Configuring batch processing jobs, such as scheduling intervals, job parameters, or execution criteria.

Example: A custom setting to store batch job configurations like batch size, query criteria, and schedule intervals.

Logging Levels:

Configuring logging levels or debug settings for monitoring and troubleshooting purposes.

Example: A custom setting to store logging levels (e.g., debug, info, error) and their corresponding verbosity levels.

These examples demonstrate the versatility of Custom Settings in Salesforce and how they can be utilized to store various types of data and configurations within the platform. Custom Settings offer a flexible and scalable solution for managing application settings, preferences, and configurations with ease.

Custom MetaData Types-

Custom metadata types are customizable, deployable, packageable, and upgradeable application metadata. All custom metadata is exposed in the application cache, which allows access without repeated queries to the database. The metadata is then available for formula fields, validation rules, flows, Apex, and SOAP API. All methods are static.

Custom metadata types methods are instance type methods and are called by and operate on a specific instance of a custom metadata type.

Code Snippet -

List< Application_Configuration__mdt> mcs = Application_Configuration__mdt.getAll().values();

boolean execute = false;

if (mcs[0].Type__c == 'Cloud') {

  execute = true;

}

Returns a map of all the records for a custom metadata type named Application_Configuration__mdt.

Map<String, Application_Configuration__mdt > mcs = Application_Configuration__mdt.getAll();


Here are some examples of how Salesforce Custom Metadata Types can be used:

Global Configuration Settings:

Storing global configuration settings that apply across different components or features of an application.

Example: A Custom Metadata Type named "Global_Configuration__mdt" with fields for default values, application-wide settings, or external service configurations.

Dynamic Picklist Values:

Managing dynamic picklist values or dropdown options that may need to be updated frequently.

Example: A Custom Metadata Type to define picklist values for a dropdown menu on a Visualforce page or Lightning component.

Business Process Configurations:

Configuring business processes, workflow rules, approval processes, or validation rules.

Example: A Custom Metadata Type to define approval process steps, criteria, and actions for different business processes.

Feature Flags or Toggles:

Enabling or disabling specific features or functionalities within the application.

Example: A Custom Metadata Type to define feature flags or toggles for experimental features, beta releases, or A/B testing.

Integration Configurations:

Storing configurations for external integrations, such as API endpoints, authentication credentials, or connection settings.

Example: A Custom Metadata Type to define integration configurations like API endpoints, OAuth tokens, and webhook URLs.

Localization and Translation:

Managing translated labels, messages, or picklist values for multilingual applications.

Example: A Custom Metadata Type to define translations for different languages supported by the application.

Page Layout and Component Configurations:

Configuring page layouts, component visibility rules, or dynamic UI configurations.

Example: A Custom Metadata Type to define page layout configurations for different user profiles or record types.

Pricebook Configurations:

Storing pricing rules, discount percentages, or special offers applicable to different products or pricing tiers.

Example: A Custom Metadata Type to define pricebook entries, pricing rules, and discount schedules for different product categories.

Environment-Specific Configurations:

Managing configurations that vary across different Salesforce environments, such as sandbox, development, or production.

Example: A Custom Metadata Type to define environment-specific settings like API endpoint URLs, debug flags, or logging levels.

Managed Package Configurations:

Storing configurable settings or parameters for managed packages distributed to customers.

Example: A Custom Metadata Type to define configurable parameters or options for a managed package, allowing customers to customize behavior without modifying code.

These examples illustrate the versatility and flexibility of Custom Metadata Types in Salesforce and how they can be used to manage various types of configurations, settings, and data within the platform. Custom Metadata Types provide a metadata-driven approach to configuration management, allowing for easier deployment, version control, and scalability across different environments and applications.

Differences between Custom Metadata and Custom Settings









Comments

Popular posts from this blog

Introduction to Salesforce Agent Script: Build Predictable AI Agents

Anti-Patterns in Salesforce Agentforce: What to Avoid When Building AI Agents

MCP vs. Traditional APIs: Choosing the Right Integration Approach