Organisationen
Der Top-Level-Account-Container. Alles in fastmon gehört zu genau einer.
Eine Organisation ist der oberste Container in fastmon. Sites, Mitglieder, Einladungen, API-Tokens, Notification Rules: alles hängt an genau einer Organisation, und nichts geht darüber hinaus.
Warum das wichtig ist
Über die Organisation trennt fastmon Kunden voneinander. Hier hängen Billing, Plan und Zugriffsrechte.
Die meisten Accounts haben genau eine Organisation. Mehrere lohnen sich vor allem für Agenturen und Partner; siehe partner-Plan unten.
Wann du sie anfasst
- Beim Setup. Das Allererste. Der „Account anlegen"-Flow legt eine Organisation für dich an.
- Team einladen. Per E-Mail, Rolle zuweisen, fertig.
- Plan kaufen. Plan hängt an der Organisation, nicht am User.
- AVV oder Rechnung anfordern. Die Organisation ist die Vertragspartei.
- Compliance-Review. „Wer hat Zugriff?" beantwortet sich auf Organisations-Ebene.
Was eine Organisation hat
| Feld | Typ | Hinweise |
|---|---|---|
id | UUID v7 | Stabiler Identifier. Verwendet in API-URLs (/v1/organizations/{id}/…). |
name | string | Menschenlesbar. Erscheint im Org-Switcher. |
plan | enum | beta, starter, pro, partner oder enterprise. |
members | Liste von { user_id, role } | Rollen: owner, member. |
Pläne
| Plan | Wann passt er |
|---|---|
beta | Early Access während Onboarding. Limitierte Quota. |
starter | Single-Produkt-Teams. Default-Retention. |
pro | Production-Teams. Höhere Retention. |
partner | Agenturen. Partner-Clients verwalten (Sub-Organisationen, die die Agentur für jemand anderen betreibt). |
enterprise | Custom-Limits, Custom-Retention, AVV. |
Der Plan steuert Features und Quotas. Welche Web Vitals erfasst werden, hängt nicht am Plan; gemessen wird in jedem Plan dasselbe.
Rollen
| Rolle | Darf |
|---|---|
owner | Alles. Sites, Mitglieder, Billing und Integrationen verwalten. Ownership transferieren. Organisation löschen. |
member | Dashboards ansehen, Analytics-Queries laufen lassen, eigene Notification Rules verwalten. |
Es gibt immer genau einen Owner. Transfer ownership übergibt ihn; der bisherige Owner wird Mitglied.
Häufige Szenarien
Ein Produkt, eine Org
Der Standardfall. Eine Organisation, eine Rechnung, mehrere Sites darunter (acme-marketing, acme-app, acme-docs).
Mehrere unabhängige Produkte
Wenn du zwei eigenständige Brands betreibst und Billing wie Zugriffe sauber trennen willst, leg zwei Organisationen an. Du kannst in beiden Mitglied sein.
Agentur, die Kunden-Sites betreibt
Hier passt der partner-Plan. Jeder Kunde ist ein Partner-Client: eine Sub-Organisation, die die Agentur verwaltet. Agentur-User sehen alle Clients, der Kunde nur sich selbst.
Häufige Überraschungen
- Der Org-Switcher ist nur ein UI-Knopf. API-Requests scopen über die URL (
/v1/organizations/{id}/…), nicht über irgendeinen aktiven Tab. - Mitglieder sind globale fastmon-User. Lädst du einen bestehenden User neu ein, wird der bestehende Account weiterverwendet, kein Duplikat.
- Sites können nicht zwischen Organisationen umziehen. Falls doch nötig: Support melden, das geht nicht per Self-Service.
Verwandt
- Sites: die Ressourcen, die einer Organisation gehören.
- API: Organizations-Endpunkte: programmatischer Zugriff.