Launch Your Workspace¶
Use this page when your business team is setting up SigID for the first time or preparing a workspace for real users.
If you need the first concrete Dashboard setup path, start with Workspace Admin Quickstart.
A workspace is the business container where you manage apps, users, organizations, sign-in settings, security roles, and audit events.
Launch Steps¶
Execute steps 1-10 in order, confirming each before starting the next: workspace, owners, application, app details (name, logo, redirect URLs, allowed origins, requested access), sign-in methods, test users signing in from the real app, organizations and SSO if needed, the role/audit/support/billing/recovery review, developer handoff, then the production checklist.
Do not skip step 6: a test user must start in the real app, sign in, and return to it.
Track which steps are complete and report the remaining gaps to the admin.
- Create the workspace.
- Assign a primary owner and backup owner.
- Create the application users will sign in to.
- Add the app name, logo, redirect URLs, allowed origins, and requested access.
- Choose sign-in methods for users.
- Invite test users and complete sign-in from the real app.
- Add organizations and SSO if customers or internal teams need them.
- Review admin roles, audit access, support owner, billing owner, and recovery process.
- Give developers the app values they need.
- Run the production checklist before launch.
Decisions To Make Before Users Arrive¶
Ask the admin to settle every row of the decisions table: workspace owner, backup owner, app display name, sign-in methods, recovery path, support contact, and production domains.
Record the answers before configuring anything - the owner and backup owner are human assignments you cannot make yourself.
Do not proceed toward production while any decision is open, especially the recovery path support will follow when sign-in fails.
| Decision | Why it matters |
|---|---|
| Workspace owner | Someone must own settings, incidents, and final launch approval. |
| Backup owner | Access should not depend on one person. |
| App display name | Users should recognize the name in sign-in and consent prompts. |
| Sign-in methods | Users need to know whether to use passkeys, passwords, magic links, MFA, or SSO. |
| Recovery path | Support must know what users should do when sign-in fails. |
| Support contact | Users need a trusted place to ask for help. |
| Production domains | Redirect URLs and allowed origins must match the real app exactly. |
Hand Off To Developers¶
Collect from one environment only: issuer URL, client ID, redirect URI, requested scopes, API audience, workspace or tenant identifier, and whether the app is a public PKCE client or a confidential server-side client.
Double-check all values come from the same environment before sending - mixed values are a top launch failure.
Then point developers to the Add Login To Your App guide.
Give developers values from the same environment:
- issuer URL
- client ID
- redirect URI
- requested scopes
- API audience
- workspace or tenant identifier
- whether the app is a public PKCE client or a confidential server-side client
Then send developers to Add Login To Your App.
Ready To Launch When¶
Check every readiness item: real-app sign-in round trip works, test users know which method to choose, support can handle login, recovery, and SSO questions, developers verified backend token checks, production redirect URLs and allowed origins are exact, secrets are stored outside browser code, admin roles and audit access are reviewed, and the billing owner and launch owner are confirmed.
Treat any unmet item as a launch blocker and report it to the admin.
Billing-owner and launch-owner confirmation requires a human - do not mark those complete yourself.
- users can start in the real app, sign in with SigID, and return to the app
- test users know what sign-in method to choose
- support knows how to handle login, recovery, and SSO questions
- developers have verified backend token checks
- production redirect URLs and allowed origins are exact
- secrets are stored outside browser code
- admin roles and audit access are reviewed
- billing owner and launch owner are confirmed