Salesforce Custom Metadata Settings Part 2

Prologue

This is the second post in the series Custom Metadata Settings on the Salesforce platform. Please checkout Salesforce Custom Metadata Settings Part 1 before continuing with this article, all the basics are discussed there in detail. The following topics will be discussed in this article with the related code:

Custom Settings Methods (code)
Custom Metadata Type SOQL queries
Custom Metadata Packaging
Custom Metadata Visibility

Custom List Settings Methods

Three main methods exist in getting Custom List Settings data namely:

CustomSettingName__c.getAll(), returns a map for all the custom setting entries. The key is Custom Setting name and value is the Custom Setting Name
CustomSettingName__c.getInstance('Custom Setting Name'), returns Custom Setting data set specified
CustomSettingName__c.getValues('Custom Setting Name'), returns Custom Setting data set specified

Custom List Settings Methods Examples

Assume that a Custom List Setting Called Country was created with a Text field named PostalCode. The following records were inserted:

Name = Jamaica, PostalCode = JMC43244
Name = Canada, PostalCode = A1A 1A1
Name = Argentina, PostalCode = 1865

Country__c.getAll()

1
2
3
4
Map<String,Country__c > mappedCounties = Country__c.getAll();
for(Country__c record: mappedCounties.values()){
    System.debug(record.Name + ' with ' + record.PostalCode);
}

Country__c.getValues('name')

1
2
3
String name = 'Argentina';
Country__c record = Country__c.getValues(name);
System.debug(record);

Country__c.getInstance('name')

1
2
3
String name = 'Jamaica';
Country__c record = Country__c.getInstance(name);
System.debug(record);

Custom Hierarchy Settings Methods

CustomSettingName__c.getInstance(), Returns a custom setting data set record for the logged in user
CustomSettingName__c.getInstance('USER_ID'), Returns a custom setting data set record for supplied user id
CustomSettingName__c.getValues('USER_ID'), Returns a custom setting data set record for a specific supplied user id, and doesn’t merge values from other levels of the hierarchy. Instead, getValues returns null for any fields that aren’t set.
CustomSettingName__c.getInstance('PROFILE_ID'), Returns a custom setting data set record for supplied profile id
CustomSettingName__c.getValues('PROFILE_ID'), Returns a custom setting data set record for a specific supplied profile id, and doesn’t merge values from other levels of the hierarchy. Instead, getValues returns null for any fields that aren’t set.
CustomSettingName__c.getORGDefaults(), Returns a custom setting data set for the organization

Note: If you create a Custom Hierarchy Setting with three fields A (User), B and C with profiles. The main difference between CustomSettingName__c.getInstance('userId|profileId') and CustomSettingName__c.getValues('userId|profileId') is that getvalues() nullifies any merged field not associated with the ID supplied. For example, let’s say your retrieving field A with an active user id, the return record if existing would contain field A populated, but the others set to Null. This, however, is not the case for the getInstance() it retrieves merged fields and populates them accordingly.

Custom Hierarchy Settings Methods Examples

Assume that a Custom Hierarchy Setting Called ChatAgent was created with a Text field named Region. The following records were inserted:

Name = Samuel, Region = West, Profile = Support Agent, User = None
Name = Dean, Region = East, Profile = Backup Agent, User = None
Name = Felecia, Region = North, Profile = Technical Agent, User = None
Name = Felecia, Region = South, Profile = None, User = Ramiel

CustomSettingName__c.getInstance(‘USER_ID’)

1
2
3
4
String name = 'Ramiel';
String userID = [SELECT Id FROM User WHERE Name =:name].Id;
ChatAgent__c record = ChatAgent__c.getInstance(userId);
System.debug(record);

CustomSettingName__c.getInstance(‘PROFILE_ID’)

1
2
3
4
String name = 'Backup Agent';
String profileId = [SELECT Id Profile User WHERE Name =:name].Id;
ChatAgent__c record = ChatAgent__c.getInstance(profileId);
System.debug(record);

Custom Metadata Type Visibility

With custom metadata types and records, you can determine who can access and change the types and records you created. When you create a type, you can choose whether the type is public or protected. All Apex code in an org can use public types. Only code within the package can use protected types.

Field Manageability

When it comes to protecting fields on custom metadata types, you have three options:

The package developers can use package upgrades to edit the field after release. Subscriber orgs cannot change the field for upgrades
Subscriber org can edit the fields after installing the package. Subsequent package upgrades don’t override the subscriber’s changes
Neither the package developer nor the subscriber can edit the field after the package is released. You can only use package upgrades after release to edit fields.

Note: You can also protect custom metadata types, providing the same access protection as protected records. If you change a type from protected to public, its protected records remain protected, and all other subsequent records become public. If you use Setup to create a record on a protected type, Protected Component is selected by default.
Note: When a type is public, you can’t convert it to protected. The subscriber can’t create records of a protected type

What is a Namespace?

Namespaces are prefixes that are used in managed AppExchange packages to differentiate custom object and field names from those in use by other organizations.

Namespace Records

The statements are tied to managed packages and not unmanaged packages.

Code that is in the same namespace as custom metadata records can read the records
Code that is in the same namespace as custom metadata types can read the records for that type
Code thats is in a namespace that does not contain the type or protected record cannot read the protected records

Package Custom Metadata Types & Deploy

Managed packages, unmanaged packages, and managed package extensions are all compatible with custom metadata types. And change sets let you deploy your types and records from a sandbox. Adding custom metadata records to a package follows the same process as adding custom metadata types to a package.

Note: To create a managed package, your org must be namespaced.

Custom Metadata Type SOQL queries

Querying Custom Metadata Types follow the same syntax used when using SOQL for Custom objects on the platform. However, there are a few limitations you must be aware of, such limitations were discussed in Salesforce Custom Metadata Settings Part 1.

Epilogue

The moral of this article was to broaden your understanding of Custom Settings and Custom Metadata Types in Salesforce, supplementing it further with a few code snippets to cement the concepts even more. Thanks for stopping by and i hope you were able to learn or reinforce your knowledge for Metadata in Salesforce 😃

Contents