Solavel Solavel Docs

How Solavel works

docs/how-solavel-works.md

Who can use this: Everyone (start here) URL / Route: n/a Plan / feature gate: Always on

The three-layer model

Solavel runs on a strict three-layer mental model. Everything in the portal — every page, every permission, every menu entry — sits on exactly one of these layers, and changes on one layer never silently leak into another.

Layer Name What it controls Lives at
1 Personal Account Your name, email, password, profile /portal/settings
2 Workspace The whole company / client account: workspace name, contact details, domains, owners, defaults /portal/workspace/settings
3 Organization One company / branch / project inside the workspace: members, billing, apps, settings /portal/orgs/{org}/*

Whenever you click anything in the portal, ask yourself which of these three layers you're on. The breadcrumb in the topbar tells you:

  • Client Portal › Workspace Home → you're at the workspace level
  • Workspace › Organizations → still workspace-level (the list)
  • Organization › KingOS Co. › Members → org-scoped

Layer 1 — Personal Account

Your account is just you — one row in the users table that represents your login. You own it. Things tied to your account:

  • Name, email, phone, password
  • Email-change verification flow
  • Account deletion

You manage your account at Account Settings (/portal/settings). The only things you do here are personal. Workspace edits live somewhere else (see Layer 2).

If you sign out and your friend signs in with their own login, your personal account is untouched — different row in the users table.

Layer 2 — Workspace (a.k.a. the Client row)

A workspace is your company's container. In the database it's a row in the clients table; in the user-facing portal it's called a "workspace". One workspace holds:

  • A workspace name (your company name — what shows on invoices)
  • Workspace domains (e.g. acme.com, acme.io)
  • One or more organizations (branches / business units / projects)
  • One or more workspace owners
  • Team members (everyone with access to anything inside the workspace)
  • Billing & subscriptions

A workspace is created automatically the first time a user signs up. Other team members join your workspace by accepting an invitation you send.

You manage your workspace at Workspace Settings (/portal/workspace/settings). Only workspace owners can edit this page.

Layer 3 — Organization

An organization is one specific company / branch / project inside your workspace. In the DB it's a row in the organizations table keyed by client_id. Each org has:

  • Its own profile (name, type, registered address, logo, website)
  • Its own member roster (Owner / Manager / Member / Viewer)
  • Its own enabled apps (Solabooks, SolaProjects, etc.)
  • Its own subscription + billing
  • Its own settings

You can have one org or many. Most accounts have one. Multi-entity businesses use multiple — each entity is an org. The sidebar's Organization section reflects whichever org you've selected in the sidebar switcher.

The two account types

A team member belongs to your workspace one of two ways. This is the account type model — pick the right one when you invite someone.

🏢 Company account

For employees using your company email. You own their account inside your workspace — meaning:

  • They were invited with a company-domain email (name@acme.com)
  • Their account belongs to your workspace
  • You can manage their Workspace builder capability (see Workspace builder)
  • They use your workspace as their primary home

🤝 Independent account

For contractors, accountants, freelancers, partners — anyone using their own email at their own domain. They own their own account, not you. You only manage:

  • Their org-scoped role inside organizations you've added them to
  • Their project access inside those orgs

You can't touch their global account, their personal portal, or anything outside the orgs you've explicitly given them access to.

See Account types for a deeper dive.

Organization roles vs portal capabilities

This is the most common confusion point. There are two separate sets of capabilities:

Per-org role

What someone can do inside one specific organization. Set when you invite them or on the team-edit page:

  • Owner in Org A → manages everything in Org A only
  • Manager in Org B → manages team and apps in Org B only
  • Member in Org C → uses Org C, no management rights

Per-org role is per-org. The same person can be Owner in Org A and Member in Org B — they get full Owner rights in A and only viewer rights in B.

Account-level portal control (Workspace builder)

What a Company employee can do across the whole workspace — specifically, can they create new organizations under your workspace? There's exactly one toggle: Workspace builder. Independent accounts never get this toggle.

See Workspace builder.

Where things live

The portal sidebar mirrors the three-layer model:

WORKSPACE
  Home                  ← layer 1+2: greeting + apps launcher
  Organizations         ← layer 2: list of orgs in your workspace
  Team                  ← layer 2: roster of everyone in the workspace
  Workspace Settings    ← layer 2: edit the client row (owners only)

ORGANIZATION  (when an org is selected)
  Overview              ← layer 3
  Members               ← layer 3
  Projects              ← layer 3
  Billing               ← layer 3

ACCOUNT
  Account Settings      ← layer 1: personal profile
  Reports               ← cross-cutting; respects your access
  Documentation         ← these docs

The sidebar's Workspace section is workspace-scoped — clicking those links never depends on which org you've selected. The Organization section only appears when an org is selected, and those links DO depend on that selection.

What this means for security

The three layers are enforced everywhere:

  • Personal: only you can change your own name/email/password
  • Workspace: only client_owner role users can edit Workspace Settings, including the workspace name and company domains
  • Organization: each per-org check (manage team, settings, billing) reads the pivot role for that specific org

A Manager in Org A who is just a Member in Org B sees the "Manage team" affordance in A and not in B — automatically. No need to think about it.

Where to go next

Source: docs/how-solavel-works.md ← All documentation