Issue with Dependency Package Picklist Value Not Found

Question

I was facing issue while creating managed Package.

Where my managed package has dependecy with one more managed package called Financial Service Cloud.

While Building Package it is failing because of the Dependecy Package newly added pikclist value is not recognized.

I get below error because i have added additional picklist value to FinServ__CustomerType__c and FinServ__KYCStatus__c this field

ERROR running force:package:version:create:  Multiple errors occurred:
(1) Account.Application: Picklist value: Consumer in picklist: FinServ__CustomerType__c not found
(2) AbandonedApplications: filters-criteriaItems-Value: Picklist value does not exist
(3) FinancialInstituteBoard: In field: report - no Report named ApprovedApplications found
(4) OpenApplications: filters-criteriaItems-Value: Picklist value does not exist
(5) ApplicationsUnderReview: filters-criteriaItems-Value: Picklist value does not exist
(6) ApprovedApplications: filters-criteriaItems-Value: Picklist value does not exist
(7) ApplicationRecordPage: '{!Record.FinServ__KYCStatus__c}' is a picklist field.'Passed' is an invalid field value.

Here is my sfdx-project.json configuration file, I have kept above field in unpackagedMetadata as referecnce while building but still it not recognize this addtional value while building pakcage

{
  "packageDirectories": [
    {
      "path": "force-app",
      "package": "test",
      "versionName": "Version 1.0",
      "versionNumber": "1.0.0.NEXT",
      "default": true,
      "unpackagedMetadata": {
        "path": "unpackaged"
      },
      "dependencies": [
        {
          "subscriberPackageVersionId": "04t1E000001Ir0Q"
        },
        {
          "subscriberPackageVersionId": "04t1E000001Iql5"
        }
      ]
    },
    {
      "path": "unpackaged",
      "default": false
    }
  ],
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "51.0",
  "packageAliases": {
    "XXX": "XXX"
  }
}

ANy help should appreciated.

Answer 1

What you are trying to do is not supported well by packaging. It is possible, but clumsy, in first-generation packaging, and I don't believe you can make it work with second-generation managed packaging at all.

---

Your metadata contains references to picklist values that you've added to a picklist field owned by Financial Services Cloud. Picklist values aren't themselves packageable entities; they're just part of the custom field. What they means is that the picklist values that you reference in your metadata cannot be part of your package, but they have to be present in the environment in which your package is built.

You've tried to address this with unpackagedMetadata, which was a good idea but won't work. The unpackaged metadata feature is designed to support Apex tests, not package builds. It's deployed after your package is built, which is too late to support your use case.

I don't believe there's a way to construct a second-generation package that has this type of dependency.

---

There are a couple of other options you can consider

You can build a first-generation package by creating the picklist values in your packaging org.

However, that means you'll have an install-time dependency: your users will have to manually create those picklist values in their orgs before installing your package, or you will have to build a way to automate that for them by deploying metadata prior to the package install. And it's critical to know that deploying metadata for a picklist field can be a destructive operation; you'll deactivate any values created in the subscriber org that aren't represented in the metadata you deploy.

We built a system called Metadata ETL in CumulusCI to address that type of problem for Salesforce.org products. This approach only covers making it easier and safer to install a first-generation package with a picklist value dependency, however - it does not allow you to build a managed 2GP.

The other possibility would be to build an org-dependent unlocked package, which performs metadata validation at install time rather than build time. This has significant consequences for your distribution model, and if you've already started down the managed package route you'll likely not want to use unlocked packages. The skip validation option for managed packages has similar behavior, but you cannot promote a skip-validation package to Release status.

--

Edit: I've written up a more detailed article about how unpackagedMetadata actually works, with an example GitHub repo.