No way to specify Sandbox Access Group for `org create sandbox` and `org refresh sandbox`
Summary
When creating or refreshing a sandbox using org create sandbox or org refresh sandbox, there is no way to specify the sandbox access group, that corresponds to the SandboxInfo.ActivationUserGroupId
Without this option I am unable to use these commands, particularly for automation in CD/CI environements. I have to always use the UI to create and refresh sandboxes, as our policy is to use that feature to restrict access on sandboxes to only those that are members of a specific public group.
Steps To Reproduce
Try to use org create sandbox or org refresh sandbox and specify a sandbox access group
Expected result
org create sandbox and org refresh sandbox should have an option to allow users to specify a public group, such as a new flag or updating the sandbox definition to include an option like ActivationUserGroupId.
Actual result
- No flag option available to specify a public group for sandbox access
- Sandbox definition does not have an option to specify a public group for sandbox access, per documentation,
System Information
{
"architecture": "linux-x64",
"cliVersion": "@salesforce/cli/2.57.7",
"nodeVersion": "node-v18.20.3",
"osVersion": "Linux 6.8.0-40-generic",
"rootPath": "/home/alan.morey/.volta/tools/image/packages/@salesforce/cli/lib/node_modules/@salesforce/cli",
"shell": "zsh",
"pluginVersions": [
"@oclif/plugin-autocomplete 3.2.2 (core)",
"@oclif/plugin-commands 4.0.13 (core)",
"@oclif/plugin-help 6.2.10 (core)",
"@oclif/plugin-not-found 3.2.18 (core)",
"@oclif/plugin-plugins 5.4.6 (core)",
"@oclif/plugin-search 1.2.7 (core)",
"@oclif/plugin-update 4.5.5 (core)",
"@oclif/plugin-version 2.2.11 (core)",
"@oclif/plugin-warn-if-update-available 3.1.13 (core)",
"@oclif/plugin-which 3.2.12 (core)",
"@salesforce/cli 2.57.7 (core)",
"apex 3.4.5 (core)",
"api 1.2.1 (core)",
"auth 3.6.51 (core)",
"data 3.6.3 (core)",
"deploy-retrieve 3.12.0 (core)",
"dev 2.3.4 (user) published 84 days ago (Fri Jun 14 2024) (latest is 2.4.2)",
"info 3.4.2 (core)",
"limits 3.3.27 (core)",
"marketplace 1.2.24 (core)",
"org 4.5.4 (core)",
"packaging 2.8.0 (core)",
"schema 3.3.26 (core)",
"settings 2.3.15 (core)",
"sobject 1.4.32 (core)",
"source 3.5.16 (core)",
"telemetry 3.6.10 (core)",
"templates 56.3.14 (core)",
"trust 3.7.25 (core)",
"user 3.5.26 (core)",
"cli-plugin 1.0.0 (link) /home/alan.morey/repos/salesforce/cli-plugin",
"gr-sfdx-plugin 0.0.0 (link) /home/alan.morey/repos/salesforce/gr-sfdx-plugin"
]
}
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.
This issue has been linked to a new work item: W-16699649
Server side support for ActivationUserGroupId was recently added back in API v61.0 so we'll add it to the CLI. Thank you for reporting!
@alan-morey what's the exact error message you get when you set ActivationUserGroupId in the sandbox def. file?
I tried with this def. file can see it set in the request (sandbox copy in progress):
{
"ActivationUserGroupId": "<id for `test1` group>"
}
request:
[17:04:07.302] DEBUG (sf:oclif:connection): request
method: "POST"
url: "https://<hub>my.salesforce.com/services/data/v61.0/tooling/sobjects/SandboxInfo"
body: "{\"ActivationUserGroupId\":\"...\",\"SandboxName\":\"sbx0wv10ia\",\"LicenseType\":\"Developer\"}"
headers: {
"content-type": "application/json",
If I set the API version to 59.0 in the hub auth file I get this API error (which is valid, ActivationUserGroupId is on >= 60):
[17:41:12.190] ERROR (sf:oclif): INVALID_FIELD: No such column 'ActivationUserGroupId' on sobject of type SandboxInfo
@cristiand391 I actually did not try using ActivationUserGroupId in the sandbox definition file. :grimacing: I'll give it a try and get back to you.
When I didn't see it in the v62 documentation or in the v61 documentation I assumed it wasn't supported.
So, maybe this is just a documentation bug then?
I did not think the field names of SandboxInfo would map directly into the definition file field names but it seems like most of the fields do. Except for maybe SandboxInfo.SourceId where sandbox definition has sourceSandboxName? Unless SourceId is also supported in sandbox definition files but just not documented?
Either way, I like the way sourceSandboxName field in the definition file works, to be able to specify the source sandbox as a name vs an ID, as it makes it clearer and easier for humans :sweat_smile:
It would be nice if something similar could be done with ApexClassId and ActivationUserGroupId, having apexClassName and activationUserGroupName respectively, in the definition file, so names could be provided instead of ID's for those options.
@cristiand391 I tried the field ActivationUserGroupId in the definition file and that seems to work.
{
"ActivationUserGroupId": "00G30000002HUShEAO",
"autoActivate": true
}
sf org create sandbox -n alantmp1 -l Developer -o PROD -f config/tmp.sandbox-def.json
=== Config Sandbox Request
Field Value
───────────────────── ──────────────────
ActivationUserGroupId 00G30000002HUShEAO
AutoActivate true
SandboxName alantmp1
LicenseType Developer
? Is the configuration correct? yes
Sandbox Create... ⣟ 00:27:30 until timeout. 17%
Field Value
───────────── ────────────────────────────
Id 0GROO0000000YOH4A2
SandboxName alantmp1
Status Processing
LicenseType DEVELOPER
SandboxInfoId 0GQOO0000000Fa94AE
Created Date 2024-09-11T18:46:41.000+0000
CopyProgress 17%
SandboxOrg 00DG1000002aJFt
---------------------
Sandbox Create Stages
✓ - Pending
… - Processing
… - Activating
… - Authenticating
However when I specify ApexClassId in the definition file, that produces an error:
{
"ActivationUserGroupId": "00G30000002HUShEAO",
"ApexClassId": "01pOO000001IyrZYAS",
"autoActivate": true
}
sf org create sandbox -n alandev05 -l Developer -o PROD -f config/tmp.sandbox-def.json
=== Config Sandbox Request
Field Value
───────────────────── ──────────────────
ActivationUserGroupId 00G30000002HUShEAO
ApexClassId 01pOO000001IyrZYAS
AutoActivate true
SandboxName alandev05
LicenseType Developer
? Is the configuration correct? yes
Sandbox Create... done
Error (1): No such column 'ApexClassId' on sobject of type SandboxInfo
Error (1): No such column 'ApexClassId' on sobject of type SandboxInfo
weird, maybe an access issue? https://issues.salesforce.com/issue/a028c00000qPwkhAAC/no-such-column-apexclassid-on-entity-sandboxinfo-seen-when-creating-sandbox-through-tooling-api
You can test access by querying the field via the tooling API:
sf data query -q 'select apexclassid from sandboxinfo' -o <org> --use-tooling-api
APEXCLASSID
───────────
null
null
null
null
null
null
null
null
null
null
null
null
null
null
null
null
null
null
null
Total number of records retrieved: 19.
Querying Data... done
Either way, I like the way sourceSandboxName field in the definition file works, to be able to specify the source sandbox as a name vs an ID, as it makes it clearer and easier for humans 😅 It would be nice if something similar could be done with ApexClassId and ActivationUserGroupId, having apexClassName and activationUserGroupName respectively, in the definition file, so names could be provided instead of ID's for those options.
Thanks for the tip, we'll add support for this (tracked internally as W-16757770).
@cristiand391 Regarding the access issue for ApexClassId. I had the "Manage Dev Sandboxes" permission assigned but this alone was not enough to be able to access the ApexClassId column of the SandboxInfo. I was able to fix it by additionally assigning the "Manage Sandboxes" permission.
This seems more appropriate than assigning the "View All Data" permission which was the suggested workaround in the knowledge article you linked to above.
It would be ideal if assigning "Manage Dev Sandboxes" permission was enough to get access to SandboxInfo.ApexClassId without having to also assign "Manage Sandboxes", at my company we are trying to limit developers to "Manage Dev Sandboxes" only but this is good enough for now.
Thanks for the update 👍🏼
We've added support for apexClassName and activationUserGroupName, available in the current RC (will be promoted to stable next Wednesday):
https://github.com/forcedotcom/cli/tree/main/releasenotes/#2618-october-9-2024-stable-rc