0

We have an unmanaged package on an org with thousands of components in this package. And package has not been released yet.

Now we'd like to do some clean up and remove this package along with all its components from this org. But removing just the package does not remove artifacts from an org itself - they are continue living there just outside of the package.

Is there any way to clean up all the artifacts along with unmanaged package removal?

We've already tried to retrieve this unmanaged package to have package.xml generated for us and then used it as destructiveChanges xml file to do a clean up of everything inside the package. But it has thrown a lot of errors now complaining about dependencies between components inside the package - seems like there is a strict order in which artifacts of different types should be removed, i.e. SF doesn't allow to remove all this network of dependencies at once.

Is there some magic to remove everything at once, i.e. package and all artifacts inside without doing it a hard way by component types etc.?

Any help would be appreciated.

1

Most likely, the situation is that things outside the package depend on things inside the package. Rather than reading the errors from back to front, as we're naturally inclined to do, read them from front to back--the later errors are almost always a result of earlier errors. There's no "easy way" to do it, but it will be relatively easier if you start by unravelling the errors in the beginning (e.g. deleting or changing components so they do not depend on package components). It could even be that a single dependency can cause literally thousands of related errors. Start from the first error, and then work your way through the list; you'll often find the list will get very short very quickly.

  • In our case we know for sure that org components do not depend upon package components. The problem is that SF does not allow us to delete in one go bunch of different types of artifacts (even if they just depend upon each other - sobjects, aura components, classes, layouts etc.). E.g. we started with deploying some mocked sobjects (by removing weblinks and action overrides from them to get rid of aura dependencies). But again we are forced to do such tricks even to remove artifacts dependent only from each other - looks like 'destructive change set' cannot figure out such complex dependencies – wesaw Apr 14 at 14:43
  • I wish SF had magical 'delete package' command with option to wipe its artifacts from an org (at least for use case when no dependencies from outside world). – wesaw Apr 14 at 14:51

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.