You know how it is with cars. You start out with that shiny new set of wheels with the new car smell that costs nothing in maintenance. Over time it picks up a few stains and scratches, and needs some minor repairs. If you keep it well maintained, a car can last nearly forever, but if you don’t, you run the risk of sudden breakdowns, putting yourself and others at risk.
Your Salesforce packages are a lot like that.
When you install a new package it is usually built against a current Salesforce API. What does that mean? You see, the Force.com platform is currently updated three times a year. Each update has a new API version – that means that the features that can be accessed by developers changes every three months. If a package uses API version 28 (which is the summer 13 version about to come out), its software will continue to use that version even after 29 and 30 come out. That helps ensure that software continues to run correctly even as Salesforce updates the platform.
However, this process isn’t perfect. That’s because packages can interact with each other. If one package has a trigger, and another package creates an object, the first package’s trigger code will execute. API versioning doesn’t solve all possible problems that can occur due to changes in the platform over time.
In addition, while Salesforce is very good about maintaining backward compatibility when new versions come out, it’s not perfect. Sometimes bugs creep in. Sometimes changes in behavior are made to improve or maintain system security.
All too often I see orgs where a package is installed but never updated. I’ve seen orgs with packages that use API version 13 – that’s 15 releases back, or almost five year old software. In many cases, it’s no longer being used – but can still interfere with the test code or even operation of newer packages.
You can find out what API version your packages are using by looking at the version of the various APEX classes as shown here:
One of the best ways to keep your org customizations operating properly is to be sure to periodically update any packages you are using. You don’t need for them all to be on the latest API version – in fact, most package vendors prefer to stay one or two versions back, to allow plenty of time to validate their software on the newer API version, and time for Salesforce to identify and resolve any issues that may exist on the new version.
By the way, this problem will exist on your own code as well. I know it’s very tempting to leave well enough alone, and that it can be costly to update your integrations to a new API version. But in the long run, just like with regular auto maintenance, the investment is well worth it. It’s still cheaper than dealing with a sudden breakdown.
