• Account
  • Resource__c

The Resource__c object has fields Type__c, AccountNumber__c, Active__c. This custom object has 4 records.

for example :

Type__c AccountNumber__c Active__c
New 0001 True
Medium 0002 False
High 0004 False
Low 0003 True

The Account SObject also has fields with those names (Type, AccountNumber, Active__c).

for example if insert 2 account records with these fields values

Type Accountnumber Active__c
High 0004 False
Low 0003 True

I need to check with these values in all the Resource__c records. If there is a match, we need to insert contact record with accountid.

We should not query with SOQL and we shouldn't check fields with static field names. How to check dynamically using schema sobject?

  • You should have included this information in your previous attempt at this question (which it appears you've deleted).
    – Derek F
    Jun 14, 2023 at 12:36

1 Answer 1


As written, your request is impossible.

As I wrote in your previous iteration of this question, SObject describe information gives you access to the SObject's metadata (the name of the SObject, record type info, field metadata, if the SObject is creatable, etc...). It does not give you access to the data, the actual records of those SObjects.

If you need to use actual records of your Resource__c SObject, then you must query for them. There is no way around that fact.

While you could create Resource__c records in-memory (and not insert them), that would largely defeat the purpose of having an SObject. A more approprite choice here would be to make it an Apex class instead.

If you want to avoid hard-coding this information (so that changes to the data do not absolutely need a deployment), then the more appropriate choice would be to use a Custom Metadata Type. While .getAll() and .getInstance() almost certainly do run a query behind the scenes (to build an internal cache), it does not count against the SOQL query limit. Even if you explicitly query against a Custom Metadata Type, it does not count against the SOQL query limit (though in this case it does contribute to the query row limit).

If you do go with the Custom Metadata Type approach, be aware that reliably testing your code means that you should create a "proxy" class (and use it instead of calling .getAll() or .getInstance() directly). This allows you to inject data specific to your test, which is helpful for testing things that should generate exceptions as well as running the test in orgs that have no records of that Custom Metadata Type (because Custom Metadata Type records are metadata, we cannot insert new __mdt records in a test).

After you get over that hurdle, doing the actual comparison sounds like a job for a Set.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .