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
Muralidhar SingriMuralidhar Singri 

Candiate Object and Candidate Field in Recruitment App ...

This question is in reference to "Recruitment App". I know that the object reference and field references are different. However, the custom object Candidate API name and the Candidate field in Job Applications object API name are same. Can this ever create a confusion? Why to duplicate like this? 
Best Answer chosen by Muralidhar Singri
bob_buzzardbob_buzzard
This is quite common - the Candidate field is a lookup to a Candidate object, which will be stored in the database as an ID. It shouldn't create confusion as their usage is quite different - one is an sobject, which is a first class type, can be queried etc, while the other is a field that can only be access via a Job Application sobject. There's no way that the platform could be duped into thinking that the field is actually an sobject or vice versa.  Sometimes people explicitly name the field as something like 'Candidate_Id__c', but there's no particular reason why this would be better or worse.

If you look at the standard objects, the relationship between Contact and Account is stored as AccountId, but if you follow the relationship to retrieve a field it is Contact.Account.Name, so the relationship matches the sobject name.

All Answers

bob_buzzardbob_buzzard
This is quite common - the Candidate field is a lookup to a Candidate object, which will be stored in the database as an ID. It shouldn't create confusion as their usage is quite different - one is an sobject, which is a first class type, can be queried etc, while the other is a field that can only be access via a Job Application sobject. There's no way that the platform could be duped into thinking that the field is actually an sobject or vice versa.  Sometimes people explicitly name the field as something like 'Candidate_Id__c', but there's no particular reason why this would be better or worse.

If you look at the standard objects, the relationship between Contact and Account is stored as AccountId, but if you follow the relationship to retrieve a field it is Contact.Account.Name, so the relationship matches the sobject name.
This was selected as the best answer
Ankit AroraAnkit Arora
It should not create any confusion as whenever you are referencing an object you simply right object API name which is in your case is probably Candidate__c but if any object say has a look up of Candidate then you will first right object API name then . and then Candidate__c.

This is the only way to access the object references. Hopr this helps.
Ankit AroraAnkit Arora
Apologies for the cross post.