Workspace Management
Manage workspace identity, roles, feature availability, and operational ownership.
Use this page when you change team access or ownership, adjust feature availability, or support customer accounts. For first-time setup and the role table, start with Workspace Setup.
Operating Model
Workspaces are the boundary for content, commerce, community, events, and integrations. Keep workspace changes tied to a named owner and a launch or support reason.
| Area | Owner to confirm | Check before changing |
|---|---|---|
| identity | workspace owner | workspace name, slug, domain, and support contact |
| roles | tenant-admin | least-privilege access for every user |
| features | product or operations owner | plan availability and readiness blockers |
| credentials | technical owner | key rotation, CORS, and webhook receivers |
| billing | finance or owner | active subscription and payment status |
Select the intended workspace before changing workspace records. A super-admin must also select a workspace before updating or deleting; a missing selection is denied.
When a settings editor asks you to select a Workspace, open the left menu and choose the Workspace to edit. On read-only pages, check the displayed Workspace name. If the environment is unavailable, use Open environment selection menu in the page body to open the menu and choose a ready environment.
Change Flow
Confirm the workspace record
Check that the workspace name, slug, and ownership metadata match the workspace you intend to operate.
Review role assignments
Give each operator the role from Access Roles with the least access their work needs. Confirm the assignment on this workspace; membership in another workspace is not enough.
Align features with the plan
Enable only features allowed by the current plan, then assign an operating owner for each enabled feature.
Re-run readiness checks
After access, feature, credential, or billing changes, run readiness checks before treating the workspace as launch-ready.
Invite teammates
A Live workspace tenant-admin or super-admin can invite teammates in Console → Settings → Project → Project team → Invite teammate.
- Enter an email and choose one Live role and one Sandbox role. Both workspaces default to Workspace Viewer. Change each workspace separately or set one to No access. When there is no Sandbox, choose a Live role only.
- Select Invite teammate. The saved invitation appears under Pending invitations, with its roles and expiry.
- The recipient opens the email link, signs in or signs up with the same email address, and explicitly accepts. If you sign up with email and password, complete the signup verification email first.
An already verified account can accept through a valid invitation link without another verification email. Sign in with the email address that received the invitation. Complete two-step verification first when required.
Invitations expire after seven days. Select Revoke invitation to prevent acceptance through that link. Inviting the same email again updates the roles and expiry and expires the previous link. If the email could not be sent, invite the same email again to resend.
A Project can have at most 20 pending invitations. If there are too many requests, try again later. For an existing Project member, check roles in the member list.
Membership And Ownership Changes
When a Live tenant-admin creates or resets Sandbox, the executor and owner receive tenant-admin on the new Sandbox. Reset also carries the previous Sandbox members' roles; the executor keeps existing roles alongside admin access. Other Live-only members are not added automatically. If the resulting membership exceeds the Sandbox member cap or processing fails, the entire reset is canceled and the previous Sandbox remains current. A super-admin receives no separate membership solely for executing the action. If the member cap blocks reset, remove unneeded members from the current Sandbox in the Project team panel, then retry reset.
A tenant-admin manages membership only for workspaces where they hold that role. Select the intended active workspace before writing; a missing, stale, or unauthorized selection must be corrected before retrying. A tenant-editor or tenant-viewer cannot grant themselves admin access.
Only the current workspace owner or a super-admin can transfer ownership. The recipient must already be a member; a completed transfer also grants tenant-admin without removing their existing roles. Use the ownership transfer action, rather than editing owner metadata. Before removing an operator who owns workspaces, transfer those workspaces first.
Customer support actions below apply to customer accounts, not Console operator membership. For app-side sign-in and identity lookup, use the Customers task guide.
Feature Guardrails
Plan-by-plan feature availability lives on Feature Planning — enable only what the current plan allows.
Do not enable customer-facing features unless support, moderation, and credential ownership are assigned.
Manual Customer Registration
Use Add customer on the customer list to create a customer record with a name and an optional email and phone number. Only admins of the selected workspace and super-admins can add customers. If the active workspace changes in another tab while the registration form is open, registration is rejected; check the current workspace, refresh the page, and try again.
A registered customer has no password. When the customer signs in with an email code or social login for the same email, they reach this record and keep its existing orders and details. A mistyped email lets that address owner reach the record, so check it carefully. A customer whose email already exists is not added again.
If the creation outcome could not be verified, the customer list refreshes. Check for the name you entered before adding the customer again.
Customer Suspension
The Account & Security tab in the customer edit view shows the current suspension state. Only super-admins can use Suspend account or Lift suspension in the document controls to change it. Saving the customer form never changes the suspension state.
A suspension can be lifted only after session revocation finishes.
If unsuspend returns 409, retry after processing finishes. If it persists,
contact support.
Customer Consent
For direct customer signup, the workspace collects required legal acknowledgement and keeps its own evidence. Customer acceptsTos and tosVersion are workspace self-reports.
Review server-recorded consent history from hosted signup and reconsent in the Admin Panel under Customers → customer detail → Privacy & Consents. Select a workspace with Customers enabled; a tenant-admin or super-admin with read access can open the list filtered to that customer. Keep evidence collected during direct signup separately.
Hosted required consent defaults off. Hosted consent required is turned on by the platform operator on request; contact support. Current terms and privacy-policy versions and valid terms links for enabled OAuth clients must be configured before activation.
When enabled, hosted password, email-code, and social login compare the customer’s latest receipt with the workspace’s current versions before issuing an authorization code. A missing or different version requires acknowledgement of the current documents; acceptance appends a new receipt. Direct login and already-issued session refresh remain outside this gate. With the setting off, existing login behavior is preserved.
Writing Your Privacy Policy
When you run a site on 01 SOFTWARE, you delegate the processing of your members' and purchasers' personal information to 01 SOFTWARE. Include the following in your site's privacy policy. This is writing guidance, not legal advice.
- Processor: Yeongwon (01 SOFTWARE), which operates the site system and stores its data.
- Sub-processors and international transfers: Copy the providers that apply to the features your site uses from Article 6 of the 01 SOFTWARE Privacy Policy, and link to it. If you do not use video or AI features, you can omit those providers.
- How to refuse and its effect: Explain how members and purchasers can ask your site to refuse international transfers, and which services are limited if they do. 01 SOFTWARE acts on your instructions.
- Payment providers: List payment providers you contract with directly, such as Toss Payments or PortOne, yourself.
- Withdrawal and deletion: For what is deleted on self-withdrawal and when, see Customer Self-withdrawal.
Customer Self-withdrawal
Customers with a local password can reauthenticate and immediately archive
their own account through the SDK. An incomplete, trialing, active, or
past_due membership blocks withdrawal, including a scheduled cancellation
until the status ends when mode is omitted. That legacy call does not cancel memberships automatically.
Customers without local password material, including social-only accounts, can confirm withdrawal with a one-time code sent to their stored email. The code is bound to the same refresh-family session (preserved across refresh) and expires after 10 minutes. No new terms acknowledgement or login session is required.
Explicit now and scheduled modes use the reservation lifecycle: stop renewal,
keep existing entitlement until its fixed deadline for scheduled withdrawal,
and end entitlements before account archival. Reauthenticated cancellation never
restarts renewal. See the SDK withdrawal results and receipt flow.
The account records its withdrawal time and a structural audit entry, and existing archive session revocation applies. Withdrawal has no recovery period: right after it is recorded, the account's personal data (name, email, phone, saved addresses, profile, and other account data) is erased with the same scope as the operator erasure action. If that erasure fails, the withdrawal still stands and an automatic retry finishes the erasure within 120 hours.
Orders, payments and membership charges remain, including the customer details captured in order records. Their retention is set separately and is not part of this erasure.
A withdrawn account cannot be restored, including while its erasure is pending (409). After erasure the email is free: signing up again with it creates a new customer that is not connected to the earlier orders, memberships or groups.
Management IP Allowlist
In Settings → Workspace Access, a tenant-admin can enable a management IP allowlist for the selected Live workspace (or a workspace without a Project). Enter one IPv4/IPv6 address or CIDR per line, up to 100 entries. A Sandbox follows its Project’s Live policy; change the list on Live.
Include your current public fixed IP or VPN network before saving. Save with a fresh six-digit authenticator code; the existing MFA policy controls when that proof is required. Changes apply from the next protected request.
If another administrator changed the policy, reload and review before saving again. After an uncertain network result, reload to confirm the saved policy.
When enabled, the policy restricts Console sessions and personal PATs, including CLI requests. Web requests use the original verified source. An unknown source is denied; a policy-check outage is denied until it can be retried.
Hosted MCP management requests are blocked because their operator network cannot be verified. Use Console or a PAT from an allowed network instead.
Service keys, storefront/customer/public APIs and internal jobs are outside the policy. Global login is unchanged. The policy cannot recall data already returned or revoke an external app’s independent session or direct URL; a new embedded app launch is still checked against workspace access.
Platform super-admin sessions and their personal PATs are exempt from the IP restriction and retain existing MFA and audit controls. If locked out, ask a platform super-admin to correct the policy using the existing settings permissions, with the recovery reason recorded in the audit. There is no separate recovery role.
Leaving the policy unset or disabled preserves existing access. Policy changes are audited atomically. Access-denial observations are best effort for Live and standalone workspaces; view recorded entries, denials and policy changes in Security history.
Next Actions
- Set the base workspace state in Workspace Setup.
- Choose the launch scope in Feature Planning.
- Validate blockers in Launch Readiness.