Retrieving Recordtypes, they land in the wrong folder, also deploying does not work.

[qwikag]

Summary

Issue #1 When retrieving Opportunity Recordtypes, they are landing in the business processes folder. see my output below. my package.xml includes, business processes, recordtypes, custom fields and standardValueSets, profiles and more.

as I was deleting the recordtypes so that they could come down again they were then going into the businessPocesses folder. initially I could not find them until I start searching for configuration files that might be pointing them into that folder (i could not) I was deleting them because they were not updating with new metadata (that is another issue #2, maybe related) This was not happening yesterday that I am aware of. I have been retrieving from Dev and deploying to QA, no issues, until today deploying to UAT and causing many breakages in UAT.

So I deleted the entire Opportunity folder and it retrieved them OK. this is a massive cause for concern, do not have faith in the deployment tool heading towards production.

We need this tool to get stable very soon!

I am not sure what caused this issue. I have upgraded CLI and it still did the same thing.

Issue #2 similar to above except on deploy any recordtypes named the same as BusinessProcess Fail to deploy.

Steps To Reproduce:

18:56:13.388 sfdx force:source:retrieve --manifest d:\OneDrive\Workspaces\SF\xyz\manifest\package.xml === Retrieved Source FULL NAME TYPE PROJECT PATH ───────────────────────────────────────────────────── ──────────────── ─────────────────────────────────────────────────────────────────────────────────────────────────────────── ... Opportunity.Commercial RecordType force-app\main\default\objects\Opportunity**businessProcesses\Commercial.recordType-meta.xml Opportunity.Referrer RecordType force-app\main\default\objects\Opportunity\businessProcesses\Referrer.recordType-meta.xml Opportunity CustomObject force-app\main\default\objects\Opportunity\Opportunity.object-meta.xml Opportunity.Commercial BusinessProcess force-app\main\default\objects\Opportunity\businessProcesses\Commercial.businessProcess-meta.xml Opportunity.Referrer BusinessProcess force-app\main\default\objects\Opportunity\businessProcesses\Referrer.businessProcess-meta.xml Opportunity.Lease RecordType force-app\main\default\objects\Opportunity\recordTypes**\Lease.recordType-meta.xml

Having deleted and re-added the entire Opportunity Folder, if I then remove a single recordtype and retrieve it again that single recordtype xml lands in the businessProcesses folder, as per pic.

Not good!

The only thing I can think of that could be causing this is the naming convention of the sale process (Business Process is the same as the recordtype. UPDATE YES I THINK THAT IS IT: I did further testing by removing all recordtypes, and only the ones with exactly the same name are the ones landing in the wrong folder. the others land happily in the recordtype folder. And also they do not deploy (if named the same)

Expected result

Delete the recordtype xml from the recordtype folder of an object and on retrieve it should return.

Actual result

on retrieve it lands in the Business Processes Folder of the Opportunity Object.

Additional information

SFDX CLI Version(to find the version of the CLI engine run sfdx --version): sfdx-cli/7.88.4-3b2e55c3f1 win32-x64 node-v14.15.4 but it also failed on 7.84.....

SFDX plugin Version(to find the version of the CLI plugin run sfdx plugins --core) @oclif/plugin-autocomplete 0.3.0 (core) @oclif/plugin-commands 1.3.0 (core) @oclif/plugin-help 3.2.2 (core) @oclif/plugin-not-found 1.2.4 (core) @oclif/plugin-plugins 1.9.5 (core) @oclif/plugin-update 1.4.0-2 (core) @oclif/plugin-warn-if-update-available 1.7.0 (core) @oclif/plugin-which 1.0.3 (core) @salesforce/sfdx-trust 3.6.0 (core) alias 1.1.5 (core) auth 1.4.8 (core) config 1.2.4 (core) generator 1.1.5 (core) salesforcedx 51.0.4 (core) ├─ schema 1.0.4 (core) ├─ limits 1.0.4 (core) ├─ user 1.1.2 (core) ├─ apex 0.1.4 (core) ├─ custom-metadata 1.0.11 (core) ├─ templates 51.2.0 (core) ├─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core) └─ salesforce-alm 51.0.2 (core) sfdx-cli 7.88.4 (core) telemetry 1.1.1 (core)

OS and version: win 10.0.19041

[github-actions[bot]]

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.

[qwikag]

It is not just on retrieve that there is an issue it is also on deploy. BusinessProcesses with the same name prevent recordtypes from deploying.

[qwikag]

I have now renamed my Sales Processes and it retrieves and deploys ok. BUT... Why does the retrieve process retrieve components in a weird order?

Opportunity.Commercial RecordType force-app\main\default\objects\Opportunity\recordTypes\Commercial.recordType-meta.xml Opportunity.Referrer RecordType force-app\main\default\objects\Opportunity\recordTypes\Referrer.recordType-meta.xml Opportunity CustomObject force-app\main\default\objects\Opportunity\Opportunity.object-meta.xml Opportunity.Commercial Contract Execution BusinessProcess force-app\main\default\objects\Opportunity\businessProcesses\Commercial Contract Execution.businessProcess-meta.xml Opportunity.Commercial Contracts BusinessProcess force-app\main\default\objects\Opportunity\businessProcesses\Commercial Contracts.businessProcess-meta.xml

then a few lines later after custom fields and list views it does the rest of the RecordTypes. Every other object is in an orderly fashion. There is definitely some issues with the ordering of the retrieve and deploy scripts.

This gives me concern that if the recordtypes are being deployed before fields could cause issues (missing pieces)

We really need clarity on this topic even after fixing. This tool is central to everything us developers do within Salesforce ecosystem and it is crucial that it works without issue.

[qwikag]

OK, now having workaround the naming issue. and having an accurate set of files in the right folders within my package.

I have deployed to the org (previously broken due to bad deploy), however the newly named Sales Processes and not being deployed. I expected them to be added (not overwritten). Instead 6 out of 7 did not deploy. only 1 deployed.

It was recently deleted, so now I will delete profiles and re-retrieve, see if that helps. Then I will delete eveything and re-retrieve. deploying each time to confirm if it works.

THIS IS NOT A GOOD SITUATION!

[qwikag]

DELETING PROFILES and re-retrieving worked. This time I got a response when I deployed advising everything what was added e.g. === Deployed Source STATE FULL NAME TYPE PROJECT PATH
───── ───────────────────────────────────────────────────── ──────────────── ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Add Opportunity.Commercial Contracts BusinessProcess force-app\main\default\objects\Opportunity\businessProcesses\Commercial Contracts.businessProcess-meta.xml
Add Opportunity.Commercial Contract Execution BusinessProcess force-app\main\default\objects\Opportunity\businessProcesses\Commercial Contract Execution.businessProcess-meta.xml ...

Why do I have to do a delete and a re-retrieve. A retrieve should overwrite everything every time, and a deployment should also deploy everything.

WHAT ARE THE EXCEPTIONS, and WHY?

[qwikag]

WHAT SHOULD HAPPEN?

RETRIEVE: Request package retrieve should update every single file based on what's requested. User should expect other components affect other components (e.g. profiles affected by recordtypes etc) No rocket science required here.

DEPLOY: Again every file should be deployed as requested (not happening for me) Obviously not destructive, unless requested etc etc. If the file is the same as the destination then sure nothing changes, but if it is a modification then it modifies.

For me I got no indication of whether my workflows were updated or not. and everything else was an "Add" (makes no sense) even though most were updates I deployed again and got nothing what so ever

Starting SFDX: Deploy Source to Org 11:18:19.580 sfdx force:source:deploy --manifest d:\OneDrive\Workspaces\SF\manifest\package.xml --json --loglevel fatal 11:18:23.528 sfdx force:source:deploy --manifest d:\OneDrive\Workspaces\SF\manifest\package.xml --json --loglevel fatal ended with exit code 0

When a component is deployed there should be 4 or more states. And every component should get a response Add - component is new and is add to the destination org. Modify - component exists but it is a change. Delete - component is deleted in destination No Change - component is the same

I am in NZ and working on Australian Site???? could this cause problems with dates???

[qwikag]

Not deleting this Comment, instead leaving it here as a reminder that Salesforce browser caching causes us so many problems. The below is no longer relevant a cache delete fixed it.

---

This problem has majorly broken my Salesforce instance, luckily Sandbox for now. But no longer confident we can deploy to prod with the current state of this org, and the current state of the SFDX tools.

I have 7 recordtypes with 7 sales processes, they appear to now be connected and correct for each, seemed to be deployed ok. BUT and this is a massive BUT...

They do not appear in salesforce during edit mode, I only get a Won-Closed StageName no other options, not even Qualify which is the current stage. Even the kanban and process widget are broken. It is like the salesprocess is not the correct process. initially I got extra stages, which is also not right, so I manually removed won-Closed saved and then put it back and then I got only Won-Closed, so I remove them all except Won-Closed and then put the correct ones back, still only get Won-Closed. I really hope this is a Browser Caching issue. Going to restart and come back to this.

Nightmare!

[renanlq]

Hi @qwikag, We have faced the same issue from here.

Due to we have a feel dependency on the field, business process, and layouts, we are not able to deploy it alone. So that any attempt to deploy it, with its dependencies, from CLI, we are told that our RT does not exist on the package.

Unfortunately, we are trying to deploy business processes and record types with the same name. As you commented, seems to be a problem with this CLI latest version.

Plugins:

@oclif/plugin-autocomplete 0.3.0 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.2.2 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.10.0 (core)
@oclif/plugin-update 1.4.0-3 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/sfdx-trust 3.6.0 (core)
alias 1.1.9 (core)
auth 1.5.3 (core)
config 1.2.8 (core)
generator 1.1.5 (core)
salesforcedx 51.11.0 (core)
├─ limits 1.1.0 (core)
├─ apex 0.1.21 (core)
├─ data 0.4.6 (core)
├─ custom-metadata 1.0.12 (core)
├─ schema 1.0.6 (core)
├─ org 1.6.4 (core)
├─ user 1.2.8 (core)
├─ templates 51.3.1 (core)
├─ salesforce-alm 51.6.18 (core)
└─ @salesforce/sfdx-plugin-lwc-test 0.1.7 (core)
sfdx-cli 7.100.0 (core)
telemetry 1.2.0 (core)

[shetzel]

@qwikag @renanlq - Are you able to reproduce this behavior with the latest version of VS Code SFDX extension? I believe it should work in VS Code while it does not in the CLI.

[uip-robot-zz]

This issue has been linked to a new work item: W-9282312

[WillieRuemmele]

@qwikag @renanlq can either of you share a link to a repo with these types, more detailed steps on how to create them, and a package.xml I could use?

Or you could try the soon-to-be-announced beta source plugin, which uses the same library as VSCode and should fix metadata related problems like this. You can install it with sfdx plugins:install @salesforce/plugin-source and then remove it with sfdx plugins:uninstall @salesforce/plugin-source. If you try the new plugin, let me know if it fixes it!