2

In one scenario, we have to redirect from VF page to create new Opportunity Page, for that following code is working fine, but each time when we are moving it from 1 sandbox to another, we have to change related field Ids in URL:

public PageReference createNewOppyWithDefaultValues() {
    PageReference ref = new PageReference('/006/e?RecordType=012G0000000nCZW&ent=Opportunity' + '&opp3='+Oppyname + '&CF00NG000000DeVnR=' + objbulkracOppy.Name+'&opp4_lkid='+fieldObj.accountid+'&opp4='+fieldObj.accountName+'&00NG0000008k9Hh='+fieldObj.dealValue+'&00NG0000008k9IY='+fieldObj.orignalPId+'&00NG0000008k9Iw=IDR&00NG0000008k9Hz=EIME&00NG0000008k9IQ=PIPU'); 
    return ref;
}

once I move this code to another sandbox custom field Ids are change to other Ids; for ex: 00NG0000008k9IY , 00NG0000008k9Iw field Id changed to other.

To fix it, each time I have to change URL field IDs, Is there any solution to assign default values for apex code to sObject(here it is opportunity)?

2 Answers 2

1

I think you have three options:

  1. Keep all sandboxes refreshed & maintain standard development lifecycle process, then field IDs will remain consistent I believe.

  2. Clone from an existing Opportunity, by redirecting the user to:

    '/e?clone=1'

  3. Redirect the user to a new Opp. entry VF page, where you can control the field IDs like so:

    <apex:inputField value="{!opp.Name}" id="OpportunityName"/>
    
1

This is a temporary development problem. As annoying as it sounds - live with it. Once you move the code to production and refresh the sandboxes from prod - the ID will be the same between the 2 environments and from that point onwards you'll forget you had to fight with the unknown field's ID.

This solution is unacceptable in environments that really can't have hardcoded field ids - for example managed packages have no control over when they're installed and what ids will be assigned...

In at least 1 project I've used a custom setting (type = hierarchy) to store field ids. Hierarchy settings are available in the formulas/validation rules/workflows as merge fields. It's counter-intuitive (hierarchy setting where you need only org-level), painful if you create fresh environment and forget the setting is empty... but well, it's something bit better than hardcoding it in the link.

The most proper way would be to use Tooling API to fetch the Field Id... More trouble than it's worth for something that's a pain only during the development... Or you know, you could always decide to override the page with visualforce and then parse the URL parameters to your heart's content ;)

You must log in to answer this question.

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