Rollen und Berechtigungen: klare Regeln mit Praxisbeispielen

Das eigentliche Problem: Personen sehen Daten, die sie nicht sehen sollten

Ein „Datenleck“ im Arbeitsalltag wirkt oft unspektakulär. Ein Support‑Agent öffnet ein Kundenprofil und sieht die komplette Zahlungshistorie. Ein Kunde meldet sich an und findet interne Notizen wie „20% Rabatt anbieten, wenn sie sich beschweren“ oder die tatsächlichen Kosten und Margen auf einer Rechnung. Es wurde kein Passwort gestohlen — die App hat einfach das Falsche angezeigt.

Die meisten Lecks passieren aus Versehen. Berechtigungen werden spät ergänzt, ein neuer Bildschirm wird schnell ausgeliefert oder jemand kopiert eine alte Rolle, die für Tests „gut genug“ war. Dann wird mit einer kleinen Änderung, etwa einem neuen Feld in einer Tabelle, stillschweigend etwas für alle sichtbar.

Deshalb sollten Rollen und Berechtigungen von Anfang an einen zentralen Platz in der App‑Planung haben, nicht nur eine Nachgedanke. Die meisten Kleinunternehmen landen bei den gleichen vier Rollentypen: Inhaber, Manager, Mitarbeiter und Kunde.

Das Ziel ist einfach: Jede Person soll nur das sehen, was sie für ihre Arbeit braucht — und nichts anderes. Das gilt für die Daten im Hintergrund, nicht nur für die erwarteten Bildschirme.

Wenn Sie schnell auf einer No‑Code‑Plattform wie AppMaster entwickeln, ist das noch wichtiger. Geschwindigkeit ist gut, erhöht aber das Risiko, private Notizen, Preisregeln oder fremde Kundendaten versehentlich offenzulegen, wenn Zugriff nicht von Anfang an mitgedacht wird.

Rollen, Berechtigungen und Scope: einfache Definitionen

Rollen und Berechtigungen sind die Regeln, die entscheiden, wer in einer App was darf.

• Eine Rolle ist ein Job‑Label wie Inhaber, Manager, Mitarbeiter oder Kunde.
• Berechtigungen sind die konkreten Aktionen, die diese Rolle ausführen darf.

Ein Zugriffslevel ist das praktische Ergebnis dieser Regeln. Zwei Personen können beide „Mitarbeiter“ sein, aber die eine hat ein höheres Zugriffslevel, weil sie Rückerstattungen genehmigen kann, die andere nicht.

Eine zuverlässige Vorgehensweise ist: Mit minimalem Zugriff starten und nur hinzufügen, was die Person wirklich für die tägliche Arbeit braucht. Wenn jemand nie Rechnungen bearbeitet, geben Sie ihm nicht „zur Sicherheit“ Bearbeitungsrechte. Es ist leichter, später Zugriff zu gewähren als ein Datenleck rückgängig zu machen.

Die meisten Berechtigungen lassen sich auf wenige Aktionen reduzieren: ansehen, erstellen, bearbeiten, löschen und einige risikoreichere Aktionen wie exportieren oder genehmigen.

Scope beantwortet eine andere Frage: „Auf welche Datensätze darf die Aktion angewendet werden?“ Jemand darf vielleicht Rechnungen ansehen, aber nur die eigenen, nicht alle.

Typische Scope‑Muster sind:

• Eigene Datensätze (nur Elemente, die sie erstellt oder denen sie zugewiesen sind)
• Team oder Standort (ihre Filiale, Abteilung oder ihr Projekt)
• Gesamtes Unternehmen (alle Datensätze der Firma)

Ein Vertriebsmitarbeiter kann eigene Angebote erstellen und ansehen, aber nicht die komplette Kundendatenbank exportieren. Ein Vertriebsleiter kann die Angebote des gesamten Teams sehen und Rabatte genehmigen. Der Inhaber sieht alles und kann Berichte für die Buchhaltung exportieren.

Was Inhaber, Manager, Mitarbeiter und Kunden normalerweise brauchen

Die meisten Apps haben am Ende dieselben vier Personengruppen. Die Details variieren, das Muster bleibt. Klare Rollen und Berechtigungen verhindern später viele unangenehme "Warum kann die das sehen?"‑Momente.

Inhaber benötigen in der Regel vollständige Sichtbarkeit über das Geschäft. Dazu gehören oft Abrechnung, Sicherheitseinstellungen (z. B. Passwortregeln und MFA) und ein Audit‑Verlauf, damit sie nachvollziehen können, wer wann was geändert hat.

Manager müssen ein Team führen, ohne komplette Administratorenrechte zu haben. Sie brauchen Übersichten (alles in ihrer Abteilung sehen), Genehmigungen (Rabatte, Rückerstattungen, Urlaubsanträge, Inhaltsänderungen) und Berichte. Eventuell benötigen sie eingeschränkte Admin‑Funktionen wie Mitarbeiter einladen oder ein Passwort zurücksetzen, aber keinen Zugang zu Abrechnung oder globalen Sicherheitseinstellungen.

Mitarbeiter sollen schnell ihre tägliche Arbeit erledigen können, mit möglichst geringem Risiko. Ein sicherer Standard ist „nur das, was mir zugewiesen ist.“ Ein Support‑Agent sieht nur seine Tickets, ein Disponent nur die Touren des Tages, ein Verkäufer nur seine Leads. Exporte und Bulk‑Downloads sollten standardmäßig aus sein und nur bei echtem Bedarf aktiviert werden.

Kunden sollten nur ihre eigenen Daten sehen, auch wenn mehrere Personen ein Konto teilen. Ermöglichen Sie begrenzte Aktionen (Anfragen erstellen, Rechnungen bezahlen, Profil aktualisieren), aber halten Sie interne Notizen, Mitarbeiterkommentare und interne Stati verborgen.

Eine Default‑Konfiguration, die in vielen Unternehmen funktioniert:

• Inhaber: alles, inklusive Abrechnung, Sicherheit und Audit‑Logs
• Manager: Teamdaten, Genehmigungen, Reporting, eingeschränkte Nutzerverwaltung
• Mitarbeiter: nur zugewiesene Datensätze, kein Massenexport, keine Admin‑Einstellungen
• Kunde: nur eigene Datensätze, keine internen Notizen, eingeschränkte Aktionen

Zugriff nach Datentypen aufschlüsseln, nicht nur nach Bildschirmen

Viele Teams definieren Rollen nach Bildschirmen: „Mitarbeiter können die Bestellseite öffnen, Kunden nicht.“ Das hilft, übersieht aber das eigentliche Risiko. Dieselben Daten erscheinen in Suche, Kommentaren, Benachrichtigungen, Exporten und Anhängen.

Listen Sie Ihre Datenbereiche auf, nicht die Menüs. Hochrelevante Bereiche sind meist Kundenkontakte, Bestellungen und Lieferstatus, Rechnungen und Zahlungsstatus, Gehälter und HR‑Notizen sowie interne Notizen oder Analysen.

Bestimmen Sie dann, was jede Rolle mit jedem Datentyp darf: ansehen, erstellen, bearbeiten, löschen, genehmigen und teilen. Hier kommen feldbezogene Regeln ins Spiel. Dasselbe Objekt braucht oft eine öffentliche und eine interne Ansicht.

Beispiel: Eine Bestellung kann Kundenname, Lieferadresse, Preis, interne Marge und eine interne Notiz wie „Kunde reklamiert häufig, Rabatt anbieten“ enthalten. Ein Kunde sollte Adresse und Status sehen, aber niemals Marge oder interne Notiz. Ein Manager sieht alle Felder plus die Möglichkeit, Rabatte zu genehmigen. Mitarbeiter sehen nur die Felder, die sie zur Ausführung benötigen, aber keine Finanzdetails.

Dateien und Anhänge verdienen besondere Vorsicht. Verträge, Ausweise, Belege und Screenshots enthalten oft sensiblere Informationen als Formularfelder. Behandeln Sie sie als eigene Berechtigung: wer kann hochladen, wer herunterladen und wer kann Dateivorschauen sehen. Entscheiden Sie außerdem, ob Anhänge die Rechte des übergeordneten Datensatzes erben (z. B. eine Rechnung) oder eigene Regeln brauchen.

Behandeln Sie Exporte und Massenaktionen nicht als automatisch inklusive, nur weil jemand eine Liste sehen kann. Machen Sie sie explizit: Export nach CSV/PDF, Batch‑Download von Anhängen, Massenstatusänderungen (genehmigen, stornieren, erstatten), Massen‑Benachrichtigungen (E‑Mail/SMS/Telegram) und Admin‑Aktionen wie Umverteilung von Datensätzen.

Praxisbeispiel 1: Vertriebs‑ und Rechnungswesen‑App

Stellen Sie sich ein kleines Dienstleistungsunternehmen vor: Der Inhaber verkauft Projekte, Manager überwachen Jobs, Mitarbeiter führen die Arbeit aus und Kunden genehmigen Angebote und bezahlen Rechnungen. Der schnellste Weg, peinliche Fehler zu vermeiden, ist, Rollen und Berechtigungen zu vereinbaren, bevor sich jemand einloggt.

Beginnen Sie bei Gelddetails. Preise dürfen für mehr Personen sichtbar sein als die Marge. Eine übliche Regel: Mitarbeiter sehen, was berechnet werden muss, aber nicht, warum dieser Preis gewählt wurde. Ein Techniker braucht vielleicht Positionen zur Erklärung einer Rechnung, aber nicht die interne Marge, Lieferantenkosten oder einen speziellen Rabatt, den Sie zur Auftragsgewinnung gewährt haben.

Kundendaten sind ein weiterer Hotspot. Viele Teams möchten, dass mehrere Personen Kontaktdaten ansehen können (um die richtige Person anzurufen), aber nur wenige dürfen sie bearbeiten. Ansonsten kommt es zu versehentlichen Überschreibungen wie der Rechnungs‑E‑Mail, die durch eine private E‑Mail ersetzt wird, und Rechnungen erreichen die Buchhaltung nicht mehr.

Ein einfaches Setup, das für viele Teams gut funktioniert:

• Inhaber: sieht alles, inklusive Marge und Rabatt‑Historie, und kann Zahlungsstatus ändern
• Manager: kann Angebote und Rechnungen erstellen, Rabatte genehmigen und Kundenkontakte bearbeiten
• Mitarbeiter: sieht zugewiesene Kundendetails und Rechnungspositionen, darf aber keine Preisregeln bearbeiten oder Margen sehen
• Kunde: sieht nur eigene Angebote und Rechnungen und kann bezahlen oder Änderungen anfragen

Sperren Sie risikoreiche Aktionen: Eine Rechnung als bezahlt markieren, eine Rückerstattung ausstellen oder eine Zahlungsmethode ändern sollte nur dem Inhaber (oder einer vertrauenswürdigen Finanzrolle) vorbehalten sein.

Praxisbeispiel 2: Support‑Desk mit internen Notizen

Ein Support‑Desk wirkt einfach: Kunden schicken Nachrichten, Ihr Team antwortet, Tickets werden geschlossen. Probleme entstehen, wenn dieselbe Ticketansicht für alle wiederverwendet wird. Eine falsche Einstellung und Kunden sehen interne Notizen, Tags oder sogar Mitarbeiterkennzahlen.

Stellen Sie sich ein kleines E‑Commerce‑Unternehmen mit einem gemeinsamen Support‑Postfach vor. Ein Ticket enthält die Kunden‑Nachricht, Bestelldetails, Versandstatus und interne Notizen wie „möglicher Betrug, Ausweis prüfen“ oder „VIP, priorisieren“. Diese interne Information hilft dem Team, darf aber niemals für den Kunden sichtbar sein.

Eine klare Trennung, die sensible Daten schützt:

• Kunde: sieht nur die eigenen Nachrichten, öffentliche Status‑Updates und die finale Lösung. Keine internen Tags, keine mitarbeiterinternen Notizen.
• Support‑Agent: sieht Kundenmeldungen und nur die Kundendaten, die zur Problemlösung nötig sind, z. B. Bestellhistorie. Kann interne Notizen und Tags hinzufügen.
• Manager: sieht alles, was Agents sehen, plus Zuweisungssteuerung und SLA‑Überschreibungen.
• Inhaber/Admin: sieht alle Tickets im Unternehmen und hochrangige Reports.

PII von Kunden ist die nächste Falle. Support braucht oft Telefonnummer oder Adresse, aber nicht bei jedem Ticket. Eine gute Regel: Zeigen Sie sensible Felder nur, wenn der Workflow sie erfordert. Beispiel: Adresse nur nach Auswahl „Versandproblem“ anzeigen und wieder verbergen, wenn das Ticket geschlossen wird.

Halten Sie interne Kennzahlen getrennt von der Kundenerfahrung. Werte wie „Zeit bis erste Antwort“, „Agentenbewertung“ oder „an Rechtsabteilung eskaliert“ gehören nur in Mitarbeiter‑ und Manager‑Ansichten.

Praxisbeispiel 3: Betrieb und Lieferverfolgung

Stellen Sie sich ein Lager und ein Außenteam vor, die den ganzen Tag Lieferungen abwickeln. Eine Person plant Routen, eine andere kommissioniert, Fahrer erledigen Stopps. Wenn Ihre App falsche Details an die falschen Leute zeigt, ist das nicht nur peinlich — es kann Kundendaten, Preise oder interne Notizen offenlegen.

Beginnen Sie damit, für jede Gruppe klar zu trennen, was sie täglich braucht.

Mitarbeiter (Kommissionierer und Fahrer) brauchen meist eine enge, aufgabenfokussierte Ansicht. Ein Fahrer sollte beim Öffnen der App nur die ihm für den Tag zugewiesenen Jobs sehen, mit Stoppreihenfolge, Kontaktdaten für den Stopp und Lieferanweisungen. Er sollte nicht die komplette Kundenliste durchstöbern oder Jobs anderer Fahrer sehen. Wenn er eine Schicht abdeckt, kann ein Manager den Job umverteilen, statt weite Zugriffsrechte zu vergeben.

Manager brauchen das breitere Bild: Dienstpläne aller Teams, Lagerbestände und laufende Probleme (verspätete Lieferungen, fehlgeschlagene Zustellungen, beschädigte Artikel, fehlende Unterschriften). Sie brauchen Werkzeuge, um Ausnahmen zu lösen: Stopp neu zuweisen, Route splitten oder eine Inventuranpassung genehmigen.

Kunden brauchen die kleinste Ansicht: nur ihren Lieferstatus. Sie können ETA verfolgen, Liefernachweis sehen und Updates erhalten wie „out for delivery“ oder „verspätet“. Sie dürfen niemals andere Kunden, Tagesrouten oder interne Ausnahme‑Notizen sehen.

Eine einfache Durchsetzungsregel ist, Daten nach Zuweisung und Kundenkonto zu scopen. Ein Delivery‑Job kann lesbar sein nur für (1) das zugewiesene Teammitglied, (2) Manager und (3) den zum Auftrag gehörenden Kunden.

Schritt für Schritt: Rollen und Berechtigungen entwerfen

Benennen Sie Ihre Nutzergruppen in klarer Sprache. „Inhaber“, „Manager“, „Mitarbeiter“ und „Kunde“ sind ein guter Anfang, aber nur, wenn sie zur Arbeitsweise Ihres Unternehmens passen. Schreiben Sie für jede Gruppe in einem Satz, wie Erfolg aussieht, z. B. „Manager können Arbeit zuweisen und Teamleistung sehen, ohne Gehaltsdaten einzusehen.“

Als Nächstes ordnen Sie Aktionen den Datenbereichen zu. Denken Sie nicht zuerst in Bildschirmen, sondern in den vorhandenen Daten: Welche Daten gibt es und was dürfen Menschen damit tun. Ein einfaches Raster auf Papier reicht:

• Listen Sie Rollen und Datenbereiche auf (Kunden, Bestellungen, Rechnungen, Tickets, Reports).
• Schreiben Sie für jede Rolle die benötigten Aktionen auf (anzeigen, erstellen, bearbeiten, genehmigen, exportieren).
• Legen Sie den Scope für jede Aktion fest (eigene, Team oder alle).
• Definieren Sie „Team“ klar (Filiale, Region, Projekt oder direkte Unterstellte).
• Markieren Sie „niemals“-Punkte (z. B. Kunden sehen niemals interne Notizen).

Testen Sie den Entwurf mit realen Aufgaben, nicht mit Vermutungen. Gehen Sie typische Abläufe durch wie „Bestellung erstellen“, „Ticket lösen“ oder „Bericht herunterladen“. Wenn eine Aufgabe Sie zwingt, zu breite Rechte zu vergeben, fehlt vermutlich eine feinere Berechtigung (z. B. „Summen anzeigen“ ohne „Export“).

Fügen Sie Genehmigungen ein, wo Geld oder sensible Änderungen betroffen sind. Mitarbeiter können eine Rechnung entwerfen, aber nur ein Manager darf sie genehmigen oder versenden. Mitarbeiter können Lieferadressen bearbeiten, aber Bankdaten dürfen nur der Inhaber ändern.

Häufige Fehler, die versehentliche Datenlecks verursachen

Die meisten Datenlecks in kleinen Teams sind keine Hacks. Sie passieren, wenn die App jemandem mehr Zugriff gibt, als der Job erfordert. Rollen und Berechtigungen versagen, wenn sie einmal gesetzt und nie wieder überprüft werden.

Ein verbreitetes Muster: Jemand erhält „Admin“ nur fürs Setup. Die Eile vergeht, die Rechte bleiben. Wochen später exportiert diese Person eine komplette Kundenliste „für einen Bericht“ und private Daten liegen in einer Tabelle.

Wiederkehrende Fehler:

• „Admin“ als Standardrolle, weil das Supportaufwand vermeidet
• Breite Exporte (Kunden, Kontakte, Auszahlungen, Rechnungen) ohne Limits oder Audit
• Ein gemeinsames Login für Schichtteams, so dass niemand mehr nachvollziehen kann, wer was angesehen oder geändert hat
• Hauptbildschirme sichern, aber Nebentüren vergessen: mobile Ansichten, PDFs, E‑Mail‑Benachrichtigungen, Anhänge und vorausgefüllte Formulare
• Kein Offboarding: Ex‑Mitarbeiter behalten Zugang zur App, E‑Mail oder gespeicherte Sessions auf dem Handy

Die Nebentüren sind am tückischsten. Sie sperren Mitarbeiter von einer Vertragsseite, schicken ihnen aber die PDF per E‑Mail. Oder die mobile Ansicht zeigt ausgeblendete Felder, die auf dem Desktop verborgen sind.

Eine praktische Lösung: Behandeln Sie Exporte und Downloads als eigene Berechtigungen, nicht als normalen „Anzeigen“-Recht. Wenn eine Rolle eine Liste braucht, geben Sie stattdessen eine gefilterte Ansicht statt eines kompletten Exports.

Schnellchecks, bevor Sie echte Nutzer einladen

Bevor Sie echte Nutzer einladen, gehen Sie davon aus, dass jemand auf das falsche Feld klickt, den Bildschirm teilt oder eine Datei herunterlädt, die er nicht darf. Ein paar Checks jetzt ersparen später viel Arbeit.

Starten Sie mit sicheren Defaults. Ein neuer Nutzer landet automatisch in der niedrigsten Rolle, ohne Zugang zu Geld, Exporten oder Admin‑Einstellungen. Wenn jemand mehr braucht, machen Sie die Änderung bewusst.

Testen Sie die Kundenerfahrung wie ein Außenstehender. Kunden dürfen nur ihre eigenen Datensätze sehen, auch wenn sie URLs ändern, suchen oder filtern. Ein schneller Test: Melden Sie sich als Kunde A an und versuchen Sie, Kunde B per Name, Rechnungsnummer oder Ticket‑ID zu finden.

Fünf schnelle Checks, die die meisten Lecks entdecken:

• Sensitive Felder standardmäßig verbergen (Gehalt, Kosten/Marge, persönliche IDs, interne Notizen)
• Exporte und Massenaktionen einschränken
• Genehmigungen hinzufügen, wo Fehler teuer sind (Rückerstattungen, Auszahlungen, Rollenänderungen)
• Sicherstellen, dass Scope überall durchgesetzt wird (Bildschirme, Suchergebnisse, API‑Antworten)
• Auditfähigkeit prüfen: Wer hat was und wann geändert, inklusive Rollenupdates und Zahlungsaktionen

Machen Sie einen „Unfall‑Test“. Bitten Sie eine Kollegin, eine echte Aufgabe mit einem Mitarbeiterkonto zu erledigen, und versuchen Sie dieselbe Aufgabe mit einem Kundenkonto. Wenn der Kunde interne Preise sehen, komplette Kundenlisten herunterladen oder eine Rückerstattung auslösen kann, sind Ihre Berechtigungen zu weit gefasst.

Ein realistisches Szenario: Eine App für Mitarbeiter und Kunden

Eine häufige Anfrage beginnt so: Ein Kunde möchte ein Portal zum „Status prüfen“, aber Ihr Team nutzt dasselbe System zur Auftragsabwicklung. Ohne klare Rollen und Berechtigungen kann das Portal interne Notizen, Aufträge anderer Kunden oder mitarbeiterinterne Preise offenbaren.

Stellen Sie sich eine Druckerei vor: Ein Auftrag läuft von Angebot über Produktion bis Lieferung und Rechnung in einer App.

Das sollte jede Rolle in diesem Ablauf sehen:

• Inhaber: alles, inklusive Gewinn, Mitarbeiterleistung und aller Kundenkonten
• Manager: alle Aufträge ihres Teams, interne Notizen und die Möglichkeit, Rabatte und Rückerstattungen zu genehmigen
• Mitarbeiter: nur die ihnen zugewiesenen Aufträge, der nächste Schritt zur Ausführung und die Kontaktdaten, die sie brauchen
• Kunde: nur die eigenen Aufträge, hoher Status (Genehmigt, In Produktion, Verschickt), Liefernachweis und zu bezahlende Rechnungen

Zwei Randfälle bringen das Modell oft durcheinander.

Erstens: Ein Manager übernimmt vorübergehend ein anderes Team. Schalten Sie ihn nicht auf Inhaber. Geben Sie stattdessen zeitlich begrenzten Zugriff, z. B. Zugriff auf Team B‑Aufträge für 7 Tage. Nach Ende der Vertretung läuft der Zugriff ab.

Zweitens: Ein VIP‑Kunde verlangt „mehr Einblick“. Geben Sie mehr Kontext, ohne mehr Daten freizugeben. Zeigen Sie eine erweiterte Zeitachse oder einen eigenen Nachrichtenverlauf, aber behalten Sie interne Notizen (z. B. „Kunde hat offene Zahlungen“ oder „Neudruck wegen unseres Fehlers“) für Mitarbeiter vor.

Verantwortlichkeiten ändern sich — betrachten Sie Zugriff als etwas, das geprüft werden muss, nicht als Einmalaufgabe. Wenn jemand die Rolle wechselt, nehmen Sie nicht einfach Rechte hinzu. Entfernen Sie, was nicht mehr nötig ist, und fügen Sie dann die kleinste notwendige Menge an Rechten für die neue Aufgabe hinzu.

Nächste Schritte: Eine klare Zugriffsrichtlinie festlegen und umsetzen

Starten Sie klein. Wählen Sie einen Workflow, der am wichtigsten ist, z. B. „Rechnung erstellen und Zahlung entgegennehmen“ oder „Support‑Ticket erfassen und beantworten“. Definieren Sie Rollen und Berechtigungen für diesen einen Ablauf zuerst, dann erweitern Sie.

Halten Sie die Regeln in einer einfachen Tabelle: Rolle, was sie tun darf, was sie nicht darf, und eventuelle Grenzen (z. B. „nur eigene Datensätze“ oder „nur Standort X“). Wenn jemand fragt: „Sehen Mitarbeiter Kundentelefonnummern?“, sollte die Tabelle in Sekunden antworten.

Ein pragmatisches Vorgehen zur Einführung:

• Entwerfen Sie die Tabelle für Ihren ersten Workflow (Inhaber, Manager, Mitarbeiter, Kunde)
• Ordnen Sie jede Regel konkreten Daten (inklusive Feldern) und Aktionen zu (anzeigen, bearbeiten, exportieren, löschen)
• Erstellen Sie Demo‑Konten für jede Rolle und testen Sie reale Tasks Ende‑zu‑Ende
• Starten Sie mit einer kleinen Gruppe und erweitern Sie erst, wenn keine Überraschungen auftreten
• Prüfen Sie Zugriffe quartalsweise und sofort nach organisatorischen Änderungen (neuer Manager, neues Team, neuer Dienstleister)

Wenn Sie auf AppMaster (appmaster.io) bauen, hilft es, Rollen gemeinsam mit Ihrem Datenmodell und der Geschäftslogik zu planen, damit dieselben Regeln konsistent in Web‑Apps, mobilen Apps und API‑Endpoints gelten.

Wenn Sie möchten: Erstellen Sie noch heute Ihre erste Rollentabelle und probieren Sie sie an einem Workflow aus. Dieser einzelne Schritt verhindert die meisten versehentlichen Datenlecks.