Neuen Mandanten anlegen

Dieser Quickstart richtet sich an Systemadministratoren, die in Workspace einen neuen Mandanten anlegen. Nach Abschluss hat Workspace den Mandanten vollständig provisioniert. Sie können anschließend bewusst in den neuen Mandanten wechseln und dort mit der fachlichen Einrichtung beginnen.

Nutzen Sie diesen Ablauf nur im System-Mandanten. Prüfen Sie vor der Anlage den aktiven Kontext im App-Footer. Wenn Sie zunächst Mandanten, Mitgliedschaften und den Systemkontext voneinander abgrenzen möchten, lesen Sie Mandanten, Benutzerkonten und Systemsicht.

Voraussetzungen

Ihr Benutzerkonto benötigt:

  • Zugriff auf den System-Mandanten,
  • den Scope tenants:list für die Seite System > Mandanten,
  • den Scope tenants:create für die Create-Aktion und
  • entweder tenants:read oder system_diagnostics:read, damit Workspace den Provisionierungsstatus anzeigen kann.

Die Seite benötigt tenants:list. Der Create-Dialog erscheint nur im System-Mandanten und nur mit tenants:create. Fehlt die Aktion trotz der erwarteten Scopes, prüfen Sie zuerst den aktiven Mandanten im Footer.

Mandant anlegen

  1. Wechseln Sie in den System-Mandanten.
  2. Öffnen Sie System > Mandanten.
  3. Wählen Sie Erstellen.
  4. Geben Sie einen Namen ein.
  5. Tragen Sie optional einen Slug ein. Lassen Sie das Feld leer, wenn Workspace ihn aus dem Namen ableiten soll.
  6. Senden Sie die Anlage einmal ab.

Workspace nimmt den Auftrag an und zeigt seinen Fortschritt im geöffneten Dialog. Wiederholte Übertragungsversuche desselben Auftrags erzeugen keinen zweiten Mandanten. Schließen Sie den Dialog nicht, solange Sie den laufenden Status beobachten möchten.

Mandant mit nucli anlegen

Verwenden Sie diesen Ablauf für Skripte oder eine nachvollziehbare Kommandozeilenadministration. Das Profil system muss auf den System-Mandanten zeigen. Prüfen Sie zuerst Kontext und Scopes:

bash
nucli --tenant system whoami --scopes
nucli --tenant system system tenants list --json

Legen Sie für jeden neuen Anlagevorgang einen Idempotenzschlüssel fest. Nutzen Sie denselben Schlüssel erneut, wenn Sie genau diesen Vorgang nach einem unsicheren Verbindungsabbruch wiederholen müssen:

bash
nucli --tenant system system tenants create "Beispiel GmbH" \
  --slug beispiel \
  --idempotency-key <eindeutiger-schluessel> \
  --wait \
  --json

Lassen Sie --slug weg, wenn Workspace den Slug aus dem Namen ableiten soll. --wait verfolgt den vom Server veröffentlichten Provisionierungsstatus. Der Befehl errät keinen API-Pfad und bricht ab, wenn Discovery, Systemkontext oder Scopes nicht zum Vertrag passen.

Lesen Sie einen vorhandenen Mandanten und seinen Status bei Bedarf getrennt:

bash
nucli --tenant system system tenants get <tenant-id> --json
nucli --tenant system system tenant-provisioning status <tenant-id> --json

Der CLI-Ablauf war erfolgreich, wenn der Create-Befehl succeeded meldet und List oder Get den angelegten Mandanten bestätigt. nucli wechselt danach nicht automatisch den aktiven Mandanten.

Anlage mit einem MCP-Agenten steuern

Starten Sie nucli mcp serve mit dem Profil des System-Mandanten. Der Agent erstellt zunächst mit nucleus_system_tenant_create_plan einen lesenden Plan. Prüfen Sie darin Name, optionalen Slug und Idempotenzschlüssel. Erteilen Sie die Freigabe nur für genau diesen Plan.

Erst danach darf der Agent nucleus_system_tenant_create mit unveränderten Werten und approved: true aufrufen. Mit nucleus_system_tenant_provisioning_status verfolgt er die Provisionierung; nucleus_system_tenants_list und nucleus_system_tenant_read bestätigen das Ergebnis. Ohne ausdrückliche Freigabe oder ohne Idempotenzschlüssel sendet das mutierende Werkzeug keinen Anlageaufruf.

Der eingebettete Agentenablauf ist über folgenden Befehl verfügbar:

bash
nucli skills show tenant-administration

Der Skill kennzeichnet seinen versionsgebundenen Vertrag als tenant-administration/v1. Agenten dürfen weder API-Pfade ergänzen noch auf direkte Datenbankzugriffe oder numin ausweichen.

Provisionierung einordnen

Die Anlage ist erst abgeschlossen, wenn der Status succeeded erreicht ist. Die übrigen Statuswerte bedeuten:

StatusBedeutungNächster Schritt
pendingDer Auftrag wartet auf die Ausführung.Warten Sie auf die nächste Statusaktualisierung.
runningWorkspace richtet die Produktmodule ein.Lassen Sie den Dialog geöffnet.
retry_waitWorkspace wartet vor einem kontrollierten Wiederholungsversuch.Warten Sie; starten Sie nicht parallel dieselbe Anlage.
blockedEine Voraussetzung verhindert den Abschluss.Prüfen Sie den angezeigten sicheren Hinweis und beheben Sie die genannte Voraussetzung.
failedDie Provisionierung konnte nicht abgeschlossen werden.Prüfen Sie den sicheren Fehlerhinweis und wenden Sie sich bei Bedarf an den Betrieb.
succeededAlle vorgesehenen Provisionierungsschritte sind abgeschlossen.Wechseln Sie bei Bedarf über die angebotene Aktion in den neuen Mandanten.

Bei blocked, failed oder einem unbekannten Status bietet Workspace keinen Mandantenwechsel an. Dadurch gelangen Sie nicht versehentlich in einen nur teilweise eingerichteten Kontext.

Meldet ein blockierter Lauf den sicheren Fehlercode tenant_provisioning_target_drift, hat sich das vorgesehene Provisionierungsziel seit dem Start geändert. Workspace führt unter diesem alten Lauf keine weiteren Schritte aus und schreibt dessen Ziel nicht um. Wiederholen Sie deshalb weder die ursprüngliche Anlage noch denselben Idempotenzschlüssel als vermeintlichen Retry.

Für die Wiederaufnahme muss ein berechtigter Administrator einen neuen, ausdrücklichen Initialisierungs- oder Provisionierungslauf mit dem aktuellen Ziel starten. Verwenden Sie dafür nur die von der installierten Version angebotene Administrationsaktion. Fehlt diese Aktion, wenden Sie sich an den Betrieb, statt einen API-Pfad zu erraten oder den blockierten Lauf zu ändern.

Ergebnis prüfen

Die Anlage war erfolgreich, wenn:

  • der Dialog succeeded meldet,
  • die Aktion zum Mandantenwechsel verfügbar ist und
  • der neue Eintrag in System > Mandanten erscheint.

Der Wechsel erfolgt nie automatisch. Wählen Sie die angebotene Aktion erst, wenn Sie im neuen Mandanten weiterarbeiten möchten. Prüfen Sie nach dem Wechsel erneut den aktiven Mandanten im App-Footer.

Die Provisionierung richtet die standardmäßige Produktbasis ein. Sie ersetzt keine fachliche Go-live-Konfiguration.

Zur Produktbasis gehört die verwaltete Workflow-Bibliothek. Bei einem neuen Business-Mandanten legt Workspace die dafür erforderliche Auswahl an, sofern noch keine ausdrückliche Auswahl vorhanden ist. Die Provisionierung gilt erst als erfolgreich, wenn Workspace die verwalteten Standardworkflows eindeutig auflösen und kompilieren kann. Workspace aktiviert dafür keine globale Workflow-Definition und erzeugt keine tenant-lokale Kopie.

Nächste Schritte