So working on abstracting my field references. Using the example of setting the form on a new sales order record. My form has a fixed ID of

custform_my_awesome_form

. I'd like to reference things by their fixed IDs as they won't change from Sandbox to Prod, vs internal ids that will. The

N/record.setValue()

however accepts an internal ID, which will be different from prod to sandbox. The

N/record.setText()

appears to take the actual Name of the form, instead of the ID. Is there a way I can use the ID as a reference that doesn't involve a separate lookup to 1. find internal id of form by form id 2. then use internal id with

N/record.setValue()

How often do you refresh your SB?

~1/month give or take, inline with the number of refreshes we get per contract

You're not missing anything. There are very few places where you can use the string ID to set a field value. I usually solve this sort of issue with a combination of enumeration modules and getters.

I have the same setup myself, except the Names are hardcoded, which just irks me since the Names are more easily changed than the ids.

Your example might look something like this. If you have multiple sandboxes, your branches can use the account ID instead to select the ID

good to know at least I'm already doing what is recommended for now. thanks.

id prefer a lookup that didnt use the environment like that

ah yes but any code that uses new IDs is wrong after any refresh, so that's not any different to any other approach. I did fail to specify that over time, after every refresh, you get to strip away all the Sandbox conditions as the accounts normalize, and you can eventually do away entirely with the getters and use static values. The more often you refresh, the less ID drift you have

i favor a value coming from the account itself

As with all problems, there are many approaches, and they all have pros and cons. I didn't offer this example as The Right Answer.

The parameter is another idea, but recreating an entire list in parameters is too much overhead when I the actual item being selected is the same in both prod & sandbox, it's just the internal ID that's different

You cannot eliminate it, correct, except maybe by never creating a new custom Object ever again 🙂 But yeah you've got several mitigating strategies at your disposal

"create a static enum file that lives only on production with it's own IIDs, and one that lives only on sandbox with it's own IIDs" And when a SB refresh happens you'd lose your file in SB.

I thought of that, and in my particular case (wouldn't work for larger companies), when I push to prod, then prod's enum would have all of the requisite keys, and their updated values from prod. when a sandbox refresh happens, then prod enum gets pushed to sandbox, but values don't need to be changed since it's a copy of prod anyway. if any new keys are added to enum in sandbox, then when add those keys when pushing to prod.

So the first time, the starting point, yes, fair enough.