My app is getting the object id from the URL query string with the following code:


However, I have a customer who is reporting that this isn't working. The above line of code is returning null, even though I see the correct object ID in their query string. Of course, I'm unable to reproduce the error, and I'm looking for leads on what to look at to find the problem.

What reasons would my Apex code not be able to access the existing id parameter of my current page?

UPDATE: The customer is reporting that the error is only happening on the Business Account object type, with the Person Account and other objects types (Contacts, Opportunities, etc) have no problems. Could differing Account object recordtypes cause this type of issue?

UPDATE 2: Finally got the code onto an org that I could access with Person Accounts enabled. Turns out having Person Accounts enabled is the issue. Unlike I thought in my original question above, the id is getting retrieved from the URL. But later in the code, when querying salesforce for the Account's Name Field we stop when the first Name Field is found (because objects normally have only one Name Field). However, with Person Accounts enabled Accounts now have 3 Name Fields: LastName, FirstName and Name. LastName comes up first. So, when trying get the name value for a Business Account, LastName is null, and thus breaking my code.

  • I would get the customer's help to recreate it. Most likely they are doing something surprising. May 30, 2014 at 22:59
  • It could be possible that the error is coming from some other line. Perhaps the user does not have access to that record whose id is being passed. You could try to put some debug logs and ask the user to try the same again.
    – AslamK
    May 30, 2014 at 23:38
  • If one is particularly determined, it's possible to trash the ID (for the whole execution context) in a controller or extension. The opposite of this: salesforce.stackexchange.com/a/22525/320 May 30, 2014 at 23:51

2 Answers 2


If they open your page without supplying an id parameter then it will be null in your Controller.

e.g. if they navigate to your page by typing the URL


Since you can't stop users doing this, you should check if the id parameter is null in your Controller and either handle this case explicitly or if it can't be handled then display an error message to the user.

  • Right, if the id isn't in the URL I would expect it to return null. However, the screenshot they've shown me has instance.Salesforce.com/apex/YourPageName?id=001xxxxxxxxxxxx , which has the id. But, the code is returning a null at that point. May 30, 2014 at 23:12
  • @stmcallister Are you absolutely sure the error is on the line you gave? May 30, 2014 at 23:14
  • Not absolutely. The error is happening in the constructor of my controller, where I'm getting the id from the URL, as explained above. Then I'm using the prefix (substring of the first three characters) of that id to find the Object type and the Object name. Since the object the code is breaking on is Account, the prefix in question is 001. My assumption is that the id is returning null URL and using that null value to make the checks of Object type and name, since 001 is a common prefix and should be found easily. Jun 2, 2014 at 21:05
  • @stmcallister Are you able to post your full constructor? Jun 2, 2014 at 21:20

It's preferable to use getId() on the StandardController to handle the record like that.

There are ways to trash the URL parameters for the controller and all extensions, for the entire execution context. The above method is immune to the kind of overloading seen in the link.

Definitely I can see situations which might preclude the StandardController at first, like a page that takes multiple Id types. But if this is the case, one can make a wrapper page that uses an appropriate StandardController for each entry point object type.

  • 2
    After a postback, getting the ID from the parameters collection can return null since it won't be in the URL any longer and may not be in a form element named 'id' either. If I remember correctly, this happens most frequently when the page does not use a rerender during the postback.
    – Mark Pond
    May 31, 2014 at 0:23

You must log in to answer this question.

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