Organizations

Every resource in Norcube — a LangSync namespace, a Backup datasource, a DomainRadar watcher — belongs to an organization. Permissions, billing, and limits are all organization-scoped, never user-scoped. Your account is just the key; organizations are the rooms.

Your default organization

Signing up creates one automatically, with you as its only member and full access. Solo users may never need another.

Reasons to create more:

• Separate clients. Agencies isolate each client's data, access, and invoice in its own org.
• Separate environments. A staging org for experiments, a production org that stays clean.
• Separate cost centres. Usage and invoices never co-mingle across orgs.

URLs and slugs

Every dashboard URL is prefixed with the organization's slug:

app.norcube.com/<org-slug>/langsync/namespaces
app.norcube.com/<org-slug>/snapdb/datasources

Slugs are URL-safe identifiers — as the create dialog puts it: "Used in URLs. Only lowercase letters, numbers, and hyphens." — unique across all of Norcube, and fixed once created.

Create an organization

• Dashboard: the organization switcher (top of the sidebar) → Add organization. The dialog asks for the Organization Name and a Slug ("optional, auto-generated from name").
• CLI: nrc org create "Acme Inc" [--slug acme] — see CLI.

The new organization is immediately active with its own free-tier allowances and empty billing state. You get the org:owner role — full access to everything in it — and can invite others from there.

Switch organizations

Use the organization switcher in the sidebar (or nrc org use <slug> / nrc org switch in the CLI). The dashboard reloads under the other org's slug, and your session tokens are re-minted for that org behind the scenes. Membership in multiple orgs is normal; each keeps its own roles for you.

Membership

Who's in an organization — and what each member may do per product — is managed through invitations and IAM policies, documented on Members and IAM. Two facts worth knowing at the org level:

• Removing a member revokes their access to every product in the org at once; their account and other org memberships are untouched.
• There is no self-service "leave organization" button — ask an org admin to remove you.

Close an organization

Self-service closing exists for organizations where you are the only member. It lives on the account-deletion page (Account → Delete account), which lists such orgs with a Close organization button — because orphaned orgs are the thing account deletion must resolve first.

Closing an organization:

1. Finalises open billing — usage accrued so far is invoiced.
2. Cascade-deletes the org's data in every product — namespaces and translations, datasources and backup records (managed-storage files included), checks and watchers, quotas. The cascade is asynchronous and retries until every service confirms.
3. Anonymises the billing contact on the payment record, which is itself retained for tax compliance.

There is no undo. For multi-member organizations, or to hand an org over rather than close it, email [email protected] — the account-deletion page says it directly: "Need to keep the organization but hand it over? Email [email protected] and we'll arrange a transfer of membership."

Behaviour and edge cases

• Cross-org isolation is enforced in the token, not just the UI: an access token is minted for one organization_id, and every service checks it. Being a member of two orgs never lets data cross.
• Consistent 404s: referencing another org's resource by ID returns the same "not found" as a nonexistent one — existence isn't leaked.
• Billing is per-org: each organization has its own payment methods, invoices, budget, and credits.

Related

• Members and IAM — roles and invitations.
• Billing — the org's money side.
• Account deletion — why sole-member orgs must be closed or handed over first.