Repository navigation
feat: add ExtensionConfig to sandbox create and refresh @W-23860697@ - #1368
Open
apanwar-sf wants to merge 2 commits into
Open
apanwar-sf wants to merge 2 commits into
apanwar-sf wants to merge 2 commits into
Conversation
|
Thanks for the contribution! It looks like @apanwar-sf is an internal user so signing the CLA is not required. However, we need to confirm this. |
wmorrow-sf
reviewed
Nov 10, 2026
Sends ExtensionConfig only when the caller provides it, serializing an object to JSON as done for PostCopyConfig. The field is not added to the SandboxInfo or SandboxProcess query fields, so requests to orgs and API versions without it (before 69.0) are unchanged. Adds querySandboxExtensionConfig, which reads ExtensionConfig from the latest SandboxProcess and returns it parsed, or undefined when none was sent or the org or API version doesn't have the field. It throws NoRecords when no SandboxProcess is found, like querySandboxInfo. It returns the config rather than a SandboxInfo, so it isn't sent back by a later refresh.
apanwar-sf
force-pushed
the
ap/extension-config
branch
from
November 11, 2026 05:30
35b3fb0 to
910ed6f
Compare
WillieRuemmele
previously approved these changes
Nov 12, 2026
| const soql = `SELECT ExtensionConfig FROM SandboxProcess WHERE SandboxName='${sandboxName}' AND Status != 'D' ORDER BY CreatedDate DESC LIMIT 1`; | ||
| let records: Array<{ ExtensionConfig?: string | null }>; | ||
| try { | ||
| records = (await this.connection.tooling.query<{ ExtensionConfig?: string | null }>(soql)).records; |
Member
There was a problem hiding this comment.
you could connection.singleRecordQuery(...,{tooling:true}) which could simplify some of the error handling below
Author
There was a problem hiding this comment.
Good call, thanks. I will switch to singleRecordQuery, so the NoRecords check now comes from there. I kept the catch, because the INVALID_FIELD case (orgs before API 69.0) still returns undefined.
…60697@ Uses connection.singleRecordQuery with tooling, so NoRecords comes from there instead of a manual check. Notes that the API returns ExtensionConfig as a JSON string, and adds a test with config for more than one extension.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@W-23860697@
Summary
ExtensionConfigfield (Record<string, JsonMap> | string) toSandboxRequestandSandboxInfo, so callers can pass per-extension sandbox config when creating, cloning or refreshing a sandbox. The field is available from API version 69.0.ExtensionConfigto JSON inOrg.createSandboxandOrg.refreshSandbox(mirroring the existingPostCopyConfighandling) before sending it to the Tooling API. It is sent only when the caller provides it.Org.querySandboxExtensionConfig(sandboxName), a read-only helper that returns the parsed config from the latestSandboxProcess. It returnsundefinedwhen no config was sent or the org or API version doesn't have the field.test/unit/org/org.test.ts.Backward compatibility
ExtensionConfigis not added tosandboxInfoFieldsorsandboxProcessFields, so existing queries are unchanged on orgs and API versions before 69.0.ExtensionConfigin the definition file, requests are the same as today on every org and API version.SandboxInfo.PostCopyConfigcode is unchanged.Test plan
yarn testpasses locally (1170 passing).createSandbox/refreshSandbox(config as an object, as a string, and absent), check thatExtensionConfigisn't added to the existing queries, and coverquerySandboxExtensionConfig(parsed, null, no records, INVALID_FIELD, other errors re-thrown).create sandbox
Example sandbox definition file:
{
"SandboxName": "MCDev266",
"LicenseType": "Developer",
"ExtensionConfig": { "marketing_cloud": { "marketing_objects": ["mc_object_1", "mc_object_2"] } }
}
refresh sandbox
Exampe of sandbox definiton file:⚠️ This refresh will break the trust relationship with eCommerce instance: www.mycustomcctrusturl.com",
{
"SandboxName": "anukt1",
"LicenseType": "Developer",
"ExtensionConfig": {
"commerce_cloud": {
"message": "
"acknowledged": true
}
}
}
Create sandbox without extension config showing its optional