Refreshing a sandbox copies the metadata, and optionally data, from your source org to the refreshed sandbox org. You can optionally specify a definition file if you want to change the configuration of the refreshed sandbox, such as its license type or template ID. You can also use the –source-id or –source-sandbox-name flags to change the refreshed sandbox org’s original source org to a new org; in this case, the refreshed sandbox org’s metadata is updated with the new source org’s metadata.
You’re not allowed to change the sandbox name when you refresh it with this command. If you want to change the sandbox name, first delete it with the “org delete sandbox” command. And then recreate it with the “org create sandbox” command and give it a new name.
Flags
Flag Name (Long)
Flag Name (Short)
Description
‑‑async
N/A
Type: Boolean
Request the sandbox refresh, but don’t wait for it to complete.
The command immediately displays the job ID and returns control of the terminal to you. This way, you can continue to use the CLI. To check the status of the sandbox refresh, run “sf org resume sandbox”.
‑‑definition‑file
‑f
Type: Value
Path to a sandbox definition file for overriding its configuration when you refresh it.
Name of the existing sandbox org in your production org that you want to refresh.
‑‑no‑auto‑activate
N/A
Type: Boolean
Disable auto-activation of the sandbox after a successful refresh.
By default, a sandbox auto-activates after a refresh. Use this flag to control sandbox activation manually.
‑‑no‑prompt
N/A
Type: Boolean
Don’t prompt for confirmation about the sandbox refresh.
‑‑poll‑interval
‑i
Type: Value Default value:30 seconds
Number of seconds to wait between status polling requests.
‑‑source‑id
N/A
Type: Value
ID of the sandbox org that becomes the new source org for the refreshed sandbox.
The value of –source-id must be an existing sandbox. The new source sandbox, and the refreshed sandbox specified with the –name flag, must both be associated with the production org (–target-org) that contains the sandbox licenses.
You can specify either –source-id or –source-sandbox-name when refreshing an existing sandbox, but not both.
‑‑source‑sandbox‑name
N/A
Type: Value
Name of the sandbox org that becomes the new source org for the refreshed sandbox.
The value of –source-sandbox-name must be an existing sandbox. The new source sandbox, and the refreshed sandbox specified with the –name flag, must both be associated with the production org (–target-org) that contains the sandbox licenses.
You can specify either –source-sandbox-name or –source-id when refreshing an existing sandbox, but not both.
‑‑target‑org
‑o
Type: Value Required
Username or alias of the production org that contains the sandbox license.
‑‑wait
‑w
Type: Value Default value:30 minutes
Number of minutes to poll for sandbox refresh status.
If the command continues to run after the wait period, the CLI returns control of the terminal to you and displays the “sf org resume sandbox” command for you run to check the status of the refresh. The displayed command includes the job ID for the running sandbox refresh.
Examples for org refresh sandbox
Refresh the sandbox named “devSbx1”. The production org that contains the sandbox license has the alias “prodOrg”.
Refresh the sandbox named “devSbx2”, and override the configuration of the refreshed sandbox with the properties in the specified defintion file. The default target org is the production org, so you don’t need to specify the --target-org flag in this case.
j