0

We have an unlocked package with some custom metadata records. These custom metadata records contain record ids for data in the org, which are configured by our admins after package installation.

The issue we are running into is that when we upgrade the package, it is overwriting these ids in the custom metadata records.

Is there a way / best practice to avoid this? Whether it be just not overwriting these values, some post install script, or other?

Thanks

Improve this question
1
  • Hard-coded id values have always been a bad practice. Why not query records based on name or something else? As you can see, including those id values are causing problems. Alternatively, have you considered simply not including the records? If they need be set up every time anyways, there's little point in including them in the package. Maybe a script would work, but it feels like the wrong solution here.
    – sfdcfox
    May 11, 2021 at 14:42

2 Answers 2

Reset to default
3

I'd probably design this to not include any Custom Metadata records in the base package, and have a separate, dependent unlocked package that stores the Metadata records. This way, updating the base package would no longer affect the dependent packages' values, as they would only need to configure it once. You could also just not include any records, and have the administrators set up unmanaged values. The best practice would be to not use Id values at all, and instead query records by some unique identifier.

Improve this answer
1
  • This makes sense to me. We don't have Id's hardcoded we actually have them blank, but its nulling out what the admins put in. Regardless, I like the approach of having a separate dependent package for the records. We want to ensure certain records exist as they are tied to other functionality and have more fields than just id. Super helpful and thanks as always.
    – GeorgeA
    May 11, 2021 at 15:00
1

It's late to do this in your case, but in general if you don't want custom field values to be overridden, make sure to select "Subscriber Controlled" as the Manageability for the field on the type. Upgrades never overwrite subscriber controlled fields on existing records aren't changed by package upgrades.

Improve this answer
1
  • Avrom Roy-Faderman, I've just tried this on a scratch org and the update of the installed unlocked package has reset the "Subscriber Controlled" fields. The OP (in all likelihood) used "Subscriber Controlled" himself and the problem has been observed by others. Is it possible that you base your reply on managed packages? Do you have any documentation to back up your belief that it works for unlocked packages?
    – Felix van Hove
    Feb 4, 2022 at 17:17

You must log in to answer this question.

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