Berechtigungskonzepte im Vergleich: Standard und APC (inkl. Dynamic)

ContractHero bietet zwei Berechtigungsmodelle, die Verwaltungsaufwand und Sicherheit ausbalancieren — Standard und APC. Welches aktiv ist, steuert eine Organisationseinstellung: die beiden Modelle laufen nicht parallel, sondern alternativ. Dynamic ist kein drittes Modell, sondern eine Funktion innerhalb von APC.

Ihr Vorteil

Das passende Konzept reduziert Pflegeaufwand und Sicherheitsrisiko. Was im Standard 15 Rollen braucht (z. B. 3 Länder × 5 Funktionen), lässt sich im APC oft in einer einzigen Rolle abbilden. Mit Dynamic übernimmt ContractHero zusätzlich die personenbezogene Vertragszuweisung — etwa für Account- oder Kunden-Pools, in denen jeder Customer Success Manager seine eigenen Verträge sehen soll.

Ausgangspunkt: im Standard sieht jeder alles

Solange niemand eine eigene, eingeschränkte Rolle hat, kann jede Person jeden Vertrag sehen und bearbeiten. Sie schränken von einem offenen Zustand aus ein, Sie bauen nicht von null auf. Für viele Unternehmen genügt das. Sobald Gehälter, Konditionen oder Verträge einzelner Bereiche nicht für alle sichtbar sein sollen, vergeben Sie Rollen.

Grundprinzipien (gelten für beide Modelle)

Inclusion-only: Sie definieren, was jemand sehen oder bearbeiten darf — es gibt keine „Verbotsregeln". Was keine Regel abdeckt, ist nicht zugänglich.
Vier Zugriffsstufen: Voll (lesen, schreiben & löschen), Schreiben (lesen & bearbeiten, ohne Löschen), Leserechte und Kein Zugriff. Jede höhere Stufe schließt die niedrigere ein. Details zur mittleren Stufe finden Sie unter Schreibrechte: Bearbeiten erlauben, Löschen verhindern.
„Kein Zugriff" verbirgt vollständig. Verträge, auf die keine Regel greift, erscheinen für die betroffene Person auch nicht in der Suche — sind also nicht nur ausgegraut, sondern gar nicht vorhanden. Im APC ist „Kein Zugriff" das Fehlen einer passenden Regel; im Standard können Sie es pro Kategorie explizit auswählen.
Großzügigste Berechtigung gewinnt: Hat eine Person mehrere Rollen, addieren sich die Rechte als ODER-Logik — Voll überschreibt Schreiben, Schreiben überschreibt Leserechte, Leserechte überschreibt Kein Zugriff.
Eigentümer sehen immer alles. Wer als Eigentümer der Organisation eingetragen ist, sieht jeden Vertrag — unabhängig von allen Rollen — und kann Rollen auch ändern. Empfehlung: mindestens zwei Eigentümer pro Account, damit das System nie ohne Admin dasteht (Urlaub, Ausscheiden).

Rollen-Grundlagen

Eigentümer (engl. Owner) — sieht und bearbeitet alles.
Mitglied mit Rolle — sieht nur das, was die Rolle erlaubt. Mehrere Rollen pro Person sind möglich; die Zugriffe addieren sich.

Woran der Zugriff festgemacht werden kann

Eine Rolle greift auf Vertrags-Merkmale zu, nicht auf Feld-Inhalte. Was als Bedingung in einer Regel funktioniert und was nicht:

Geht:

Bereich oder Team
Gesellschaft (Mehrmandantenfähigkeit)
Vertragskategorie (Arbeitsvertrag, NDA, Mietvertrag …)
Status des Vertrags (Entwurf, Aktiv, Gekündigt, Beendet)
Vertragspartner
Art des Vertrages und Laufzeitart
Zahlungsart und Zahlungszyklus

Geht nicht:

Vertragswert — eine Regel wie „alles über 100.000 Euro nur für die Geschäftsführung" lässt sich nicht bauen.
Im Vertrag genannte Personen („nur Verträge, in denen Person X vorkommt")
Datumsangaben („nur Verträge, die nach 2024 abgeschlossen wurden")
Einzelne Verträge — eine Regel greift immer auf ein Vertrags-Merkmal, nie auf einen konkreten Vertrag per ID.

Für Fälle, die eine der „geht nicht"-Bedingungen brauchen, arbeiten wir mit einer eigenen Kategorie — die Verträge, die anders behandelt werden sollen, wandern in eine separate Kategorie, auf die dann gezielt Rechte gesetzt werden.

Grenzfall: einzelne Felder lassen sich nicht verbergen

Wer einen Vertrag sehen darf, sieht alle Felder darin. Ein Gehalt lässt sich nicht innerhalb eines sonst sichtbaren Arbeitsvertrags verstecken — die Feldsichtbarkeit ist immer an die Vertragssichtbarkeit gekoppelt.

Lösung: Verträge mit sensiblen Feldinhalten gehören in eine eigene Kategorie, auf die dann per Rolle gezielt Rechte gesetzt werden. Typische Beispiele: eigene Kategorie für Geschäftsführer-Verträge, für M&A-relevante Verträge oder für besonders sensitive Kunden.

Die zwei Konzepte im Überblick

Eigenschaft	Standard	APC
Steuerung über	Kategorie + Team	Bedingungen (Kategorie, Status, Team, Vertragspartner u. a.), mehrere Regeln pro Rolle
Cross-Team in einer Rolle	Nein	Ja
Mehrere Regeln pro Rolle	Nein	Ja, ODER-verknüpft
Zugriffsstufen	Voll / Schreiben / Leserechte / Kein Zugriff (pro Kategorie wählbar)	Voll / Schreiben / Leserechte (Inclusion-only; Kein Zugriff = keine Regel)
Personenbezogene Zuweisung (Dynamic)	Nein	Ja, als Funktion innerhalb von APC
Plan	Alle Pläne	Ab Professional

1. Standard — für kleine, klar strukturierte Organisationen

Im Standard-Modell läuft der Zugriff über die Kombination Team × Kategorie. Pro Kategorie wählen Sie eine Stufe: Voll, Schreiben, Leserechte oder Kein Zugriff.

Passend für:

1–3 Teams mit sauber getrennten Zuständigkeiten (z. B. HR sieht Arbeitsverträge, Finance sieht Finanzverträge).
Organisationen ohne Cross-Team-Verantwortung.

Grenze:

Skaliert schlecht bei vielen Dimensionen. 3 Länder × 5 Funktionen = 15 fast identische Rollen. Hier lohnt der Wechsel auf APC.

2. APC — Advanced Permission Concept für teamübergreifende Setups

APC ist ContractHeros regelbasiertes Berechtigungs-Modell, ab dem Professional-Plan verfügbar. Statt einer starren Rolle pro Team kombinieren Sie mehrere Regeln zu einer Rolle, die teamübergreifend wirkt.

Eigenschaften:

Rollen wirken teamübergreifend statt pro Team.
Eine Rolle kann mehrere Regeln bündeln (ODER-Logik), z. B. „alles lesen, eigenen Bereich bearbeiten" in einer einzigen Rolle.
Pro Regel kombinieren Sie mehrere Bedingungen (UND-Logik), z. B. Kategorie = NDA UND Status = Aktiv UND Team = Legal.
Pro Regel wählen Sie die Zugriffsstufe separat — eine Rolle kann also in einem Bereich Voll und in einem anderen nur Leserechte gewähren.
Verfügbare Bedingungstypen: Kategorie, Status, Team, Laufzeitart, Vertragspartner, Zahlzyklus, Zahlungsart, Art des Vertrages, Art.

Beispiel: NDAs pro Bereich, mit Cross-Read für Legal und Buchhaltung

Jedes NDA soll dem Bereich gehören, der es geschlossen hat. Die Rechtsabteilung soll alle NDAs sehen und bearbeiten können, die Buchhaltung soll alles mitlesen können:

Rolle	Erlaubnis	Zugriffsstufe
Einkauf	NDAs des Einkaufs	Voll
Personal	NDAs des Personalbereichs	Voll
Recht	NDAs aller Bereiche	Voll
Buchhaltung	alle Verträge aller Bereiche	Leserechte

Die Rolle „Recht" braucht dafür eine Regel, in der alle Bereiche zusammen ausgewählt sind — nicht eine pro Bereich. Ein Modell mit fünf Bereichen bleibt dadurch überschaubar, statt mit jeder Abteilung zu wachsen.

Typischer Effizienzgewinn:

Finance/Operations über 10 Länder: 10 Rollen → 1 APC-Rolle mit zehn Regeln.

Passend für:

Mehrere Teams mit überlappenden Zuständigkeiten.
Setups, in denen kombinierte Regeln pro Rolle den Pflegeaufwand spürbar reduzieren.

Dynamic — eine Funktion innerhalb von APC

Wenn Zuständigkeiten nicht zu Kategorien oder Teams passen, sondern an einzelne Personen gebunden sind, nutzen Sie Dynamic-Regeln innerhalb von APC. Statt fester Werte verweist die Regel auf personenbezogene Werte am Mitglied — und weist Verträge automatisch pro Person zu.

So funktioniert's:

Am Mitglied werden personenbezogene Werte hinterlegt — aktuell die Partner & Accounts (Vertragspartner) dieser Person.
Eine Dynamic-Regel referenziert diese Werte: „Vertragspartner = Partner & Accounts des Mitglieds".
Beim Login sieht jede Person nur die Verträge, deren Vertragspartner mit ihren hinterlegten Werten übereinstimmen.

Typischer Fall:

Kunden- / Account-Pools: Jeder Customer Success Manager sieht ausschließlich die Verträge seiner zugeteilten Kunden — ohne dass Sie pro Person eine eigene Rolle bauen müssen.

Wichtig:

Dynamic ist KEIN eigenständiger Modus — sie funktioniert nur, wenn APC für die Organisation aktiv ist.
Strukturierte Listenfelder erforderlich — Freitext- oder Checkbox-Felder funktionieren nicht für Dynamic-Matching.
Aktuell ist das personenbezogene Matching auf Partner & Accounts (Vertragspartner) beschränkt. Weitere personenbezogene Felder auf Anfrage.

Was Dynamic NICHT ist:

„Standort", „Ersteller/Uploader" oder „Wertebereiche" sind normale statische Regelbedingungen im APC — kein automatisches Pro-Person-Matching.

Wann was?

Standard — kleine Organisationen, Zuständigkeit = Team + Kategorie.
APC — mehrere Teams, kombinierte Regeln, ab Professional-Plan.
Dynamic (innerhalb von APC) — individuelle Zuständigkeit über Account- bzw. Partner-Pools.

Für APC und insbesondere Dynamic empfehlen wir die Abstimmung mit dem Customer-Experience-Team, damit Sie die Rollenstruktur von Anfang an sauber aufsetzen.

Setup vorbereiten — was Sie mitbringen sollten

Bevor Sie mit dem Aufsetzen (oder mit uns) starten, klären Sie zwei Fragen intern. Beide lassen sich ohne Systemwissen beantworten — und beschleunigen die Modellierung später deutlich.

Frage 1: Welche Bereiche gibt es, und wessen Verträge muss jeder davon außer den eigenen noch lesen können?
Daraus entstehen die Rollen fast eins zu eins. Das bereichsübergreifende Lesen ergibt sich nicht von selbst und wird am häufigsten vergessen — bis jemand etwas nicht findet.

Frage 2: Woran erkennt man bei einem einzelnen Vertrag, zu welchem Bereich er gehört?
Steckt das heute nur im Ordnernamen oder im Kopf der Kolleg:innen, müssen wir es zuerst als Vertrags-Merkmal (Kategorie, Team, Vertragspartner o. ä.) erzeugen. Sonst fehlt das Merkmal, an dem die Abgrenzung hängt.

Der 4-Schritte-Prozess (mit CX-Team)

Für APC- und Dynamic-Setups begleiten wir Sie strukturiert:

Fragebogen vorab — Sie beschreiben Ihre Bereiche und wer worauf zugreifen soll, in Ihren Worten. Das Dokument bekommen Sie von uns.
Modell abstimmen — Wir übersetzen Ihre Antworten in Rollen und legen sie Ihnen als Liste vor. Jede Zeile ist ein prüfbarer Satz.
Aufsetzen — Wir legen die Rollen in Ihrem Zugang an.
Nachweis — Ein Testzugang zeigt, was eine Rolle wirklich sieht. Erst danach laden Sie Ihr Team ein.

Häufige Fragen

Kann ich Standard und APC parallel betreiben?

Nein. Pro Organisation läuft entweder Standard oder APC — gesteuert über eine zentrale Einstellung. Ein Wechsel zwischen den Modellen wird mit dem CX-Team gemeinsam durchgeführt.

Ist „Dynamic" ein eigenes Berechtigungskonzept?

Nein. Dynamic ist eine Funktion innerhalb von APC — APC-Regeln, die personenbezogene Werte am Mitglied nutzen. Ohne aktives APC keine Dynamic-Regeln.

Welche Zugriffsstufen gibt es?

Vier: Voll (lesen, schreiben & löschen), Schreiben (lesen & bearbeiten, ohne Löschen), Leserechte und Kein Zugriff. Jede höhere Stufe schließt die niedrigere ein. Im APC wählen Sie die Stufe pro Regel; „Kein Zugriff" ist dort keine wählbare Stufe, sondern das Fehlen einer Regel. Im Standard wählen Sie die Stufe pro Kategorie und können zusätzlich „Kein Zugriff" explizit setzen.

Was passiert, wenn jemand mehrere Rollen hat?

Die Zugriffe addieren sich nach ODER-Logik — die großzügigste Berechtigung gewinnt. Ein Vertrag, den Rolle A lesen darf und Rolle B bearbeiten darf, ist für die Person bearbeitbar. Rechte lassen sich nicht durch eine zweite, engere Erlaubnis einschränken.

Kann ich „alles außer X" verbieten?

Nein — ContractHero arbeitet ausschließlich mit Inclusion-Logik. „Alles außer Entwurf" bilden Sie ab, indem Sie alle Stati außer Entwurf explizit einschließen. Fällt Ihnen ein Verbot ein, formulieren Sie es trotzdem gegenüber dem CX-Team — wir drehen es gemeinsam in eine Inclusion-Regel um.

Kann ich einzelne Felder in einem Vertrag verstecken?

Nein. Wer einen Vertrag sehen darf, sieht alle Felder darin. Für sensible Inhalte (z. B. Gehalt in Arbeitsverträgen) legen Sie eine eigene Kategorie an und schränken den Zugriff darauf per Rolle ein.

Kann ich Zugriff auf einen einzelnen Vertrag beschränken?

Nein. Rollen greifen immer auf ein Vertrags-Merkmal (Kategorie, Status, Team, Vertragspartner …), nie auf einen konkreten Vertrag per ID. Für Einzelfall-Regelungen: eigene Kategorie oder eigenes Team anlegen.

Kann ich über den Vertragswert filtern?

Nein. Zahlen-Felder wie Vertragswert sind nicht als Bedingung verfügbar — auch nicht per Range („> 100.000 €"). Wer sensible Verträge über dem Wert schwärzen will, nutzt eine eigene Kategorie.

Welche personenbezogenen Felder kann Dynamic nutzen?

Aktuell Partner & Accounts (Vertragspartner) am Mitglied. Weitere personenbezogene Felder können auf Anfrage geprüft werden — die Voraussetzung ist immer ein strukturiertes Listenfeld.

Wechsel von Standard auf APC — was passiert mit bestehenden Rollen?

Beim Wechsel werden bestehende Rollen nicht automatisch in APC-Regeln übersetzt. Wir gehen die Rollenstruktur gemeinsam durch und bauen sie im APC-Modell neu auf — typischerweise mit deutlich weniger Rollen als vorher.

Gut zu wissen

Klein starten, dann erweitern. Beginnen Sie im APC mit einer Regel pro Rolle, testen Sie das Verhalten, und ergänzen Sie weitere Regeln nur, wenn der Anwendungsfall es verlangt. Komplexe Regelketten sind schwerer zu debuggen.
Sprechende Regelnamen sparen später Zeit. „Aktive Verträge lesen", „Lieferanten schreiben" sind später wiederfindbar — „Regel #2" nicht.
Nicht reflexartig Vollzugriff vergeben. Für Teams, die pflegen aber nicht löschen sollen, ist Schreiben die richtige Stufe. Das ist in Audits die kürzere Antwort auf „Wer kann löschen?".
Eigentümer brauchen keine Rolle. Wer Eigentümer ist, hat automatisch vollen Zugriff auf alles — eine zusätzliche APC-Rolle bringt nichts und stiftet nur Verwirrung. Mindestens zwei Eigentümer pro Account empfohlen.
Verträge, auf die keine Regel greift, verschwinden. „Kein Zugriff" bedeutet: nicht sichtbar, nicht suchbar, existiert für die betroffene Person nicht. Sicherheits-freundlich, aber überraschend, wenn jemand einen früher gesehenen Vertrag plötzlich nicht mehr findet.
Sensible Felder → eigene Kategorie. Da einzelne Felder nicht verborgen werden können, ist die eigene Kategorie das Werkzeug für sensitive Verträge. Beispiele: Geschäftsführer-Verträge, M&A, besonders sensible Kunden.
Dynamic ist mächtig — und still. Eine fehlerhaft konfigurierte Dynamic-Regel führt nicht zu Fehlermeldungen, sondern zu einer falschen Sichtbarkeit. Testen Sie nach jeder Änderung mit einem realen Mitgliedskonto.
Setup-Support nutzen. Beim Onboarding gehen wir Ihre Rollenstruktur gemeinsam durch — viele Kunden senden uns vorab eine Excel-Tabelle (Personen × Kategorien/Teams × Zugriffsstufe), daraus bauen wir das Modell auf.