3

I have set history tracking for my Custom Object and set a Lookup field for my referenced Object.

CustomObjectX_c[Field1,Field2,Account_c]

Here Account__c is a lookup field to the Salesforce Account Object.

Whenever there is any change in Account_c it reflects back in CustomObjectX_History with two entries.

Say old Account_c is 001ABC (named A1)and new Account_c is 001XYZ (named A2).

entry1 for Account.Id:

  • OldValue: 001ABC

  • NewValue: 001XYZ

  • Field/Event: Account__c

entry2 for Account.Name:

  • OldValue: A1

  • NewValue: A2

  • Field/Event: Account__c

Problem:

  • Since the Field/Event is same in both these records it is hard to distinguish which maps to Account.Id and which maps to Account.Name.

  • Currently I am querying back the Salesforce with each NewValue to check whether an Account with that Id exits.

check for entry 1: 

SELECT id from Account where id = '001XYZ' => true

check for entry 2:

SELECT id from Account where id = 'A2' => false

Is there a smarter way to prevent Account.Name records being mixed up with the History Tracking ?

Improve this question

1 Answer 1

Reset to default
3

Firstly a with pleasure +1 on the quality of your question!

Yes it seems a shame to have to query the database to check this. The following use of Id.valueOf might be preferable for you? Though does assume your users are not naming Accounts with valid Id's, which would be bizzare i agree. That said something you could write a trigger validation on to be safe.

Boolean isId = true; // Think possitive thoughts!
try { 
    Id.valueOf(newValue);
} catch (Exception e) { isId = false; }
System.debug('Was it an Id? ' + isId);
Improve this answer
3
  • thank you for the suggestion. Sorry I missed out a point that I am consuming this data through REST API outside the scope of Apex. I tried these approaches 1) if some_random_text.starts_with('001') #=> likely to be AccountId 2) Changing Account__c type from Lookup to Master-Detail (works the way I want but this doesn't allow me to edit the field after creation) 3) order by Parent.LastModifiedDate and pick the second record with Field => 'Account__c' #=> seems Id record gets created before the Name. But I think if there is a way to stop the creation in the first place it would be great.
    – karthikselva
    Commented Nov 30, 2013 at 2:25
  • I moved away from my initial Reverse Lookup Query approach, since its really bad for my scenario(with REST API) due to two reasons 1. Costs me Additional API limit usage. 2. Processing delay due to Network request-response cycle (I felt this to be an overkill just for validation).
    – karthikselva
    Commented Nov 30, 2013 at 2:43
  • a regex would do a decent job of detecting an id, [A-Za-z0-9]{18}
    – Ralph Callaway
    Commented Mar 14, 2014 at 1:06

You must log in to answer this question.

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