I have an Org Dependent Unlocked package that contains 2 approval processes -- and nothing else. It exists because when we built one of our early packages, we failed to realize that once you put an approval process in a package, it has checked into the Hotel California, and can never leave. Everything (everything) else except for the approval processes and their associated workflows got moved to a package called Core Objects, where they have lived happily ever after , and still do.
But in the fullness of time, I had to make a change to one of the approval processes, and that meant updating the package it lives in. Which now stubbornly refuses to install, giving the following error:
04tUM0000000N1RYAU | Installed Package | 0 | 0 |
Cannot add component of type:CustomObject named:Sponsored_Program__c subjectId:01I6g000002uvdv to this package because it is an installed component in another package with packageId:0336g000000iiTO.,
Details: package.xml: Cannot add component of type:CustomObject named:Sponsored_Program__c subjectId:01I6g000002uvdv to this package because it is an installed component in another package with packageId:0336g000000iiTO.
Now I have had this error come up before with other components, and after some muttering and swearing managed to find the offending package, and figure out which one will have to give up the element in question and resolve the issue peaceably. But this is new. This is giving me an error on a custom object that doesn't exist in the package I'm trying to install. In fact not only is the Custom Object Sponsored_Program__c not in this package, there is not even an objects folder. I am mystified. Bewitched, bothered, and bewildered. I've seen some weird deployment errors before, but I'm pretty sure I never had a component that wasn't in the package cause a problem because it's in a different package.
Nah, not stupid. But my understanding is that once you have records that have been approved by the process, the only way to delete it is to also delete the records that were approved by it. And that's not gonna work out well. I must confess, however, there is a lot about approval process that doesn't make sense to me. (I'm sure it made sense to somebody -- probably somebody far smarter than me -- at some point though.)
I should also confess that I've taken it on the word of the guy who brought us out of the darkness of change sets and into the packaged delivery devops model that there's no way to get an approval process out of a package. But he was a pretty smart guy, and a dliligent researcher, so I don't have reason to think he's wrong. But he's since moved on, so I can't ask about the details (not that he'd be likely to remember anyway). That's exactly the sort of thing that Salesforce would do, just to keep us on our toes. It's also possible that there's an Idea out there that's been collecting points for 18 years or something to address that issue.
And yes, there are a couple of ways that I can still deploy. One is to go back to a change set for the few component sin the package. I don't love it, but as far as I know there's nothing that would keep it from working. Another trick is to Deploy Source to Org directly from the project, which is a bit of a blunt force trauma, but it does work (even in production). And of course it's always possible to make the changes manually as you say. You'll get scolded by Setup that any changes you make directly will be lost if a package is deployed with this item in it, but if we could deploy a package with it, we wouldn't need to do it this way. All that said, I'd rather do it using a standardized life cycle, if for no other reason than to keep DevOps from becoming an economy sized bucket of whiskey-tango-foxtrot.
