issues under the hood. There is no bespoke signup endpoint: signup = inserting a
SignupRequest
(key prefix
0SR
) against an authenticated
host org
(a Trialforce Source Org / Env Hub / partner org that is entitled to create trial orgs).
The flow is
two CLI calls
(1) create the
SignupRequest
, (2) read it back to pick up the assigned org id (creation is asynchronous — the org id appears shortly after the insert).
Prerequisites — confirm before executing
Authenticated host org — always confirm which one, explicitly.
You are signing up
from
an authenticated host org, not anonymously. The
sf
CLI operates against an org you have already logged into once (
sf org login web
, or
sf org login
).
Always pass an explicit
--target-org
(
-o
) with the host org's alias or username on every command, and confirm the target with the user before creating
— even if a default org is configured. Creating a
SignupRequest
is a real provisioning action; do not let it run against whatever org happens to be the default.
Do not rely on the default-org fallback.
With no
-o
, the CLI resolves the target from
--target-org
→
SF_TARGET_ORG
env var → local then global
target-org
config, and
errors (
NoDefaultEnvError
) if none is set
— it never auto-picks among your connected orgs. That default may be an unrelated dev/scratch org, so an omitted
-o
is either wrong-org or a hard failure. Never omit it.
The user may have many authenticated orgs.
Run
sf org list
and, if the intended host org is ambiguous or not provided, ask the user which alias/username to use. Do not guess.
Verify the chosen org is
Connected
in
sf org list
before creating (stale refresh tokens / expired certs show as error states, not
Connected
).
Never invent credentials.
Host org must be entitled to create trial orgs
, and the invoking user must have sufficient access on it. The skill does
not
run a separate permission check — the
sf data create record
call (Step 1) is the definitive gate, and the same API enforcement is what a check would rely on. If the org is not entitled, the
SignupRequest
entity is not exposed and the create fails with a non-zero
status
and
name
/
code
of
NOT_FOUND
("The requested resource does not exist") or
INVALID_TYPE
("sObject type 'SignupRequest' is not supported"). This case is handled in Step 1's error table.
When it happens,
stop
(it is not retryable from the CLI) and report to the user: (a) the
raw CLI error as-is
— the exact
name
/
errorCode
and
message
the CLI returned, verbatim — and (b) that they should
reach out to Salesforce support
to get the org enabled for trial-org creation, then try again.
Do NOT diagnose or name which permission is missing
— just surface the raw error and point them to support.
Show more
Installs
1.0K
Repository
forcedotcom/sf-skills
GitHub Stars
956
First Seen
13 days ago
Security Audits
Gen Agent Trust Hub
Pass
Socket
Pass
Snyk
Pass