Operatoren

Mandantenverwaltung für Operatoren

Bedienen Sie die Zugriffs-Oberfläche des Operators – wählen Sie die Kontogrenze, und bearbeiten Sie dann Mitglieder, Berechtigungen, Workspace-Ziele, Abrechnungsrichtlinie, SSO und Onboarding-Nachweise von einem einzigen, von Console verwalteten Arbeitsplatz aus.

Plattform-OperatorenPlattform-AdministratorenKunden-Administratoren

Zuletzt aktualisiert 18. Juni 2026

Wozu die Zugriffs-Oberfläche dient

Die Operator-Oberfläche unter /tenants trägt in Console den Titel Zugriffsoperationen, und der Arbeitsbereich darin ist der Kunden-Betriebsarbeitsplatz. Es ist eine einzige von Console verwaltete Route, auf der Plattformteams einmal eine Kontogrenze wählen und dann die gesamte Bereitstellungsschleife ausführen: Zugriffs- und Identitätsbereich, Mitglieder und Berechtigungen, Workspace-Ziel-Routing, Abrechnungsbereitschaft, persistente Umgebungen, Shared-Drive-Nachweise und Nutzungs-Showback.

Dieselbe Route zeigt Kunden-Administratoren eine Self-Service-Ansicht, damit sie ihren Zugriff bestätigen, SSO-Details übermitteln, die Onboarding-Checkliste abarbeiten und ihr Team einladen können. Die Beschriftungen und verfügbaren Aktionen ändern sich je nach Ihrer Rolle: Plattform-Operatoren und -Administratoren sehen kundenübergreifenden Support und genehmigte Einrichtungsarbeit, während Kunden-Administratoren nur ihr eigenes Konto sehen.

Nutzen Sie sie als Startkontrolle. Genehmigen Sie die Kontogrenze, das Abrechnungs-Gate, den Mandantenzugriff, das Ziel-Routing und die Nutzungsübergabe, bevor ein Kunde mit dem Erstellen von Workspaces beginnt.

Wählen Sie zuerst den Bereich

Bestätigen Sie immer den abrechenbaren Kunden, den Mandanten und den Mitgliederbereich, bevor Sie etwas ändern. Die meisten Aktionen sind kundenbezogen und erzwingen den ausgewählten Kunden, sofern einer vorhanden ist. Führen Sie auf einem neuen Cluster zuerst den Bootstrap und die Bereichsprüfung aus – sie beantwortet, als wer Sie angemeldet sind, welches Kundenkonto Sie verwalten, wo Workspaces ausgeführt werden und ob die Nutzung diesem Kunden zugeordnet werden kann – bevor Sie nachgelagerte Workspace- oder Abrechnungsabläufe testen.

Wenn die SSO-Zugriffsbeschriftungen leer sind, wissen nachgelagerte Seiten wie Analytics möglicherweise nicht, welcher Kundenbereich zu verwenden ist. Treten Sie über SSO erneut ein, bevor Sie die Workspace-Erstellung testen.

Unter-Tabs über den Arbeitsplatz hinweg

Der Kunden-Betriebsarbeitsplatz gruppiert seine Arbeit in Unter-Tabs entlang des oberen Rands der Oberfläche. Bewegen Sie sich während eines Launches ungefähr in dieser Reihenfolge durch sie hindurch.

Die Overview-Spuren spiegeln die Betriebsschleife wider: Kundenzugriff, geprüfte Änderung, QA-Nachweis, Kandidatenumgebung, Promotion und Abrechnungsprüfung. Schnellaktionen in der Overview öffnen Customers, Members, CI & Review, Environments, Shared Drive, Abrechnungsrichtlinie, Analytics und Audit-Verlauf.

Aktionsverfügbarkeit (die CRUD-Karte)

Das Abzeichen CRUD-Karte zeigt an, welche Erstellungs-, Aktualisierungs- und Löschpfade in der aktuellen Sitzung erreichbar sind und warum die übrigen es nicht sind. Lesen Sie es, wenn eine Aktion zu fehlen scheint. Beispielsweise erklärt es, dass Kundenkonten noch keine Löschroute haben – verschieben Sie den Lebenszyklus stattdessen auf gesperrt, Offboarding oder geschlossen – und dass einige Aktionen operatorgebunden sind, weil sie Abrechnung, Zuordnung oder die Kontogrenze steuern.

Einige Einträge, die man kennen sollte:

• Kundenkonto – nur für Operatoren, da der Kontodatensatz Abrechnung, Lebenszyklus und Zuordnung steuert. Kunden-Administratoren können Onboarding-Daten übermitteln, aber den abrechenbaren Datensatz nicht verändern.
• Members – Erstellen, Aktualisieren und Löschen erfordern Mandantenadministrator-Rechte; kundenbezogene Routen erzwingen den ausgewählten Kunden.
• Archibot-API-Schlüssel – im Kundenübergabeschritt verfügbar. Rohe Geheimnisse werden einmal angezeigt.
• Notifications – Kunden-Administratoren können ihren Benachrichtigungsverlauf lesen; der Versand bleibt operatorgebunden.

In-App-Hilfe

Jedes Panel trägt ein kontextbezogenes Hilfesteuerelement. Die Aktion Zugriffsoperationen erklären öffnet einen Dialog, der die vier Einrichtungsfragen und ein leicht verständliches Glossar wiedergibt: Ein Kundenkonto ist das abrechenbare Unternehmen, ein Mandant ist der Anteil am Console-Zugriff für dieses Unternehmen, ein Workspace-Ziel ist der Laufzeit-Cluster, auf dem Workspaces ausgeführt werden, und ein API-Schlüssel ist die Art und Weise, wie Archibot oder Automatisierung die kundenbezogene API aufruft. Der Dialog ist schreibgeschützter Kontext; das Schließen bringt Sie in denselben Bereich zurück. Verwenden Sie ihn, wenn Sie unsicher sind, ob eine fehlende Beschriftung oder ein leerer Bereich einen nachgelagerten Test blockiert.

Customers- und Onboarding-Tabs

Öffnen Sie den Unter-Tab Customers, um ein einzelnes Konto zu bearbeiten. Jeder Kundendatensatz trägt seinen eigenen Tab-Streifen:

• Profile – Kontoidentität.
• Plan – Lebenszyklus, Standardwerte und Servicestufe.
• Onboarding – Checkliste und Lebenszyklusverlauf.
• Billing – Abrechnungsprüfung und Preisrichtlinie.
• API – kundenbezogener API-Zugriff.

Der Onboarding-Tab öffnet eigene Unter-Tabs: Details (Kontokontext und Kontakte), SSO setup (IdP-Metadaten teilen oder prüfen), Checklist (der gemeinsame Launch-Datensatz), Lifecycle (Statusverlauf) und Notifications (dauerhafter Benachrichtigungsverlauf). Checklistenstatus und -notizen werden zum gemeinsamen Launch-Datensatz statt zu E-Mail oder Chat über Nebenkanäle.

Mitglieder und Berechtigungen

Im Unter-Tab Members können Operatoren Mitglieder innerhalb des ausgewählten Mandanten einladen, erstellen, aktualisieren, übertragen, deaktivieren und entfernen. (Kunden-Administratoren können einladen, erstellen, aktualisieren, deaktivieren und entfernen, aber nicht übertragen.) Verwenden Sie den Mandantenadministrator sparsam – die meisten Benutzer sollten Mandantenmitglieder sein, sofern sie nicht Einladungen oder Onboarding-Nachweise verwalten.

Der Unter-Tab Permissions öffnet den Editor Berechtigungsrichtlinien, der rollenabgeleiteten Zugriff, benutzerdefinierte Funktionsberechtigungen und Meta-Berechtigungen für jede Mitgliedschaft im ausgewählten Bereich festlegt.

Bearbeiten Sie den Editor in drei Schritten:

1. Verwenden Sie Richtliniensteuerung und Filter und Suche, um die Liste einzugrenzen, und wählen Sie dann ein Mitglied aus. Die Metrikkacheln (Rollenvorlagen, Benutzerdefinierte Richtlinien, Meta-Gewährungen, Administratoren) zeigen, wie der Bereich verteilt ist.
2. Wählen Sie im Mitgliedsrichtlinien-Editor den Richtlinienmodus. Rollenvorlage berechnet effektive Berechtigungen aus der ausgewählten Rolle und dem Status; Benutzerdefinierte Gewährungen speichert Funktions- und Meta-Berechtigungsarrays direkt in der Mitgliedschaft.
3. Wenden Sie eine Voreingestellte Gewährung als Startpaket an, passen Sie einzelne Gewährungen in der Funktionsmatrix an und wählen Sie dann Richtlinie speichern. Verwenden Sie Auswahl löschen, um ohne Speichern zurückzugehen.

Voreingestellte Gewährungen bieten ein bekanntes Paket, das Sie anpassen können:

• Mandantenadministrator – vollständige Mandanten- und Kundenverwaltung mit kontrollierter Delegation.
• Workspace-Leiter – Workspace-Lebenszyklus, Shared-Drive-Schreibzugriff und CI-Review-Verwaltung.
• Abrechnungsmanager – Analytics, Rechnungen, Ausgabenobergrenzen und Ressourcenpreise ohne Workspace-Kontrolle.
• Auditor – schreibgeschützte Sichtbarkeit über alle Operationen hinweg plus Audit-Exportbefugnis.

Meta-Berechtigungen steuern, wer Rollen delegieren, Berechtigungen gewähren oder widerrufen, Ausnahmen genehmigen, Richtlinienvorlagen verwalten, Support-Zugriff genehmigen, Audit-Nachweise exportieren oder eine Break-Glass-Erhöhung genehmigen darf. Gewähren Sie diese nur Mitgliedschaften, die die Zugriffsrichtlinie verwalten. Jede Funktionsgewährung wird nach stabiler Berechtigungs-ID gespeichert, sodass die künftige Backend-Durchsetzung dieselbe Richtlinie verwendet.

Workspace-Ziele und Standardwerte

Create Workspace kann Workspaces für ein Konto erst routen, wenn ein Workspace-Ziel angehängt ist, hängen Sie also ein Ziel vor der Workspace-Erstellung durch den Kunden an. Im Unter-Tab Targets bestätigen Sie die Workspace-Laufzeit-URL, den Ziel-Authentifizierungsmodus, die Vorlagen-Aliase und die unterstützten Git-Anbieter. Vorlagen-Aliase halten die für den Kunden sichtbaren Namen stabil; Service-Token-Felder an Zielen bleiben nur für Operatoren.

Verwenden Sie Workspace-Standardwerte, um die Werte auf Organisationsebene festzulegen, mit denen Create Workspace für diesen Kunden beginnen sollte.

Abrechnung und Ressourcenpreise

Der Billing-Tab deckt die Abrechnungsbereitschaft, die Stripe-Übergabe und die Ressourcenpreisrichtlinie ab. Der Abrechnungsstatus ist das Workspace-Erstellungs-Gate: Erfassen Sie den Zahlungsweg und markieren Sie das Konto als testgenehmigt oder verifiziert, bevor der Kunde Workspaces erstellt.

Die Ressourcenpreisrichtlinie überlagert die Bereitstellungsstandardwerte für die Analytics- und Überschreitungsabrechnung eines einzelnen Kunden. Das Panel zeigt die Richtlinienquelle, wie viele Schlüssel für den Kunden explizit festgelegt sind und die Basis-Standardschlüssel aus der Bereitstellungskonfiguration. Überschreiben Sie Kundenbedingungen hier nur, wenn ein Angebot, ein Serviceplan oder eine Unternehmensvereinbarung andere Kontingente oder Tarife verwendet, und wählen Sie dann Richtlinie speichern.

Geschätzte Preisvoreinstellungen bieten Launch-Ausgangspunkte, die Sie vor der Angebotserstellung anpassen können:

• Pilot – Anfangskontingent für ein Implementierungsteam, das CI, Review, QA und einen kleinen Shared Drive validiert.
• Team – Arbeitskontingent für ein aktives Kundenteam mit wiederholten Review-/QA-Zyklen und mäßiger Shared-Drive-Nutzung.
• Enterprise – größeres Kontingent für teamübergreifende Rollout-Planung, intensives QA und größeren persistenten Umgebungsspeicher.

Verwenden Sie Von Bereitstellungsstandardwerten starten, um den Editor zurückzusetzen. Erfassen Sie die Versionsbezeichnung des Preismodells für das Angebot oder die Richtlinienrevision. Stripe bleibt maßgeblich für Rechnungen, Zahlungen und Umsatzdatensätze – Console-Preiseinträge sind Operator- oder Kundenbedingungen, keine Anbieter-Payloads, und Stripe-Rechnungsereignisse aktualisieren den Zahlungsverlauf automatisch.

SSO-Einrichtung

Kunden-Administratoren übermitteln IdP-Typ, Domänen, Claims, Gruppen, Callback-URLs und Testbenutzer im Tab SSO setup, damit ISM den Zugriff sicher zuordnen kann. Für OIDC sammeln Sie Discovery-URLs; für SAML sammeln Sie Metadaten-URLs und Callback-Validierungsdetails. Operatoren prüfen die übermittelten Metadaten im selben Tab. SSO-Zugriffsbeschriftungen stammen vom Identitätsanbieter und bestimmen, welche Übersicht, welche Einrichtungsaktionen und welchen Kundenbereich Console offenlegt.

Halten Sie die zwei Notizpakete getrennt

• Vom Kunden übermittelte Details und ISM-Launch-Kontext sind für den Kunden sichtbar. Verwenden Sie sie für Kontext, den der Kunde mit ISM prüfen kann.
• Interne Operator-Notizen sind nur für ISM und sollten nicht in kundenbezogenen Onboarding-Antworten erscheinen.

Halten Sie in jedem Feld – ob für den Kunden sichtbar oder intern – Anmeldedaten, Zahlungsdetails, private Schlüssel und Einladungslinks heraus. Onboarding-Lebenszyklus und Benachrichtigungsverlauf sind dauerhafte Datensätze; der E-Mail-Versand bleibt hinter dem Benachrichtigungsabsender gesperrt.

Verwandte Leitfäden

• Zugriffsrollen für die Rollengrenzen, die diese Oberfläche durchsetzt.
• Einrichtung für Kunden-Administratoren für den kundenseitigen Self-Service-Pfad.
• Operations-Center für Live-Signale zu CI, QA, Bots und Kapazität.
• Persistente Umgebungen und CI Review für die Spuren von Review bis Promotion.
• Nutzung und Abrechnung dafür, wie Showback und Stripe-Datensätze auf die hier festgelegte Preisrichtlinie treffen.