Zugriff und Rollen
Der Zugriff bestimmt, wer im Portal was sieht und tun darf. Fuer Eigentuemer und Administrator ist das kein Satz von Haekchen, sondern ein Verantwortungsmodell: Mitarbeitende arbeiten mit ihren eigenen Aufgaben und Kunden, die Abteilungsleitung sieht ihre Abteilung, und fremde Daten bleiben geschlossen, solange der Zugriff nicht bewusst erteilt wurde.
Diese Seite erklaert das Zugriffsmodell. Die Einrichtung selbst befindet sich im Bereich der Portaladministration — siehe Administrierung des Portals.
Rollen
Konzeptionelle Orientierung, kein UI-Screenshot und kein Nachweis von Portaldaten.
Dem Zugriff liegen drei Rollen zugrunde:
- Administrator — richtet das Portal, die Rechte und die Richtlinien ein; sieht und steuert einen weiten Rahmen.
- Abteilungsleitung — verantwortet ihre Abteilung oder ihren Bereich; sieht die Arbeit ihres Teams.
- Mitarbeitende — arbeiten mit ihren eigenen Aufgaben, Kunden und Materialien.
Die Rolle legt das Grundniveau des Zugriffs fest, waehrend die genauen Rechte durch Richtlinien nach Bereichen und Modulen praezisiert werden.
Zugriffsbereiche
Konzeptionelle Orientierung, kein UI-Screenshot und kein Nachweis von Portaldaten.
Zugriff wird nicht pauschal auf alles vergeben, sondern nach Bereichen. Ein Bereich ist die Grenze, in der ein Recht gilt: das gesamte Unternehmen, eine Abteilung, eine Pipeline, eine Stufe, ein Projekt oder ein einzelner Benutzer.
So kann ein und dieselbe Person in ihrem eigenen Projekt weitreichenden Zugriff haben und in einem fremden gar keinen. Damit laesst sich genau das oeffnen, was fuer die Arbeit noetig ist, ohne Ueberfluessiges preiszugeben.
Rechte: lesen, aendern, verwalten
Konzeptionelle Orientierung, kein UI-Screenshot und kein Nachweis von Portaldaten.
In jedem Bereich setzt sich ein Recht aus mehreren Stufen zusammen:
- Lesen — Objekte und ihre Inhalte sehen;
- Erstellen — neue Objekte anlegen;
- Aendern — bestehende bearbeiten;
- Verwalten — Zugriff und Regeln in diesem Bereich einrichten.
Trennen Sie die Stufen bewusst: Das Recht zu sehen bedeutet nicht das Recht zu aendern, und das Recht zu arbeiten bedeutet nicht das Recht, anderen Zugriff zu erteilen.
Was eine Richtlinie steuert
Konzeptionelle Orientierung, kein UI-Screenshot und kein Nachweis von Portaldaten.
Die Modulauswahl umfasst Aufgaben und CRM sowie Workflows, Chats, Projekte, Benutzer, Unternehmen, Zeit, Automatisierung, KI-Assistent, Operations und Dokumente. Waehlen Sie Bereich und Rolle. Fuer eine Abteilung kann der Wert explizit, vom Parent geerbt oder der Modul-Fallback sein; Auf Kinder anwenden vererbt nach unten. Erstellen und Verwalten sind in expliziten Regeln von Lesen und Aendern getrennt.
Aufgabenrichtlinien steuern die Zuweisung nach unten, oben und zwischen Abteilungen; Richtung, Tiefe, Zielrollen sowie Erlaubnis-/Sperrlisten werden unabhaengig von der Sichtbarkeit festgelegt. In CRM gehoeren Deal-Sichtbarkeit und Pipeline-/Phasenziel zur selben Richtlinie; lassen Sie Felder leer, wenn kein solcher Bereich gilt.
Bei Modulen mit Automatisierungsschema zeigt der Editor unter den CRUD-Rechten zusätzliche Capability-Schalter. Setzen Sie jede Capability auf Erlauben, Verweigern oder Erben; dies ist unabhängig von Lesen, Ändern und Verwalten. Sammelaktionen setzen alle Capabilities zugleich. Für den Assistenten gibt es optionale Presets für Antworten, Antworten plus Aktionen oder das Zurücksetzen auf Vererbung. Sie ändern nur die Richtlinie und starten keine Automatisierung.
Übernimmt eine Abteilungsregel den Wert vom übergeordneten Bereich oder vom Modul-Fallback, sind die Capability-Schalter bis zur Wahl einer expliziten Quelle deaktiviert. Fehlt das Schema, zeigt der Block diesen Zustand statt technische Capability-Namen manuell entgegenzunehmen.
Bei Operations beginnt die Liste mit Rechten, die fuer das Operations-Modul registriert sind, und mit verstaendlichen lokalisierten Bezeichnungen. Ein bereits in der Richtlinie gespeichertes Recht bleibt auch dann sichtbar, wenn es ausserhalb der normalen Modulliste liegt, damit es bewusst geprueft und geaendert werden kann. Eine kuerzere Liste entzieht keinen Zugriff: Pruefen Sie vor dem Speichern fuer jedes sichtbare Recht Erlauben, Verweigern oder Erben und geben Sie keinen technischen Namen von Hand ein.
Aenderungen pruefen und rueckgaengig machen
Konzeptionelle Orientierung, kein UI-Screenshot und kein Nachweis von Portaldaten.
Loeschen und das Anwenden einer Revision erfordern eine Begruendung. Lange Historienzusammenfassungen lassen sich aufklappen. Explain und Simulate pruefen CRM-Zugriff, aendern aber die Richtlinie nicht.
Standard-Zugriffsmodus
Konzeptionelle Orientierung, kein UI-Screenshot und kein Nachweis von Portaldaten.
Fuer Module wird ein Standard-Zugriffsmodus festgelegt — was geschieht, wenn keine ausdrueckliche Regel vorliegt:
- Streng — der Zugriff ist standardmaessig geschlossen; geoeffnet wird nur, was eine Richtlinie ausdruecklich erlaubt. Geeignet fuer sensible Daten und groessere Unternehmen.
- Offen — der Lese- und Arbeitszugriff ist standardmaessig offen, und Richtlinien schraenken einzelne Bereiche ein. Geeignet fuer ein kleines Team mit hohem Vertrauen.
Sicherer ist es, in Modulen mit Kunden- und Finanzdaten mit dem strengen Modus zu beginnen und den Zugriff nach Bedarf zu oeffnen.
Aenderungshistorie und Begruendung
Konzeptionelle Orientierung, kein UI-Screenshot und kein Nachweis von Portaldaten.
Eine Aenderung des Zugriffs ist eine Managemententscheidung und keine unbemerkte Korrektur. Deshalb bittet das System bei einer Aenderung der Richtlinie um die Angabe eines Aenderungsgrunds, und die Historie der Aenderungen wird gespeichert: Es ist ersichtlich, wer wann und warum den Zugriff geaendert hat.
Das ist wichtig fuer die Kontrolle und die Aufarbeitung von Vorfaellen: Falls jemand Ueberfluessiges gesehen oder umgekehrt den Zugriff verloren hat, ist aus der Historie ersichtlich, welche Aenderung dazu gefuehrt hat.
Das Journal verwendet verständliche Bezeichnungen für geänderte Felder und zeigt
keine internen Feldnamen oder technischen Daten an. Wenn ein Feld keiner Bezeichnung zugeordnet
werden kann, wird es als +N zusammengefasst, statt technische Daten offenzulegen.
Nach dem Speichern einer Regel wechselt das Register automatisch zu deren Modul,
damit die neue Zeile sichtbar bleibt; prüfen Sie sie dort und lesen Sie danach den
resultierenden Zugriff erneut.
Gute Praktiken
Konzeptionelle Orientierung, kein UI-Screenshot und kein Nachweis von Portaldaten.
- Vergeben Sie Zugriff nach Bereich und Rolle, nicht vorsorglich auf das gesamte Unternehmen.
- Trennen Sie das Recht zu sehen und das Recht zu aendern; das Recht, Zugriff zu verwalten, geben Sie nur einem engen Kreis.
- Halten Sie in Modulen mit Kunden- und Finanzdaten standardmaessig den strengen Modus.
- Schreiben Sie bei einer Aenderung der Richtlinie eine verstaendliche Begruendung — sie bleibt in der Historie erhalten.
- Ueberpruefen Sie Zugriffe regelmaessig: Entfernen Sie ueberfluessige, wenn sich Rollen und Projekte aendern.
Haeufige Fehler
Konzeptionelle Orientierung, kein UI-Screenshot und kein Nachweis von Portaldaten.
- Es wird ein weiter Zugriff auf das gesamte Unternehmen vergeben statt Zugriff nach Bereich.
- Das Recht zu sehen wird mit dem Recht zu aendern verwechselt — Mitarbeitende bearbeiten versehentlich fremde Daten.
- Der offene Standardmodus bleibt in einem Modul mit sensiblen Daten bestehen.
- Richtlinien werden ohne Grund geaendert — spaeter laesst sich nicht mehr nachvollziehen, warum der Zugriff so wurde.
- Zugriffe werden nach einem Rollenwechsel oder Projektabschluss nicht ueberprueft.
Verwandte Abschnitte
Konzeptionelle Orientierung, kein UI-Screenshot und kein Nachweis von Portaldaten.