2.78.3 (Feb 26; 2025) [stable]$$$NEW: When you run project deploy start with both --test-level and --verbose; the human-readable output now shows how long each Apex test took to run; in milliseconds. This information was already available in the JSON output. Heres sample output:$$$$$$Test Success [11]$$$? GeocodingServiceTest.blankAddress (159ms)$$$? FileUtilitiesTest.createFileFailsWhenIncorrectBase64Data (263ms)$$$? FileUtilitiesTest.createFileFailsWhenIncorrectFilename (227ms)$$$? FileUtilitiesTest.createFileFailsWhenIncorrectRecordId (481ms)$$$(GitHub discussion #3194; plugin-deploy-retrieve #1286)$$$$$$FIX: The project retrieve start --output-dir mydir command now correctly writes single-file metadata components; such as GlobalValueSet; directly to the mydir directory; previously the command would incorrectly write them to mydir/main/default. (GitHub issue #3177; plugin-deploy-retrieve PR #1289)$$$$$$FIX: Salesforce DX projects now support these metadata types:$$$$$$ContentTypeBundle$$$AnalyticsDashboard

2.75.5 (Feb 5; 2025) [stable]$$$NEW: (Beta) You can now decompose the ExternalServiceRegistration metadata component into two source files when you retrieve it to your Salesforce DX project; rather than retrieve a single monolithic metadata API format XML file. When you deploy to your org; the two files are re-converted into the one metadata API XML file. For example; lets say the name of your ExternalServiceRegistration metadata component BankService. The two source files after decomposition are:$$$$$$BankService.yaml : A YAML file that contains the contents of the schema field. If the fields content is in JSON format in your org; its always converted to YAML format when retrieved to your DX project.$$$BankService.externalServiceRegistration-meta.xml : A standard metadata API XML file that contains all the fields except schema.$$$Decomposing ExternalServiceRegistration metadata components is optional; so you must explicitly specify the behavior by running this command:$$$$$$sf project convert source-behavior --behavior decomposeExternalServiceRegistrationBeta$$$When the project convert source-behavior command finishes; your sfdx-project.json file is updated to always decompose ExternalServiceRegistration components. The existing source files in your local package directories are converted into the new decomposed format and you can deploy and retrieve your metadata as usual. To preview what the command does without making any changes; specify the --dry-run flag.$$$$$$See Start Decomposing the Optional Metadata Types (Beta) for more information. The documentation will soon be updated with details about how ExternalServiceRegistration components are decomposed. (source-deploy-retrieve PR #1493; plugin-deploy-retrieve PR #1275)$$$$$$CHANGE: On January 31; 2025; Salesforce will retire Salesforce Functions; also known as Salesforce Elastic Services. See Salesforce Functions Retirement for more information. As a result; Salesforce CLI no longer JIT-installs the Salesforce Functions plugins (plugin-env and plugin-functions) and the Salesforce Functions commands; such as run function start arent available by default. If you need these commands; you must install the plugins-functions and plugins-env plugins manually using the plugins install command.$$$$$$Well also soon remove the associated Salesforce Functions commands from the current version of the Salesforce CLI Command Reference. If you need online reference information about the Salesforce Functions commands; see the Winter 25 Salesforce CLI Command Reference. (cli PR #2093)$$$$$$FIX: The force data bulk upsert command now works correctly when upserting 10K+ records synchronously (specify the --wait flag) and using Node.js v22 or greater. (GitHub issue #3180; plugin-data PR #1172)$$$$$$FIX: Salesforce DX projects now support the LightningTypeBundle metadata type.

2.72.21 (Jan 15; 2025) [stable]$$$NEW: When generating a manifest from the metadata components in an org by running the project generate manifest --from-org command; you can now specify the metadata components you dont want to include with the new --excluded-metadata flag. For example; this command generates a manifest of all the metadata components except StandardValueSet from the org with alias my-org:$$$$$$sf project generate manifest --from-org my-org --excluded-metadata StandardValueSet$$$Use the existing --metadata flag with --from-org to specify the metadata components that you want to include in your manifest. For example:$$$$$$sf project generate manifest --from-org my-org --metadata ApexClass --metadata CustomObject$$$Tip: If your list of included or excluded metadata components is long; consider using --flags-dir to specify the components in a file rather than at the command-line.$$$$$$The project generate manifest command makes many concurrent API calls to discover the metadata that exists when generating a manifest from an org. To limit the number of concurrent requests; use the new SF_LIST_METADATA_BATCH_SIZE environment variable and set it to a size that works best for your org and environment. For example; to limit the number of concurrent API calls to 20:$$$$$$export SF_LIST_METADATA_BATCH_SIZE=20$$$If you experience timeouts or inconsistent manifest contents; then setting this environment variable can improve accuracy. However; the command takes longer to run because it sends fewer requests at a time.$$$$$$(plugin-deploy-retrieve PR #1247; source-deploy-retrieve PR #1469)$$$$$$CHANGE: As we announced on July 10; 2024; we removed these two hidden commands:$$$$$$data import legacy tree$$$data export legacy tree$$$Use data import|export tree instead. (plugin-data PR #1116)$$$$$$FIX: The WorkFlowAction child metadata type of Workflow is now correctly decomposed into its own subdirectory in your DX project when you opt to decompose workflows. Additionally; you can now deploy children of the Workflow metadata type (such as WorkFlowAction) individually; rather than having to deploy the entire Workflow with all its children.$$$$$$Many thanks to Matt Carvin for finding the bug; and then contributing the fix! We love your awesome initiative. (GitHub issue #2563; source-deploy-retrieve PR #1467)$$$$$$FIX: Salesforce DX projects now support these metadata types:$$$$$$AiEvaluationDefinition$$$AiEvaluationTestSet$$$WorkflowFlowAction

2.71.6 (January 8; 2025) [stable]$$$CHANGE: Starting this release; the --bulk; --wait; and --async flags of the data query command are deprecated. The data query resume command is also deprecated because it works with only the data query command in bulk mode. All these deprecated flags and command will be removed from Salesforce CLI on April 25; 2025; or later. Use the data export bulk|resume commands instead. For example:$$$$$$sf data export bulk --query SELECT Id; Name; Account.Name FROM Contact --output-file export-accounts.csv --wait 10 --target-org my-scratch$$$(plugin-data PR #1134)$$$$$$FIX: We changed the running output of project deploy start to show test failures right away. As a result; you don’t need to wait for the entire deploy to finish before you decide how to handle the test failures. (GitHub issue #3104; plugin-deploy-retrieve PR #1215)$$$$$$FIX: The data bulk commands; when importing from a CSV file; default to the COMMA delimiter if they cant find the delimiter used in the CSV file. (plugin-data PR #1151)$$$$$$FIX: The data import tree command no longer fails when importing over 2K records. (GitHub comment; plugin-data PR #1146)

2.70.7 (December 18; 2024) [stable]$$$NEW: Write the output of an executed SOQL query to a file with the new --output-file flag of the data query command. This new flag works only with CSV (comma-separated values) and JSON output; so you must use it in combination with --result-format csv|json. This example executes a SOQL query in an org with alias my-scratch and writes the JSON results to a file called query-output.json:$$$$$$sf data query --query SELECT Id; Name; Account.Name FROM Contact --output-file query-output.json --result-format json --target-org my-scratch$$$(plugin-data PR #1135)$$$$$$FIX: The org refresh|resume sandbox commands no longer output the erroneous error INSUFFICIENT_ACCESS: use of the Metadata API requires a user with the ModifyAllData or ModifyMetadata permissions? after they finish executing. The error was incorrect because users who refresh or resume sandboxes dont need those permissions. The refresh and resume of the sandbox always finished correctly; despite that error. (GitHub issue #3048; plugin-org PR #1276)$$$$$$FIX: The data export bulk command no longer fails when exporting a very large dataset; such as millions of records; to a JSON-formatted output file. (GitHub issue #3138; plugin-data PR #1140)

2.69.14 (December 11; 2024) [stable]$$$NEW: Specify the line endings used in the comma-separated values (CSV) file when you run the data delete|upsert bulk commands with the new --line-ending flag. The default value on Windows is CRLF; on macOS and Linux its LF. Similarly; specify the column delimiters in the CSV file when you run data upsert bulk with the new --column-delimiter flag; possible values include BACKQUOTE; CARET; and more. For example:$$$$$$sf data upsert bulk --sobject Contact --file contacts.csv --external-id Id --line-ending LF --column-delimiter CARET$$$(GitHub discussion #2947; plugin-data PR #1110)$$$$$$FIX: Salesforce CLI no longer outputs the message that starts (node:9801) [DEP0040] DeprecationWarning: The punycode module is deprecated. when youre using Node.js v22 or greater and you run any CLI command. (GitHub issue #2535; salesforce/cli PR #1971)

2.68.6 (December 4; 2024) [stable]$$$NEW: (BETA) Open an agent in the Agent Builder UI with the new open org agent command. Use the --name flag to open an agent using its API name. For example:$$$$$$sf open org agent --name Coral_Cloud_Agent$$$To find the agents API name; go to Setup in your org and navigate to the agents details page. (plugin-org PR #1264)$$$$$$FIX: We improved the table output when project deploy start fails due to an metadata validation error. We now provide the name of the metadata type thats causing the error in the Type column. (GitHub issue #3110; plugin-deploy-retrieve PR #1217)$$$$$$FIX: If you set your target-org configuration variable to a sandbox; and then run org delete scratch without specifying the --target-org flag; the command now returns an error. Previously the command would delete the sandbox. (GitHub issue #3058; plugin-org PR #1257)

2.67.7 (November 20; 2024) [stable]$$$FIX: We updated the --help of apex test run to say that users who run the command must have the View All Data system permission. (plugin-apex PR #630)

2.66.7 (November 13; 2024) [stable]$$$NEW: Bulk update many records of a Salesforce object from a comma-separated values (CSV) file with the new data update bulk command.$$$$$$All the records in the CSV file must be for the same Salesforce object and the first column of every line must be an ID of the record you want to update. The CSV file can contain only existing records; if a record in the file doesnt currently exist in the Salesforce object; the command fails. Use the --sobject flag to specify the Salesforce object. See Prepare Data to Ingest in the Bulk API 2.0 and Bulk API Developer Guide for details about creating the CSV file.$$$$$$For example; this command updates Account records from the accounts.csv file in an org with alias my-scratch:$$$$$$sf data update bulk --file accounts.csv --sobject Account --wait 10 --target-org my-scratch$$$Bulk updates can take a while; depending on how many records are in the CSV file. If the command times out after the specified wait time (10 minutes in our example); it displays a job ID that you then pass to the new data update resume command to see the status and results of the original update. For example:$$$$$$sf data update resume --job-id 750xx000fake005sAAA$$$(plugin-data PR #1098)$$$$$$NEW: Get the results of a previously run and completed bulk ingest (import; update; upsert; or delete) job with the new data bulk results command. The command works for jobs executed with Bulk API 2.0; such as a CLI command like data import bulk or an external tool like Data Loader; as long as the job provides a job ID. Pass the job ID to data bulk results to retrieve the results.$$$$$$The command displays information such as the job status; the ingest operation; updated Salesforce object; how many records were processed; and how many failed or succeeded. Finally; the output displays the names of the generated CSV-formatted files that contain the specific results for each ingested record. For example:$$$$$$sf data bulk results --job-id 7507i000fake341G --target-org my-scratch$$$(GitHub discussion #2387; plugin-data PR #1097)$$$$$$NEW: Specify the ID of the sandbox you want to clone with the new --source-id flag of the org create sandbox command. We also added a similar new option sourceId to the sandbox definition file. As always; the flag takes precendence if you specify both. This example shows how to clone an existing sandbox with ID 00Dxygfake and name the new sandbox NewClonedSandbox; the org with the sandbox license has the alias prodOrg:$$$$$$sf org create sandbox --source-id 00Dxygfake --name NewClonedSandbox --target-org prodOrg --alias MyDevSandbox --set-default$$$For consistency; we also changed the name of the existing --clone flag of org create sandbox to --source-sandbox-name. Dont worry; we aliased the old --clone flag name to --source-sandbox-name; although we highly recommend you update your scripts to use the new flag name as soon as possible.$$$$$$(plugin-org PR #1237)$$$$$$NEW: Customize how the new table-formatted command output looks like with these new environment variables:$$$$$$SF_NO_TABLE_STYLE: Removes all table stylings; such as borders and colors.$$$SF_TABLE_OVERFLOW: Specifies how to handle text in table output that is too wide for its column; such as by wrapping or truncating.$$$SF_TABLE_BORDER_STYLE: Specifies how to display the borders of table output; such as whether the table has an outline or vertical lines between columns.$$$See Salesforce CLI Environment Variables for the possible and default values.$$$$$$NEW: Specify the column deliminator used in the CSV file when running data import bulk with the new --column-delimiter flag. If you dont specify --column-delimiter; Salesforce CLI determines the delimiter used in the CSV file automatically. Run sf data import bulk -h to see the list of possible values. (plugin-data PR #1098)$$$$$$CHANGE: We upgraded the version of Node.js bundled in the Salesforce CLI operating system-specific installers; TAR files; and Docker images to v22. We alw

2.65.8 (November 6; 2024) [stable]$$$NEW: We updated these commands to use multi-stage output; so while they are running they now display the stage theyre currently on; the elapsed time; and more:$$$$$$project delete source$$$project deploy start$$$project deploy resume$$$project deploy validate$$$project deploy report$$$project retrieve start$$$Also; as a result of this GitHub feedback; we changed how this multi-stage output displays in a continuous integration (CI) environment. Specifically:$$$$$$The command polls for status updates every 5 seconds by default. You can change this interval with the new SF_CI_UPDATE_FREQUENCY_MS environment variable. For example; to poll every 10 seconds; set SF_CI_UPDATE_FREQUENCY_MS=10000. This environment variable works only in a CI environment.$$$Status messages; such as Components: 21/30 (70%) which shows how many components have been deployed to the org; are displayed only when information changes.$$$If 5 minutes goes by without an update; then the last status message is displayed again. You can change this interval with the new SF_CI_HEARTBEAT_FREQUENCY_MS environment variable. For example; to specify 10 minutes; set SF_CI_HEARTBEAT_FREQUENCY_MS=600000. This environment variable works only in a CI environment.$$$(oclif multi-stage-output PR #52)$$$$$$CHANGE: As we announced back in July 2024; we removed these deprecated commands from this release of Salesforce CLI:$$$$$$force:mdapi:convert$$$force:mdapi:deploy$$$force:mdapi:deploy:cancel$$$force:mdapi:deploy:report$$$force:mdapi:describemetadata$$$force:mdapi:listmetadata$$$force:mdapi:retrieve$$$force:mdapi:retrieve:report$$$force:source:convert$$$force:source:delete$$$force:source:deploy$$$force:source:deploy:cancel$$$force:source:deploy:report$$$force:source:ignored:list$$$force:source:manifest:create$$$force:source:open$$$force:source:pull$$$force:source:push$$$force:source:retrieve$$$force:source:status$$$force:source:tracking:clear$$$force:source:tracking:reset$$$If you havent yet migrated to the new sf commands; see the Migration Guide for details. In particular:$$$$$$Map the old sfdx commands to their new sf equivalents.$$$Read details and examples for migrating the force:mdapi:* and force:source:* commands.$$$Read details and examples for migrating the force:org:* commands.$$$Finally; if youre not ready to migrate; see this pinned issue for workarounds. (source-deploy-retrieve PR #1446; plugin-deploy-retrieve PR #1197; cli PR #1962; plugin-org PR #1244)$$$$$$FIX: If you run data export tree to export records from a Salesforce object that has a RecordType field; and you specify RecordType.Name in the SOQL query; you can now import that data using data import tree into a new org and the RecordType IDs and Names are correctly resolved. (GitHub discussion #2753; plugin-data PR #1102)$$$$$$FIX: Salesforce DX projects now support these metadata types:$$$$$$AppFrameworkTemplateBundle$$$ChoiceList$$$ConvIntelligenceSignalRule$$$PublicKeyCertificate$$$PublicKeyCertificateSet

2.63.8 (October 23; 2024) [stable]$$$ANNOUNCEMENT: Be sure you read this pinned GitHub issue about the upcoming removal of these commands: force:source:*; force:mdapi:*; force:org:create; and force:org:delete.$$$$$$NEW: Get a behind-the-scenes look at what happens when you execute certain CLI commands with the new multi-stage output feature. For example; when you execute project deploy start; you now see this output while the command is executing:$$$$$$$ sf project deploy start --source-dir force-app$$$$$$ --------------- Deploying Metadata ---------------$$$$$$ Deploying v61.0 metadata to test-ztqmfakeflt@example.com using the v62.0 SOAP API.$$$$$$ ? Preparing 142ms$$$ ? Waiting for the org to respond 24.38s$$$ ? Deploying Metadata$$$ ? Running Tests$$$ ? Updating Source Tracking$$$ ? Done$$$$$$ Status: Pending$$$ Deploy ID: 0AfRK00000Sfake0A3$$$ Target Org: test-ztqmfakegmflt@example.com$$$ Elapsed Time: 25.02s$$$Checkmarks let you know when each stage completes and how long it took; with the total elapsed time counter at the bottom. Pretty cool; huh. These commands have been updated to use this new output:$$$$$$project delete source$$$project deploy start$$$project deploy resume$$$project deploy validate$$$project deploy report$$$project retrieve start$$$org create scratch$$$org resume scratch$$$(plugin-org PR #1203; plugin-deploy-retrieve PR #1155; oclif multi-stage-output)$$$$$$NEW: Open a local metadata file in its associated builder in your org; such as Agent Builder; with the improved --source-file flag of org open.$$$$$$Lets say; for example; that you completed the Trailhead Quick Start: Build Your First Agent with Agentforce. The Coral Cloud Agent that you built was so cool that you decided to retrieve its associated metadata to a local DX project. To then quickly open the agent back up in Agent Builder; simply run this CLI command:$$$$$$sf org open --source-file force-app/main/default/bots/Coral_Cloud_Agent/Coral_Cloud_Agent.bot-meta.xml --target-org <your-org>$$$You can also use the --source-file flag to open local metadata in Flow Builder; Apex Classes Setup page; and more. (plugin-org PR #1230)$$$$$$NEW: We now display the Lightning deploy URL; in addition to the deploy ID; when you run any of the project deploy commands with the --verbose flag. For example; when you run project deploy start --verbose; you now see a Deploy URL entry in the output:$$$$$$...$$$Status: Succeeded$$$Deploy ID: 0AfRKfake00WH0A3$$$Target Org: test-ztqm4gogmflt@example.com$$$Deploy URL: https://customer-fake.scratch.my.salesforce.com/lightning/setup/DeployStatus/page?address=%2Fchangemgmt%2Fmonitlotsofstuff.apexp$$$...$$$Many thanks to Matt Carvin for contributing this useful new feature. It was your first contribution; but we sure hope it wont be your last!$$$$$$FIX: The sf plugins --json command no longer fails in certain circumstances with a TypeError. (GitHub issue #3051; oclif core PR #1216)$$$

2.62.6 (October 16; 2024) [stable]$$$ANNOUNCEMENT: Be sure you read this pinned GitHub issue about the upcoming removal of these commands: force:source:*; force:mdapi:*; force:org:create; and force:org:delete.$$$$$$NEW: Export a large number of records from an org with the new data export bulk command. Use a SOQL query to select the fields and records that you want to export; and specify whether you want to write to a CSV- or JSON-formatted file. For example; this command exports the Id; Name; and Account.Name fields of the Contact object into a JSON-formatted file:$$$$$$sf data export bulk --query SELECT Id; Name; Account.Name FROM Contact --output-file export-accounts.json --result-format json --wait 10 --target-org my-scratch$$$Bulk exports can take a while; so if the command times out after the specified wait time (10 minutes in our example); it displays a job ID that you then pass to the new data export resume command to see the status and results of the original export. For example:$$$$$$sf data export resume --job-id 750XXX00fake1222$$$IMPORTANT: The data export bulk command uses Bulk API 2.0; which is optimized to handle very large sets of data asynchronously. However; the API limits the type of SOQL queries you can run. For example; you cant use aggregate functions such as count(). For the complete list of limitations; see the SOQL Considerations section at the end of this page. (plugin-data PR #1035)$$$$$$NEW: Salesforce CLI now warns you when you deploy metadata with the project deploy start command and either the total size of the metadata or the number of metadata files is over 80% of the Metadata API limits. You can change this threshold by setting the new SF_DEPLOY_SIZE_THRESHOLD environment variable to a number between 1 and 100. For example; if you set SF_DEPLOY_SIZE_THRESHOLD=70; you get the warning when you try to deploy metadata thats over 70% of the limit.$$$$$$Salesforce CLI always attempts to deploy the metadata when you run the project deploy start command; even if it determines that the size or file count might be over the limit. (source-deploy-retrieve PR #1435)$$$$$$NEW: Store the values for the HTTP request (header; body; etc) in a file when you run the api request rest command with the new --file flag. The command allows you to make an authenticated HTTP request using the Salesforce REST API. This flag is useful if you want to put the request information in a single JSON-formatted file rather than specify all the sections using flags; such as --header; --body; and so on. For example:$$$$$$sf api request rest --file ./myHttpRequest.json$$$Run sf api request rest --help and read the long description for the --file flag for information on how to create the file. (plugin-api PR #14)$$$$$$NEW: Easily see which Salesforce CLI versions you previously downloaded with the new Download column in the sf update --available output. To see the Location column; you must now use the new --verbose flag along with the --available flag. We also made some minor formatting tweaks to the table output. (oclif plugin-plugins #980; plugin-update #932; plugin-commands #763)$$$$$$FIX: The force lightning lwc test run command now correctly returns a non-zero exit code if a Lightning Web Component Jest test fails. (GitHub issue #2991; plugin-lwc-test PR #193)$$$$$$FIX: The Apex Code Coverage percentages displayed in the output of sf project deploy start --test-level <value> --coverage-formatters <value> now match the percentages in the code coverage reports; such as coverage-summary.json. (GitHub issue #3030; plugin-deploy-retrieve #1175)$$$$$$FIX: (This fix is mostly interesting to oclif users; such as Salesforce CLI plugin developers). When you generate a README.md file for your plugin using oclif readme; flags that have the noCacheDefault: false option no longer display any locally set configuration variable values; similar to how --help works. (GitHub issue #3041; oclif core PR #1212; oclif oclif PR #1566)$$$$$$FIX: The project retrieve st

2.61.8 (October 9; 2024) [stable]$$$ANNOUNCEMENT: Be sure you read this pinned GitHub issue about the upcoming removal of these commands: force:source:*; force:mdapi:*; force:org:create; and force:org:delete.$$$$$$NEW: Download and install Salesforce CLI on Windows ARM64 computers with our new sf-arm64 installer. Were in the process of updating the download page with this new option; but in the meantime you can download the stable executable here. (oclif PR #1559)$$$$$$NEW: When you create a sandbox with the org create sandbox command; you can now specify the public group of Salesforce users that can access the sandbox by including either the activationUserGroupId or activationUserGroupName option (but not both) in the sandbox definition file. This example specifies that the Salesforce public user group with name ExpertUsers can access the sandbox after its created:$$$$$${$$$ sandboxName: dev1;$$$ licenseType: Developer;$$$ activationUserGroupName: ExpertUsers$$$}$$$You can also now specify the name of the Apex class that runs after each copy of the sandbox with the new apexClassName option. Previously you could specify it only with an ID (apexClassId). (plugin-org PR #1221)$$$$$$NEW: Get detailed coverage results about an asynchronous test run by specifying the new --detailed-coverage flag of the apex get test command. Similar to how the apex run test command works; you must specify human-readable result format (the default) when you use the --detailed-coverage flag. For example:$$$$$$sf apex get test --test-run-id <ID> --code-coverage --detailed-coverage --result-format human$$$(plugin-apex PR #597)$$$$$$FIX: We fixed a source tracking issue with some metadata types; such as EmailTemplateFolder. (GitHub issue #2902; source-tracking PR #679)$$$$$$FIX: Salesforce DX projects now support the ExtlClntAppSamlConfigurablePolicies metadata type.

2.60.13 (October 2; 2024) [stable]$$$ANNOUNCEMENT: Be sure you read this pinned GitHub issue about the upcoming removal of these commands: force:source:*; force:mdapi:*; force:org:create; and force:org:delete.$$$$$$CHANGE: We shipped decomposePermissionSetBeta back in April; asked you to vote on a new design of the feature (thank you); and we now have a winner! We went with option 2 (focused decomposition); see details here.$$$$$$We now have a new source behavior value: decomposePermissionSetBeta2. If you havent played with source decomposition at all yet; you can try it by running sf project convert source-behavior --behavior decomposePermissionSetBeta2. You can also use this command if you previously updated your project to use the original decomposePermissionSetBeta flavor; but you now want to try out the new stuff. Enjoy! (source-deploy-retrieve PR #1412$$$$$$FIX: Deploying a sharing rule by specifying one of its child metadata types (such as project deploy start --metadata SharingCriteriaRule:Account.Test_Rule1) now works correctly. (source-deploy-retrieve PR #1419)$$$$$$FIX: Salesforce DX projects now support these metadata types:$$$$$$ExtlClntAppPushSettings$$$ExtlClntAppPushConfigurablePolicies

2.59.6 (September 25; 2024) [stable]$$$ANNOUNCEMENT: Be sure you read this pinned GitHub issue about the upcoming removal of these commands: force:source:*; force:mdapi:*; force:org:create; and force:org:delete.$$$$$$FIX: We fixed some under-the-hood bugs.

2.58.7 (September 11; 2024) [stable]$$$ANNOUNCEMENT: Be sure you read this pinned GitHub issue about the upcoming removal of these commands: force:source:*; force:mdapi:*; force:org:create; and force:org:delete.$$$$$$FIX: Salesforce CLI now supports these environment variables: SF_DISABLE_SOURCE_MEMBER_POLLING and SF_SOURCE_MEMBER_POLLING_TIMEOUT. Previously only their SFDX_ equivalents were supported. (GitHub comment; source-tracking PR #668)

2.57.7 (September 4; 2024) [stable]$$$ANNOUNCEMENT: Be sure you read this pinned GitHub issue about the upcoming removal of these commands: force:source:*; force:mdapi:*; force:org:create; and force:org:delete.$$$$$$NEW: The project deploy start command now reports the zip size and zip file count when using the --verbose flag. (GitHub Discussion #2942; plugin-deploy-retrieve PR #1138)$$$$$$NEW: Weve improved the doctor command so it now checks whether you are setting proxy env vars correctly (plugin-info PR #848)$$$$$$NEW: Try the new BETA api request graphql command to send GraphQL requests to your org! (plugin-api PR #6)$$$$$$sf api request graphql --body query accounts { uiapi { query { Account { edges { node { Id $$$ Name { value } } } } } } }$$$cat body.txt | sf api request graphql --body -$$$Stream results to a file with the --stream-to-file flag$$$Run sf api request graphql --help to see more examples$$$FIX: String Replacement logic will explicitly skip binary files even if they are included in the glob pattern. (source-deploy-retrieve PR #1405)

2.56.7 (August 28; 2024) [stable]$$$ANNOUNCEMENT: Be sure you read this pinned GitHub issue about the upcoming removal of these commands: force:source:*; force:mdapi:*; force:org:create; and force:org:delete.$$$$$$NEW: Try the new BETA api request rest command to send REST calls to your org! (plugin-api repo)$$$$$$sf api request rest sobjects/account/<ID> --method PATCH --body {\Name\: \Updated\}$$$sf api request rest sobjects/account/<ID> --method PATCH --body body.txt$$$cat body.txt | sf api request rest sobjects/account --body -$$$Stream results to a file with the --stream-to-file flag$$$Run sf api request rest --help to see more examples$$$CHANGE: We shipped decomposeCustomLabelsBeta; got feedback (thank you!); and decided to change how it behaves. You can see the design proposal here. It removes an extra folder layer that other decomposition strategies needed and supports more flexible folder structures.$$$$$$Now theres decomposeCustomLabeltsBeta2. If you havent used it yet; you can try it via sf project convert source-behavior --behavior decomposeCustomLabelsBeta2. This works if your project isnt using a preset OR if you started using the original flavor of decomposeCustomLabeltsBeta. Please keep the feedback coming! (source-deploy-retrieve PR #1392)$$$$$$FIX: Salesforce DX projects now support the GenAiFunction metadata type (source-deploy-retrieve PR #1404; plugin-deploy-retrieve PR #1137)$$$$$$NEW: The apex run test and apex get test commands now have a new --concise flag$$$$$$Setting this flag for apex run test or apex get test will suppress passing test results and the code coverage table. Only failing tests and the summary table will be displayed. (plugin-apex PR #504; Github Issue #243; Github Discussion #2872)$$$$$$Many thanks to Kyle Capehart for contributing this useful new flag!$$$$$$NEW: The sf project convert source-behavior command will now warn if you have uncommitted work before doing project modifications. Note that this command puts components in a newly created main/default folder in each package directory. You might need to re-organize them into your preferred structure. (plugin-deploy-retrieve PR #1130)$$$$$$FIX: Support for 21 new metadata types (source-deploy-retrieve PR #1398)$$$$$$AssessmentConfiguration$$$ContextUseCaseMapping$$$ContractType$$$DocumentTemplate$$$EmployeeDataSyncProfile$$$ExternalAuthIdentityProvider$$$ExternalDataTranObject$$$ExternalDocStorageConfig$$$GenAiPlugin$$$LearningAchievementConfig$$$MktDataConnection$$$MktDataConnectionSrcParam$$$PortalDelegablePermissionSet$$$ProductAttrDisplayConfig$$$ProductSpecificationRecType$$$ProductSpecificationType$$$RecAlrtDataSrcExpSetDef$$$ReferencedDashboard$$$RelatedRecordAssocCriteria$$$VirtualVisitConfig$$$WaveAnalyticAssetCollection$$$NEW: Execute a SOSL text-based search query in your org with the new data search command. Similar to how the data query command works with SOQL queries; you can specify the SOSL query at the command line with the --query flag or read the query from a file with the --file flag. This example executes the specified SOSL query in an org with alias my-scratch:$$$$$$sf data search --query FIND {Anna Jones} IN Name Fields RETURNING Contact (Name; Phone) --target-org my-scratch$$$(plugin-data PR #1025)$$$$$$FIX: When parsing a scratch org definition file; Salesforce CLI now removes the $schema property (if it exists at the top of the JSON file) to prevent getting an invalid JSON error. (sfdx-core PR #1113)$$$$$$Thank you; Alan Jaouen; for noticing the problem and then contributing the fix! We love it.$$$$$$FIX: We now wait for config files to be unlocked before we read them. This improvement fixes issues like parallel command executions that cause file reads to return empty. (GitHub issue #2965; sfdx-core PR #1116)$$$$$$FIX: We updated the help and output of the --package-name flag of project retrieve start to clarify that the results are for reference only and shouldnt be used in your development work. (GitHub issue #2931; plugin-deploy-retrie

2.55.6 (August 21; 2024) [stable]$$$ANNOUNCEMENT: Be sure you read this pinned GitHub issue about the upcoming removal of these commands: force:source:*; force:mdapi:*; force:org:create; and force:org:delete.$$$$$$NEW: Execute a SOSL text-based search query in your org with the new data search command. Similar to how the data query command works with SOQL queries; you can specify the SOSL query at the command line with the --query flag or read the query from a file with the --file flag. This example executes the specified SOSL query in an org with alias my-scratch:$$$$$$sf data search --query FIND {Anna Jones} IN Name Fields RETURNING Contact (Name; Phone) --target-org my-scratch$$$(plugin-data PR #1025)$$$$$$FIX: When parsing a scratch org definition file; Salesforce CLI now removes the $schema property (if it exists at the top of the JSON file) to prevent getting an invalid JSON error. (sfdx-core PR #1113)$$$$$$Thank you; Alan Jaouen; for noticing the problem and then contributing the fix! We love it.$$$$$$FIX: We now wait for config files to be unlocked before we read them. This improvement fixes issues like parallel command executions that cause file reads to return empty. (GitHub issue #2965; sfdx-core PR #1116)$$$$$$FIX: We updated the help and output of the --package-name flag of project retrieve start to clarify that the results are for reference only and shouldnt be used in your development work. (GitHub issue #2931; plugin-deploy-retrieve #1124)$$$$$$FIX: Salesforce DX projects now support the UiFormatSpecificationSet metadata type.

2.53.6 (August 7; 2024) [stable]$$$ANNOUNCEMENT: Be sure you read this pinned GitHub issue about the upcoming removal of these commands: force:source:*; force:mdapi:*; force:org:create; and force:org:delete.$$$$$$NEW: If you misspell a metadata type when using the --metadata flag of one of the project commands; such as project deploy start; we now prompt you with similar valid options. We also provide other troubleshooting resources. Go ahead; make a typo and see what the command suggests! (source-deploy-retrieve PR #1374)$$$$$$NEW: Review what the dev generate command|plugin commands will do; without actually changing anything on your computer; with the new --dry-run flag. Instead; the command displays the files it will update or create and the commands it will run when you dont specify --dry-run. For example:$$$$$$$ sf dev generate command --name init --dry-run$$$[DRY RUN] Updating package.json$$$[DRY RUN] Creating src/commands/init.ts$$$[DRY RUN] Creating messages/init.md$$$[DRY RUN] Creating test/commands/init.nut.ts$$$[DRY RUN] Creating test/commands/init.test.ts$$$[DRY RUN] yarn format$$$[DRY RUN] yarn lint -- --fix$$$[DRY RUN] yarn compile$$$(plugin-dev PR #519)$$$$$$CHANGE: Weve deprecated using the --wait flag of the data query command without --bulk. We plan to remove the usage in a future release. You can safely stop using --wait in this case; because it never affected the command without --bulk anyway. (plugin-data PR #1002)$$$$$$FIX: The sf update command now works correctly on computers running proxies. (plugin-update PR #880)$$$$$$FIX: If a flag value contains a comma in its name; you can now escape it with a \ character so that Salesforce CLI doesnt think its a delimiter. For example: project source convert --source-dir dirwith\;comma.$$$$$$Also; as part of this fix; we now print a warning when you use the old format of specifying multiple flag values with a comma (--flag value1;value2). Instead you should specify the flag multiple times (--flag value1 --flag value2). (GitHub issue [#2928]#2928); oclif PR

2.49.7 (July 10; 2024) [stable]$$$NEW and FIX: (This new and fixed issue is interesting mostly to Salesforce CLI plugin developers.) The JSDoc for the SfProject and SfProjectJson classes in the @salesforce/core library now align with the code; and we cleaned up the examples. While we were messing around in there anyway; we added these two useful methods: SfProject.getPluginConfiguration and SfProject.setPLuginConfiguration. Check em out! (sfdx-core PR #1094)$$$$$$CHANGE: After a successful beta period; the data import|export beta tree commands are now generally available. Specifically:$$$$$$We moved the new functionality in data import beta tree to the official data import tree command. We moved the functionality from the old data import tree to data import legacy tree. Similarly...$$$We moved the new functionality in data export beta tree to the official data export tree command. We moved the functionality from the old data export tree to data export legacy tree.$$$What does this mean in practice? As of this release; when you execute data import tree; for example; you get the new functionality that was in beta until now. If you run into any issues and you want to return to the old functionality; use the data import legacy tree command. Same with data export tree. However; note that we plan to remove these legacy commands in November; 2024.$$$$$$Read about the changes we added to these new commands; including two breaking changes to data import tree; in this issue that weve pinned since February 2024. (plugin-data PR #975).$$$$$$CHANGE: These scratch org snapshot commands are now generally available; they were previously in beta. (plugin-signups PR #629)$$$$$$org create snapshot$$$org delete snapshot$$$org get snapshot$$$org list snapshot$$$FIX: You can now correctly deploy and retrieve the DecisionMatrixDefinition; DecisionMatrixDefinitionVersion; and ExpressionSetDefinitionVersion metadata types. (GitHub issue #2823; source-deploy-retrieve PR #1357)$$$$$$FIX: You can now correctly deploy and retrieve the ExperienceResource; DigitalExperienceBundle; and DigitalExperience metadata types. (GitHub issue #2634; source-tracking PR #621)$$$$$$FIX: You can now use the --purge-on-delete and --metadata-dir flags of the project deploy start command together to hard delete components whose local source files are in metadata-format. Hard delete means the component is immediately eligible for deletion in the org rather than being stored in the Recycle Bin. The directory pointed to by --metadata-dir must contain at least one of the destructive manifest files (destructiveChangesPre.xml or destructiveChangesPost.xml) or you get an error. (GitHub issue #2909; plugin-deploy-retrieve #1069)$$$$$$FIX: The org list command no longer displays incorrect information for a scratch org when its ID (when you ignore case) matches the ID of other ScratchOrgInfo records in the Dev Hub org. (plugin-org PR #1119)$$$$$$FIX: We improved the error message when a deploy; retrieve; or convert fails because of a problem with the source file; such as an incorrect XML element or missing parent XML file. (source-deploy-retrieve PR #1355)

2.47.6 (June 26; 2024) [stable]$$$NEW: Permanently delete records in your org via the Bulk API 2.0 with the new --hard-delete flag of the data delete bulk command. When you specify this flag; the records become immediately eligible for deletion; which means you no longer need to manually clean them from the Recycle Bin. For example; permanently delete account records from your default org using the IDs listed in the specified CSV file:$$$$$$sf data delete bulk --sobject Account --file files/delete.csv --hard-delete$$$Users must have the Bulk API Hard Delete system permission to use the --hard-delete flag. This permission is disabled by default and can be enabled only by a system administrator. (GitHub discussion #2904; plugin-data PR #959)$$$$$$FIX: The force data bulk delete|status|upsert commands now stop polling for the bulk job state in the org; and then stop executing and throw an error; if the job is aborted for some reason. These commands use Bulk API 1.0; the data bulk commands that use Bulk API 2.0 already work this way. (GitHub jsforce issue #765; jsforce PR #1481)$$$$$$FIX: Weve improved the warning message when retrieving custom fields using wildcards. (GitHub issue #1366; plugin-deploy-retrieve #1052)$$$$$$FIX: If a scratch org creation fails; after the org has created (such as it fails to deploy the settings); the command returns exit code 68 (like all other partial success outcomes). It will save the auth so you can debug the settings deploy error or delete the scratch org. (GitHub issue #202; sfdx-core #1086)$$$$$$FIX: Salesforce DX projects now support the StageDefinition metadata type.$$$$$$Salesforce DX projects no longer support using the ExpressionSetDefinitionVersion metadata type directly. Use its parent (ExpressionSetDefinition) instead.

2.46.6 (June 19; 2024) [stable]$$$NEW: We now publish all artifacts associated with a Salesforce CLI release in the salesforce/cli GitHub repository. The release artifacts include the operating system-specific installers; such as the Windows * executable; and all TAR files for the Linux; Windows; and macOS installs.$$$$$$To download a particular artifact; go to the Releases page; click on the release (such as 2.45.6); open Assets; and then click on the artifact. (github-workflows PR #107)$$$$$$The links to download the Salesforce CLI installation packages; executables; and TAR files that are documented in the Salesforce CLI Setup Guide continue to work as before.$$$$$$NEW: Salesforce CLI now prompts you with potential alternatives when you misstype a username or alias when running an org login command. (sfdx-core PR #1079)$$$$$$CHANGE: Weve improved the filesystem structure of the output when you set the SF_MDAPI_TEMP_DIR environment variable and then run project deploy start or project retrieve start. These changes make it easier to debug any issues when deploying or retrieving. The changes to the output include:$$$$$$A top-level directory whose name includes the timestamp of the operation and whether the output is a result of a deploy or a retrieve.$$$For retrieves; the output includes both formats of the retrieved files; in their own directories (metadata and source). The metadata directory includes the downloaded .ZIP file and the unzipped metadata format files; the source directory contains the converted files in source format. Both directories include the package.xml file.$$$For deploys; the output includes only the metadata format of the deployed files in the metadata directory; along with a package.xml file.$$$(source-deploy-retrieve PR #1331)$$$$$$FIX: Source Mobility (BETA): If you move a local file to a new location in your project; and then edit the file before running project deploy start|preview or project retrieve start|preview; Salesforce CLI now correctly handles both the file move and the update. (source-tracking #601)$$$$$$FIX: Source Mobility (BETA): You can now move source files in very large projects (over 8GB with over 1700 files) and successfully deploy without getting an out of memory error. (GitHub issue #2880; source-tracking PR #591)$$$$$$FIX: When retrieving a CustomField from the org; project retrieve start now preserves the content of the fields CustomObject source file. We partly fixed this bug back in May; but this time around we think we fixed it all. (Github issue #2865; source-deploy-retrieve PR #1338)

2.45.6 (June 12; 2024) [stable]$$$NEW: We now warn you if you set an alias that includes a space; which we dont recommend. If you decide to stick with the spaces; then you must use double quotes around it; such as:$$$$$$sf project deploy start --target-org my scratch$$$(plugin-settings PR #625)$$$$$$FIX: We now correctly display an error if you try to convert source files that are already in metadata format to the same format. (source-deploy-retrieve PR #1329)$$$$$$FIX: The JSON response; when running the org sandbox create|refresh|resume commands with the --json flag; now includes the sandbox username if the sandbox is in a completed state and has been authenticated. This update makes the JSON output consistent with the human-readable output. (GitHub issue #2879; plugin-org PR #1068)$$$$$$FIX: We improved the error message when you run package install on a package that was created with an installation key; but you either dont provide the key when installing it; or the key is incorrect. (GitHub issue #2882; packaging PR #580)$$$$$$FIX: Salesforce DX projects now support these metadata types:$$$$$$EnblProgramTaskSubCategory$$$LearningItemType$$$2.44.8 (Jun 5; 2024)

2.44.8 (Jun 5; 2024) [stable]$$$NEW: (Beta) Enable a behavior of your project source files with the new project convert source-behavior command. For example; to update your project so it starts decomposing permission sets; run this command:$$$$$$$ sf project convert source-behavior --behavior decomposePermissionSetBeta$$$When the command finishes; your sfdx-project.json file is updated to always decompose permission sets; and the existing permission set files in your local package directories are converted into the new decomposed format. You run this command only once for a given behavior change. Use the --dry-run flag to preview what would be changed; sample files are created in a DRY-RUN-RESULTS directory.$$$$$$Here are the current possible values for the --behavior flag:$$$$$$decomposePermissionSetBeta — Decompose the PermissionSet metadata type.$$$decomposeCustomLabelsBeta — Decompose the CustomLabels metadata type.$$$decomposeWorkflowBeta — Decompose the WorkFlow metadata type.$$$decomposeSharingRulesBeta — Decompose the SharingRules metadata type$$$This command replaces the manual steps we documented in the April 10; 2024 release notes for converting your project to decompose the additional four metadata types. Because the behaviors are beta; the values for the --behavior flag include the word Beta. When a particular behavior becomes generally available (GA); well remove the Beta label; for example; when we make decomposing permission sets generally available; the new flag value will be --behavior decomposePermissionSet. This command; and the individual behaviors; can become generally available at different times; check these release notes for announcements.$$$$$$(plugin-deploy-retrieve PR #1015)$$$$$$NEW: Weve improved the doctor command so it now checks whether your computer can access certain Web sites and registries required by Salesforce CLI. Heres truncated sample output to show which URLs it checks:$$$$$$$ sf doctor$$$=== Running all diagnostics$$$$$$pass - salesforcedx plugin not installed$$$pass - no linked plugins$$$pass - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches apiVersion$$$pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org$$$pass - [@salesforce/plugin-trust] can ping: https://registry.yarnpkg.com$$$pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org/$$$pass - can access: https://test.salesforce.com$$$pass - can access: https://appexchange.salesforce.com/services/data$$$pass - can access: https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-win32-x64-buildmanifest$$$...$$$(plugin-info PR #746; plugin-trust PR #828)$$$$$$NEW: Source Mobility (BETA). Source files can now be moved within your local Salesforce DX project without source-tracking thinking that youve deleted and then recreated a metadata component. This is a BETA feature and you must opt-in to enable it. You can opt-in by setting the SF_BETA_TRACK_FILE_MOVES environment variable to true. Then reorganize your files as you like! A few things to keep in mind:$$$$$$Source Mobility works with file moves; not file renames. Renaming a source file is still interpreted as deleting a metadata component and creating a new one with the different name.$$$Child source files can only move to an identically named parent. For example; a custom field can move between Object folders in different package directories only if both Object folders have the same name.$$$Enjoy! (GitHub discussion #2682; source-tracking #574)$$$$$$NEW: Upload a local file to an org with the new data create file command. The default title of the uploaded file in the Salesforce UI is its filename; you can change its title with the --title flag. By default; the file isnt associated with a Salesforce record; use the --parent-id flag to attach the file to an existing Salesforce record; such as an account.$$$$$$In this example; the uploaded file is given a new title and its attached to the Salesforce record with ID a03fakeLoJWPIA3:$$$$$$sf data create

2.43.7 (May 29; 2024) [stable]$$$NEW: Source Mobility (BETA). Source files can now be moved within your local Salesforce DX project without source-tracking thinking that youve deleted and then recreated a metadata component. This is a BETA feature and you must opt-in to enable it. You can opt-in by setting the SF_BETA_TRACK_FILE_MOVES environment variable to true. Then reorganize your files as you like! A few things to keep in mind:$$$$$$Source Mobility works with file moves; not file renames. Renaming a source file is still interpreted as deleting a metadata component and creating a new one with the different name.$$$Child source files can only move to an identically named parent. For example; a custom field can move between Object folders in different package directories only if both Object folders have the same name.$$$Enjoy! (GitHub discussion #2682; source-tracking #574)$$$$$$NEW: Upload a local file to an org with the new data create file command. The default title of the uploaded file in the Salesforce UI is its filename; you can change its title with the --title flag. By default; the file isnt associated with a Salesforce record; use the --parent-id flag to attach the file to an existing Salesforce record; such as an account.$$$$$$In this example; the uploaded file is given a new title and its attached to the Salesforce record with ID a03fakeLoJWPIA3:$$$$$$sf data create file --file resources/astro.png --parent-id a03fakeLoJWPIA3 --title AstroOnABoat --target-org my-sandbox$$$(GitHub issues #2344 and #2346; plugin-data PR #922)$$$$$$CHANGE: Weve changed the name of the new beta sfdx-project.json option that you use to decompose the optional metadata types when syncing source between your org and project.$$$$$$Old name: registryPresets$$$New name: sourceBehaviorOptions$$$For example:$$$$$$sourceBehaviorOptions: [decomposePermissionSetBeta; decomposeWorkflowBeta]$$$The new beta feature itself hasnt changed; including the list of possible values for the sourceBehaviorOptions. See the April 10; 2024 release notes for more information. (schemas PR #87; source-deploy-retrieve PR #1312)$$$$$$FIX: Salesforce DX projects now support these metadata types:$$$$$$GenAiFunction$$$GenAiPlanner

2.42.6 (May 22; 2024) [stable]$$$NEW: Quickly find the date that your current Salesforce CLI version was published by running the version --verbose command. The new output also lists the current latest (AKA stable) version of Salesforce CLI; based on the npm tags. The new output also displays the same information for any user-installed plugins; including the Salesforce JIT plugins such as @salesforce/sfdx-scanner. We also made the output easier to read. (oclif plugin-version PR #425)$$$$$$Heres partial output of the new command showing that the installed version (2.39.6) was published 21 days ago; and that the latest version is 2.40.7:$$$$$$$ sf version --verbose$$$CLI Version:$$$ @salesforce/cli/2.39.6 published 21 days ago (Tue Apr 23 2024) (latest is 2.40.7)$$$...$$$CHANGE: If you install Salesforce CLI using npm; your local version of Node.js must be at least 18.16. (cli PR #1645)$$$$$$FIX: On Windows; running a Salesforce CLI command no longer causes a new CMD window to briefly appear and then disappear. Thanks @jaklein for pointing out the fix! (GitHub issue #2833; plugin-telemetry PR #620)$$$$$$FIX: The project deploy report command no longer displays incorrect warnings about source format files that dont apply to the asynchronous deployment of metadata format files. (GitHub issue #2862; source-deploy-retrieve PR #1311)$$$$$$FIX: (This fix is mostly relevant to our fabulous plugin developers) Weve updated various files; such as the schema for sfdx-project.json; so that you no longer get type issues or Property not found when developing with our APIs in VSCode or other IDE. (GitHub issue #2201; schemas PR #85; sfdx-core #1066; packaging #569)

2.41.8 (May 15; 2024) [stable]$$$NEW: The project retrieve start command now warns you if you have the pattern **/unpackaged/** in your .forceignore file. This pattern causes the retrieve to ignore all files; because /unpackaged is the directory within the retrieved ZIP file in which all unpackaged metadata lives. (GitHub issue #2399; source-deploy-retrieve PR #1301)$$$$$$CHANGE: The org delete snapshot command now prompts for confirmation from the user before it deletes the snapshot; previously the command didnt prompt. Use the new --no-prompt flag to not be prompted; which is the old behavior. (plugin-signups PR #567)$$$$$$FIX: Specifying the --no-namespace flag of the org create scratch command now correctly creates a scratch org that doesnt have a namespace. (GitHub issue #2855; sfdx-core PR #1064)$$$$$$FIX: When retrieving a CustomField from the org; project retrieve start now preserves the content of the fields CustomObject source file. (Github issue #2865; source-deploy-retrieve PR #1308)$$$$$$FIX: Salesforce DX projects now support these metadata types:$$$$$$ForecastingGroup$$$RecordAlertTemplate$$$RetrievalSummaryDefinition$$$SearchCustomization$$$SearchOrgWideObjectConfig

2.40.7 (May 8; 2024) [stable]$$$NEW: Some Salesforce CLI downloads; installations; and updates are now faster because we reduced the size of the Salesforce CLI OS-specific installers and TAR files. Specifically; we no longer include files like oclif.lock; yarn.lock; npm-shrinkwrap; and package-lock in them. (GitHub discussion #2835; oclif PR #1385)$$$$$$FIX: When converting from mdapi format to source format; Salesforce CLI now preserves all comments in the metadata XML file. As a result; the help text; labels; and picklist values of Custom Object Translations are correctly included in the source format files. (GitHub issue #2830; source-deploy-retrieve PR #1288)$$$$$$FIX: Salesforce CLI once again supports big object types whose index files use the legacy .indexe suffix rather than the better .index suffix. But weve also added a warning if your big object uses the .indexe suffix; asking you to update it to .index. (GitHub issue #2847; source-deploy-retrieve PR #1298)$$$$$$FIX: The .forceignore file now works consistently; whether youre using source or mdapi format. Specifically; when you deploy or retrieve in source format (using sf project deploy start; for example); the command respects file names of .forceignore entries in source format. Similarly; when you deploy or retrieve in mdapi format (using sf project deploy start --metadata-dir; for example); the command respects file name entries in mdapi format. (GitHub issue #2737; source-deploy-retrieve PR #1295)$$$$$$FIX: The org shape list command now works as expected; even when the connection to the Dev Hub org is incorrect.

2.38.7 (April 24; 2024) [stable]$$$These changes are in the Salesforce CLI release candidate. We plan to include these changes in next weeks official release. This list isnt final and is subject to change.$$$$$$NEW: Salesforce CLI downloads; installations; and updates just got a whole lot faster; especially on Windows! Why? Because weve significantly reduced the size of both the npm packages and the OS-specific installers. The npm reduction is the champion: its ~35% smaller. But the installers are ~10% slimmer too. Nice.$$$$$$NEW: You can now use the language property in scratch org definition files in combination with scratch org snapshots in Summer24. (GitHub issue #2643; sfdx-core PR #1055 plus some server-side changes in the major release)$$$$$$FIX: Salesforce CLI; when interacting with an org; now properly retries the command when it runs into a network error. (GitHub issues #1350 and #2557; jsforce PR #1403)$$$$$$FIX: The project deploy report command now returns results about all deployed files; even if they dont currently exist in your local project. This scenario can happen if the deploy occurs on one computer and the report command is run on a different computer where the project looks different. The report command warns the user if a local file doesnt exist. (GitHub issues #2602 and #2602; source-deploy-retrieve PR #1273)$$$$$$FIX: The project deploy retrieve command now does not check for a project when doing a metadata api retrieve when using the --manifest flag; and it shouldnt have started doing that. (Github issue #2832 and #2831; plugin-deploy-retrieve PR #978$$$$$$FIX: NodeJS made a breaking windows-related security change. We adjusted the CLI to comply. (Github issue #2822; plugin-telemetry PR #611; oclif/plugin-plugins PR #847; oclif/plugin-update #788)$$$$$$NOTE: As a result of this NodeJS change; some windows users will see a terminal flash (see #2833) in certain scenarios. Were working on a way to avoid that.

2.37.4 (April 17; 2024) [stable]$$$NEW: The JSON output of the package version create command now contains more information: the percentage of Apex code lines that are covered by tests (CodeCoverage) and the full package version number (VersionNumber). The new CodeCoverage key corresponds to the Tooling API Package2Version.CodeCoverage field; the VersionNumber key corresponds to a concatenation of the Package2Version.MajorVersion; Package2Version.MinorVersion; Package2Version.PatchVersion; and Package2Version.BuildNumber fields. (packaging PR #492)$$$$$$Thank you; Ronny Rokitta! This is a great follow-on contribution from the one you made in January -- we love repeat contributors. Cheers!$$$$$$CHANGE: We removed the force org clone and force org status commands from Salesforce CLI; use the org create sandbox and org resume sandbox; respectively; instead. We deprecated the two commands on Feb 9; 2023. (plugin-org PR #1009).$$$$$$FIX: If you deploy source to an org; and source tracking fails for some reason (such as a server error; CLI error; or a problem in your environment); you now get the full details of the failure. Previously you would get just the MetadataTransferError error; and no more information; so it was difficult to troubleshoot what the problem was. (source-deploy-retrieve PR #1275)$$$$$$FIX: You can now successfully run project deploy report and get information about a deployment that you first validated with project deploy validate and then quick deployed with project deploy quick. (plugin-deploy-retrieve PR #962)$$$$$$

2.36.8 (April 10; 2024) [stable]$$$NEW: (Beta) Specify that Salesforce CLI decompose four more metadata types when it converts from mdapi to source format; in addition to the types it currently decomposes automatically (CustomObject and CustomObjectTranslation). And stay tuned; were planning to do more types soon!$$$$$$By decompose we mean that Salesforce CLI breaks the single; and often very large; mdapi-format XML file that corresponds to a metadata component into smaller XML files based on the sub-types. These files live in sub-directories of a directory named the same as the component. See Salesforce DX Project Structure and Source Format for information on how CustomObject and CustomObjectTranslations are decomposed; that topic will soon be updated with similar information about the new decomposed types.$$$$$$Unlike CustomObject and CustomObjectTranslation; you must explicitly opt-in to decompose these new types. Its easy: just add a registryPresets option to your sfdx-project.json file and set it to one or more of these values:$$$$$$decomposePermissionSetBeta : decompose the PermissionSet metadata type$$$decomposeWorkflowBeta : decompose the Workflow metadata type$$$decomposeCustomLabelsBeta : decompose the CustomLabels metadata type$$$decomposeSharingRulesBeta : decompose the SharingRules metadata type$$$When you next retrieve the component; it will be decomposed. (The values include the word Beta; because this feature is currently in beta. When it becomes generally available; youll simply remove the Beta part.)$$$$$$For example; if you want to decompose PermissionSet and Workflow types; add this to your sfdx-project.json:$$$$$$registryPresets: [decomposePermissionSetBeta; decomposeWorkflowBeta]$$$$$$If you already have these metadata types in your project; be sure you follow these steps to start using this new feature:$$$$$$Remove all the files that correspond to the existing metadata components from your project. For example; if you want to start decomposing PermissionSet and Workflow types; remove files that look something like this:$$$$$$cd <myproject>$$$rm force-app/main/default/permissionsets/MyPermSet.permissionset-meta.xml$$$rm force-app/main/default/workflows/Account.workflow-meta.xml$$$Update your sfdx-project.json file and specify the two values to the registryPresets option:$$$$$$registryPresets: [decomposePermissionSetBeta; decomposeWorkflowBeta]$$$$$$Retrieve these components again:$$$$$$sf project retrieve start --metadata PermissionSet --metadata Workflow$$$$$$The command retrieved a bunch of smaller XML files for each permission set and workflow; rather than a single file. Hurray! (GitHub discussion #2544; issues #1159; #2356; and #2376. source-deploy-retrieve PR #1217 source-tracking PR #552)$$$$$$NOTE: This feature is a Beta Service. Customers may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms (https://www.salesforce.com/company/legal/agreements/).$$$$$$NOTE: This beta feature is supported and tested for only the sf project deploy|retrieve|delete|convert commands. We dont support using the force:source:push|pull|deploy|retrieve commands with this feature.$$$$$$NEW: Bypass the warning prompt thats displayed when you install a trusted; yet unsigned; plugin using its GitHub URL by adding the URL to the Salesforce CLI allowlist. Previously you could add only npm names to the file. The GitHub URL must be in the format https://github.com/<org>/<repo>.$$$$$$For example; lets say you add the https://github.com/oclif/plugin-version plugin; which isnt signed by Salesforce; to the unsignedPluginAllowList.json file. You can then run this command and you wont get the warning prompt:$$$$$$sf plugins install https://github.com/oclif/plugin-version$$$We also improved the warning and install messages to clearly indicate which plugin youre installing. (plugin-trust PR #771)$$$$$$FIX: Salesforce DX projects now s

2.34.7 (March 27; 2024) [stable]$$$CHANGE: You can now override the name or license type of a new sandbox (that you create with a definition file) by specifying the --name or --license-type flags in addition to --definition-file. Previously; if you specified a definition file; you couldnt also specify either --name or --license-type.$$$$$$For example; lets say the sandboxName option in the config/dev-sandbox-def.json file is fulldev1; the following command creates a sandbox using all the options in the definition file; except that the sandbox name is fulldev2:$$$$$$$ sf org create sandbox --definition-file config/dev-sandbox-def.json --target-org prodOrg --name fulldev2$$$(plugin-org PR #991)$$$$$$FIX: String replacements during deployments of individual CustomLabel metadata types (without their parent CustomLabels metadata type) are now working as expected. (GitHub issue #2755; source-deploy-retrieve PR #1257)$$$$$$FIX: You can now successfully execute the sf org open command from the terminal window of VS Code thats running on Windows Subsystem for Linux (WSL) 2. (GitHub issue #2677; plugin-org PR #962)$$$$$$Thank you nrakuyama for contributing the fix! We love your initiative and help. Heres to many more!$$$$$$FIX: Weve improved how Salesforce CLI internally converts files between source and metadata formats. The conversion no longer returns an error when done outside a Salesforce DX project. Also; the conversion can now write a zip to disk. (source-deploy-retrieve PR #1252)$$$$$$Many thanks to Aaron Csetter for finding the problems; and then contributing the fixes. Contributions like yours help make Salesforce CLI a better-than-ever developer tool; and were very appreciative!$$$$$$FIX: When deploying; Salesforce CLI now continues to poll for status even when these HTTP error codes are in the response: 502; 503; and 420. (source-deploy-retrieve PR #1262)$$$$$$FIX: Salesforce DX projects now support the ConversationMessageDefinition metadata type.

2.35.6 (April 3; 2024) [stable]$$$NEW: Specify the flag values for Salesforce CLI commands in local text files by using the --flags-dir <dir-name> flag when running the command. If the command finds a file in the specified directory with the same name as one of its flags; it uses the contents of the file as the value of the flag. Take this command; for example:$$$$$$sf project deploy start --metadata ApexClass --test-level RunLocalTests --target-org my-scratch$$$Lets say you create a directory called flag-values in your DX project. You then create a file in that directory called metadata (no extension) and add one line of content to the file: ApexClass. Similarly; you create a file called test-level with contents RunLocalTests and a file called target-org with contents my-scratch. You can then run the preceding command from the DX project this way:$$$$$$sf project deploy start --flags-dir ./flag-values$$$Additional usage notes:$$$$$$The files that contain flag values dont usually have an extension; the only exception is if the files contain JSON content; in which case you must use the .json extension; such as files.json.$$$For Boolean flags; create an empty file with the name of the Boolean flag. For example; to specify the --concise flag; create an empty file called concise.$$$You can name files for Boolean flags no-<flagname>; as long as the Boolean flag supports it. For example; to use this feature with the org create scratch command and disable source tracking; create an empty file called no-track-source.$$$If you include multiple lines in a file; then the result is multiple flags; such as --metadata ApexClass --metadata CustomObject --metadata PermissionSet.$$$Actual flags take precedence over values in a file. For example; if you specify --target-org my-scratch when you run the command; but also specify --flags-dir that points to a target-org file that contains the line my-other-scratch; the command connects to my-scratch. The only exception is for flags that take multiple values; such as --metadata; in this case; the flag and file values are combined.$$$You can name the files using the flags short name; such as m rather than metadata.$$$This release adds the new --flags-dir flag to all CLI commands except for the commands contained in these plugins:$$$sfdx-scanner: Code Analyzer commands; such as scanner run.$$$plugin-devops-center: DevOps Center commands; such as project deploy pipeline start.$$$plugin-functions: Salesforce Functions commands; such as run function.$$$Pretty cool feature; dont you think? (GitHub discussions #2346 and #2670. GitHub issue #2260. salesforcecli/cli PR #1536;$$$$$$CHANGE: As previously announced; Salesforce CLI is now using a major new version of oclif/plugin-plugins; this oclif plugin uses npm instead of yarn (v1) to install and update user plugins.$$$$$$In most cases; theres nothing for you to do as a result of this change. The user plugins youve already installed will continue to work and be updatable using plugins update. But just in case; check the What do I need to do? section of the announcement for the specific use cases in which you might need to do something. The announcement also explains why we made this change.$$$$$$If you experience issues after you update to this Salesforce CLI release; we recommend that you run plugins reset --reinstall --hard; which completely uninstalls all your plugins and then reinstalls them on your behalf. If you continue to experience issues; create a new GitHub issue. (oclif/plugin-plugins PR #776)$$$$$$FIX: You can now include the same source component in all the manifest files (standard; pre-deploy-delete; post-deploy-delete) simultaneously. As a result; you can now; for example; first delete a component and then add it again in a single execution of the project deploy start command. (GitHub issue #2761; source-deploy-retrieve PR #1261)$$$$$$FIX: Salesforce CLI now supports authenticating to orgs with .cn domains. (plugin-auth PR #995)$$$$$$FIX: You can now use the --targ

2.29.5 (Feb 21; 2024) [stable]$$$ANNOUNCEMENTS:$$$$$$On March 14; 2024; Salesforce CLI is going to switch to a new major version of @oclif/plugin-plugins which will use npm instead of yarn (v1) for installing and updating user plugins. For more information; see here.$$$$$$On or after June 1; 2024; Salesforce CLI plans to change how it creates default record types in a scratch org. Specifically; Salesforce CLI will no longer capitalize default record type names if theyre in lower case in the scratch org definition file. Currently; the CLI always capitalizes the record types names; regardless of how theyre specified in the definition file. See the NEW note for the 2.26.10 release for additional details.$$$$$$If you use record types; we recommend that you try setting org-capitalize-record-types to false now and run through your workflows to see if anything breaks; just so youre prepared for the upcoming change. Starting in the 2.26.10 release ; you get a warning if you havent set this config or environment variable. After June 1; if you want to continue using the current behavior; set the new configuration variable org-capitalize-record-types (or its companion SF_CAPITALIZE_RECORD_TYPES environment variable) to true.$$$$$$CHANGE: We removed the --target-dev-hub flag from these commands; the flag has been deprecated and hidden for over two years because it has no effect:$$$$$$org create user$$$org display user$$$org list users$$$(plugin-users PR #864)$$$$$$FIX: We updated our Github Actions to be more friendly to external developers. In particular; we modified our external plugin template so that dev generate plugin generates updated sample GitHub Actions workflow files. We also added Personal Access Token instructions to the README in our GitHub Actions repo.$$$$$$FIX: Salesforce DX projects now support the EnablementMeasureDefinition metadata type.