Hi @Rupert Barrow,
Related link
Thanks
Hi All,
We have created a unlocked package and when we tried to install this package in sandbox, we are getting notification that package installation failed
1. Experience Cloud: Changed Password Email file is located in both the package you tried to install, and in either the unfiled-public folder or a user folder in this org. To install this package, either delete Experience Cloud: Changed Password Email from this org, or move it to a different folder.
Experience Cloud: Changed Password Email: Experience Cloud: Changed Password Email file is located in both the package you tried to install, and in either the unfiled-public folder or a user folder in this org. To install this package, either delete Experience Cloud: Changed Password Email from this org, or move it to a different folder.
The Email template is standard template connected to experience bundles
We tried to delete it from Destination Org but its not getting deleted. We renamed the email templates in destination org and still getting the same error.
We tried to delete it from package and our package validation is failed due to dependency errors.
Any recommendation how to bypass this
#Unlocked Packaging #Digital Experience #Email Template
Thanks in advance
We were able to bypass the errors by moving all the reports and email templates from UnfiledPublic to custom public folder. We have logged a case with salesforce support (45992349) but no lucky. There is no documentation around it as well.
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.
If you work for an end-user or SI partner and are interested in using modern package based development in a mature org, come along to my session in the Developer Theatre. I'll demonstrate how org-dependent packaging can play nicely with even the richest happy soup, without the need to deconstruct the soup into its basic ingredients.
Event if you aren't attending Dreamforce, there's plenty of useful resources to get you started.
In the session I demonstrated an application built with a combination of a fairly simple Bookstore "Happy Soup" and an org-dependent package that added the concept of book readings by authors. You can find the source to each of these on Github (after the session completes - links are not public yet) :
Trailhead, as usual, is a great place to start learning:
And a few other links that should prove useful:
#Unlocked Packaging #Org-Dependent Packages #SFDX #Dreamforce2023
Hi Keir, thanks for your slides.
Here are mine, which I presented last week at French Touch Dreamin in Paris #FTD23 on a similar subject :
https://github.com/RupertBarrow/ftd23/blob/main/docs/slides/rbw-slides-v2.pdf
Hello, I've started down the Unlocked Packaging trail and have built a couple of packages for some of our Orgs. In one of those packages I have a fieldset on a custom object that is used in a SOQL to return data with a custom. After installing the package in another scratch org and adding an additional field to the object I am not able to add that field to the fieldset through the UI. I can remove the existing field but no other fields show to be added. I can however add them through metadata in the dx project. Anybody run across this. I'm working on some sample code for this but thought I'd ask the question here.
Thanks in Advance,
Dave Casper
