Weird Advanced PDF/HTML Template trick I made up yesterday, if it's helpful to anyone: When you want to use a single template for several Transaction Forms, with only minor variations in its content conditional on the Custom Form field, you can't use record.customform because at least for now, customform is not included in the record data object for Freemarker. But I tried a workaround and it works for me: • Create a Saved Transaction Search with an Available Filter of Internal ID, and if needed, a condition filter of Type = Sales Order (or whatever transaction type you're doing this for) ◦ The Results should contain a Min or Max aggregation column of the Custom Form field. I actually used a FormulaText of {customform.id} so it would be sure to return the internal ID of the form instead of whatever name it happens to have at the moment. • Create a non-stored Transaction Body field whose Default Value is set to the value returned by that Saved Search you just made. I made it be a Freeform text field. • In your Advanced PDF/HTML Template, reference that custom transaction body field instead of customform. If you set up your search and field the way I did, you'll need to have your freemarker code's conditional logic check for the forms' internal IDs as strings, like record.custbody_customform_lookup == "123" for example. For some reason the ?number builtin fails in this situation. ◦ I wonder if it would work better to make the field an Integer type, and in the freemarker just compare it to 123 instead of "123". And/or maybe the FormulaText should be a FormulaNumeric? Whatever you do, just make sure the data types line up across all 3 components: Unstored field type, Search result aggregate column, and Freemarker conditional code. This approach allows you to access the Custom Form field value's internal ID in the template, without having to render the template from a suitelet that adds it in a data object first. UPDATE: I found out other users were getting a blank value in this lookup field, until I changed the Search to be Public, and then it could see the custom form ID and the rest of the template logic worked properly. On the other hand, you could also just make one template per Transaction Form and put your content variations that depend on which custom form it is, in each template. As a programmer I dislike that approach because it feels denormalized, but it has the advantage of never breaking because you're not trying to be clever and subvert the system which could change at any time.