I have two objects, Parent__c and Child__c, Child__c has a lookup field to Parent__c calledParentId__c.

I have overridden the New and Edit pages for Child__c using a Visualforce page with the Child__c standard controller.

<apex:page standardController="Child__c" extension="ParentChildExtension">
    <apex:sectionHeader title="{!Child__c.ParentId**r.Name}"/>

If I click the Edit button on the Child__c related list to access my page, the apex:sectionHeader title is populated. However when I use the New button it is not.

I've tried using the addFields method in my controller to add the Name (and other fields) from Parent__c that I'm interested in but this still does not work when using the New button.

Edit Button Behaviour

Edit Button - Related List

Visualforce Page
Edit Button - Visualforce Page

New Button Behaviour

New Button - Related List

Visualforce Page
New Button - Visualforce Page

This is easily solved by querying for the Name field of Parent__c in a controller extension (if it's missing), but is there a way of doing this that without using a controller extension and/or a SOQL query (and preferably without resorting to the "lkid hack" mentioned in Keith C's answer)?

public with sharing class ParentChildExtension
    private final Child__c child;

    private String parentName;

    public ParentChildExtension(ApexPages.StandardController stdController)
        this.child = (Child__c)stdController.getRecord();
        this.parentName = child.ParentId**r.Name;

    public String getParentName()
        if(parentName == null)
            parentName = [SELECT Name FROM Parent__c WHERE Id = :child.ParentId__c].Name;

        return parentName;

EDIT: Added stipulation that I would prefer to avoid the "lkid hack" if possible, and that I've tried using the addFields method in my controller.

  • In a 'New' you must query specifically for the parent. The object brought back from the 'New' button is not in the database, which also means that the links to the parent is not yet in the database. It still has time to change before actually being inserted and so makes sense that it doesn't have the parent value by default. You must query to get the value.
    – dphil
    Mar 18, 2014 at 14:55

1 Answer 1


The standard controller addFields method supports field access via relationship fields allowing you to pass the responsibility back to the standard controller to do the querying. But "New" behaving differently to "Edit" suggests that the problem may be more related to differences in how the standard controller handles the two situations. But addFields is worth a quick try.

Beyond that, you'll note some command-line parameters get automatically added that identify the id and name of the parent object. (Google "Lkid hack" for more detail.) As you don't care about the specific key values, you can just grab the id and name from there.

PS But as the comment thread below discusses, given the choice between an extra query and relying on Salesforce not changing the URL pattern, the extra query is the way to go. Meanwhile, a load more votes and comments on https://success.salesforce.com/ideaView?id=08730000000gM7mAAE for the benefit of future generations can't do any harm.

  • I should have added to my post that I've tried addFields and that doesn't work. The problem I have with the "Lkid hack" is that it requires an awful lot of work to get it going without hard-coding field IDs, and that makes it feel like a worse solution than the extension and SOQL one. Mar 18, 2014 at 14:11
  • ... I'm suggesting you can rely on the pattern not the actual values e.g. find the key that ends in "lkid" then pull out the field id from that then take the value that has that key. Relies on the URL pattern that Salesforce reserves the right to change (but many people use) but doesn't rely on the field ids.
    – Keith C
    Mar 18, 2014 at 14:14
  • I see what you're saying now, but my overall opinion remains, whilst this does avoid the need for an extension and SOQL query, it still feel like a bit of a hack, especially as it's vulnerable to being broken if SFDC decide to change how their URLs are formed in future releases. I'll give you an up-vote regardless, since hacky as the answer is, it does answer my question. Mar 18, 2014 at 14:16
  • I'm not denying it is a hack and for the sake of avoiding a query I wouldn't use it. The URL pattern is more necessary in other cases and an alternative from salesforce remains in the safe harboured (and probably distant) future success.salesforce.com/ideaView?id=08730000000gM7mAAE.
    – Keith C
    Mar 18, 2014 at 14:22
  • Just to confirm, this only works for the 'Name' field (or whichever field is used in the lookup depending on the object) and won't work other arbitrary fields as these are passed in the URL. Is that correct? Mar 18, 2014 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.