4

SF is going to drop Territory Management (aka TM 1.0) in Summer 2020.

So we are trying to migrate our managed package to Enterprise Territory Management (aka TM 2.0).

As the first step of such migration, we are building some abstraction layer at Apex code level to work with territories, hiding all the hard references to Territory object (e.g. using dynamic soql, sobject get/put methods etc.)

After wrapping all hard references into abstraction layer, we were able to deploy our code base successfully to sandbox without any TM enabled, as a proof that all dependencies are really hidden, i.e. no static dependencies.

But when it comes to our managed package, hitting upload button still leads us to the screen where Territory Management is ticked in Package Requirements section, claiming that this is sort of 'auto-detected' dependencies.

Question here: how to make managed package let this dependency go? From our perspective, it seems like there is nothing pointing to territory explicitly in our repository. Is there any way to detect why it's still considered TM as a dependency when uploading managed package? Any idea would be appreciated.enter image description here

  • Can you check once more to make sure your package does not have any Territory management field or rules etc ? I think it could be there is some dependency that you have missed. – Mohith Shrivastava Aug 24 at 12:46
  • Specially check in your test classes etc to make sure nothing is hard referenced – Mohith Shrivastava Aug 24 at 12:47
  • @MohithShrivastava As I mentioned, we were able to deploy our code to sandbox with TM turned off (i.e. there were neither Territory object there, nor territory related permissions on that org). We have gone a long path so far, cleaning up our package day by day. – wesaw Aug 24 at 13:46
2

As it's been stated before, you need to engage Partner Support. Once a managed package has a dependency on a feature, and a version with that dependency is uploaded, it cannot be removed by the ISV. This restriction is in place to allow for upgrades.

  • That's the think here. When it comes to dependency from another package, it really works only one way - you can easily introduce a dependency, but cannot get rid of it. But in case of feature dependency (Territory Management in particular) SF is claiming that it's enough to remove all references from package and it will let it go by itself. – wesaw Aug 24 at 13:43
  • @wesaw If that's the case, I think your best bet is still Partner Support. They can help resolve issues of this nature. – sfdcfox Aug 24 at 15:17
1

Finally we've figured it out.

All our code base in repository has already been cleaned up from territory dependencies. But at the same time there was some garbage left right on packaging org itself (some obsolete test classes etc.) probably someone forgot to add sf artifacts to destructive changes xml when removing them from repo.

After retrieving package from packaging org itself and comparing with snapshot in repository, we were able to identify and remove those obsolete artifacts. And this was enough, i.e. on next package upload TM feature was not ticked anymore as an auto-detected dependency.

So there is no need to involve SF support here. After cleaning up all explicit Territory dependencies, package really let it go by itself, even despite having previously released major versions currently installed on many clients orgs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.