function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
D0ubleStakkedD0ubleStakked 

strange behavior with Ids: 2 Ids for the same opportunity?

Hi,
   I've seen this a few times now, and I'm a bit cofused.
 
   I have an S-Control that passes the {!Opportunity.Id} merge field from SFDC to my external application, and my external application maps that Id to some data in my application.
   I then have a data replication job run in my external application, and the first thing it does is it makes a webservice call to SFDC to validate that the Opportunity in its mapping table still exists.  What I'm seeing is that the Ids returned to me from the webservice call are DIFFERENT from the {!Opportunity.Id} merge field that my external app originally received.
   I'm seeing Ids like:
      b125000001111cX and b125000001111cXAAG
 
   When I put both Ids into SFDC's interface  (...//na3.salesforce.com/either_id_goes_hereBOTH return the same record.  So it looks like my Opportunity has 2 Ids.
 
   Has anyone else seen anything like this before?
   I'm not creating these Opportunities from my external app, so all of this data is coming from SFDC.  My external app only replicates supporting data to/from SFDC based on the Opportunity's Id.
 
Thanks,
-Brian
SuperfellSuperfell
search for 15 vs 18 char Ids, this has been covered in detail before.
D0ubleStakkedD0ubleStakked

Thanks Simon.  I found several discussions on the "15 vs 18 char Ids".
However, I didn't see any set decision or recommendation about a best practice.

Some people recommended checking the length of the Id, and if its 18 characters, then always substring it down to 15.  Others recommended always using looking up the sObject and using its 18 char Id.

Do you have any recommendations about which would be a better approach or best practice?
I'm currently looking up the sObject and using the 18 char Id, rather than doing the substring.

Thanks again for your quick response,
-Brian