2

We build all our packages as "unlocked" packages.

We have a package called "common". Common holds anything that is related to standard objects, like standard value sets. ie: CaseStatus and the such.

We have other projects that all depend on the "common" package. For example "application1", "application2" both depend on "common".

Now "application1" requires a new CaseStatus entry. We add the new entry to the CaseStatus standard value set in the "common" package.

We would like to be able to reference that new CaseStatus in classes that are in our "application1", however we can't because the CaseStatus standard value set is not part of the built package.

The only way we can do this is to also include the same CaseStatus standard value set in our "application1" and "application2" source so that each of those packages can build successfully.

I do realize that standard value sets are not supported by unlocked packages, but what is a team to do? What we are doing works however we come across issues, where new members get added to the team and they modify their local version and then deploy that. If that local version is behind, then statuses get deactivated. Sometimes a new project starts up and they end up pulling an version into their local that is not correct...

It would be nice if standard value sets could be part of the package for dependency sake, but then salesforce ignores them on package install, that would at least be better.

Just wondering if anyone has any other suggestions? OR if salesforce will be supporting standard value sets in packages in the future?

1 Answer 1

1

The current solution here is "unpackaged metadata" or making it an org-dependent unlocked package.

David Reed goes into more considerations in his blog, but the gist of it is that unpackaged metadata helps with otherwise unpackageable things.

Unpackaged metadata is deployed after the packaged code, but before tests are run. The initial deploy of the packaged metadata (which means it goes through the compilation step) means that you can't have any hard references to that unpackaged metadata in your packaged metadata. For picklists, since I don't think there is a way to make a hard referece to a particular picklist value, the main concern is that you avoid hard, compile-time references to the picklist field itself.

So if your code or a formula contains something like

Case myCase = new Case();
myCase.Status = 'value';

that's a hard reference (resolved at compile-time), and an issue.

To get around that, you'd need to use myCase.put('Status', 'value'); instead (a soft/runtime reference).

To include unpackaged metadata in an sfdx project, you need to:

  1. Create a folder that's outside of all of your other paths in the "packageDirectories" in your sfdx-project.json
  2. Move the target metadata into that new folder (use force:source:retrieve if you don't already have the target metadata)
    • I'm not sure how strict sfdx is with the folder structure inside of the unpackaged directory. Just keeping things in their source-form subfolders like "objects" and "standardValueSets" seems to be sufficient
    • That is, you don't need to bury the metadata in the full ./main/default/ structure. ./unpackaged/standardValueSets should be good enough
  3. Add this new folder to the "packageDirectories" in your sfdx-project.json (another JSON object in the list), and specify "default":false
  4. Specify "default":true in one of your packaged directories in sfdx-project.json
  5. Create an unlocked package for your project (if you haven't already)
  6. Add "unpackagedMetadata": {"path": "unpackaged"} to one or more of your packaged directories to have it picked up by the packaging commands

You only really need to complete steps 4 and 5 in that relative order. SFDX will complain if you try to include "unpackagedMetadata":{} in your sfdx-project.json for a non-packaged project.

Also, yes, you do need to include {"path": "unpackaged","default": false} in addition to using the same path name in "unpackagedMetadata":{}. If you don't, SFDX will give you some error messages that don't (to our customer eyes) make any sense or help you resolve the issue.

A more concrete example of the changes required to sfdx-project.json...

before:

{
    "packageDirectories": [
        {
            "path": "force-app",
            "package": "Customizations",
            "versionName": "ver 0.1",
            "versionNumber": "0.1.0.NEXT",
            "dependencies": [
            ],
            "apexTestAccess": {
                "permissionSetLicenses": []
            }
        }
    ],
    "name": "Customizations",
    "namespace": "",
    "sfdcLoginUrl": "https://login.salesforce.com",
    "sourceApiVersion": "52.0",
    "packageAliases": {
        "Customizations": "0Ho2J00000000a1AAA",
        "[email protected]": "04t2J00000000a1AAA"
    }
}

after:

{
    "packageDirectories": [
        {
            "path": "unpackaged",
            "default": false
        },
        {
            "path": "force-app",
            "unpackagedMetadata": {
                "path": "unpackaged"
            },
            "default": true,
            "package": "Customizations",
            "versionName": "ver 0.1",
            "versionNumber": "0.1.0.NEXT",
            "dependencies": [
            ],
            "apexTestAccess": {
                "permissionSetLicenses": []
            }
        }
    ],
    "name": "Customizations",
    "namespace": "",
    "sfdcLoginUrl": "https://login.salesforce.com",
    "sourceApiVersion": "52.0",
    "packageAliases": {
        "Customizations": "0Ho2J00000000a1AAA",
        "[email protected]": "04t2J00000000a1AAA"
    }
}

You must log in to answer this question.

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