In our managed package, we have several s-controls that are called from buttons to prefill form data on page layouts (both custom and standard fields). During upgrade testing, we recently found out that this was broken as of the Winter09 release, when SF redesigned their packaging structure and eliminated the need for identical IDs on packaged items.

We knew that prefilling forms in this way (using the field ID in the URL) was an unsupported/undocumented feature, and that it could break some day, but we were none-the-less surprised. Turns out that it only affects packages (not simple customers) and only shows up on upgrades in our case because the DOT/trialForce process fixes the IDs automagically.

We did find a solution, however, that works in all instances, and doesn't require any manual setup or configuration.

We wrote a snippet that will, given a URL prefix (/003 for contacts, /006 for acct, etc) fetch the edit page for that type of object and parse through the request, pulling out the label tags. Each field has a <label for="fieldId">Some Field</label> tag which cross-refs the field label to its ID. We then build a map of Label/Ids, which is used to replace the label token place-holders in the custom URLs we are building.

The ajax request is only at most 1/2 sec, so there's not much performance impact to doing it in this way.

It's true that SF could change their page layout schema in the future, but I'm betting there will always be some mechanism for prefilling forms, as this has been done since the early days of the internet. We can easily tweak our parser to compensate for any changes here.

This was the cleanest solution that we came up with, taking into consideration the packaging constraints and wanting to limit API call usage. We wanted to share with the community here, because in talking with some SF folks, a few other partners had similar issues, but didn't find very good (in our opinion) solutions. Feedback is welcome!