Organization-Wide Defaults (OWD) in Salesforce erklärt

Org-Wide Defaults sind der Ausgangspunkt jeder Sharing-Entscheidung in Salesforce. Setzen Sie sie richtig, hat der Rest des Modells — Rollenhierarchie, Sharing Rules, Freigaben — ein sauberes Fundament zum Aufbauen. Setzen Sie sie falsch (meist zu offen), bringt auch die cleverste Sharing Rule keine Rettung. Dieser Leitfaden erklärt, was sie sind und wie Sie sie richtig setzen.

Was Org-Wide Defaults sind

Organization-Wide Defaults (OWD) definieren pro Objekt die Basiszugriffsstufe, die Benutzer auf Datensätze haben, die sie nicht besitzen. Sie sind die restriktivste Einstellung; alles andere existiert, um den Zugriff über diese Basis hinaus zu öffnen.

Org-Wide Defaults sind das Fundament. Rollenhierarchie und Sharing Rules sind die Wege, bestimmte Personen darüber hinaus zu heben. Mit Standardmitteln kommen Sie nicht darunter.

Deshalb ist OWD die erste Ebene im Modell des Datensatzzugriffs.

Die Zugriffsstufen

Die OWD jedes Objekts ist auf einen dieser Werte gesetzt:

Stufe	Wer darf was sehen / tun
Private	Nur der Eigentümer (und Benutzer über ihm in der Rollenhierarchie) kann ansehen
Public Read Only	Jeder mit Objektzugriff kann ansehen; nur der Eigentümer kann bearbeiten
Public Read/Write	Jeder mit Objektzugriff kann ansehen und bearbeiten
Controlled by Parent	Der Zugriff folgt dem zugehörigen Master-/Parent-Datensatz

Manche Objekte bieten zusätzliche Varianten (z. B. Read/Write/Transfer für Leads und Cases).

Interne vs. externe Defaults

Bei vielen Objekten können Sie separate interne und externe Org-Wide Defaults festlegen. Der externe Default steuert Experience-Cloud- (Community-) und Portal-Benutzer und kann — und sollte in der Regel — restriktiver sein als der interne, damit externe Zielgruppen nicht den breiteren Zugriff erben, den Ihre Mitarbeiter haben.

Best Practice: restriktiv starten, bewusst öffnen

Die goldene Regel:

Setzen Sie die OWD auf die restriktivste Stufe, die das Geschäft verträgt — meist Private — und öffnen Sie den Zugriff dann mit der Rollenhierarchie und Sharing Rules.

Der Grund liegt in der Richtung des Sharing-Modells. Zugriff ist additiv: Sie können auf einer Private-Basis jederzeit Zugriff hinzufügen, aber Sie können mit Sharing Rules keinen Zugriff abziehen, den eine zu offene OWD bereits allen gewährt hat. Mit Private zu starten hält das Modell zielgerichtet, prüfbar und leicht nachvollziehbar.

Eine schnelle Entscheidungshilfe

Fragen Sie sich für jedes Objekt: Soll ein beliebiger Mitarbeiter, der diesen Datensatz nicht besitzt, ihn standardmäßig sehen?

Nein, niemals → Private.
Er darf lesen, aber nicht ändern → Public Read Only.
Jeder darf ihn frei bearbeiten → Public Read/Write (selten für sensible Daten).

Eine OWD nach dem Go-Live ändern

Eine OWD zu öffnen (z. B. Private → Public Read Only) ist risikoarm — es gewährt nur mehr Zugriff.
Eine OWD zu verschärfen (Public → Private) ist die Änderung, die Planung erfordert. Sie löst eine Neuberechnung des Sharings aus und kann Zugriff entfernen, auf den sich Benutzer aktuell verlassen. Testen Sie in einer Sandbox und kommunizieren Sie, bevor Sie ausliefern.

Warum OWD das Erste ist, was Sie prüfen sollten

Weil jeder andere Mechanismus darauf aufbaut, bläht eine zu offene OWD still und leise auf, was alle sehen können — und das bleibt unsichtbar, bis jemand fragt: „Moment, wer kann das alles eigentlich sehen?” Wenn Sie Zugriffe überprüfen, ist die OWD die Basis, die die größten Überraschungen erklärt.

AgentForceAccess macht diese Basis lesbar: Fragen Sie, warum ein Benutzer einen Datensatz sehen kann, und es sagt Ihnen, wenn die Antwort schlicht „der Org-Wide Default ist Public” lautet — im Gegensatz zu einer bestimmten Regel oder Freigabe — damit Sie die Ursache auf der richtigen Ebene beheben.

Häufig gestellte Fragen

Was bedeutet jede OWD-Zugriffsstufe?

Private — nur der Eigentümer und Benutzer über ihm in der Rollenhierarchie sehen den Datensatz. Public Read Only — jeder mit Objektzugriff kann ihn ansehen, nur der Eigentümer kann ihn bearbeiten. Public Read/Write — jeder kann ansehen und bearbeiten. Controlled by Parent — der Zugriff folgt dem zugehörigen Master-Datensatz.

Warum sollte ich mit Private starten?

Weil Sharing additiv ist: Sie können den Zugriff mit Rollenhierarchie und Sharing Rules jederzeit erweitern, aber Sie können sie nicht nutzen, um Zugriff zurückzunehmen, den eine zu offene OWD bereits gewährt hat. Mit Private zu starten und bewusst zu erweitern hält das Modell zielgerichtet und prüfbar.

Was sind interne vs. externe Org-Wide Defaults?

Bei vielen Objekten können Sie einen separaten Default für externe Benutzer festlegen — Experience-Cloud-/Community- und Portal-Benutzer — der restriktiver sein kann als der interne Default. So wird verhindert, dass externe Zielgruppen den Zugriff Ihrer internen Benutzer erben.

Kann ich den Zugriff für ein Objekt nach dem Go-Live senken?

Ja, aber das Verschärfen einer OWD löst eine Neuberechnung des Sharings aus und kann Zugriff entfernen, auf den sich Benutzer aktuell verlassen — testen Sie also in einer Sandbox und kommunizieren Sie die Änderung. Eine OWD zu öffnen ist risikoarm; sie einzuschränken ist die Änderung, die sorgfältige Planung erfordert.