No way to specify Sandbox Access Group for org create sandbox and org refresh sandbox

[alan-morey]

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"
  ]
}

[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.

[git2gus]

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

[shetzel]

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!

[cristiand391]

@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",

[cristiand391]

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

[alan-morey]

@cristiand391 I actually did not try using ActivationUserGroupId in the sandbox definition file. 😬 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 😅

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.

[alan-morey]

@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

[cristiand391]

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

[cristiand391]

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).