Among the things people often find themselves wondering about – what is the meaning of all this, why should I get up from bed in the morning and what awaits us after, there is one particular question that you’re painfully aware of (and if you’re not, you will be) if you’re a Salesforce managed package owner. That question is ‘what on earth do I do with the nearly-infinite number of components in my managed package that are not upgraded after a new version of the package is released?’ – and variations of this question.
While, fortunately, we do not have answers for the first three questions, we have come up with the answer to the latter – and it’s not 42.
But before we answer, let’s elaborate on the issue and the reasons for it. These components are what Salesforce itself refers to as ‘Subscriber and Developer Editable Components’ and describes them as follows: ‘The subscriber and developer can edit the component attributes…. However, these attributes aren’t upgradeable. Only new subscribers receive the latest changes.’
What it really means is that a subscriber can delete or edit certain components of your Salesforce managed package on their org – and they will not receive any updates of this component. Essentially, even if they choose to do nothing with the components from the list, they still won’t receive the updates after a new version release, which makes those components non-upgradeable (at least ‘automatically’).
As far as we know, the reason for it is fairly simple – a customer has to have certain ability to customize things, even within a managed package, so updating those things automatically thus rendering the customization – however small it is – null and void would defeat the purpose.
So, yet again, after weeks of development you find yourself in a position where the new version of the package is ready, tested and released. The next logical step would be to follow one of the two ways to update packages – you either inform your customers of the new version and provide the installation link or push the update onto their orgs.
This is where we finally come to the issue at hand – the components of your managed package that will not be updated no matter which of the two ways above you choose.
You can find all of those following the link from earlier but here’s the list of the most common cases:
- Page Layouts
- Field Sets
- Picklist Values
- Listviews
- Reports and Dashboards
- Apex Page Overrides
- …and so much more.
Yet again, there are a couple of ways to deal with this situation – some of the ISVs have their staff handle these updates manually – in which case they need to contact the client and arrange the time and access – and also discuss whether or not those hours are billable (more often than not they are of course not billable).
Some choose to provide step-by-step instructions for the clients’ admin – which puts an unnecessary brunt on the admin’s back.
But what we’ve come up with is something entirely different and that would be our application, Zuppio – now available on the Appexchange!
We will not elaborate on all the technicalities but essentially what it does is it lets you update those previously non-upgradeable, subscriber-editable components on as many subscriber orgs as you need at a time. As simple as that – you just connect every subscriber org, create a couple of actions in our app and you’re good to go.
It can also execute anonymous Apex code on those subscriber orgs, but that’s an entirely different story.
