mdapi Commands
mdapi:convert
Command Syntax
- sfdx force:mdapi:convert
- -r ROOTDIR
- [-d OUTPUTDIR]
- [--json]
- [--loglevel LOGLEVEL]
Parameters
- -r | --rootdir ROOTDIR
- Required
-
The root directory that contains the metadata you retrieved using Metadata API.
- Type: directory
- -d | --outputdir OUTPUTDIR
- Optional
-
The directory to store your files in after they’re converted to the source format. Can be an absolute or relative path.
- Type: directory
- --json
- Optional
-
Format output as JSON.
- Type: flag
- --loglevel LOGLEVEL
- Optional
-
The logging level for this command invocation. Logs are stored in $HOME/.sfdx/sfdx.log.
- Type: string
- Permissible values are: trace, debug, info, warn, error, fatal
- Default value: error
Help for mdapi:convert
NOTE: This command must be run from within a project.
To use Salesforce CLI to work with components that you retrieved via Metadata API, first convert your files from the metadata format to the source format using "sfdx force:mdapi:convert".
To convert files from the source format back to the metadata format, so that you can deploy them using "sfdx force:mdapi:deploy", run "sfdx force:source:convert".
Examples:
1$ sfdx force:mdapi:convert -r path/to/metadata1$ sfdx force:mdapi:convert -r path/to/metadata -d path/to/outputdirmdapi:deploy
Command Syntax
- sfdx force:mdapi:deploy
- [-c]
- [-d DEPLOYDIR]
- [-w WAIT]
- [-i JOBID]
- [-l TESTLEVEL]
- [-r RUNTESTS]
- [-e ROLLBACKONERROR]
- [-o]
- [-g]
- [-q VALIDATEDDEPLOYREQUESTID]
- [-f ZIPFILE]
- [-u TARGETUSERNAME]
- [--json]
- [--loglevel LOGLEVEL]
- [--verbose]
Parameters
- -c | --checkonly
- Optional
-
Validates the deployed metadata and runs all Apex tests, but prevents the deployment from being saved to the org.
If you change a field type from Master-Detail to Lookup or vice versa, that change isn’t supported when using the --checkonly parameter to test a deployment (validation). This kind of change isn’t supported for test deployments to avoid the risk of data loss or corruption. If a change that isn’t supported for test deployments is included in a deployment package, the test deployment fails and issues an error.
If your deployment package changes a field type from Master-Detail to Lookup or vice versa, you can still validate the changes prior to deploying to Production by performing a full deployment to another test Sandbox. A full deployment includes a validation of the changes as part of the deployment process.
Note: A Metadata API deployment that includes Master-Detail relationships deletes all detail records in the Recycle Bin in the following cases.
1. For a deployment with a new Master-Detail field, soft delete (send to the Recycle Bin) all detail records before proceeding to deploy the Master-Detail field, or the deployment fails. During the deployment, detail records are permanently deleted from the Recycle Bin and cannot be recovered.
2. For a deployment that converts a Lookup field relationship to a Master-Detail relationship, detail records must reference a master record or be soft-deleted (sent to the Recycle Bin) for the deployment to succeed. However, a successful deployment permanently deletes any detail records in the Recycle Bin.
- Type: boolean
- Default value: false
- -d | --deploydir DEPLOYDIR
- Optional
-
The root of the directory tree that contains the files to deploy. The root must contain a valid package.xml file describing the entities in the directory structure. Required to initiate a deployment if you don’t use --zipfile. If you specify both --zipfile and --deploydir, a zip file of the contents of the --deploydir directory is written to the location specified by --zipfile.
- Type: directory
- -w | --wait WAIT
- Optional
-
The number of minutes to wait for the command to complete. The default is –1 (no limit). 0
- Type: minutes
- -i | --jobid JOBID
- The parameter --jobid has been deprecated and will be removed in v42.0 or later. Use instead.
- Optional
-
The job ID (asyncId) of the deployment you want to check. If not specified, the default value is the ID of the most recent metadata deployment you ran using Salesforce CLI. Use with -w to resume waiting.
- Type: id
- -l | --testlevel TESTLEVEL
- Optional
-
Specifies which level of deployment tests to run. Valid values are:
NoTestRun—No tests are run. This test level applies only to deployments to development environments, such as sandbox, Developer Edition, or trial orgs. This test level is the default for development environments.
RunSpecifiedTests—Runs only the tests that you specify in the --runtests option. Code coverage requirements differ from the default coverage requirements when using this test level. Executed tests must comprise a minimum of 75% code coverage for each class and trigger in the deployment package. This coverage is computed for each class and trigger individually and is different than the overall coverage percentage.
RunLocalTests—All tests in your org are run, except the ones that originate from installed managed packages. This test level is the default for production deployments that include Apex classes or triggers.
RunAllTestsInOrg—All tests in your org are run, including tests of managed packages.
If you don’t specify a test level, the default behavior depends on the contents of your deployment package. For more information, see “Running Tests in a Deployment” in the Metadata API Developer Guide.
- Type: string
- Permissible values are: NoTestRun, RunSpecifiedTests, RunLocalTests, RunAllTestsInOrg
- -r | --runtests RUNTESTS
- Optional
-
Lists the Apex classes containing the deployment tests to run. Use this parameter when you set --testlevel to RunSpecifiedTests.
- Type: string
- -e | --rollbackonerror ROLLBACKONERROR
- The parameter --rollbackonerror has been deprecated and will be removed in v42.0 or later. Use instead.
- Optional
-
Indicates whether any failure causes a complete rollback of the deploy operation. The default is true. If set to false, the operation performs actions that don’t have errors and returns errors for the remaining actions. You must set this parameter to true if you are deploying to a production org.
- Type: boolean
- Default value: true
- -o | --ignoreerrors
- Optional
-
Ignores the deploy errors, and continues with the deploy operation. The default is false. Keep this parameter set to false when deploying to a production org. If set to true, components without errors are deployed, and components with errors are skipped.
- Type: flag
- Default value: false
- -g | --ignorewarnings
- Optional
-
If a warning occurs and ignoreWarnings is set to true, the success field in DeployMessage is true. When ignoreWarnings is set to false, success is set to false, and the warning is treated like an error.
This field is available in API version 18.0 and later. Prior to version 18.0, there was no distinction between warnings and errors. All problems were treated as errors and prevented a successful deployment.
- Type: flag
- Default value: false
- -q | --validateddeployrequestid VALIDATEDDEPLOYREQUESTID
- Optional
-
Specifies the ID of a package with recently validated components to run a Quick Deploy. Deploying a validation helps you shorten your deployment time because tests aren’t rerun. If you have a recent successful validation, you can deploy the validated components without running tests. A validation doesn’t save any components in the org. You use a validation only to check the success or failure messages that you would receive with an actual deployment. To validate your components, add the -c | --checkonly flag when you run "sfdx force:mdapi:deploy". This flag sets the checkOnly="true" parameter for your deployment. Before deploying a recent validation, ensure that the following requirements are met:
1. The components have been validated successfully for the target environment within the last 10 days.
2. As part of the validation, Apex tests in the target org have passed.
3. Code coverage requirements are met.
- If all tests in the org or all local tests are run, overall code coverage is at least 75%, and Apex triggers have some coverage.
- If specific tests are run with the RunSpecifiedTests test level, each class and trigger that was deployed is covered by at least 75% individually.
- Type: id
- -f | --zipfile ZIPFILE
- Optional
-
The path to the .zip file of metadata files to deploy. You must indicate this option or --deploydir.If you specify both --zipfile and --deploydir, a .zip file of the contents of the deploy directory is created at the path specified for the .zip file.
- Type: filepath
- -u | --targetusername TARGETUSERNAME
- Optional
-
A username or alias for the target org. Overrides the default target org.
- Type: string
- --json
- Optional
-
Format output as JSON.
- Type: flag
- --loglevel LOGLEVEL
- Optional
-
The logging level for this command invocation. Logs are stored in $HOME/.sfdx/sfdx.log.
- Type: string
- Permissible values are: trace, debug, info, warn, error, fatal
- Default value: error
- --verbose
- Optional
-
Indicates that you want verbose output from the deploy operation.
- Type: flag
Help for mdapi:deploy
Specify the location of the files to deploy as a .zip file or by the root of the directory tree containing the files. To check the status of a deployment, specify its job ID. To run quick deploy of a recently validated package, use --validateddeployrequestid with the validated ID.
The default value of --rollbackonerror is true, but the corresponding parameter in the Metadata API deploy() call defaults to false.
To wait for the command to finish running no matter how long the deployment takes, set --wait to -1: "sfdx force mdapi:deploy -w -1 ...".
mdapi:deploy:cancel
Command Syntax
- sfdx force:mdapi:deploy:cancel
- [-w WAIT]
- [-i JOBID]
- [-u TARGETUSERNAME]
- [--json]
- [--loglevel LOGLEVEL]
Parameters
- -w | --wait WAIT
- Optional
-
Number of minutes to wait for the command to complete and display results to the terminal window. If the command continues to run after the wait period, the CLI returns control of the terminal window to you. The default is 33 minutes.
- Type: minutes
- Default value: 33
- -i | --jobid JOBID
- Optional
-
The job ID (requestId) of the deployment you want to cancel. If not specified, the default value is the ID of the most recent metadata deployment you ran using Salesforce CLI.
- Type: id
- -u | --targetusername TARGETUSERNAME
- Optional
-
A username or alias for the target org. Overrides the default target org.
- Type: string
- --json
- Optional
-
Format output as JSON.
- Type: flag
- --loglevel LOGLEVEL
- Optional
-
The logging level for this command invocation. Logs are stored in $HOME/.sfdx/sfdx.log.
- Type: string
- Permissible values are: trace, debug, info, warn, error, fatal
- Default value: error
Help for mdapi:deploy:cancel
Use this command to cancel a specified asynchronous metadata deployment. You can also specify a wait time (in minutes) to check for updates to the canceled deploy status.
Examples:
Deploy a directory of files to the org
1$ sfdx force:mdapi:deploy -d <directory>Now cancel this deployment and wait two minutes
1$ sfdx force:mdapi:deploy:cancel -w 2If you have multiple deployments in progress and want to cancel a specific one, specify the job ID
1$ sfdx force:mdapi:deploy:cancel -i <jobid>Check the status of the cancel job
1$ sfdx force:mdapi:deploy:reportmdapi:deploy:report
Command Syntax
- sfdx force:mdapi:deploy:report
- [-w WAIT]
- [-i JOBID]
- [-u TARGETUSERNAME]
- [--json]
- [--loglevel LOGLEVEL]
- [--verbose]
Parameters
- -w | --wait WAIT
- Optional
-
The number of minutes to wait for the command to complete. The default is –1 (no limit). 0
- Type: minutes
- -i | --jobid JOBID
- Optional
-
The job ID (asyncId) of the deployment you want to check. If not specified, the default value is the ID of the most recent metadata deployment you ran using Salesforce CLI. Use with -w to resume waiting.
- Type: id
- -u | --targetusername TARGETUSERNAME
- Optional
-
A username or alias for the target org. Overrides the default target org.
- Type: string
- --json
- Optional
-
Format output as JSON.
- Type: flag
- --loglevel LOGLEVEL
- Optional
-
The logging level for this command invocation. Logs are stored in $HOME/.sfdx/sfdx.log.
- Type: string
- Permissible values are: trace, debug, info, warn, error, fatal
- Default value: error
- --verbose
- Optional
-
Indicates that you want verbose output for deploy results.
- Type: flag
Help for mdapi:deploy:report
Specify the job ID for the deploy you want to check. You can also specify a wait time (minutes) to check for updates to the deploy status.
mdapi:retrieve
Command Syntax
- sfdx force:mdapi:retrieve
- [-a APIVERSION]
- [-w WAIT]
- -r RETRIEVETARGETDIR
- [-k UNPACKAGED]
- [-d SOURCEDIR]
- [-p PACKAGENAMES]
- [-s]
- [-i JOBID]
- [-u TARGETUSERNAME]
- [--json]
- [--loglevel LOGLEVEL]
- [--verbose]
Parameters
- -a | --apiversion APIVERSION
- Optional
-
Use to override the default, which is the latest version supported by your CLI plug-in, with the version in your package.xml file.
- Type: number
- -w | --wait WAIT
- Optional
-
The number of minutes to wait for the command to complete. -1
- Type: minutes
- -r | --retrievetargetdir RETRIEVETARGETDIR
- Required
-
The root of the directory structure where the retrieved .zip or metadata files are put.
- Type: directory
- -k | --unpackaged UNPACKAGED
- Optional
-
The complete path for the manifest file that specifies the components to retrieve.
- Type: filepath
- -d | --sourcedir SOURCEDIR
- Optional
-
The source directory to use instead of the default manifest specified in sfdx-config.json.
- Type: directory
- -p | --packagenames PACKAGENAMES
- Optional
-
A comma-separated list of package names to retrieve.
- Type: string
- -s | --singlepackage
- Optional
-
Specifies whether only a single package is being retrieved (true) or more than one package (false).
- Type: flag
- -i | --jobid JOBID
- The parameter --jobid has been deprecated and will be removed in v42.0 or later. Use instead.
- Optional
-
The job ID (asyncId) of the retrieve you want to check. If not specified, the default value is the ID of the most recent metadata retrieval you ran using Salesforce CLI. You must specify a --retrievetargetdir. Use with --wait to resume waiting.
- Type: id
- -u | --targetusername TARGETUSERNAME
- Optional
-
A username or alias for the target org. Overrides the default target org.
- Type: string
- --json
- Optional
-
Format output as JSON.
- Type: flag
- --loglevel LOGLEVEL
- Optional
-
The logging level for this command invocation. Logs are stored in $HOME/.sfdx/sfdx.log.
- Type: string
- Permissible values are: trace, debug, info, warn, error, fatal
- Default value: error
- --verbose
- Optional
-
Indicates that you want verbose output from the retrieve operation.
- Type: flag
Help for mdapi:retrieve
The default target username is the admin user for the default scratch org. You can retrieve and deploy up to 10,000 files or 400 MB (39 MB compressed) at one time.
mdapi:retrieve:report
Command Syntax
- sfdx force:mdapi:retrieve:report
- [-w WAIT]
- [-r RETRIEVETARGETDIR]
- [-i JOBID]
- [-u TARGETUSERNAME]
- [--json]
- [--loglevel LOGLEVEL]
- [--verbose]
Parameters
- -w | --wait WAIT
- Optional
-
The number of minutes to wait for the command to complete. -1
- Type: minutes
- -r | --retrievetargetdir RETRIEVETARGETDIR
- Optional
-
The root of the directory structure where the retrieved .zip or metadata files are put.
- Type: directory
- -i | --jobid JOBID
- Optional
-
The job ID (asyncId) of the retrieve you want to check. If not specified, the default value is the ID of the most recent metadata retrieval you ran using Salesforce CLI. You must specify a --retrievetargetdir. Use with --wait to resume waiting.
- Type: id
- -u | --targetusername TARGETUSERNAME
- Optional
-
A username or alias for the target org. Overrides the default target org.
- Type: string
- --json
- Optional
-
Format output as JSON.
- Type: flag
- --loglevel LOGLEVEL
- Optional
-
The logging level for this command invocation. Logs are stored in $HOME/.sfdx/sfdx.log.
- Type: string
- Permissible values are: trace, debug, info, warn, error, fatal
- Default value: error
- --verbose
- Optional
-
Indicates that you want verbose output from the retrieve operation.
- Type: flag
Help for mdapi:retrieve:report
Specify the job ID and a target directory for the retrieve you want to check. You can also specify a wait time (minutes) to check for updates to the deploy status. If the retrieve was successful, the resulting zip file will be saved to the location passed in with the retrieve target parameter.