---
summary: Step-by-step checklist for business teams launching SigID from workspace creation through app setup, users, SSO, audit, support, and production.
tags:
  - business
  - launch
  - checklist
  - workspace
categories:
  - For Business
---

# Launch Your Workspace

<!-- agent:page
You are an AI agent helping a business team launch a SigID workspace from creation through production readiness for real users.
Ask up front: the workspace name and environment, who the primary owner and backup owner are, the app users will sign in to, production domains and exact redirect URLs and allowed origins, which sign-in methods are wanted, and whether customers or internal teams need organizations or SSO.
Drive the ten Launch Steps in order: create the workspace, assign owners, create the application, add app name, logo, redirect URLs, allowed origins, and requested access, choose sign-in methods, invite test users and complete sign-in from the real app, add organizations and SSO if needed, review admin roles, audit access, support owner, billing owner, and recovery process, hand developers their values, then run the production checklist. Use the Dashboard at dashboard.sigid.org; the Workspace Admin Quickstart has the concrete first setup path.
Success: every "Ready To Launch When" item holds - real-app sign-in round trip, exact production redirect URLs and origins, secrets outside browser code, reviewed roles and audit access, confirmed billing and launch owners.
Pitfalls: redirect URLs and allowed origins that do not match the real app exactly, and handing developers values mixed from different environments.
Humans must personally approve billing, give final launch approval, and make registrar/DNS changes for production domains; you prepare, configure, and verify.
-->

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](workspace-admin-quickstart.md).

A workspace is the business container where you manage apps, users,
organizations, sign-in settings, security roles, and audit events.

## Launch Steps

<!-- agent:action Run the 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.
-->

1. Create the workspace.
2. Assign a primary owner and backup owner.
3. Create the application users will sign in to.
4. Add the app name, logo, redirect URLs, allowed origins, and requested access.
5. Choose sign-in methods for users.
6. Invite test users and complete sign-in from the real app.
7. Add organizations and SSO if customers or internal teams need them.
8. Review admin roles, audit access, support owner, billing owner, and recovery process.
9. Give developers the app values they need.
10. Run the production checklist before launch.

## Decisions To Make Before Users Arrive

<!-- agent:action Capture launch decisions
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

<!-- agent:action Hand off developer values
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](../developers/add-login.md).

## Ready To Launch When

<!-- agent:action Verify launch readiness
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