[SalesForce] Scratch org was created with entitlements enabled, but pulling the source results in entity not found

I created a scratch org with the following definition file:

{
  "orgName": "Company, Inc",
  "edition": "Enterprise",
  "features": ["PersonAccounts", "ServiceCloud"],
  "settings": {
    "orgPreferenceSettings": {
      "s1DesktopEnabled": true
    },
    "entitlementSettings": {
      "enableEntitlements": true
    },
    "caseSettings": {
      "systemUserEmail": "my@address.com",
      "enableCaseFeed": true,
      "enableDraftEmails": true,
      "emailToCase": {
        "unauthorizedSenderAction": "Bounce",
        "enableThreadIDInBody": true,
        "enableThreadIDInSubject": true,
        "enableEmailToCase": true,
        "enableHtmlEmail": true
      }
    }
  },
  "language": "pt_BR"
}

And then proceeded to create my first entitlement process. After doing so, I tried pulling the source to my machine, and it resulted in the following error:

ERROR running force:source:pull: Entity of type 'EntitlementProcess' named 'DefaultSupportProcess' cannot be found

Note: "DefaultSupportProcess" is the name of the process I created on the org.

My project's sfdx-project.json file has the source version set to 45.0 (latest in production), and the Metadata Coverage report states that this is supported on source tracking.

Running sfdx-cli/7.7.0.

It seems that using the force:mdapi:retrieve followed by a convert command does work though, so it might be an issue on Salesforce's end, I suppose? The problem is that this will mess with the development process, I guess.

After retrieving the metadata, converting it and deploying it to the scratch org, I can see that it is all there. However, if I dare to edit the metadata (like changing the name or the description of the process) the pull command fails again (that's not unexpected, actually, but I think is relevant to classify this as a bug).

Anyone has the same or similar issue?

Edit 6/4/2019

I forgot to add, but I opened a case with Salesforce, and as of this day the case has been escalated to Tier-3. I'll update this question once the issue is either solved or classified as a bug.

Best Answer

I have confirmed with Salesforce support that this is an issue with how the platform handles the API name of the entitlement process. On the backend, Salesforce seems to use the name entirely as lowercase, while we define it with mixed case.

The workaround, for now, is to name the process with no uppercase characters. If the process is named like mydefaultprocess instead of MyDefaultProcess, the command works as expected.

I haven't had the confirmation that this is a bug yet ("Tier-3 is still investigating" they say), but to me it seems pretty obvious that this is a bug (otherwise the retrieve command would retrieve the lowercase fullname instead of the defined fullname).

Known Issue: https://success.salesforce.com/issues_view?Id=a1p3A0000003cqw

Related Topic