Auf dieser Seite
Das Prinzip: Du siehst, was du darfst
Die Rechte in Bricksta sind rollenbasierte Zugriffskontrolle (RBAC) — dasselbe Modell wie bei GitLab, Jira oder monday.com. Es gilt eine Regel: Die Oberfläche zeigt genau das, was du auch tun darfst. Navigation und Durchsetzung lesen dieselben Rechte, deshalb gibt es keine Knöpfe ohne Funktion und keine widersprüchlichen Vergaben. Vergibst du jemandem ein Recht, erscheint der passende Bereich automatisch; nimmst du es weg, verschwindet er.
Die vier Mitglieder-Typen
Jedes Mitglied hat einen Typ — seine eingebaute Startrolle. Die vier Typen decken die allermeisten Fälle ab, ohne dass du einzelne Rechte anfassen musst. Den Typ setzt du je Person unter Organisation → Mitglieder.
Eine Ausnahme gilt für den Typ „Administrator“: Wer Mitglieder verwalten darf, kann zwischen Manager, Mitwirkender und Externer Gast frei umschalten — den Administrator vergibt und entzieht aber nur, wer selbst Owner oder Administrator ist. Grund: Dieser Typ trägt nicht ein Recht mehr, sondern alle auf einmal. Fehlt dir die Stufe, steht die Karte „Administrator“ grau und nur zum Lesen da, mit einem Hinweis darüber; ist das Mitglied bereits Administrator, sind alle Karten gesperrt, denn jeder Wechsel würde ihm die Stufe nehmen.
- Administrator
- Darf alles: Vorgänge bearbeiten, Vorlagen und Automatisierung konfigurieren, Mitglieder und Rollen verwalten, Einstellungen ändern. Für die Personen, die eure Bricksta-Organisation aufsetzen und pflegen.
- Manager
- Arbeitet an Vorgängen mit — Aufgaben übernehmen, ausfüllen, abschließen, zuweisen — und sieht alle Vorgänge der Organisation, aber keine Konfiguration (Vorlagen, Rollen, Einstellungen). Der Standardtyp fürs Team; „Manager“ steht für den organisationsweiten Überblick, nicht für Verwaltungsrechte (die hat nur der Administrator).
- Mitwirkender
- Sieht und bearbeitet nur Vorgänge, in denen ihm selbst eine Aufgabe zugewiesen ist. Für Personen, die punktuell mitwirken, ohne den ganzen Vorgangsbestand zu sehen.
- Externer Gast
- Kein Login. Füllt über einen sicheren Link genau eine Aufgabe aus (z. B. ein Kunde, der ein Formular zurückschickt) und sieht sonst nichts von eurer Organisation.
Was ein Typ genau umfasst, siehst du unter Organisation → Berechtigungen: Die drei Typen (Administrator, Manager, Mitwirkender) stehen dort ganz oben, über den Profilen — mit ihren Rechten, ihrer Sichtbarkeit (alle Vorgänge oder nur eigene) und den erreichbaren Navigations-Bereichen. So ist auf einen Blick klar, was der Typ steuert: wie viel jemand überhaupt sieht und welche Basis-Rechte er mitbringt. Was er darüber hinaus darf, steuert nicht die Rolle, sondern sein Berechtigungsprofil unter Organisation → Berechtigungen.
Vergib Typen so knapp wie möglich: Die meisten Mitglieder brauchen zum Mitarbeiten keine Verwaltungsrechte. Manager ist für die meisten die richtige Wahl.
Neben den menschlichen Typen gibt es einen weiteren Mitglieder-Typ: den KI-Agenten. Er hat eine fest begrenzte Ausführer-Rolle (nur Aufgaben starten, ausfüllen, abschließen), kann sich nicht anmelden und arbeitet unter Budget und freigegebenen Werkzeugen. Wie du Agenten anlegst und steuerst, erklärt der Artikel KI-Agenten.
Eigene Rollen: Zuständigkeit im Vorgang benennen
Eine Rolle benennt einen Job im Prozess — „Einkauf“, „Freigeber“, „Projektleitung“. Du legst sie unter Organisation → Rollen an und besetzt sie im Vorgang; Aufgaben und Freigaben werden an sie adressiert. Sie vergibt selbst KEINE Rechte. Soll jemand mehr dürfen als sein Typ vorsieht, aber nicht gleich voller Admin sein, ist das Mittel dafür ein Berechtigungsprofil — Beispiel: ein Profil „Vorlagen-Redaktion“, das nur das Recht zum Bearbeiten von Vorlagen enthält. Bis Mig 871 trug tatsächlich die Rolle diese Häkchen; seither ist beides getrennt, weil dieselbe Person in einem Vorgang zuständig sein kann und im nächsten nicht, ohne dass sich an ihren Rechten etwas ändert.
Du wählst links in der durchsuchbaren Rollen-Liste eine Rolle und siehst rechts, wer sie hat — als Person, über eine Gruppe oder als Vorbelegung. Rechte stehen dort nicht mehr: eine Rolle sagt, WOFÜR jemand zuständig ist; WAS er darf, steht im Berechtigungsprofil unter Organisation → Berechtigungen. Eine neue Rolle legst du mit ihrem Namen an. Zwei Rollen, die dasselbe meinen, wählst du in der Liste an und führst sie über „Zusammenführen“ zu einer zusammen. Sind für die Organisation Inhalts-Sprachen eingestellt, erscheint bei einer Custom-Rolle unter dem Titel ein Sprach-Umschalter: du wählst die Zielsprache und übersetzt den Rollennamen (leer = Basis-Sprache) — die Mitglieder-Typen sind ohnehin schon übersetzt.
Das Berechtigungsprofil: was jemand darf
Ein Berechtigungsprofil ist eine benannte Liste von Rechten — „Vorgänge bearbeiten“, „Vorlagen pflegen“, „Mitglieder einladen“. Du legst es unter Organisation → Berechtigungen an und weist es einer Person oder einer Gruppe zu. Wer mehrere Profile trägt, darf alles zusammen, was darin steht.
Warum es zwei Dinge sind und nicht eines: eine Rolle beantwortet die Frage WOFÜR — wer ist in diesem Vorgang der Prüfer, wer die Bearbeiterin. Ein Profil beantwortet die Frage WAS — wer darf überhaupt abschließen, wer nur lesen. Dieselbe Person kann in einem Vorgang Prüferin sein und in einem anderen gar nichts, ohne dass sich an ihren Rechten etwas ändert. Deshalb hat die Rolle keine Häkchen mehr: sie hatte nie welche, die diese Unterscheidung tragen konnten.
Und daraus folgt, WO ein Recht gilt. Vorgangsbezogene Rechte — alles rund um Aufgaben — wirken dort, wo du beteiligt bist: du besitzt den Vorgang, bist darin auf einer Rolle besetzt, oder dir gehört eine Aufgabe darin. Soll ein Profil überall gelten, setzt du am Profil das Häkchen „gilt in allen Vorgängen“. Organisationsweite Rechte wie „Vorlagen pflegen“ brauchen keine Beteiligung, sie gelten immer.
Wer einen Vorgang anlegt, darf darin nicht automatisch alles. Als Besitzerin eines Vorgangs bist du darin beteiligt — du darfst also das, was dein Profil erlaubt. Nicht mehr. Legt jemand mit einem schmalen Profil einen Vorgang an, kann er darin also weniger tun, als man erwarten würde. Das ist Absicht: der Besitz sagt, WO du etwas darfst, nicht WAS.
Custom-Rollen sind rein additiv: Sie geben Nicht-Admins mehr, sie nehmen niemandem etwas weg. Admins haben ohnehin alle Rechte. Für die meisten Organisationen reichen die vier Typen — Rollen sind der optionale Feinschliff.
Eine neue Organisation startet ohne jede Rolle: welche Rollen es gibt, entscheidest du — sie beschreiben deinen Prozess, und bricksta kann ihn nicht erraten. Die Liste ist leer, bis du die erste über „+“ anlegst. Trägt eine Rolle das Kennzeichen „System“, steht sie in einem eigenen Abschnitt „Systemrollen“ über den übrigen und ist nur lesbar — du siehst, wer sie hat, kannst den Namen aber nicht ändern; zugewiesen wird sie unter Organisation → Mitglieder. Diesen Abschnitt bekommst du nur zu sehen, wenn es solche Rollen in deiner Organisation gibt. Die Grundausstattung der drei Mitglieds-Typen findest du unter Organisation → Berechtigungen, zusammen mit den Berechtigungsprofilen: sie beantwortet dieselbe Frage („was darf jemand“) und steht deshalb dort. Ihre vorgangsbezogenen Rechte gelten dort, wo die Person am Vorgang beteiligt ist — sie besitzt ihn, ist darin auf einer Rolle besetzt, hat eine Aufgabe darin, oder sie ist darin als Freigeberin benannt.
Die Grundausstattung eines Mitglieds-Typs ändert unter Organisation → Berechtigungen, wer Mitglieder verwalten darf. Für org-weite Rechte — „Organisation verwalten“, „Missionen verwalten“, „Mitglieder / Rollen verwalten“, „Mitglieder einladen“ sowie „Vorlagen verwalten“, „Vorgänge anlegen / starten“ und „Vorgang löschen“ — brauchst du zusätzlich das Recht „Organisation verwalten“. Grund: Ein Recht an der Grundausstattung wirkt sofort auf alle Mitglieder dieses Typs — auch auf dich selbst. Ohne „Organisation verwalten“ stehen genau diese Häkchen grau und nur zum Lesen da, mit einem Hinweis darüber; alle vorgangs- und aufgabenbezogenen Rechte bleiben unverändert bedienbar. Wer einen Mitglieds-Typ trägt, steht in derselben Ansicht gleich unter seinem Namen: die Personen dieses Typs, nur zum Lesen. Wechseln lässt sich der Typ einer Person unter Organisation → Mitglieder — auch hier gibt es für jede Sache genau einen Ort, an dem man sie ändert.
Rollen können auch automatisch entstehen: Legst du eine Vorlage mit der KI-Generierung an, leitet die KI passende Rollen aus dem Prozess ab, weist sie den Aufgaben als Standard-Zuständigkeit zu und legt sie hier an — erkennbar am Kennzeichen „KI“. Gibt es eine gleichnamige Rolle bereits, wird sie wiederverwendet statt doppelt angelegt. Für ähnlich benannte Rollen (etwa „Sachbearbeiter“ und „Bearbeiter“) blendet die Rollen-Verwaltung einen Hinweis „Mögliche Duplikate“ ein: Über „Zusammenführen“ verschmilzt du zwei Rollen zu einer — alle Zuweisungen und Vorlagen-Zuständigkeiten ziehen dabei auf die erhaltene Rolle um. Rechte ziehen nicht mit, weil eine Rolle keine trägt; wer die Rechte der einen Person geben will, weist ihr ein Berechtigungsprofil zu.
Sind es in Wahrheit zwei verschiedene Funktionen, markierst du das Paar mit „Kein Duplikat“ — dann ist der Vorschlag dauerhaft weg und kommt beim nächsten Seitenaufruf nicht wieder. Diese Entscheidung gilt für die ganze Organisation: Rollen sind ein gemeinsames Gut, und was eine Verwaltung geklärt hat, soll den anderen nicht erneut vorgelegt werden. Kurz nach dem Klick kannst du sie über „Rückgängig“ zurücknehmen; danach führt der Weg über die Zeile „Ausgeblendete Paare“ unter dem Hinweis. Sie klappt die abgeblendeten Paare auf und stellt jedes einzeln über „Wieder anzeigen“ wieder her — und sie bleibt sichtbar, auch wenn es gerade keinen offenen Vorschlag mehr gibt. Die Ablehnung hängt an den beiden Rollen selbst, nicht an ihren Namen: Sie übersteht ein Umbenennen und verschwindet erst, wenn eine der beiden Rollen gelöscht wird.
Wo eine Rolle überall hängt, siehst du im Tab „Verwendung“ des Rollen-Details. Er ist in zwei Abschnitte geteilt: „Zuweisungen“ zeigt, wer die Rolle hat (org-weit, in einzelnen Vorgängen, als Standard-Mitglied oder über eine Personengruppe), „Verwendung“ zeigt, wo sie erwartet wird (Vorlagen-Zuständigkeit, Freigeber, Aufgaben-Bibliothek, Feld-Rechte, laufende Aufgaben, offene Einladungen). Jede Kategorie klappst du einzeln auf — die Einträge werden erst dann geladen, damit die Ansicht auch bei sehr vielen Treffern schnell bleibt; sehr große Mengen zeigt Bricksta als „200+“. Aus jeder Zeile kannst du die Verknüpfung direkt lösen, oder über „Alle lösen“ eine ganze Kategorie auf einmal.
Eine Rolle lässt sich erst löschen, wenn nichts mehr an ihr hängt — Bricksta prüft das vorab und listet im Lösch-Dialog jede offene Verwendung mit Anzahl auf; „Anzeigen“ springt in genau diese Kategorie im Tab „Verwendung“, wo du sie lösen kannst. Nichts wird beim Löschen still entfernt: Eine Vorlage soll ihre Freigabe-Regel nicht unbemerkt verlieren. Abgeschlossene Aufgaben behalten ihre Zuständigkeit dauerhaft, damit die Historie eurer Vorgänge nicht nachträglich verfälscht wird — steckt die Rolle dort, bleibt das Löschen gesperrt. Dann hast du zwei Auswege. „Deaktivieren“ ist der einfachere: Die Rolle verschwindet aus allen Auswahllisten und vergibt keine Rechte mehr, aber nichts wird umgeschrieben — abgeschlossene Vorgänge zeigen weiterhin, wer zuständig war, und du kannst die Rolle jederzeit wieder aktivieren. „Stattdessen zusammenführen …“ wählst du, wenn die Arbeit wirklich an eine andere Rolle übergeht: Du wählst eine Ziel-Rolle, alle Verwendungen ziehen dorthin um und die alte Rolle verschwindet. Das lässt sich nicht rückgängig machen.
Eine Rolle deaktivierst du über das ⋮-Menü oben rechts in ihrer Detail-Ansicht. Danach steht sie unten in der Liste in einem eigenen Abschnitt „Deaktiviert“, der sich über den Schalter „Anzeigen“ ein- und ausblenden lässt — so bleibt die Arbeitsliste aufgeräumt, ohne dass etwas verloren geht. Personen, die die Rolle haben, behalten den Eintrag; er wirkt nur nicht mehr und wird bei ihnen als „(deaktiviert)“ gekennzeichnet. Wo die Rolle bereits zugewiesen ist — an laufenden und erledigten Aufgaben, in Vorlagen, an offenen Einladungen — bleibt ihr Name sichtbar; nur neu auswählen kannst du sie nicht mehr. Trägt eine Rolle das Kennzeichen „System“, lässt sie sich nicht deaktivieren.
Prüfstand: warum darf diese Person hier was?
Bis hierher hast du gelesen, woraus sich ein Recht ergeben kann: Mitglieds-Typ, Berechtigungsprofil (direkt oder über eine Gruppe) und die Beteiligung an einem Vorgang. Im Einzelfall stellt sich die Frage aber andersherum — „Warum kann diese Person die Aufgabe nicht abschließen?“ Dafür gibt es den Prüfstand unter Organisation → Prüfstand. Du wählst eine Person und einen Vorgang; darunter steht jedes Recht mit seinem Zustand (gewährt oder verweigert) und der Quelle, aus der es kommt: etwa „Vorgangs-Rolle: Prüfer“, „Berechtigungsprofil (über eine Gruppe): Buchhaltung“ oder, bei einem verweigerten Recht, der Grund — „Kein aktives Profil trägt dieses Recht“.
Der Prüfstand rechnet nichts nach: Er fragt dieselbe Regel, die Bricksta auch durchsetzt. Was dort steht, gilt also genau so — auch dann, wenn es überrascht. Ohne gewählten Vorgang lassen sich nur die organisationsweiten Rechte beantworten; die vorgangsbezogenen brauchen einen Vorgang, weil sie von der Beteiligung darin abhängen. Und weil der Prüfstand die Rechtelage einer anderen Person zeigt, ist er allein den Personen vorbehalten, die die Organisation verwalten dürfen.
Lässt sich die Rechtelage gerade nicht lesen — etwa weil die Verbindung wackelt —, zeigt der Prüfstand einen Hinweis mit „Erneut versuchen“ und KEINE leere Liste. Eine leere Liste läse sich als „diese Person darf nichts“, und das ist eine ganz andere Aussage.
Sichtbarkeit: Vorlagen und Kategorien privat stellen
Neben „was darf jemand tun“ gibt es die Frage „was darf jemand sehen“. Das ist eine eigene Ebene. Standardmäßig sind Vorlagen für alle sichtbar. Eine einzelne Vorlage oder eine ganze Kategorie kannst du auf privat stellen — dann sehen ihre Vorgänge nur noch die Personen und Gruppen, die du ausdrücklich freigibst. Die Freigabe stellst du direkt an der Vorlage bzw. Kategorie unter Sichtbarkeit ein; Gruppen pflegst du unter Organisation → Gruppen — dort wählst du links eine Gruppe, fügst rechts ihre Mitglieder hinzu und kannst sie über das Stift-Symbol neben dem Namen umbenennen, genau wie bei den Rollen.
Zwei Ausnahmen gelten immer: Admins sehen alles, und wer in einem privaten Vorgang eine eigene Aufgabe hat, sieht diesen Vorgang — sonst könnte man ihm keine Arbeit zuweisen.
Feld-Rechte innerhalb einer Aufgabe
Für den Feinschliff kannst du im Formular-Editor einer Vorlage einzelne Felder auf bestimmte Rollen beschränken — sichtbar nur für sie oder editierbar nur für sie. So bleibt etwa ein interner Vermerk für die zuständige Rolle reserviert, während der Rest der Aufgabe für alle offen ist. Ohne solche Einschränkung ist ein Feld für alle sichtbar und editierbar.
Rechte werden serverseitig durchgesetzt, nicht nur in der Oberfläche versteckt. Und: Entziehst du jemandem Zugriff oder deaktivierst ein Mitglied, endet der Zugriff sofort — die Historie der bisherigen Arbeit bleibt aber lückenlos erhalten.