Salesforce Transaction API version

Question

In ORG we have multiple triggers for Opportunity with different API versions. Some of triggers are installed from managed package and have api versions 25-28. Local ORG opportunity trigger has api version 35. The question is Do all APEX code in transaction runs under same api version or they are separated for each class? If api version is transaction wide will it affect on apex code compilation proccess? For example we use user address field that is new from api version 29 and in apex class with api version less then 29 it will not be visible.

Answer 1

All of the org will operate under the current API for an Org. What happens is that when code is running under the current API, code saved under a previous API is processed using the rules that were in existence or that "apply" to that API.

Whether a trigger would act on a previously new API field would depend on the design of the trigger. If for example a trigger was looking for changes in any field, then I'd expect an older trigger and/or handler to still be "called" by a change in your new address field. That being said, I wouldn't expect the trigger to do anything specific with that field since you'd not written code that would specifically act on it.

The exception to the above being if you were using dynamic apex where you'd done a schema call to get the Schema.DescribeFieldResult followed by using getSObjectField().getDescribe() on the results. Doing that would detect any new fields and allow the trigger and/or handler to operate on them.

The answer is that all fields will be "visible" to your triggers along with any handlers they call. All your fields will exist in both trigger.new and trigger.old. How your triggers will be affected by the new field is something that's going to be code specific. Look at your code and perhaps run tests to determine whether your trigger will get called and just exit, or if it will get called then operate on those fields plus related objects. You'll need to look at the impact on a case-by-case basis to determine this, just as you'd presumably need to do when adding a custom field.