1

Let's say, we had LMA (License Managing Application) configured for our managed package and subscriber granted us permission to log in on their behalf via Subscriber Support tab.

If we logged in, would we be able to see on subscriber's org all protected custom settings and custom metadata hidden from subscriber by managed package? Would we be able to update them, i.e. custom settings values and custom metadata records? And what about introducing new fields to protected entities right on subscriber org?

If so, could we use this 'Subscriber Support' feature not just for debugging purposes, but for doing some additional/special configuration on subscriber's org? E.g. we are delivering managed package using 'generic' external service as a default, but for some VIP clients based on request we may log in via Subscriber Support and update endpoint/credentials/keys in protected settings to switch to 'Premium' external service (at the same time not exposing any secret info to VIP clients).

Any help would be appreciated.

Improve this question

1 Answer 1

Reset to default
2

Re Custom Settings, yes - if you log into an org via Subscriber Support, then you can see and update all protected custom settings in your package. Don't think that is true for Custom MetaData - I can't see\edit any protected CMD when I login to a customer org - the idea there is that you would push updates via a push upgrade, not update in the customer org.

But re your point about additional config, I really don't advise that approach. We have used that in the past, but some instances e.g. anything hosted on GovCloud - don't allow Subscriber Access, plus organizations are increasingly wary of letting ISVs access their orgs via Subscriber Support since they can't control what you can access

I would consider Feature Management rather than Protected Settings, since you can control that from the LMA. So you could include the Premium service in the package, and just enable it via Feature Management for any customer that requires it. It's pretty simple to set up and check for in the package.

Improve this answer
2
  • The main downside of Feature Management approach is that we need to think it through and package everything in advance when we are doing major release. So it becomes not possible to introduce e.g. the third type of service and configure it on subscriber org without pushing new package version there. But according to our development flow we are doing major releases just 3 times per year, and supporting them via patch flow then, which prevents us from adding new artifacts (e.g. new named credential or metadata record). That's why original idea with updating protected settings was so promising.
    – wesaw
    Dec 4, 2019 at 15:42
  • Another option would be to have the ability in the package to enter some encrypted token you provide to the customer that the package would decrypt and parse, or maybe use the token to make a callout to your services that would then send back the updated details to the customer's org and update the protected settings in package with the new credentials. Relying on Login Access for config is risky IMO
    – BritishBoyinDC
    Dec 4, 2019 at 15:50

You must log in to answer this question.

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