Chris B - 5 years ago
@Andrew Waite, although a mechanism for defaulting field values is needed very badly, there are also valid use cases for needing an object/field Id as well. For example, I'm currently designing a custom visualforce "page layout" section where people can select the fields they want to display for a dynamically generated visualforce page (without me having to hard code each field and update the fields displayed anytime someone wants to make a change).
In order to accomplish that, I'm saving the fields they've selected for their page layout to the Custom Settings object (since salesforce doesn't permit access to the describeLayout() method via APEX without getting super kludgy). But if someone updates the API name of a field (which happens all the time), the reference to that field that was selected for the page layout suddenly stops working, and I have to put in some exception logic that just makes the field dissapear from the layout, instead of just having its name get updated and remain on the layout.
All the salesforce metadata that references fields in salesforce (layouts, formula fields, etc) always reference the salesforce field ID's (beyind the scenes) when they get saved, in order to avoid exactly those kinds of problems. It would just be extremely helpful to have access to the same functionality on the APEX/Visualforce level, so that modifications to field names wouldn't cause problems when using Dynamic Visualforce or Dynamic Apex.
Chris Hubbard - 5 years ago
Anytime we need to make a button to create a new object with a pre-populated Record Type, we need to use the lkid hack. It would be great if we could get field IDs via Apex so that we don't have to keep updating the field Ids for the lkid hack after deployment to another environment.
Kai Amundsen - 5 years ago
We have the need for defaulting fields when creating new records all of the time.
Andrew Fawcett - 6 years ago
While I agree with Andrew Waite's comments to urge caution around the URL hacking use case that lies at the root of this requirement. I did want to update folks here that while its not quite via Apex Describe, Salesforce has now exposed the field ID's via the CustomField object in the Tooling API. You can read more about the approach I used to query this info from Apex at my blog. Hopefully this discovery can help add a little more robustness to the solutions surrounding underlying need here.