0

We are trying to update custom metadata records via deployment from source org (Dev Sandbox) to target (i.e. Packaging environment - Dev Edition), these records were packaged into a managed release in the target environment in the past. Below error occurs during the deployment:

Developer name already exists for given entity or has been previously used. Please choose a different name.

  • For example, initially the custom metadata data record was deployed with name Acc_xyz successfully!
  • Later during a round of deployment the same error occurred, as a work-around to the deployment error it was renamed to A_xyz just in the target environment. (not in source environment) The record was not packaged at that time.
  • Currently, when we try to deploy the same record with the original name as Acc_xyz (same as source org) which does not exist in the target org, it breaks the deployment and throws the error mentioned above.
  • Because the existing custom metadata records in the target org are packaged, their name is not editable or the record is not deletable. So, clean-up can't be done in the target org as well.

There are around 250-300 custom metadata records which need to be updated and also the number can grow in future. So, it would not be feasible to update the records manually in the meta file directly by keeping the same name.

This issue blocking the package creation/release. Appreciate any help/possible solution on how to go around this issue, Thanks!

1 Answer 1

0

When you build a managed package, you're subject to manageability rules that govern how you can change or delete already-packaged components. These rules are intended to prevent you from shipping changes that could break subscribers who are relying on the components you have shipped. As a managed package developer, you need to be aware of manageability rules as you plan which components you wish to ship and how you intend to maintain those components throughout the lifespan of your package.

For Custom Metadata Records, the ISVforce Guide documents that Custom Metadata Records are developer-deletable only if they are marked Protected. This rule takes effect once the component has been uploaded in a Managed - Release package.

For all components, it is generally the case (although there may be exceptions and edge cases!) that

  • once you have used an API name for a component in a managed package and subsequently deleted that component, you cannot reuse that API name in the future.
  • you cannot change the API name of a component that has already been packaged.

Your timeline is not entirely clear to me, but it does seem clear that you're encountering these two rules. Those Custom Metadata records which you've already shipped in your package, if not Protected, you will not be able to delete (although you should be able to change their content other than their API names). For any Custom Metadata record that you've successfully deleted, it is likely that you will be unable to reuse the API name, although if the record is only soft-deleted you might be able to recover it within 30 days.

2
  • Thanks a lot for the response @David! The team which shipped the custom metadata records (without marking them protectable) is no longer part of the project and the damage is already done. So as a solution, should we nullify the existing records (around 200) in the target and deploy the records with updated values using names which are not present as well as never been used before? In that case, we will always have those 200 blank useless records in the package. Any thoughts?
    – SFDC_Dev
    Dec 19, 2020 at 15:46
  • I'm not totally sure what "nullify" means in this context, but fundamentally, you'll likely have to live with these records. (Note: if they were only uploaded in a managed beta, you might still be able to delete them).
    – David Reed
    Dec 19, 2020 at 18:06

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.