Salesforce introduced a feature Custom Settings in its Winter’10 release which allows users to store custom data sets and associate them on an org-wide, profile or user basis. Custom Settings are similar to Custom Objects. In the same way that we create fields for custom objects, we need to create our own custom settings with its fields.
Real-time, bi-directional, multi-company – Sage ERP Integration with Salesforce
When using the cache methods Custom_setting__c.getAll(), .getInstance(), and .getValues(), Salesforce uses the cached values. If you use a SOQL query (SELECT id, name FROM Custom_setting__c) to get data for a custom setting, Salesforce queries the database and uses one of your allotted queries.
We can use page layouts, record types, validation rules, triggers and workflow rules on Custom Objects. Page layouts, record types, validation rules, triggers and workflow rules cannot be used on Custom Settings.
Difference between custom settings and custom objects –
Custom Objects
- All custom field types supported.
- Records are updated by users.
- Stored in database.
- Requires lookup or Master-Detail relationship to reference from another object.
- Counts against cross object reference limit when used in formula.
- We can use page layouts, record types, validation rules, triggers and workflow rules on custom objects.
Custom Settings
- No relationship calculated, Picklist or long/rich text fields supported.
- Records are updated by Admin/Developer.
- Cached in Memory (Limit 2MB).
- No relationship fields required.
- Not a Cross Object reference.
- No Page layouts, record types, validation rules, triggers and workflow rules can be used on Custom Settings.
Use of Custom Settings –
- No governor limit feature.
- The data is stored in the cache, it is very fast and efficient.
- You have to use the Custom Setting’s GET methods, not SOQL to query for data.
- Create and manage data at different levels like organization, profile and user levels.
- Access dictionary tables without querying.
- Doesn’t require hard coding of user or profile Id.
- Saves Time.
- Reduces the number of places you need to make changes.
There are two types of Custom Setting: List and Hierarchy
1. List:
– List of data like custom object.
– Accessible only through code.
– Good for lists of reference data used in code.
2. Hierarchy:
– Defined globally (for organisation) by profile, by user.
– Accessible through code, formula, Validation Rules, Apex, and the Force.com Web Services API.
– Good for data that may differ based on user or profiles.
– Good for data that needs to be accessed declaratively.
Custom Setting visibility:
1. Public
The public type Custom Setting data can be accessed by everyone who has the Profile setting “Customize Application” enabled.
2. Protected
If it is protected, then no one will be able to see the Custom Settings. It will be hidden for all the Users. Only the code written in the App can access the data. So this is normally used to store application setting values such as tokens, client IDs, client secrets, etc.
When to use custom setting?
- When you are using the same constant value, representing the same thing in more than one formula.
- Data can be entered by an admin or developer.
- When you need a different value based on the runtime user or their profile.
When not to use custom setting?
- When you are using same value but it means different things in different formulas.
- Data needs to be entered by end users.
- When you need different values based on the record owner or their profile or based on permission set.
Limits of Custom Settings in Salesforce –
- You are unable to share a custom setting object or record.
- Cached data allowed for you to store in your organization depends on your licenses –
– 10 Mb.
– 1 MB multiplied by the number of full-featured user licenses in your organization.
For example: If your organization has 3 full licenses, you have 3 MB of storage. - You can add up to 300 fields per custom setting.
- No owner is assigned when a custom setting is created, so the owner can’t be changed.
- Each certified managed package gets a separate limit in addition to your organization limit.
- Accessing an undeleted custom setting in a formula field results in an error if the user doesn’t have the “Customize Application” permission. To prevent this error, redeploy this custom setting to the organization. Alternatively, delete this custom setting, re-create it with the same name and data, and then delete and re-create all formula fields that use this setting.
Is there an impact on custom object count as it’s a managed package?
It will not affect the custom object limits provided your package has Aloha status (which requires Security Review to be passed).
In our next blog, we will see how to create and use a custom setting in Salesforce. Stay tuned.
About Us
Greytrix as a Salesforce Product development partner offers a wide variety of integration products and services to the end users as well as to the Partners across the globe. We offer Consultation, Configuration, Training and support services in out-of-the-box functionality as well as customizations to incorporate custom business rules and functionalities that require apex code incorporation into the Salesforce platform.
Greytrix has some unique solutions for Cloud CRM such as Salesforce integration with Sage Enterprise Management (Sage X3), Sage Intacct, Sage 100 and Sage 300 (Sage Accpac). We also offer best-in-class Cloud CRM Salesforce customization and development services along with services such as Salesforce Data Migration, Integrated App development, Custom App development and Technical Support to business partners and end users.
Greytrix GUMU™ integration for Sage ERP – Salesforce is a 5-star app listed on Salesforce AppExchange.
For more information, please contact us at salesforce@greytrix.com. We will be glad to assist you.
Related Posts