Xjyuk

Here is an example of the challenge I have faced multiple times. I was wondering if anyone could offer best practices on how they handle situations like these.

I have an apex class that process records. I want to store some parameters outside so that my administrator could modify these parameters in the future without modifying and deploying the Class.

Consider this example:
I have a class that processes records owned by Users of specific Profiles.
In my class I have an SOQL query:

List<Id> profileIds = _____________; //I want to reference these Ids.
List<Opportunity> liOpportunity = [Select Id....FROM Opportunity WHERE Owner.ProfileId IN: profileIds];

What I have done in the past is create a new List custom setting Config__c with a Custom Text Field to store the profile Ids called Value__c and comments__c.

Then I would create the following record:

In my Apex Class, now all I have to do is reference the Value field in the Custom Setting.

List<Id> profileIds = Config__c.getValues('ProfileIds').Value__c.split(';');

The advantages of this method are:

1. Doesn't count towards governor limits


2. Easily configurable without deployment if requirements change at a later date.

My questions are the following:

1. Is this an optimal way of doing this or is there a better way to accomplish this (with similar or greater advantages)?




2. Would it be better to use a Custom Metadata Type for this scenario?

I hope this is the correct forum / way to ask this question. If there is a problem with my question or it is unclear kindly comment and I will restructure the question.

Is this an optimal way of doing this or is there a better way to accomplish this (with similar or greater advantages)/Would it be better to use a Custom Metadata Type for this scenario?

I would use custom metadata types for the following reason.

1. We can use SOQL, and each profile ID can be a record of custom metadata. SOQL on custom metadata are not counted towards the governor SOQL limit


2. Can be configured directly in prod. No need of deployment


3. Can be source controlled as its a metadata, that mean you will retain history of what was the older value if you use Version control like GIT or SVN


4. Can be deployed using ant and change set. You dont have to worry about moving them as they can also be packaged(read unmanaged, managed, unlocked etc)


5. Can have relationships to other custom metadata records


6. Can have entity deifinition and field definition to Standard/Custom Object and fields.