„Gib mir bitte Zugriff“ kommt als ein Satz an und wird jedes Mal anders repariert: dem einen fehlt die CRM-Rolle, der andere hat das Feld „Verantwortlich“ verloren, der dritte ist an der Aufgabe schlicht nicht beteiligt. Solange das Portal klein ist, werden Rechte auf Zuruf vergeben. Bei fünfzig Mitarbeitenden wird daraus eine eigene Tätigkeit, und die Frage „wer sieht diesen Deal eigentlich“ hat keine kurze Antwort mehr.

Wie funktionieren Zugriffsrechte in Bitrix24?

Ein einheitliches Rechtesystem gibt es im Portal nicht — es sind drei, und sie lassen sich nicht ineinander überführen. Das CRM arbeitet mit einem Rollenmodell: Rolle plus Zugriffsstufe, getrennt für Lesen, Bearbeiten, Löschen, Export und Import. Aufgaben kennen keine Rollen; Sichtbarkeit entsteht aus Beteiligung — Ersteller, Verantwortlicher, Mitwirkender, Beobachter, Projektmitglied. Gruppen, Drive und der Aktivitätsstream bilden ein drittes Modell mit eigenen Privatsphäre-Einstellungen. „Zugriff auf den Deal und auf die zugehörige Aufgabe geben“ bedeutet in Bitrix24 (Alaio) also zwei verschiedene Einstellungen an zwei verschiedenen Stellen — und das ist der erste Grund, warum Zugriff vergeben wird und trotzdem nicht wirkt.

Wie richtet man CRM-Rechte ein?

Die Matrix liegt in den CRM-Einstellungen unter den Zugriffsrechten. Eine Rolle wird nicht nur an Personen vergeben, sondern auch an Abteilungen oder Gruppen — die Vergabe an Abteilungen ist die Variante, die überlebt, denn neue Mitarbeitende erben ihre Rechte in dem Moment, in dem sie in der Unternehmensstruktur auftauchen. Die Stufen sind die bekannten: kein Zugriff, eigene, eigene und der Abteilung, eigene und der Unterabteilungen, alle. Sie werden pro Entität gesetzt, bei Deals und Leads zusätzlich pro Phase — Bearbeitung im laufenden Deal erlauben, den gewonnenen einfrieren.

Zwei Regeln, die später Ärger sparen. Halten Sie die Zahl der Rollen klein: drei bis fünf, an Abteilungen gebunden statt eine Rolle pro Person, sonst ist die Matrix binnen eines Jahres unlesbar. Und behandeln Sie die Export-Spalte als eigene Entscheidung: die Stufe „alle“ mit aktiviertem Export ist der Weg, auf dem Kundendatenbanken ein CRM verlassen.

Warum sieht jemand einen Deal oder Kontakt nicht?

In neun von zehn Fällen ist die Rolle unschuldig und das Feld „Verantwortlich“ der Auslöser. Die Stufe „eigene“ heißt wörtlich „Datensätze, in denen ich verantwortlich bin“, deshalb entzieht ein Wechsel des Verantwortlichen dem bisherigen Besitzer den Zugriff sofort. Zweithäufigster Fall: verknüpfte Entitäten tragen eigene Rechte, jemand sieht den Deal, aber nicht das angehängte Unternehmen — die Karte wirkt halb leer, obwohl die Daten da sind. Dritter Fall: das Kennzeichen „für alle verfügbar“ auf der Karte, das genau diesen einen Datensatz an der ganzen Matrix vorbei öffnet.

Prüfen Sie in dieser Reihenfolge: welche Rolle hat die Person, welche Stufe gilt für genau diese Entität, wer ist verantwortlich, in welcher Abteilung steht sie in der Struktur, und ist sie womöglich Extranet-Nutzer. Der erste Schritt, an dem die Antwort von der Erwartung abweicht, ist die Ursache.

Wer sieht eine Aufgabe, und wie gibt man Zugriff darauf?

Aufgaben haben weder Rollen noch Stufen. Sichtbar ist eine Aufgabe für den Ersteller, den Verantwortlichen, die Mitwirkenden, die Beobachter, die Mitglieder des Projekts, zu dem sie gehört, und für Vorgesetzte bei Aufgaben ihrer unterstellten Mitarbeitenden. Das ist die vollständige Liste. „Rechte auf eine Aufgabe vergeben“ geht daher technisch nicht: der einzige Weg hinein führt über die Beteiligung, meist als Beobachter. Der Baustein Beobachter verwalten erledigt das als Prozessschritt — die Abteilungsleitung wird Beobachter, sobald ein Deal in die Freigabe geht, und wieder entfernt, wenn die Freigabe durch ist.

Warum sieht die Automatisierung einen Datensatz, den ein Mensch nicht sieht?

Weil beide unter verschiedenen Identitäten handeln. Native Automatisierungsregeln und Prozessaktionen laufen im Namen eines Nutzers — der Person, die die Regel angelegt hat, oder des Verantwortlichen — und stoßen genau an dessen Grenzen: sieht der Mensch den Datensatz nicht, scheitert auch die Aktion. Apps aus dem Market funktionieren anders: sie sprechen mit dem Portal über das Token, das eine Administratorin bei der Installation erteilt hat. Deshalb lesen und schreiben die Aktivitäten von Roboteka den Datensatz unabhängig davon, wer den Prozess gestartet hat.

Das beseitigt eine ganze Klasse stiller Fehlschläge und verschiebt eine Pflicht zu Ihnen: da Rechte nichts mehr aufhalten, gehört die Prüfung „darf diese Person das überhaupt“ als Bedingung in den Prozess und nicht in die Rechtematrix. Lief der Prozess dagegen gar nicht an, sind Rechte selten die Ursache — die Diagnosereihenfolge steht in warum Roboter nicht funktionieren, die Seite der externen Aufrufe in der Webhook-Fehlersuche.

Wie hält man Zugriffe automatisch aktuell?

CRM-Rollen selbst lassen sich nicht automatisieren: die REST-API bietet keine Methoden, um die Rechtematrix zu bearbeiten — sie bleibt ein manueller Bildschirm. Automatisieren lässt sich alles, wovon der Zugriff tatsächlich abhängt: der Verantwortliche, die Abteilung und die Beteiligten.

Wie geht es weiter

Beginnen Sie mit einer Inventur: notieren Sie die tatsächlich genutzten Rollen und ihre Deal-Stufen — die Hälfte entpuppt sich meist als Dublette. Schalten Sie danach den Export dort ab, wo er nicht gebraucht wird, und verlagern Sie die Rollenvergabe von Personen auf Abteilungen. Ergänzen Sie zuletzt einen Schritt, der den Verantwortlichen aktuell hält, denn an diesem einen Feld hängt der Großteil der CRM-Sichtbarkeit. Die übrigen Bausteine stehen im Roboterkatalog, das größere Bild im Leitfaden zu Geschäftsprozessen. Fehlt der Baustein, den Sie brauchen: beschreiben Sie die Aufgabe — Roboteka baut fehlende Aktivitäten kostenlos und stellt sie in die gemeinsame Bibliothek.