Profiles vs. Permission Sets vs. Sharing Rules in Salesforce

„Profiles vs. Permission Sets vs. Sharing Rules” bringt viele durcheinander, weil die drei keine Alternativen sind — sie beantworten unterschiedliche Fragen und arbeiten zusammen. Profiles und Permission Sets entscheiden, was du mit einem Objekt tun kannst; Sharing Rules entscheiden, auf welchen Datensätzen du es tun kannst. So greifen sie ineinander.

Das Zwei-Prüfungen-Modell

Jeder Datensatzzugriff in Salesforce durchläuft zwei voneinander unabhängige Prüfungen:

1. Objekt- und Feldprüfung — aus Profiles und Permission Sets: Hat der Nutzer CRUD auf dem Objekt und Field-Level Security auf den Feldern?
2. Datensatzprüfung — aus dem Sharing-Modell: Gewähren die Org-Wide Defaults, die Rollenhierarchie oder eine Sharing Rule diesen konkreten Datensatz?

Die Objektberechtigung ist das Tor. Das Sharing entscheidet, welche Datensätze hindurchgelangen. Beides muss bestehen.

Das ist das Fundament des gesamten Datensatz-Zugriffsmodells.

Profiles und Permission Sets: das „Was darf ich tun”

Diese steuern den Zugriff auf Objektebene und mehr:

• CRUD pro Objekt (Read / Create / Edit / Delete).
• Field-Level Security — welche Felder sichtbar/bearbeitbar sind.
• Systemberechtigungen, App- und Tab-Sichtbarkeit sowie das zugriffsumgehende View All / Modify All.

Profile vs. Permission Set

• Ein Nutzer hat genau ein Profile — historisch die Grundlage der Berechtigungen.
• Ein Nutzer kann viele Permission Sets (und Permission Set Groups) darüberlegen.

Der moderne, empfohlene Ansatz ist Permission-Set-geführt: Halte das Profile minimal und gewähre den Zugriff über Permission Sets, denn sie lassen sich leichter zuweisen, wiederverwenden und auditieren als ein Wildwuchs an Profiles. (Rollen treiben dagegen die Sharing-Hierarchie an — eine von den Profiles getrennte Achse.)

Sharing Rules: das „Welche Datensätze”

Sharing Rules berühren den Objekt- oder Feldzugriff überhaupt nicht. Sie erweitern lediglich den Zugriff auf Datensatzebene — nach Eigentümerschaft oder Kriterien — zusätzlich zum Org-Wide Default. Wie sie sich zur Hierarchie verhalten, zeigt Sharing Rules vs. Rollenhierarchie.

Entscheidend: Eine Sharing Rule kann eine fehlende Objektberechtigung nicht retten. Kein Read auf Opportunities bedeutet keine Opportunities, egal wie viele Sharing Rules auf den Nutzer zeigen.

Wo Berechtigungen das Sharing außer Kraft setzen

Es gibt eine Stelle, an der sich die Ebenen kreuzen: View All und Modify All (auf Objektebene) sowie View All Data / Modify All Data (systemweit). Diese umgehen das Sharing-Modell vollständig — ein Nutzer mit ihnen sieht jeden Datensatz, unabhängig von OWD, Hierarchie oder Rules. Weil sie so mächtig sind, sind sie das Erste, was du prüfen solltest, wenn der Zugriff falsch aussieht. Siehe View All / Modify All — die Umgehung, auf die du achten musst.

Alles zusammengeführt

Frage	Beantwortet durch
Kann der Nutzer dieses Objekt überhaupt öffnen?	Profile / Permission Set (CRUD)
Kann er dieses Feld sehen?	Field-Level Security
Welche Datensätze des Objekts kann er sehen?	Sharing-Modell
Kann er das Sharing umgehen?	View All / Modify All

Um zu verstehen, warum ein Nutzer einen Datensatz erreichen kann oder nicht, liest du beide Achsen zusammen — Objekt-/Feldberechtigungen und das Sharing, das für diesen Datensatz gilt.

Beide Achsen auf einmal lesen

Die Reibung entsteht dadurch, dass diese in verschiedenen Teilen des Setups leben — Profiles und Permission Sets an einem Ort, das Sharing-Modell an einem anderen — und du sie im Kopf miteinander verschneiden musst. AgentForceAccess übernimmt diese Verschneidung für dich: Frag, was ein Nutzer mit einem Datensatz tun kann, und es berücksichtigt Objektberechtigungen, Field-Level Security und das Sharing-Modell gemeinsam — mit Beleg dafür, was den Zugriff genau gewährt oder blockiert.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Objektzugriff und Datensatzzugriff?

Der Objektzugriff (aus Profiles und Permission Sets) entscheidet, ob ein Nutzer ein Objekt überhaupt anfassen darf — Read, Create, Edit, Delete — und welche Felder er sieht. Der Datensatzzugriff (das Sharing-Modell) entscheidet, welche konkreten Datensätze dieses Objekts er sehen kann. Du brauchst beides.

Profiles oder Permission Sets — was sollte ich verwenden?

Beides existiert, doch der moderne Ansatz ist Permission-Set-geführt: Halte Profiles als minimale Grundlage und gewähre zusätzlichen Zugriff über Permission Sets und Permission Set Groups. Ein Nutzer hat ein Profile, kann aber viele Permission Sets halten, was die Zuweisung und das Auditing des Zugriffs erleichtert.

Gewähren Sharing Rules Objektzugriff?

Nein. Sharing Rules erweitern nur den Zugriff auf Datensatzebene. Hat ein Nutzer über sein Profile oder ein Permission Set keine Read-Berechtigung auf einem Objekt, wird ihm keine Sharing Rule auch nur einen einzigen Datensatz zeigen. Die Objektberechtigung ist das Tor; das Sharing entscheidet, welche Datensätze hindurchgelangen.

Wie kann ein Profile eine Sharing Rule außer Kraft setzen?

Über View All und Modify All. Diese Berechtigungen — auf Objektebene oder „View All Data"/„Modify All Data" systemweit — lassen einen Nutzer jeden Datensatz unabhängig vom Sharing sehen oder bearbeiten. Sie stehen über dem Sharing-Modell, sodass eine Berechtigung überschreiben kann, was das Sharing einschränken würde.