[SalesForce] How To Avoid Hard Coding ID

Basically, I have three custom objects:

Object1__c : Id, Name, Field1__c
Object2__c : Id, Name, Object1__c, Type__c (TypeA,TypeB)
Object3__c : Id, Name, Object2__c

I created custom lookup fields to build relationship among the objects.

Every time a new Object3__c is inserted, a new Object2__c must be created. Here's a sample scenario to make things clearer:

Sample Object1__c record :
  Object1 Name: ABC
  Field1: This is just a sample field. 

Sample Object2__c record :
  Object2 Name: O2-{00001}
  Object1: ABC
  Type: TypeA

Sample Object3__c record :
  Object3 Name: O3-{00001}
  Object2: 02-{00001}

Now, a new Object2__c record must be created, but this time, Object1__c lookup field must be ALWAYS equal to this value: DEF. But remember that this is a lookup field, so I made sure that there's an Object1__c record with this name:

Sample Object1__c record :
      Object1 Name: DEF
      Field1: This is a sample field1 value.

Assume that I already have this record. Now, to create new Object2__c record, I just assigned a Object1__c field the Id of the above record (DEF record) like this:

o2.Object1__c = 'a0sp0000008zHMw';

But someone told me that this is not a good practice.

How can I handle this kind of scenario without hardcoding the record Id?

Best Answer

If I'm understanding you correctly, you have an object with a lookup field that you always want to associate to the same record. If that is the case, then there must be something distinguishing that record, for example its name. In that case, you would build a query and then reference the returned Id.

Object1__c o1 = [SELECT Id FROM Object1__c WHERE Name = :'DEF' LIMIT 1];
Object2__c o2 = new Object2__c();
o2.Object1__c = o1.Id;

It is true that hard-coding an Id is bad practice. Let's look at why. Here are a few scenarios:

If you are planning on migrating this to another environment (sandbox to sandbox or production) then the ID of your record will change. What will work in SandboxA won't work in SandboxB because even if you create the exact same record, the ID will be different.
If you delete that record, you have to go fix all of your hard-coded Ids. That is difficult to manage.
Say that someone deletes your record. Obviously that would result in a few errors in your code. Hopefully what you would do with your query is then check to make sure there is a record that is being returned, and if not, you can handle the error properly.
It makes your code less understandable. No one has any idea what 'aBbb0000000PBvNCAW' refers to until they go look up that record (which may be difficult if you made the record in one environment and they are in another.) With a query, another developer (or future you) will be able to understand that you are getting a record with the name 'DEF'.

Related Solutions

[SalesForce] Remove lookup value once selected in a record

Lookup fields such as your Object1__c.Object2__c field can have a lookup filter defined. To exclude the already selected Object2__c instances in such a filter, you then need say a checkbox field Object2__c.InUse__c to use in the filter expression. A trigger can populate that checkbox field on insert/update/delete/undelete of Object1__c.

The trigger would look like this in its basic form:

trigger Object2InUse on Object1__c (after insert, after update, after delete, after undelete) {
    Set<Id> o2Ids = new Set<Id>();
    if (Trigger.isInsert || Trigger.isUpdate || Trigger.isUndelete) {
        for(Object1__c o1 : Trigger.new){
            if (o1.Object2__c != null) o2Ids.add(o1.Object2__c);
        }
    }
    if (Trigger.isUpdate || Trigger.isDelete) {
        for(Object1__c o1 : Trigger.old){
            if (o1.Object2__c != null) o2Ids.add(o1.Object2__c);
        }
    }
    if (o2ids.size() > 0) {
        Map<Id, Integer> m = new Map<Id, Integer>();
        for (Id id : o2ids) m.put(id, 0);
        for (AggregateResult ar : [
                select Object2__c i, count(id) c
                from Object1__c
                where Object2__c in :o2ids
                group by Object2__c
                ]) {
            m.put((Id) ar.get('i'), (Integer) ar.get('c'));
        }
        Object2__c[] o2s = new Object2__c[] {};
        for (Id id : m.keySet()) {
            o2s.add(new Object2__c(Id = id, InUse__c = m.get(id) > 0));
        }
        update o2s;
    }
}

and the filter criteria on the Object1__c.Object2__c field would be:

Object 2: In Use EQUALS False

[SalesForce] Use Custom Metadata as lookup instead of hard coding

Yes, you're doing it right. Your code would look approximately like this:

for(Account record: Trigger.new) {
  AccountGroup__mdt[] value = [select GroupType__c FROM AccountGroup__mdt WHERE GroupCode__c = :record.AccountGroup__c];
  if(!value.isEmpty()) {
    record.Field__c = value[0].GroupType__c;
  }
}

Note that this is one of the few times where a SOQL in a loop is acceptable. It does not consume governor limits like a normal query does.

Edit: As a minor performance optimization, you might still consider using the normal aggregate-query-update pattern, for consistency:

Map<String, String> codeToType = new Map<String, String>();
for(Account record: Trigger.new) {
  codeToType.put(record.AccountGroup__c, null);
}
for(AccountGroup__mdt record: [SELECT GroupCode__c, GroupType__c FROM AccountGroup__mdt FROM AccountGroup__mdt WHERE GroupCode__c = :codeToType.keySet()]) {
  codeToType.put(record.GroupCode__c, record.GroupType__c);
}
for(Account record: Trigger.new) {
  record.Field__c = codeToType.get(record.AccountGroup__c);
}

I recommend this pattern because it is mildly more efficient CPU-wise to do so, even when other limits are essentially free.

Best Answer

Related Solutions

[SalesForce] Remove lookup value once selected in a record

[SalesForce] Use Custom Metadata as lookup instead of hard coding

Related Topic