HiveGrid-Wireframes/02 Wireframes/P2 Auth/WF-P2 Admin RBAC/WF-P2 Admin RBAC.md

kind, project, ticket, package, typ, status, subframe, canvas

kind	project	ticket	package	typ	status	subframe	canvas
wireframe-package	HiveGrid Screen Project	D-P2	WF-P2 Admin RBAC	Admin Flow	In Subframe	https://app.subframe.com/f023064a5ca0/flow/42c54a17-9c08-4db3-9306-1449f5b874e4/edit	WF-P2 Admin RBAC.canvas

WF-P2 Admin RBAC

Status: In Subframe
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/42c54a17-9c08-4db3-9306-1449f5b874e4/edit
Canvas: WF-P2 Admin RBAC.canvas
Stand: 2026-06-23

---

1. Kurzfassung

Dieses Paket plant die Admin-Flaechen aus D-P2 fuer Rollen, Berechtigungen und Mitarbeiter. Gruppen sind nach Produktentscheidung nicht Teil dieses Pakets.

Der wichtigste UX-Risikopunkt ist das sichere Bearbeiten von Rollen/Permissions. Reassign beim Deaktivieren wird fuer v1 bewusst in den Backlog gelegt.

---

2. Intent Check

Frage	Antwort
Welches Ticket/Modul ist betroffen?	D-P2 Auth / RBAC / Tenant Users
Was soll der Nutzer am Ende schaffen?	Mitarbeiter einladen/verwalten, Rollen zuweisen und Rollen/Permissions pflegen
Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation?	Admin-Paket mit Listen, Editoren und Modal-/Workflow-Zustaenden
Welche Planning-Quellen wurden geprueft?	D-P2, SCREEN-MAP §1 Auth-Screens, bestehende Settings-Routen roles-and-permissions
Was ist sicher im Scope?	Mitarbeiter/Rollen-Zuweisung, Rollen-Subpage mit Rechtebereichen, Einladungsmodal, einfache Deaktivieren-Bestaetigung
Was ist sicher nicht im Scope?	Gruppen, Plattform-Admin, Feature-Flags, Audit-Viewer
Gibt es Admin/Normalrolle-Unterschiede?	Ja, nur Admins duerfen diese Flaechen sehen/bearbeiten
Welche Annahmen sind noch unsicher?	keine fuer v1; konkrete Permission-Zuschnitte werden im Development finalisiert

---

3. Scope

Punkt	Inhalt
Ticket/Modul	D-P2 Auth
Nutzerrolle	Tenant-Admin
Admin-Variante	Vollzugriff auf Rollen, Permissions-Katalog und Mitarbeiter
Normale Rolle	Keine Berechtigung / kein Zugriff
Startpunkt	Settings -> Mitarbeiter
Ziel	Tenant-Team und Rechte verwalten
Haupt-Archetyp	A2 List + A5 Modal + A6 Settings
Bespoke-Anteil	nein
Out of scope	Gruppen, Audit, Plattform-Admin, Billing

---

4. Brainstorming

Flow-Frage

Wie schneiden wir RBAC so, dass es genug fuer Dev/Handoff ist, aber nicht zu einem riesigen Admin-Board wird?

UX-Varianten

Option	Beschreibung	Vorteil	Nachteil	Empfehlung
A	Settings-Bereich mit Tabs: Mitarbeiter, Rollen und Berechtigungen	kompakt, gut scanbar	mehrere Arbeitsmomente	genommen
B	Ein grosses Team-Admin-Dashboard	alles zentral	zu breit und schwer zu validieren	raus
C	Nur Mitarbeiter bauen, Rollen spaeter	schneller	D-P2-Luecke bleibt offen	raus
D	Gruppen als Teil des RBAC-Pakets	bildet D-P2 voll ab	fuer v1 zu viel und fachlich nicht benoetigt	raus

Entscheidung

Entscheidung	Status	Notiz
Settings-Struktur statt separatem Admin-Center	genommen	bestehende Route ist Settings -> Roles & Permissions
Gruppen raus	genommen	Gruppen werden in diesem Paket nicht gebaut
Startrollen	genommen	Zum Start gibt es nur die Systemrolle Admin; weitere Rollen legt der Admin selbst an
Rollen-Vorlagen	WIP	Beim Erstellen koennen spaeter Vorlagen angeboten werden, sind aber noch nicht final
Eigene Rollen anlegen und benennen	genommen	Rollen-Editor erlaubt Custom Roles
Rollen-Editor als eigener Arbeitsmoment	genommen	Permission-Bundles + Advanced brauchen Raum
Kein separater Berechtigungen-Tab	genommen	Berechtigungen sind fuer Admins Teil des Tabs Rollen und Berechtigungen
Einladung als Modal	genommen	A5, kein eigener Fullscreen noetig
Deaktivieren mit Reassign	Backlog	v1 macht nur einfache Deaktivieren-Bestaetigung
Keine-Berechtigung-Zustand dokumentieren	genommen	normale Nutzer duerfen Admin-Flaechen nicht sehen

Happy Path

1. Admin oeffnet Mitarbeiterliste.
2. Admin laedt Nutzer ein und weist eine oder mehrere Rollen zu.
3. Admin nutzt Admin als geschuetzte Systemrolle oder erstellt eine eigene Rolle mit eigenem Namen.
4. Wenn ein Nutzer deaktiviert wird, bestaetigt der Admin eine kurze Sicherheitsfrage.

Varianten / Branches

• Rolle anlegen: Name, Beschreibung und Permission-Bundles auswaehlen.
• Rolle bearbeiten: Permission-Bundles anpassen.
• Rolle loeschen: nur moeglich, wenn keine Mitarbeiter zugewiesen sind; sonst kleines Blocker-Modal und manuelle Umzuweisung.
• Nutzer deaktivieren: kurzes Confirm-Modal; Status wird danach Deaktiviert.
• Einladung laeuft ab oder wird erneut gesendet.
• Admin versucht letzten Admin zu deaktivieren.

Roadblocks

• keine Berechtigung
• letzter Admin
• Rolle in Benutzung
• Rollenname existiert bereits
• Einladung bereits vorhanden
• Reassign-Ziel fehlt nur spaeter relevant, Backlog

Meldungs-/Error-State-Brainstorming

Ereignis	UI-Form	Blockiert?	Bauen?	Copy/Notiz
Einladung gesendet	Toast	nein	nein	Erfolg
Einladung existiert	Inline/Modal-Hinweis	ja	nein	erneutes Senden anbieten
Rolle in Benutzung	kleines Blocker-Modal	ja	Nur dokumentieren	Loeschen erst nach manueller Umzuweisung moeglich
Rollenname existiert	Inline	ja	nein	Name muss eindeutig sein
Nutzer deaktivieren	kleines Modal	ja	ja	einfache Bestaetigung
Letzter Admin	Blocker	ja	pruefen	sicherheitskritisch
Keine Berechtigung	A7 State	ja	nein	wiederverwenden

---

5. Screen-Kandidaten nach Entscheidung

Kandidat	Warum eventuell noetig?	Erste Einschaetzung
Mitarbeiter & Rollen	zentrale Zuweisung von Rollen an User	Bauen
Einladung Modal	neuer Nutzer	Bauen/Wiederverwenden A5
Rollen-Dropdown in Mitarbeiterliste	direkte Rollenzuweisung und Sprung zum Tab Rollen und Berechtigungen	Nur dokumentieren
Mitarbeiter deaktivieren	einfache Sicherheitsbestaetigung	Bauen
Deaktivieren mit Reassign	spaetere Uebertragung offener Verantwortlichkeiten	Backlog
Rollen und Berechtigungen	Systemrolle Admin und eigene Rollen verwalten	Bauen
Rolle anlegen/bearbeiten	eigene Rollen anlegen/benennen und atomar Permissions setzen	In S02 loesen
Rechtebereiche im Tab Rollen und Berechtigungen	erklaert Berechtigungen im Kontext der Rolle	In S02 loesen
Rolle loeschen mit Ersatzrolle	verhindert Rechteverlust	Backlog
Letzter Admin blockiert	Sicherheitsblocker	Validiert

---

6. Rollen- und Permission-Vorschlag

Rollenmodell

Typ	Rolle	Zweck	Notiz
Systemrolle	Admin	Vollzugriff auf Mitarbeiter, Rollen, Workspace-Settings und kritische Admin-Funktionen	einzige sichtbare Systemrolle
Custom Role	frei benennbar	Admin legt eigene Rolle an	Name, Beschreibung, Bereich und Permission-Bereiche

Notiz: Es gibt in v1 keine sichtbaren vordefinierten Rollen ausser Admin. Vorlagen wie Geschaeftsfuehrer, Projektleiter, Verwaltung, Vertriebler, Kundensupporter oder Monteur koennen spaeter beim Erstellen einer Rolle angeboten werden, sind aber Work in Progress und nicht Teil der initialen Rollenliste.

Permission-Bundles fuer den Editor

Die folgenden Bundles sind nur ein Arbeitsgeruest fuer Planung und Wireframe. Sie muessen nicht vollstaendig vorgebaut werden; Development kann den finalen Rechtekatalog spaeter sauber ausmodellieren. Fuer das UI reicht in v1 ein konkretes Permission-Zeilenmuster im Rollen-Modal.

Bundle	Enthalt grob	Relevanz fuer v1
Basiszugriff	Dashboard/App betreten, eigene Daten sehen	direkt
Mitarbeiter	Mitglieder sehen, einladen, bearbeiten, deaktivieren	direkt
Rollen & Berechtigungen	Rollen ansehen, Rollen setzen, Custom Roles pflegen	direkt
Workspace Settings	Workspace/Account Settings sehen und bearbeiten	direkt
Abrechnung	Subscription, Rechnungen, Rechnungsdaten	direkt/teilweise
Audit & Sicherheit	Audit-Log sehen, sicherheitsrelevante Admin-Einsicht	direkt/teilweise
Integrationen/API	API Keys, Plugins, technische Anbindungen	direkt/teilweise
CRM/Kunden	Kunden/Firmen/Kontakte lesen/schreiben/admin	fachliches Modul, ggf. spaeter
Leads/Vertrieb	Leads, Angebote, Pipeline, Umsatzfelder	fachliches Modul, ggf. spaeter
Projekte/Auftraege	Projekte, Auftraege, Planung, Zuweisungen	fachliches Modul, ggf. spaeter
Aufgaben/Dateien	Tasks, Dokumente, Uploads, Freigaben	fachliches Modul, ggf. spaeter
Kommunikation/Support	Anfragen, Chat, Telefonie/Support-Kontext	fachliches Modul, ggf. spaeter

Rollen-Vorlagen WIP

Vorlage	Permission-Richtung	Status
Geschaeftsfuehrer	fast alles, inklusive Mitarbeiter, Rollen, Workspace Settings, Abrechnung, Audit	WIP, nicht in v1-Rollenliste
Projektleiter	Projekte/Auftraege, Aufgaben/Dateien, Team-Ueberblick, Mitglieder nur lesen	WIP
Verwaltung	Mitarbeiter lesen, Workspace/Account-Basis, Abrechnung/Rechnungen, Kunden-/Projekt-Ueberblick	WIP
Vertriebler	CRM/Kunden, Leads/Vertrieb, Angebote, eigene Pipeline	WIP
Kundensupporter	Kundenkommunikation, Supportfaelle, lesender Projekt-/Kundenkontext	WIP
Monteur	eigene/zugewiesene Auftraege, Aufgaben, Dateien, mobile Ausfuehrung	WIP

---

7. Grober Screen-Aufbau

Settings-Aufteilung

Entscheidung: Option A ist genommen. Das Paket lebt unter Settings -> Mitarbeiter. Darin liegen nur die Tabs Mitarbeiter und Rollen und Berechtigungen.

Option	Aufbau	Vorteil	Nachteil
A	Settings -> Mitarbeiter als Oberpunkt mit Tabs Mitarbeiter, Rollen und Berechtigungen	fuer Admins intuitiv und kompakt	technische Berechtigungen sind nur im Rollen-Kontext sichtbar
B	Settings -> Rollen & Berechtigungen als Oberpunkt mit Tabs Mitarbeiter, Rollen, Berechtigungen	passt zur bestehenden Code-Struktur	zu technisch und weniger kompakt
C	zwei Settings-Punkte: Mitarbeiter und Rollen & Berechtigungen	klare Trennung zwischen Menschen und Rechte-System	mehr Navigation, Rollen-Zuweisung springt zwischen Bereichen

Die technische Route kann spaeter weiterhin an die bestehende App-Struktur angepasst werden; fuer Wireframes und Navigation ist der sichtbare Einstieg Settings -> Mitarbeiter.

Validierungsreihenfolge

Wir validieren einzeln und legen erst danach Screen-Dateien/Canvas an.

1. S01 Mitarbeiterliste
2. M01 Mitarbeiter einladen
3. Rollen-Dropdown innerhalb S01 Mitarbeiterliste pruefen; D01 bleibt nur Dokumentation, kein eigener Subframe-Screen
4. M03 Mitarbeiter deaktivieren
5. S02 Rollen und Berechtigungen
6. M04A Rolle anlegen
7. M04B Rolle duplizieren
8. M02 Rolle bearbeiten
9. D03 Rolle in Nutzung blockiert

S01 Mitarbeiterliste

Ziel: Admin findet schnell Nutzer und kann Rollen/Status pruefen.

Layout:

1. Header: Mitarbeiter, kurze Beschreibung, Primaer-CTA Mitarbeiter einladen.
2. Tab-Leiste innerhalb Settings -> Mitarbeiter: Mitarbeiter, Rollen und Berechtigungen.
3. Toolbar:
   • Suchfeld: Name, E-Mail, Telefonnummer.
   • Filter Rolle als Multi-Select.
   • Filter Abteilung als Multi-Select.
   • Filter Status: Aktiv, Eingeladen, Deaktiviert.
   • Filter 2FA: Aktiv, Nicht eingerichtet.
   • Aktive Filter als Chips mit Alle zuruecksetzen.
4. Tabelle:
   • Mitarbeiter: Avatar, Name, E-Mail.
   • Abteilung.
   • Rollen als Dropdown/Select.
   • Status.
   • 2FA.
   • Aktionen: 3-Punkte-Menue rechts.
5. Empty/Filtered State:
   • keine Treffer fuer Suche/Filter.
   • Link/Button zum Filter zuruecksetzen.
6. Rollen-Dropdown:
   • zeigt aktuelle Rolle(n).
   • erlaubt direkte Rollenauswahl, sofern Admin die Berechtigung hat.
   • enthaelt Eintrag Rollen und Berechtigungen bearbeiten.
   • Rollen und Berechtigungen bearbeiten navigiert in den Tab Rollen und Berechtigungen unter Settings -> Mitarbeiter.
7. Zeilenaktionen:
   • rechts in jeder Tabellenzeile ein 3-Punkte-Menue.
   • enthaelt kontextabhaengig Einladung erneut senden, Deaktivieren, ggf. Profil oeffnen.

M03 Mitarbeiter deaktivieren

Ziel: Admin bestaetigt eine einfache Deaktivierung eines Mitarbeiters.

Layout:

1. Kleines Confirm-Modal aus der Mitarbeiterliste.
2. Headline: Mitarbeiter deaktivieren?
3. Inhalt:
   • Name und E-Mail des Mitarbeiters.
   • kurzer Hinweis, dass der Mitarbeiter danach keinen Zugriff mehr auf den Workspace hat.
   • Hinweis, dass der Mitarbeiter in der Liste mit Status Deaktiviert sichtbar bleibt.
4. Aktionen:
   • Primaer/Danger: Deaktivieren
   • Sekundaer: Abbrechen
5. Nach Erfolg:
   • Modal schliesst.
   • Toast Mitarbeiter wurde deaktiviert.
   • Tabellenstatus wechselt auf Deaktiviert.
6. Nicht in v1:
   • Reassign offener Verantwortlichkeiten.
   • mehrstufiger Workflow.

S02 Rollen und Berechtigungen

Ziel: Admin verwaltet Rollen als eigene Subpage innerhalb Settings -> Mitarbeiter, nicht als Modal aus der Mitarbeiterliste. Berechtigungen werden nur hier im Kontext der Rolle sichtbar.

Layout:

1. Header: Rollen und Berechtigungen, CTA Rolle anlegen.
2. Toolbar:
   • Suchfeld: Rollenname, Beschreibung.
   • Filter Typ: Systemrolle, Eigene Rolle.
   • Filter Permission-Bereich: z. B. Mitarbeiter, Abrechnung, Dateien, Aufgaben.
   • Filter In Nutzung: mit Mitgliedern / ohne Mitglieder.
3. Tabelle:
   • Rolle.
   • Beschreibung.
   • Typ: Systemrolle, Eigene Rolle.
   • Mitglieder: Avatar-Stack oder Anzahl.
   • Status: Aktiv, Pruefen.
   • Aktionen: 3-Punkte-Menue rechts.
4. Zeilenaktionen:
   • rechts in jeder Tabellenzeile ein 3-Punkte-Menue.
   • enthaelt Bearbeiten, Duplizieren, Loeschen.
   • bei Systemrolle Admin keine Loeschen-Aktion.
5. Rollen-Bearbeitung:
   • passiert in diesem Tab/Subpage-Kontext.
   • Rolle anlegen oeffnet M04A mit Basisdaten.
   • Bearbeiten oeffnet M02 direkt im grossen Permission-Editor.
   • Duplizieren oeffnet M04B mit vorausgefuellten Basisdaten.
   • das Modal ist nicht aus der Mitarbeiterliste heraus erreichbar, sondern nur aus Rollen und Berechtigungen.
6. Rechtebereiche:
   • werden beim Bearbeiten einer Rolle angezeigt.
   • keine separate Hauptnavigation.
   • optional mit Advanced-Einzelrechten als ausklappbare Details.
7. Loeschzustand:
   • wenn keine Mitglieder zugewiesen sind, kann eine Rolle geloescht werden.
   • wenn die Rolle noch genutzt wird, erscheint ein kleines Blocker-Modal.
   • Copy-Richtung: Diese Rolle kann nicht geloescht werden, solange Mitarbeiter zugewiesen sind.
   • Aktion: Verstanden; Admin weist Mitglieder danach manuell einer anderen Rolle zu.
   • Ersatzrolle/Bulk-Reassign bleibt Backlog.

M04A Rolle anlegen

Ziel: Admin klaert bei einer komplett neuen eigenen Rolle zuerst Name, Beschreibung und Bereich, bevor die atomaren Berechtigungen gesetzt werden.

Einstieg:

1. Rolle anlegen aus S02 oeffnet M04A mit leerem Formular.
2. Bearbeiten nutzt M04A nicht und springt direkt in M02.
3. Duplizieren nutzt M04A nicht, sondern M04B.

Layout:

1. Modal-Step ueber S02 Rollen und Berechtigungen, mit Schliessen-Icon.
2. Headline: Rolle anlegen.
3. Formular:
   • Rollenname als Pflichtfeld.
   • Beschreibung als optionales Textfeld.
   • Bereich/Kategorie als Select, z. B. Team, Verwaltung, Operativ.
4. Optionaler Bereich Vorlage verwenden:
   • nur als Work-in-Progress-Platzhalter.
   • Vorlagen sind keine Seed-Rollen und erscheinen nicht in der Rollenliste.
5. Footer:
   • Weiter zu Berechtigungen fuehrt zu M02.
   • Abbrechen schliesst den Modal-Step.

Subframe:

• M04A ist der bestehende Subframe-Screen fuer Rolle anlegen.
• Der Screen bleibt als Dialog/Modal-Step ueber S02 gedacht.

M04B Rolle duplizieren

Ziel: Admin nutzt eine bestehende eigene Rolle als Startpunkt, passt die Basisdaten an und landet danach im grossen Permission-Editor mit kopierten Berechtigungen.

Einstieg:

1. Duplizieren aus dem Zeilenmenue in S02 oeffnet M04B mit vorausgefuellten Basisdaten.
2. Rolle anlegen nutzt M04B nicht, sondern M04A.
3. Bearbeiten nutzt M04B nicht und springt direkt in M02.

Layout:

1. Modal-Step ueber S02 Rollen und Berechtigungen, mit Schliessen-Icon.
2. Headline: Rolle duplizieren.
3. Hinweisblock: Basisdaten und Berechtigungen werden aus der Quellrolle kopiert.
4. Formular:
   • Rollenname als Pflichtfeld, vorausgefuellt z. B. als Kopie von ....
   • Beschreibung als optionales Textfeld.
   • Bereich/Kategorie als Select.
5. Footer:
   • Weiter zu Berechtigungen fuehrt zu M02.
   • Abbrechen schliesst den Modal-Step.

Subframe:

• M04B ist der bestehende Subframe-Screen fuer Rolle duplizieren.
• Der Screen bleibt als Dialog/Modal-Step ueber S02 gedacht.

M02 Rolle bearbeiten

Ziel: Admin bearbeitet die Basisdaten und Berechtigungen einer vorhandenen oder gerade angelegten eigenen Rolle, ohne die Rollen-Subpage zu verlassen. Die Systemrolle Admin ist geschuetzt.

Einstiege:

1. Bearbeiten auf einer bestehenden Rolle oeffnet direkt den grossen Permission-Editor.
   • Der Admin landet sofort im Editor, oben im Bereich Rolle.
   • Rollenname, Beschreibung und Bereich/Kategorie bleiben dort weiterhin editierbar.
2. Rolle anlegen kommt aus M04A und uebergibt die Basisdaten in den Editor.
3. Duplizieren kommt aus M04B, mit vorausgefuellten Basisdaten und kopierten Berechtigungen.

Layout:

1. Sehr grosser Modal-Flow ueber dem Tab Rollen und Berechtigungen.
2. Modal kann jederzeit geschlossen werden.
3. Im Editor steht oben der Bereich Rolle:
   • Rollenname.
   • Beschreibung.
   • Bereich/Kategorie der Rolle, z. B. Team, Verwaltung, Operativ.
   • Typ als Information: Systemrolle oder Eigene Rolle; nicht frei umstellbar.
   • diese Daten koennen auch nach M04A/M04B weiterhin bearbeitet werden.
4. Linke Sidebar:
   • oben links sitzt die globale Suche, aehnlich Apple-Einstellungen.
   • darunter stehen die Bereiche als Navigation.
   • Beispiele: Rolle, Allgemein, Mitarbeiter, Rollen und Berechtigungen, Workspace Settings, Abrechnung, Audit & Sicherheit, Integrationen/API, Dateien, Aufgaben.
   • Klick springt zum jeweiligen Bereich im scrollbaren Modal.
5. Globale Berechtigungs-Suche:
   • Suchfeld links ueber der Sidebar.
   • durchsucht alle Berechtigungen/Rechtebereiche ueber alle Module hinweg.
   • filtert die sichtbaren Treffer bereichsuebergreifend.
   • Treffer bleiben ihren Bereichsueberschriften zugeordnet, damit Kontext erhalten bleibt.
6. Hauptbereich:
   • startet oben mit Rolle.
   • darunter folgen Allgemein und die weiteren Rechtebereiche.
   • die Bereichsueberschriften entsprechen den Eintraegen in der linken Sidebar.
   • Admin kann durch alle Bereiche nach unten scrollen.
7. Permission-Abschnitte:
   • jeder Bereich hat einzelne Zeilen mit Toggle-Switches, um Berechtigungen an- oder auszuschalten.
   • Bereich kann eine Kurzbeschreibung enthalten.
   • einzelne technische Rechte koennen als Advanced Details aufgeklappt werden, falls noetig.
8. Permission-Zeilenmuster:
   • eine Beispiel-Permission wird im Wireframe konkret vorgebaut.
   • Aufbau als Tabelle/Liste wie in der Referenz: links Setting/Permission, mittig Beschreibung, rechts Enable/Disable.
   • Beispiel-Ueberschrift: Mitarbeiter ansehen.
   • Beispiel-Beschreibung: Darf Mitarbeiterliste und Mitarbeiterprofile im Workspace lesen.
   • Control: Toggle-Switch An/Aus.
   • Wenn ein Recht Abstufungen braucht, kann spaeter Read-only/Bearbeiten als Detail/Advanced Control ergaenzt werden.
   • weitere Permissions koennen Development-seitig nach diesem Muster ergaenzt werden.
9. Footer:
   • Speichern.
   • Abbrechen.
   • ggf. Rolle loeschen als Danger Action.

8. Screen Validation Gate

ID	Screen/Zustand	Ist eigener Arbeitsmoment?	Neue Struktur/Entscheidung/Risiko?	Entscheidung	Begruendung
S01	Mitarbeiterliste	ja	ja	Validiert	Suche, Filter, Tabelle und Aktionen passen erstmal
M01	Mitarbeiter einladen	ja	ja	Validiert	Modal mit E-Mail, optional Name/Abteilung und Rollen
D01	Rollen-Dropdown in Mitarbeiterliste	nein	ja	Validiert	direkte Rollenauswahl; Bearbeiten fuehrt in Rollen und Berechtigungen
M03	Mitarbeiter deaktivieren	ja	ja	Validiert	kleines Confirm-Modal, kein Reassign
S02	Rollen und Berechtigungen	ja	ja	Validiert	Rollen-Tabelle nach Referenz, 3-Punkte-Menue, nur Systemrolle Admin
M04A	Rolle anlegen	ja	ja	Validiert	eigener Basisdaten-Step fuer neue Rollen vor dem Permission-Editor
M04B	Rolle duplizieren	ja	ja	Validiert	eigener Basisdaten-Step fuer duplizierte Rollen mit Quellrollen-Kontext
M02	Rolle bearbeiten	ja	ja, Permissions	Validiert	grosses Modal mit Sidebar, Ueberblick, globaler Suche und Rechte-Toggles
D03	Rolle in Nutzung blockiert	nein	ja	Validiert	Loeschen nur ohne Mitglieder; sonst kleines Blocker-Modal, Ersatzrolle/Bulk-Reassign im Backlog
V01	Letzter Admin blockiert	ja	ja, Sicherheitsblocker	Validiert	kleiner Blocker-State im jeweiligen Kontext

Copy-kritische Zustaende

Zustand	Bauen?	Warum / Copy-Entscheidung
Mitarbeiter deaktivieren	ja	kurzer Sicherheitsmoment
Letzter Admin blockiert	ja	kleiner Blocker-State im jeweiligen Kontext
Rolle in Benutzung	Nur dokumentieren	kleines Blocker-Modal; Ersatzrolle/Bulk-Reassign liegt im Backlog
Custom Role anlegen	ja	muss klar zwischen Vorlage und eigener Rolle unterscheiden

Blockierende Error States

Zustand	UI-Form	Primaeraktion	Sekundare Aktion	Inhalt/Copy-Richtung
Letzter Admin	Screen/Modal	weiteren Admin bestimmen	abbrechen	kein Tenant ohne Admin
Reassign-Ziel fehlt	Backlog	-	-	spaeter fuer Reassign-Workflow
Rolle in Benutzung	kleines Blocker-Modal	Verstanden	-	Rolle kann erst geloescht werden, wenn keine Mitarbeiter mehr zugewiesen sind
Rollenname existiert	Inline	Namen aendern	abbrechen	eindeutige Rollennamen

---

9. Validierte Screen-Liste

Alle aktiven Screen-Kandidaten sind von David validiert. Das Rollenmodell startet nur mit Admin plus eigenen Rollen; Vorlagen und finaler Rechtekatalog werden spaeter ausgearbeitet.

ID	Screen/Zustand	Typ	Umsetzung	Ort	Status
S01	Mitarbeiterliste	Admin List	Bauen	Settings -> Mitarbeiter, Tab Mitarbeiter	Validiert
M01	Mitarbeiter einladen	Modal	Bauen	von S01	Validiert
D01	Rollen-Dropdown in Mitarbeiterliste	Inline-Zustand in S01	Nur dokumentieren	in S01, kein eigener Subframe-Screen	Validiert
M03	Mitarbeiter deaktivieren	Confirm Modal	Bauen	von S01	Validiert
S02	Rollen und Berechtigungen	Settings Subpage	Bauen	Settings -> Mitarbeiter, Tab Rollen und Berechtigungen	Validiert
M04A	Rolle anlegen	Modal Step	Bauen	von S02 CTA Rolle anlegen	Subframe: Rolle anlegen
M04B	Rolle duplizieren	Modal Step	Bauen	von S02 Zeilenaktion Duplizieren	Subframe: Rolle duplizieren
M02	Rolle bearbeiten	Grosses Modal	Bauen	von S02 Bearbeiten oder M04A/M04B	Finale Subframe-Seite: M02 Rolle bearbeiten
D03	Rolle in Nutzung blockiert	Admin Blocker	Nur dokumentieren	von S02/M02	Validiert
V01	Letzter Admin blockiert	Admin Blocker	Nur dokumentieren	von S01/M03/Rollenwechsel	Validiert

---

10. Subframe-Grid

S01 Mitarbeiterliste -> M01 Mitarbeiter einladen
S01 Mitarbeiterliste -> M03 Mitarbeiter deaktivieren
S01 Mitarbeiterliste -> V01 Letzter Admin blockiert
S01 Mitarbeiterliste -> Rolle wechseln inline
S01 Mitarbeiterliste -> S02 Rollen und Berechtigungen via Dropdown-Eintrag `Rollen und Berechtigungen bearbeiten`
S02 Rollen und Berechtigungen -> M04A Rolle anlegen via Rolle anlegen
S02 Rollen und Berechtigungen -> M04B Rolle duplizieren via Duplizieren
M04A Rolle anlegen -> M02 Rolle bearbeiten
M04B Rolle duplizieren -> M02 Rolle bearbeiten
S02 Rollen und Berechtigungen -> M02 Rolle bearbeiten via Bearbeiten
S02 Rollen und Berechtigungen -> D03 Rolle in Nutzung blockiert

Subframe-Stand M02/M04A/M04B

M02 Rolle bearbeiten ist die finale Subframe-Seite fuer die Umsetzung. Die alten M02-Referenzvarianten wurden aus Subframe geloescht, damit der Admin-RBAC-Flow clean bleibt. Fuer den M04-Split werden die bestehenden Subframe-Seiten getrennt referenziert: M04A fuer Rolle anlegen, M04B fuer Rolle duplizieren. Aktueller Subframe-Stand im Admin-RBAC-Flow:

Screen	Subframe
M02 Rolle bearbeiten	Subframe
M04A Rolle anlegen	Subframe
M04B Rolle duplizieren	Subframe

---

11. Screen-Pakete

ID	Datei
S01	Screens/S01 Mitarbeiterliste
M01	Screens/M01 Mitarbeiter einladen
D01	Screens/D01 Rollen-Dropdown in Mitarbeiterliste
M03	Screens/M03 Mitarbeiter deaktivieren
S02	Screens/S02 Rollen und Berechtigungen
M04A	Screens/M04A Rolle anlegen
M04B	Screens/M04B Rolle duplizieren
M02	Screens/M02 Rolle bearbeiten
D03	Screens/D03 Rolle in Nutzung blockiert
V01	Screens/V01 Letzter Admin blockiert

---

12. Backlog / V2

Diese Punkte sind bewusst nicht Teil der v1-Screen-Liste, sollen aber fuer spaetere Versionen sichtbar bleiben.

Thema	Beschreibung	Warum spaeter
Deaktivieren mit Reassign	Beim Deaktivieren offene Projekte, Aufgaben, Leads, Kunden, Dateien oder Verantwortlichkeiten auf andere Nutzer uebertragen	v1 bleibt bewusst bei kleinem Confirm-Modal
Rollen-Loeschen mit Ersatzrolle	Wenn eine Rolle noch Nutzer hat, Ersatzrolle waehlen und Nutzer gesammelt umziehen	v1 blockiert nur und verlangt manuelle Umzuweisung
Gruppen	Gruppen/Teams/Abteilungen als eigene Verwaltung, ggf. mit Bulk-Zuweisung	fuer v1 aus RBAC rausgenommen
Rechtekatalog als eigener Tab	Alle technischen Berechtigungen unabhaengig von Rollen durchsuchen/erklaeren	v1 zeigt Rechte nur im Rollen-Editor
Rollen-Audit	Historie, wer Rollen/Rechte geaendert hat	Audit-Viewer nicht Teil dieses Pakets
Rollen-Review / Needs Review	Rollen markieren, die geprueft werden muessen, inkl. Review-Zyklus	Status Pruefen ist UI-vorbereitet, Prozess spaeter
Rollen-Vorlagen ausarbeiten	branchenspezifische Rollen-Vorlagen fuer neue Rollen definieren	Vorlagen sind aktuell Work in Progress und nicht Teil der initialen Rollenliste
Rechte-Matrix	Vergleich mehrerer Rollen nebeneinander	fuer v1 zu breit/technisch
Bulk-Aktionen	mehrere Mitarbeiter gleichzeitig einladen, deaktivieren oder Rollen zuweisen	spaeter, wenn Teamlisten groesser werden
Admin-Schutz erweitert	detaillierte Regeln fuer Selbst-Deaktivierung, letzter Admin, kritische Rollenwechsel	v1 dokumentiert Blocker, genaue Policy spaeter mit Dev/Security

---

13. Handoff-Check

• Paket ist angelegt.
• D-P2 Admin-Screens sind geprueft.
• Gruppen sind fuer dieses Paket rausgenommen.
• Admin als einzige Startrolle plus eigene Rollen sind als Richtung notiert.
• Rollen-Vorlagen sind als Work in Progress dokumentiert.
• Permission-Bundles sind als Arbeitsgeruest markiert, nicht als finaler Rechtekatalog.
• Permission-Zeilenmuster fuer das Rollen-Modal ist dokumentiert.
• Grober Screen-Aufbau mit Suche/Filtern ist dokumentiert.
• S01 Mitarbeiterliste ist validiert.
• M01 Mitarbeiter einladen ist validiert.
• Rollen-Dropdown in S01 und Sprung zu Rollen und Berechtigungen sind dokumentiert.
• S02 Rollen und Berechtigungen ist validiert.
• M04A Rolle anlegen ist als eigener Screen vermerkt.
• M04B Rolle duplizieren ist als eigener Screen vermerkt.
• M02 Rolle bearbeiten ist validiert.
• M03 Mitarbeiter deaktivieren ist validiert.
• D03 Rolle in Nutzung blockiert ist validiert.
• V01 Letzter Admin blockiert ist validiert.
• Reassign ist in den Backlog gelegt.
• Backlog/V2-Liste ist dokumentiert.
• Permission-Bundles sind fuer v1 als UI-Arbeitsgeruest ausreichend benannt.
• David hat die Kandidaten validiert.
• Screen-Dateien sind angelegt und nach Screen-Zuschnitt synchronisiert.
• Canvas ist angelegt und nach M04-Split synchronisiert.
• M01/M02/M03/M04A/M04B/D03/V01 sind auf echte Subframe-Dialog-Struktur geprueft: DialogLayout -> Dialog -> Dialog.Content.
• Subframe-Links sind eingetragen.
• M04A ist visuell an den final angepassten M04B-Duplikat-Screen angeglichen, aber ohne Duplikat-Modus.