sourceSandboxName sandbox def file value throws 'no such column on SandboxInfo object' error on sandbox refresh

[stafik]

Summary

The sourceSandboxName config value (link to the doc) in my sandbox definition file throws an error when I try refreshing an existing sandbox.

Steps To Reproduce

I think I can skip providing a test repository as my issue doesn't relate to Salesforce metadata but SF CLI itself. I hope it's fine?

Prerequisites:

1. Two existing developer sandboxes: sbx1 and sbx2 created off production org.

Steps to reproduce:

1. Create a developer-sandbox-def.json file and add the following content:

{
    "sandboxName": "sbx2",
    "sourceSandboxName": "sbx1"
}

2. Run: sf org refresh sandbox --definition-file developer-sandbox-def.json --target-org prodOrgAlias --wait 600 --no-prompt
3. See the following error: Error (1): No such column 'SourceSandboxName' on sobject of type SandboxInfo.

Expected result

I'd expect that refreshing the sbx2 sandbox has started successfully. Besides, I'd see in the console output and in the production org | Setup | Sandboxes that sbx1 is the source sandbox.

Actual result

An error is thrown: Error (1): No such column 'SourceSandboxName' on sobject of type SandboxInfo.

Additional information

I fiddled around a bit and replaced sourceSandboxName with sourceId, because such field does exist in the SandboxInfo object. So, effectively, the developer-sandbox-def.json file would look as follows:

{
    "sandboxName": "sbx2",
    "sourceId": "0GQW60000000A2bOAE"
}

When I run a sandbox refresh, it worked without issues.
I guess that maybe a sourceSandboxName -> sourceId mapping didn't work correctly when submitting a new sandbox refresh request in my case?

System Information

I'm using Bash. I run my scenario in a GitLab pipeline.

{
  "architecture": "linux-x[64](https://gitlab.richemont.com/scm_project/ric/client360/tools/-/jobs/5583830#L64)",
  "cliVersion": "@salesforce/cli/2.82.6",
  "nodeVersion": "node-v22.14.0",
  "osVersion": "Linux 6.5.0-1024-aws",
  "rootPath": "/usr/local/lib/nodejs/lib/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.26 (core)",
    "@oclif/plugin-commands 4.1.22 (core)",
    "@oclif/plugin-help 6.2.27 (core)",
    "@oclif/plugin-not-found 3.2.48 (core)",
    "@oclif/plugin-plugins 5.4.36 (core)",
    "@oclif/plugin-search 1.2.23 (core)",
    "@oclif/plugin-update 4.6.35 (core)",
    "@oclif/plugin-version 2.2.27 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.38 (core)",
    "@oclif/plugin-which 3.2.34 (core)",
    "@salesforce/cli 2.82.6 (core)",
    "apex 3.6.11 (core)",
    "api 1.3.3 (core)",
    "auth 3.6.107 (core)",
    "data 4.0.23 (core)",
    "deploy-retrieve 3.21.1 (core)",
    "info 3.4.50 (core)",
    "limits 3.3.51 (core)",
    "marketplace 1.3.7 (core)",
    "org 5.5.5 (core)",
    "packaging 2.12.3 (core)",
    "schema 3.3.57 (core)",
    "settings 2.4.21 (core)",
    "sobject 1.4.53 (core)",
    "telemetry 3.6.36 (core)",
    "templates 56.3.43 (core)",
    "trust 3.7.[75](https://gitlab.richemont.com/scm_project/ric/client360/tools/-/jobs/5583830#L75) (core)",
    "user 3.6.15 (core)",
    "@salesforce/sfdx-scanner 4.11.0 (user) published 13 days ago (Tue Mar 25 2025)",
    "sfdx-git-delta 6.5.1 (user) published 6 days ago (Wed Apr 02 2025)"
  ]
}

Thanks a lot for checking my issue and for your support!

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[iowillhoit]

Hey @stafik 👋 Thanks for creating this issue. SourceSandboxName is not needed for a sandbox refresh and can be removed from the definition file. That relationship is already set from when the Sandbox was created.

That said, we can add some logic to ignore that value when building the sandboxInfo here. Hopefully this would prevent confusion in the future.

[git2gus]

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

[stafik]

Hi @iowillhoit,
thanks a lot for a quick response.
I think I haven't explained my case well enough, sorry!
I have a frequent scenario where I refresh a cloned sandbox and switch the relationship with the source sandbox.
Let's say, I have 3 sandboxes:

1. sbx1 and sbx2 created off production
2. sbx3 which is a clone of sbx1
   I'd like to be able to refresh sbx3 and this time make it be a clone of sbx2.
   I had to delete sbx3 in the past, wait 1h or so until the sandbox name becomes free again and create a brand new clone of sbx2.

My scenario is perfectly doable in UI (Setup | Sandboxes). It's also doable if I specify sourceId value in my developer-sandbox-def.json file. I think it would be great to unify the experience and make it work the same way when I provide SourceSandboxName value too.
I think this is how other sandbox config values work, e.g.:

• activationUserGroupId & activationUserGroupName
• apexClassId & apexClassName

Right now, I do the name->orgId mapping myself in my pipeline automation that leverages SF CLI and refreshes sandboxes. I enter a new source sandbox name in the pipeline UI. The pipeline queries SandboxInfo object to get the new source sandbox org id and sets it as sourceId value in my developer-sandbox-def.json.

How do you think?

Thanks again for your support!

[iowillhoit]

Hey @stafik, gotcha that does make sense. So if you do have a sourceId in your definition file, you can switch the source from which your sandbox gets refreshed. Just to clarify, when you don't add a sourceId to your definition file and run sf org sandbox refresh, it automatically refreshes from the sandbox it was created from, right?

Using your example:

• sbx1 and sbx2 created off production
• sbx3 which is a clone of sbx1
• If I run sf org refresh sandbox --name sbx3 --target-org prodOrgAlias does it refresh from sbx1?

We already have a helper function to get the source id by name (here). We will need to discuss, but we could potentially change the refresh command to work more similarly to sandbox create

[stafik]

Hi @iowillhoit,
thanks for a quick response!

So if you do have a sourceId in your definition file, you can switch the source from which your sandbox gets refreshed.

Yes. Correct.
Just a side note, that I'm pretty sure it didn't work in a SF CLI version from Nov '24. I came back to the topic lately, checked this scenario again using the newest SF CLI version and it worked. :)

Just to clarify, when you don't add a sourceId to your definition file and run sf org sandbox refresh, it automatically refreshes from the sandbox it was created from, right?

Yes, that's correct.

If I run sf org refresh sandbox --name sbx3 --target-org prodOrgAlias does it refresh from sbx1?

Yes, that's correct.

We already have a helper function to get the source id by name (here).

That's great. This is actually what I'm doing as a workaround now.

Since switching source orgs while refreshing a sandbox is working when I use the sourceId config value, it's no longer a blocker for me anymore. Yet, I think it would be great to get rid of the error I reported initially and unify the behaviour of sourceId and sourceSandboxName config values.

Let me know, please if I can provide some more feedback.

Thanks a lot guys! I really appreciate your quick help!

[iowillhoit]

Thanks for the additional details @stafik ! Looks like @soridalac jumped on this one and has a PR already open 🏆

[cristiand391]

the new source flags were added in sf v2.86.9:
https://github.com/forcedotcom/cli/tree/main/releasenotes/#2869-april-30-2025-stable