Unable to deploy new version of Entitlement Process as another entitlement process is already using this name

[anderg4]

Summary

We're attempting to deploy a new v2 version of an existing Entitlement Process. The deployment fails with the message "Another entitlement process is already using this name. Try a different name." -- but we're deploying a second version of the existing Entitlement Process.

If we manually create a v2 in the target org, but do not link it to an Entitlement - the deployment then works as expected.

Steps To Reproduce

Basic package deploy fails - with something like

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
	<types>
        <members>someslaprocess_v2</members>
        <name>EntitlementProcess</name>
    </types>
	<version>58.0</version>
</Package>

Expected result

Deployment should happen, new version of Entitlement Process should be created.

Actual result

PROJECT PATH ERRORS
────────────────────────────────────────────────────────────────────────────────────────── ─────────────────────────────────────────────────────────────────────────────
force-app\main\default\entitlementProcesses\someslaprocess_v2.entitlementProcess-meta.xml Another entitlement process is already using this name. Try a different name.

System Information

PS C:\VSCode\salesforce-operations> sf version --verbose --json  
{
  "cliVersion": "@salesforce/cli/2.5.8",
  "architecture": "win32-x64",
  "nodeVersion": "node-v18.15.0",
  "osVersion": "Windows_NT 10.0.19045",
  "shell": "cmd.exe",
  "rootPath": "C:\\Users\\anderg4\\AppData\\Local\\sf\\client\\2.5.8-cb030e8",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.6 (core)",
    "@oclif/plugin-commands 2.2.22 (core)",
    "@oclif/plugin-help 5.2.17 (core)",
    "@oclif/plugin-not-found 2.3.37 (core)",
    "@oclif/plugin-plugins 3.2.6 (core)",
    "@oclif/plugin-search 0.0.22 (core)",
    "@oclif/plugin-update 3.1.32 (core)",
    "@oclif/plugin-version 1.3.8 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.48 (core)",
    "@oclif/plugin-which 2.2.30 (core)",
    "@salesforce/cli 2.5.8 (core)",
    "apex 2.3.10 (core)",
    "auth 2.8.12 (core)",
    "data 2.5.6 (core)",
    "deploy-retrieve 1.17.5 (core)",
    "info 2.6.39 (core)",
    "limits 2.3.30 (core)",
    "login 1.2.26 (core)",
    "org 2.10.0 (core)",
    "schema 2.3.23 (core)",
    "settings 1.4.25 (core)",
    "sobject 0.2.4 (core)",
    "source 2.10.31 (core)",
    "telemetry 2.3.0 (core)",
    "templates 55.5.10 (core)",
    "trust 2.6.1 (core)",
    "user 2.3.28 (core)"
  ]
}

Additional information

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[github-actions]

Hello @anderg4 👋

It looks like you're using an outdated version of Salesforce CLI. sfdx (v7) is in "maintenance mode" as of July 12, 2023. We highly recommend you move from sfdx (v7) to sf (v2) ASAP.

Moving to sf (v2) is easy and takes just two commands. Find all the information here.

After you move to the latest version of sf (v2), run your command again and provide the output of sf version --verbose --json.

[azlam-abdulsalam]

@anderg4 you need a bit of scripting to do this. This is how we handled in dx@scale for instance

https://medium.com/@gnemiq/salesforce-entitlement-handling-9e69735e3687

[anderg4]

Hi @azlam-abdulsalam, and thanks for the link.

To be honest, I'm not sure what this article means when it says "turn on versioning" - but I can see the point. As another work around we've already found you can just create a new version in the target org with the same version number and then deploy over the to of it. It then doesn't seem to care that the "VersionMaster" is not the same/maintained between different orgs. Surely the scenario that is described on that link is still a bug that needs to be fixed?

The metadata which we retrieve is supposed to be able to be deployed to another org, by design. This used to work fine - we have done it many times in the past for new versions - but "something" has broken it. My assumption is that they've started to try and be clever and use VersionMaster rather than the base API Name of the Entitlement Process - and that it's different between the orgs. Our pipeline consists of validations &/or deployments to 6 different orgs - so if the VersionMaster is different in all of them then it's a bit of a problem. Suggestion: they should just put it back like it was - it worked fine (until it was in use, obvs).

#rant
There is literally no point to sf/sfdx if you cannot do retrieve/deploy between orgs consistently. The whole CI/CD concept is based on it.
#endrant

[shetzel]

@anderg4 - when you say, "This used to work fine..." - are you referring to a CLI version that it used to work with or an org update that changed the behavior? To me, it looks like the latter. If so, the CLI can't fix this and it's an issue for support who can pass this to the correct server side team.

[iowillhoit]

Closing as stale