So I've run into a bit of a crazy issue that may or may not qualify as a bug. But it's really weird. I haven't had the time to put together a minimal example but I will describe it here, anonymized.

  • I have a Visualforce page with an Apex Controller.
  • The Apex Controller contains a property Thing of type Thing__c, and a field Thing.field1__c is referenced on the VF page. The field is definitely always retrieved in SOQL.
  • The VF page has a button that runs an Apex method that makes an update to a ChildThing__c record and then re-renders the section of the VF page containing the Thing.field1__c reference. Note that Thing has not been re-fetched in this Apex method and gets retrieved from the view state.
  • There is a Process Builder on ChildThing__c that runs an E-mail Alert based off a Visualforce e-mail template if certain conditions are met.
  • The Visualforce e-mail template uses several fields from the parent Thing__c record (although, notably, NOT field1__c so as a shortcut I added <apex:variable var="Thing" value="{!relatedTo.Thing__r}" /> near the top so that I could bind to its fields with less hassle.

If I click the button to save, under a condition where the Process Builder won't run, everything is fine and nothing weird happens. If the Process Builder does run, the save completes and the e-mail sends, but the re-render fails on the error "SObject row was retrieved via SOQL without querying the requested field. Thing__c.field1__c".

If I edit the VF e-mail template so that the apex:variable is now named something else, not the same as the property of my VF page's Apex controller, no such error happens.

I can only conclude that if a VF e-mail template runs in the same transaction as a VF page re-render, they share one ApexPages context and the e-mail template can "clobber" the VF page's properties.

I was racking my brain until I finally noticed that it was only erroring out if the Process Builder ran, which led me on a trail to the VF template. Has anyone else ever run into this bizarre scenario?

1 Answer 1


I haven't run in to this, but it makes sense. You can run in to similar errors if you share variables in pages, and then apex:include them into a parent page. I don't know if they have a bug for this, but the general idea is that you should avoid using apex:variable until/unless they actually fix the problem. Variables don't have scope, meaning you can reference them in places that do not logically make sense, and you can confuse the Visualforce engine when using apex:composition, apex:include, and other elements that allow you to mix and match elements. In fact, this can also happen if you use variables in a Visualforce component as well. They should only be considered a last resort, not a preferred choice.

  • Interesting. I do tend to use apex:variable to slim down pieces of declarative logic into reusable chunks. I wonder though if there are any similar clobbering issues that occur without the use of apex:variable when two VF contexts are in the same transaction.
    – Charles T
    Commented Jan 20, 2018 at 2:56

You must log in to answer this question.

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