+ Start a Discussion

Solution for pre-populating custom fields from s-controls in Managed Package

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!

I also would include that Visualforce can solve this problem too in a cleaner, supported manner.

Please, do tell!


One of the major requirements that we needed to maintain was the ability for subscribers to be able to edit their page layouts in the normal fashion. It is my understanding that with VF, you could replicate the look and feel of the page, but it would require an inordinate amount of maintenance going forward, and the user could not modify the content of the page.


How can Visual Force solve this problem differently?


We have a VF page for custom object A. From this page we need to open the New page for related object B with the lookup field for A pre-filled. So if we determine the custom field id of A's id on the object B we can use it to construct a query string that opens a New page with the custom field prefilled. We can determine the custom field id of A's id on B by examining the source code of the B page. However this solution is not packagable since in each org the custom field id is unique.


The post below seems the most relevant to this issue that I can find. cgoss mentions that the "DOT/trialForce process fixes the IDs automagically." Also aalbert asserts tantalizingly that the process works more smoothly in Visual Force. Can anybody further explain any of this? What am I missing about this?