Beziehungen haben Folgen

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 7 von 10 im Kapitel Salesforce-Datenarchitektur, Kapitel 3 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Auch Felder sind Architektur · Weiter: Eigentümerschaft und Lebenszyklus

Die Frage, die dieses Modul beantwortet: Was wähle ich eigentlich, wenn ich zwei Salesforce-Objekte verbinde?

Eine Beziehung zu zeichnen ist leicht. In Kapitel 2 haben wir Linien gezeichnet und benannt: Ein Handelspartner schickt viele Ladelisten, eine Lieferung enthält viele Positionen, Crews und Lastwagen treffen sich in einer Crew-Zuweisung. Wir haben über Kardinalität, Optionalität und Historie gesprochen. Jetzt setzen wir diese Linien auf Salesforce um, und eine Linie im Diagramm beginnt, viel mehr Gewicht zu tragen.

Wenn ich auf Salesforce einen Beziehungstyp wähle, sage ich nicht nur, dass diese beiden Datensätze verbunden sind. Vielleicht entscheide ich auch, wem das untergeordnete Element gehört, ob es ohne das übergeordnete existieren kann, wer es sehen kann, was passiert, wenn das übergeordnete gelöscht wird, ob es zu einem anderen übergeordneten wechseln kann, ob ich es auf dem übergeordneten zusammenfassen kann und was passiert, wenn es Hunderttausende untergeordnete Datensätze gibt. Eine Beziehung ist nicht nur eine Linie. Sie trägt Verhalten.

Beginnen Sie mit der geschäftlichen Beziehung

Vor Nachschlagen oder Master-Detail gehen Sie zurück zum Geschäft. Nehmen Sie eine Lieferung und ihre Lieferpositionen, den Kühlschrank, die Installation, die Mitnahme. Kann eine Position ohne ihre Lieferung existieren? Nein. Wenn die Lieferung gelöscht wird, sollen ihre Positionen mitgehen? Ja. Brauchen die Positionen einen eigenen Eigentümer oder eine eigene Sicherheit? Eigentlich nicht. Sollte jemand eine Position von einer Lieferung auf eine andere verschieben? Hoffentlich nicht aus Versehen.

Nehmen Sie jetzt eine Lieferung und die Tour, auf der sie ist. Die Lieferung existiert, bevor sie einer Tour zugeordnet wird, sie kann auf eine andere Tour verschoben werden, wenn sich der Plan ändert, und das Löschen einer Tour sollte nie die Lieferungen darauf löschen. Zwei Eins-zu-viele-Linien, die im Diagramm gleich aussehen, mit völlig verschiedenem Verhalten. Beachten Sie, dass wir noch immer nicht «Nachschlagen» oder «Master-Detail» gesagt haben. Beschreiben Sie zuerst das Verhalten. Die Konfiguration setzt es um.

Die Beziehungstypen

Öffnen Sie den Bildschirm «New Field» (Neues Feld), und Salesforce bietet Ihnen eine Handvoll Beziehungstypen an (Object Relationships Overview (opens in a new tab), auf Englisch):

• Nachschlagebeziehung (Lookup): verbindet zwei Objekte. Das tägliche Brot der Salesforce-Beziehungen.
• Master-Detail: eine Eltern-Kind-Bindung, bei der das übergeordnete Element das untergeordnete steuert.
• Viele-zu-viele: kein eigener Feldtyp, sondern ein Muster: ein Salesforce-Verbindungsobjekt (Junction Object), ein benutzerdefiniertes Objekt mit zwei Master-Detail-Beziehungen.
• Selbstbeziehung: eine Nachschlagebeziehung von einem Objekt auf sich selbst.
• Hierarchisch: eine besondere Nachschlagebeziehung, die es nur auf dem Objekt User (Benutzer) gibt, etwa für die Führungskraft eines Benutzers.
• Externe Nachschlagebeziehung und indirekte Nachschlagebeziehung: die Beziehungen zu und von externen Objekten, den __x-Objekten aus Modul 4. Eine externe Nachschlagebeziehung zeigt auf ein übergeordnetes externes Objekt; eine indirekte Nachschlagebeziehung zeigt von einem externen Objekt auf ein Standard- oder benutzerdefiniertes Objekt und gleicht über eine eindeutige externe ID ab.

Den Grossteil Ihrer Entwurfszeit verbringen Sie mit den ersten drei. Nehmen wir sie einzeln durch.

Nachschlagebeziehung: Diese Datensätze sind verbunden

Eine Nachschlagebeziehung sagt: Dieser Datensatz ist mit jenem Datensatz verknüpft. Das untergeordnete Element behält seine eigene Identität, seinen eigenen Eigentümer und sein eigenes Leben. Eine Lieferung verweist auf ihre Tour. Wird die Tour abgesagt, verschwinden die Lieferungen nicht; sie gehen zurück in die Tourenplanung.

Das Witzige ist: Das Nachschlagefeld sitzt auf dem untergeordneten Objekt, aber auch das übergeordnete bekommt etwas, nämlich eine Themenliste (Related List) seiner untergeordneten Datensätze. Wenn Sie eine anlegen, benennen Sie also beide Enden. Das Related List Label (Bezeichnung der Themenliste) ist das, was die Leute auf dem übergeordneten Datensatz sehen, und der Child Relationship Name (Name der untergeordneten Beziehung) ist das, womit Entwicklungsteams und Integrationen vom übergeordneten zu den untergeordneten Datensätzen gehen. Übernehmen Sie nicht die Standardwerte.

Eine Nachschlagebeziehung kann erforderlich oder optional sein. Ist sie optional, entscheiden Sie, was passiert, wenn der Datensatz, auf den sie zeigt, gelöscht wird, und es gibt drei Möglichkeiten (Considerations for Object Relationships (opens in a new tab), auf Englisch):

• Clear the value of this field (Wert dieses Felds leeren), die Standardeinstellung. Das untergeordnete Element bleibt, mit leerem Nachschlagefeld.
• Don’t allow deletion (Löschen nicht zulassen) des Nachschlagedatensatzes. Versuchen Sie, die Tour zu löschen, und Salesforce sagt Nein: Sie ist Teil einer Beziehung.
• Delete this record also (Diesen Datensatz ebenfalls löschen), ein kaskadierendes Löschen wie bei Master-Detail. Es wird nur für eine benutzerdefinierte Nachschlagebeziehung auf einem benutzerdefinierten Objekt angeboten, ist standardmässig deaktiviert, und Salesforce muss es für Ihre Org einschalten, denn ein kaskadierendes Löschen umgeht Sicherheit und Freigabe: Benutzer können Datensätze löschen, die sie nicht einmal sehen konnten.

Das ist eine Lebenszyklusentscheidung, versteckt in einem Setup-Bildschirm.

Nachschlagefilter (Lookup Filters) schränken ein, was ein Benutzer auswählen kann. Angenommen, Lieferung hat eine Nachschlagebeziehung Installer auf Kontakt, und Installateur:innen sind ein Datensatztyp von Kontakt unter vielen. Ein Nachschlagefilter zeigt nur Installateur:innen, und er kann nach dem aktuellen Datensatz filtern, nach dem nachgeschlagenen Datensatz und nach dem Benutzer: nach Profil, Rolle oder Berechtigungen (Lookup Filters (opens in a new tab), auf Englisch). Das ist ein günstiger Weg, eine Nachschlagebeziehung ehrlich zu halten.

Master-Detail: Dieses untergeordnete Element gehört zu jenem übergeordneten

Master-Detail macht eine viel stärkere Aussage. Im Kurs nenne ich es eine sehr enge Bindung. Ohne seinen Master kann es kein Detail geben; das Master-Feld ist erforderlich. Das Detail verliert sein eigenes Feld Eigentümer und erbt den Eigentümer seines übergeordneten Datensatzes. Für das Detail gibt es keine eigene Freigabetabelle, Sie können ein untergeordnetes Element also nicht allein freigeben; es erbt die Freigabe seines übergeordneten. Deshalb kann ein Detailobjekt keine Freigaberegeln, keine manuelle Freigabe und keine Warteschlangen haben: Sie alle brauchen ein Feld Eigentümer (Object Relationships Overview (opens in a new tab), auf Englisch). Im Setup steht bei seiner Freigabeeinstellung Controlled by Parent (Durch übergeordnetes Element gesteuert). Und auf dem Master-Detail-Feld selbst wählen Sie eine Sharing Setting (Freigabeeinstellung): ob ein Benutzer Read Only (Schreibgeschützt) oder Read/Write (Lesen/Schreiben) auf dem Master braucht, um dessen Details anzulegen, zu bearbeiten oder zu löschen. Das Löschen des Masters löscht seine Details. Und der Master bekommt Rollup-Zusammenfassungsfelder.

Wenn die Lieferposition also ein Detail der Lieferung ist, sage ich: Diese Position gehört ihr ganzes Leben lang zu dieser Lieferung. Diese Frage möchte ich beantwortet haben, bevor irgendjemand im Setup Master-Detail-Beziehung auswählt.

Die Löschfrage

Hier ist meine liebste Art herauszufinden, ob wir es durchdacht haben: Was soll mit den untergeordneten Datensätzen passieren, wenn jemand den übergeordneten löscht? Alle werden unruhig. Gut. Jetzt betreiben wir Architektur.

Ein Handelspartner hat Hunderttausende historische Lieferungen. Jemand löscht den Partner. Sollen die Lieferungen verschwinden? Mit ziemlicher Sicherheit nicht: Die Reklamationen, die Abrechnung und die Historie hängen alle davon ab. Vielleicht sollte das Löschen eines Partners gar nicht erlaubt sein und der Partner stattdessen deaktiviert werden. Bei Master-Detail kaskadiert das Löschen des Masters auf die Details und deren Details; das Wiederherstellen des Masters holt sie zurück (Considerations for Object Relationships (opens in a new tab), auf Englisch). Wenn also jemand sagt «Master-Detail gibt uns Rollups», lautet meine Antwort: Wunderbar. Wozu haben Sie sonst noch zugestimmt?

Die Eigentümerschaft fährt mit

Bei einer Nachschlagebeziehung kann das untergeordnete Element einen eigenen Eigentümer haben. Bei Master-Detail kann es das nicht; der Zugriff folgt dem Master. Das ist genau richtig, wenn das Detail wirklich Teil des übergeordneten ist. Aber wenn das untergeordnete Element einen eigenen Eigentümer, eine eigene Freigabe oder einen eigenen Lebenszyklus braucht, sagt Ihnen das Modell, dass Master-Detail die falsche Wahl ist. Das nächste Modul geht tiefer auf die Eigentümerschaft ein, und der Kurs Sharing and Visibility noch weiter. Für jetzt: Beziehungsentwurf und Sicherheitsentwurf sind keine getrennten Gespräche. Das Datenmodell formt das Sicherheitsmodell, bevor irgendjemand eine Freigaberegel schreibt.

Erforderliches übergeordnetes Element oder optional?

Kann das untergeordnete Element existieren, bevor wir sein übergeordnetes kennen? Das ist wichtiger, als es klingt. Wenn Lieferungen am Vorabend auf der Ladeliste eintreffen und die Touren danach gebaut werden, würde eine erforderliche Tour auf der Lieferung bedeuten, dass die Tourenplanung geschehen muss, bevor der Datensatz überhaupt erstellt werden kann. Die physische Beziehung muss den echten Lebenszyklus tragen. Deshalb entwerfe ich Beziehungen nicht allein aus einem statischen Diagramm. Ich will wissen: Wie entstehen sie, können sie allein existieren, können sie umziehen, und wie sterben sie?

Kann das untergeordnete Element das übergeordnete wechseln?

Standardmässig kann ein Master-Detail-Kind nicht zu einem anderen übergeordneten Datensatz verschoben werden. Sie können es erlauben, indem Sie bei der Beziehung Neuzuordnung zulassen (Allow reparenting) auswählen (Considerations for Object Relationships (opens in a new tab), auf Englisch). Mein Instinkt ist konservativ: Wenn das Geschäft sagt, das untergeordnete Element gehört lebenslang zu einem übergeordneten, mache ich das Verschieben nicht leicht. Eine Position, die von einer Lieferung zu einer anderen wechselt, sollte ein bewusstes Geschäftsereignis sein, keine Feldbearbeitung. Auch hier ist die Einstellung nicht die Architektur. Die Lebenszyklusregel ist es, und die Einstellung setzt sie um.

Zwei weitere Dinge, die Teams später erwischen. Sie können keine Master-Detail-Beziehung auf einem Objekt anlegen, das bereits Daten hat; Sie legen eine Nachschlagebeziehung an, befüllen sie bei jedem Datensatz und wandeln sie dann um. Und Sie können nur dann zurück in eine Nachschlagebeziehung umwandeln, wenn es auf dem Master keine Rollup-Zusammenfassungsfelder gibt. Achten Sie auch darauf, was das Umwandeln mit der Sicherheit macht: Wird eine Nachschlagebeziehung zu Master-Detail, wird die Freigabe des untergeordneten Objekts auf Controlled by Parent gesetzt, und wird eine Master-Detail-Beziehung zurück zur Nachschlagebeziehung, wird die organisationsweite Standardeinstellung des untergeordneten Objekts auf Public Read/Write (Öffentlich Lesen/Schreiben) gesetzt (Considerations for Object Relationships (opens in a new tab), auf Englisch). Datensätze, die gestern privat waren, sind heute offen, bis es jemand bemerkt. Wählen Sie früh.

Rollups sind nützlich, aber nicht kostenlos

Ich mag Rollups. Die Positionen einer Lieferung zählen, die Zeilenbeträge einer Rechnung summieren, das späteste Datum finden: nativ, ohne Code. Das Master-Detail-Feld sitzt auf dem untergeordneten Objekt, das Rollup aber auf dem übergeordneten. Allerdings haben sie Kleingedrucktes (Roll-Up Summary Field (opens in a new tab), auf Englisch):

• Die Berechnung von Rollup-Werten nach bestimmten Änderungen (ein neues Rollup-Feld, eine geänderte Formel, von der es abhängt, eine erzwungene Neuberechnung) kann je nach Zahl der betroffenen Datensätze bis zu 30 Minuten dauern. Ich habe Leute gesehen, die sich wunderten, warum sich die Zahl auf dem übergeordneten Datensatz noch nicht geändert hat.
• Sie können nicht alles zusammenfassen. Eine automatische Nummer kann nicht das Feld sein, das Sie aggregieren. Und ein Rollup kann ein Formelfeld nur dann zusammenfassen, wenn diese Formel nicht auf ein anderes Objekt übergreift und keine Funktion verwendet, die sich von selbst ändert, etwa NOW() oder TODAY(). Eine Formel «Tage überfällig», die auf TODAY() aufbaut, ändert sich jede Nacht, ohne dass jemand einen Datensatz speichert, also gibt es nichts, woraus das Rollup neu berechnen könnte. Eine solche Zahl braucht einen geplanten Flow oder einen Bericht.
• Auch der Filter hat Grenzen: kein langes Textfeld, keine Mehrfachauswahlliste, keine Beschreibung, keine Systemfelder wie Last Activity (Letzte Aktivität), keine objektübergreifenden Formeln und keine Nachschlagefelder.
• Rollups stehen nicht auf Bearbeitungsseiten; eine Validierungsregel kann also eines verwenden, ihren Fehler dort aber nicht anzeigen.

Und drehen Sie die Entscheidung nicht um. Sagen Sie nicht: «Wir brauchen ein Rollup, also muss das Master-Detail sein.» Sagen Sie: «Dieses untergeordnete Element gehört wirklich zu diesem übergeordneten, Eigentümerschaft und Lebenszyklus passen, und einer der Vorteile sind native Rollups.» Wenn die Bedeutung nicht passt, lösen Sie die Berechnung anders. Verbiegen Sie das Datenmodell nicht, um eine Funktion zu bekommen.

Wie sieht der andere Weg also aus? Sie bauen das Rollup selbst: ein Feld auf dem übergeordneten Objekt, das den berechneten Wert hält, und eine Automatisierung, die ihn aktuell hält. Angenommen, Handelspartner ist, wie es sein sollte, eine Nachschlagebeziehung von Lieferung, und das Geschäft möchte «Offene Lieferungen» auf dem Partner sehen. Fügen Sie dem Partner ein Zahlenfeld «Offene Lieferungen» hinzu. Dann berechnet ein datensatzausgelöster Flow oder, wenn Volumen oder Logik Code verlangen, ein Apex-Trigger es neu, sobald sich eine Lieferung ändert. Das funktioniert über eine Nachschlagebeziehung, kann nach allem filtern und kann Datumswerte und Formeln verwenden, die ein natives Rollup nicht kann.

Aber jetzt liegt es an Ihnen, es richtig zu machen, und genau da gehen solche Lösungen schief. Die Automatisierung muss bei jeder relevanten Änderung auslösen: ein neues untergeordnetes Element, ein bearbeitetes, ein gelöschtes, ein wiederhergestelltes und ein untergeordnetes Element, das zu einem anderen übergeordneten verschoben wird, was bedeutet, sowohl das alte als auch das neue übergeordnete neu zu berechnen. Sie muss einen Datenimport mit 200 Datensätzen auf einmal verarbeiten, ohne an Grenzen zu stossen. Zählen Sie neu, statt zu addieren und zu subtrahieren, damit ein verpasstes Ereignis die Zahl nicht für immer falsch lässt. Planen Sie einen Weg, alles neu zu berechnen, für den ersten Import und für den Tag, an dem die Zahl abdriftet. Und denken Sie daran: Jedes Speichern eines untergeordneten Datensatzes aktualisiert jetzt das übergeordnete, also bringt ein übergeordneter Datensatz mit Tausenden untergeordneten die Sperren zurück, die wir gleich sehen werden. Ein natives Rollup erledigt all das für Sie; ein eigenes ist ein kleines Stück Software, das Ihnen gehört.

Drei Ebenen tief: Master-Detail-Beziehungen stapeln

Die Plattform hat eine Form, und Master-Detail hat davon zwei Dimensionen. Die erste ist die Tiefe.

Sie können Master-Detail-Beziehungen drei benutzerdefinierte Detailebenen tief stapeln, und das ist der Boden (Considerations for Object Relationships (opens in a new tab), auf Englisch). Im Kurs zeichne ich es als Account mit einem Auftrag (eins), den Auftrag mit seinen Positionen (zwei) und die Positionen mit ihren Details (drei), und dann versuche ich, eine vierte Ebene hinzuzufügen, und Salesforce lässt mich nicht. Bei Steve Trucking könnte es so aussehen: Eine Lieferung (Delivery) ist der Master; ihre Lieferpositionen (Delivery Items) sind die erste Ebene; die Installationsaufgaben (Install Tasks) einer Position die zweite; und die Aufgabenschritte (Task Steps) jeder Aufgabe die dritte. Eine vierte Ebene, etwa eine Schrittnotiz (Step Note), muss eine Nachschlagebeziehung sein.

Click to enlarge

Mit dem Stapel kommen ein paar Regeln:

• Standardobjekte können nicht auf der Detailseite eines benutzerdefinierten Objekts stehen. Ein benutzerdefiniertes Objekt kann ein Detail von Account sein; Account kann kein Detail Ihres Objekts sein.
• Ein Objekt darf nur einmal vorkommen in einem mehrstufigen Stapel. Salesforce will nicht, dass Sie sich im Kreis drehen: Ein Unterdetail kann nicht zugleich der Master seines eigenen Masters sein.
• Der Master kann die unterste Ebene nicht direkt zusammenfassen. Wenn die Lieferung die Zahl der Aufgabenschritte will, fasst die Installationsaufgabe ihre Schritte zusammen, die Lieferposition fasst diese Rollups zusammen, und die Lieferung fasst die Positionen zusammen: eine Ebene nach der anderen.
• Eigentümerschaft und Freigabe kommen von oben. Jede Ebene erbt den Eigentümer und den Zugriff des Masters.
• Das Löschen des Masters löscht alles darunter, und das Wiederherstellen holt alles zurück.

Drei Ebenen reichen meistens völlig. Wenn Ihr Entwurf immer wieder eine vierte will, fragen Sie, ob jede Ebene wirklich lebenslang zu der darüber gehört. Und denken Sie daran, dass Sie wählen können, welche Verbindung die Kette unterbricht. Die vierte Ebene muss nicht die Nachschlagebeziehung sein: Vielleicht gehört eine Installationsaufgabe gar nicht wirklich zu ihrer Lieferposition, sie wird eigenständig geplant und zugewiesen, also wird diese Verbindung zur Nachschlagebeziehung, und jetzt beginnt die Installationsaufgabe eine neue Kette mit Aufgabenschritt und Schrittnotiz darunter. Wählen Sie die Verbindung, bei der das untergeordnete Element wirklich ein eigenes Leben hat, und machen Sie genau diese zur Nachschlagebeziehung.

Click to enlarge

Jetzt hat die Installationsaufgabe ihren eigenen Eigentümer und ihre eigene Freigabe, eine Lieferung kann gelöscht werden, ohne ihre Installationsaufgaben mitzunehmen, und unter der Installationsaufgabe können noch zwei Ebenen liegen. Das ist der Tausch: Die Kette ist kürzer, und das Leben der Installationsaufgabe gehört ihr selbst.

Zwei Eltern breit: das Salesforce-Verbindungsobjekt

Zuerst ein Wort zu den Wörtern, denn «Verbindungsobjekt» (Junction Object) bedeutet zwei Dinge, und ich unterrichte beide.

In Kapitel 2 haben wir das logische Verbindungsobjekt gefunden: die Verbindung zweier Schlüsselideen, die zu einem eigenen Ding mit eigenen Attributen wird. Ein Hund kann viele Tricks, ein Trick wird von vielen Hunden beherrscht, und der Hundetrick (Dog Trick) sitzt dazwischen und hält den Kenntnisstand und das Datum. Das ist ein logisches Verbindungsobjekt, im logischen Modell, lange bevor irgendjemand über Nachschlagebeziehung oder Master-Detail entscheidet.

Salesforce verwendet den Begriff enger. Wenn Salesforce Junction Object sagt, meint es ein benutzerdefiniertes Objekt mit zwei Master-Detail-Beziehungen (Create a Many-to-Many Object Relationship (opens in a new tab), auf Englisch). Ich nenne das ein Salesforce-Verbindungsobjekt. Jedes Salesforce-Verbindungsobjekt ist ein logisches Verbindungsobjekt, aber nicht jedes logische Verbindungsobjekt wird zu einem Salesforce-Verbindungsobjekt: Bauen Sie eines mit einer Master-Detail- und einer Nachschlagebeziehung oder mit zwei Nachschlagebeziehungen, und es ist immer noch ein logisches Verbindungsobjekt, nur nicht die Salesforce-Art. (Salesforce ist selbst nicht ganz konsistent: Die eigene Objektreferenz nennt einige Standardobjekte, die auf Nachschlagebeziehungen aufbauen, «Junction Objects». Gehen Sie in der Prüfung von der engen Definition aus.)

Prüfungswissen. Ein Salesforce-Verbindungsobjekt ist ein benutzerdefiniertes Objekt mit zwei Master-Detail-Beziehungen, und genau das meint Salesforce, wenn es «Junction Object» sagt. Das logische Verbindungsobjekt ist die weitere Modellierungsidee: jedes Objekt, das zwei andere in einer Viele-zu-viele-Beziehung verbindet und eigene Attribute trägt, egal wie es gebaut ist.

Die zweite Dimension ist die Breite. Kann ein untergeordnetes Element zwei Master-Detail-Eltern haben? Ja. Drei? Nein. Jedes benutzerdefinierte Objekt kann bis zu zwei Master-Detail-Beziehungen haben (Considerations for Object Relationships (opens in a new tab), auf Englisch). Mit zwei Master-Detail-Eltern bauen Sie ein Salesforce-Verbindungsobjekt für eine Viele-zu-viele-Beziehung. Crew und Lastwagen treffen sich in einer Crew-Zuweisung (Crew Assignment), und wie wir in Kapitel 2 gesehen haben, ist sie keine Leitung: Sie hat ein Datum, eine Tour, vielleicht einen Status. Im Verbindungsobjekt wird die Beziehung zu einem Geschäftskonzept. Die Tipps von Salesforce für den Bau: Geben Sie ihm einen Namen, der sagt, was es ist, machen Sie seinen Datensatznamen zu einer automatischen Nummer, und benennen Sie die Themenliste jedes Masters nach dem anderen Master, sodass die Crew-Seite «Lastwagen» zeigt und die Lastwagenseite «Crews» (Create a Many-to-Many Object Relationship (opens in a new tab), auf Englisch).

Hier liegt die Feinheit. Einer der beiden Eltern ist der primäre, und zwar der, dessen Master-Detail-Feld Sie zuerst angelegt haben. Es gibt keinen sichtbaren Hinweis, welcher das ist, also ist das eine klassische Prüfungsfrage und eine klassische Überraschung.

Was entscheidet der primäre? Drei Dinge (Create a Many-to-Many Object Relationship (opens in a new tab), auf Englisch):

• Aussehen. Die Seiten des Verbindungsobjekts verwenden die Farbe und das Symbol des primären Masters.
• Eigentümer. Die Datensätze des Verbindungsobjekts erben den Eigentümer des primären Master-Datensatzes. Sie sehen ihn nie, weil ein Detail kein Feld Eigentümer hat; er zählt erst, wenn Sie später beide Master-Detail-Beziehungen entfernen.
• Division, wenn Ihre Org Divisionen verwendet, auf dieselbe Weise.

Und der andere ist der sekundäre. Was bedeutet das?

• Er steht als Nächster in der Reihe, primär zu werden. Löschen Sie das primäre Master-Detail-Feld oder wandeln Sie es in eine Nachschlagebeziehung um, und der sekundäre wird zum primären.
• Er bestimmt den Umfang der Berichte. Salesforce gibt Ihnen zwei Berichtstypen: «Primary master with junction object and secondary master» (primärer Master mit Verbindungsobjekt und sekundärem Master) und «Secondary master with junction object and primary master» (sekundärer Master mit Verbindungsobjekt und primärem Master). Der zuerst genannte Master entscheidet, welche Datensätze der Bericht zeigen kann.
• Für den Zugriff zählt er genauso viel. So sage ich es: Eigentümerschaft vom primären, Zugriff von beiden, und das Restriktivste gewinnt. Ein Verbindungsobjekt hat wie jedes Detail keine eigene Freigabetabelle. Salesforce prüft den Zugriff des Benutzers auf beide Master-Datensätze, über die Sharing Setting (Freigabeeinstellung) auf jedem Master-Detail-Feld. Wenn beide auf Read/Write stehen, braucht der Benutzer Read/Write auf der Crew und auf dem Lastwagen, um die Crew-Zuweisung zu bearbeiten (Considerations for Object Relationships (opens in a new tab), auf Englisch).
• Er löscht genauso viel. Löschen Sie einen der beiden Master, die Crew oder den Lastwagen, und seine Datensätze im Verbindungsobjekt gehen in den Papierkorb. Löschen Sie beide, und sie sind endgültig weg.

Click to enlarge

Noch ein paar Regeln: Beide Master können Rollup-Zusammenfassungen aus dem Verbindungsobjekt haben, und die Formeln und Validierungsregeln des Verbindungsobjekts können Felder auf beiden erreichen. Aber ein Verbindungsobjekt kann nicht der Master von etwas anderem sein, also kann es nicht in der Mitte eines Stapels sitzen, und die beiden Master können nicht dasselbe Objekt sein; eine Viele-zu-viele-Beziehung eines Objekts mit sich selbst braucht einen anderen Entwurf. Und wenn ein übergeordneter Datensatz mehr als 200 Datensätze im Verbindungsobjekt hat und das Verbindungsobjekt auf den anderen übergeordneten zusammenfasst, lässt Salesforce Sie diesen übergeordneten Datensatz erst löschen, wenn Sie genug davon entfernt haben.

Also: Welcher Elternteil sollte primär sein? Legen Sie den zuerst an, der die Bedeutung trägt. Bei einer Crew-Zuweisung erledigt die Crew die Arbeit, also würde ich Crew zuerst anlegen. Und dann schreiben Sie es auf, denn nichts auf dem Bildschirm wird es der nächsten Person sagen.

Bei allem Gesagten: Viele Salesforce-Verbindungsobjekte habe ich am Ende nicht. Typischerweise hat ein Objekt einen Master-Detail-Elternteil, und das ist dieselbe Art von Daten: Kundendaten unter Kundendaten, Bewegungsdaten unter Bewegungsdaten (erinnern Sie sich an die Datenarten aus Kapitel 2: Kundendaten, Bewegungsdaten, Referenzdaten). Wenn der andere Elternteil eine andere Art ist, meist ein Referenzobjekt, ist diese Beziehung eine Nachschlagebeziehung. Eine Lieferposition gehört zu ihrer Lieferung: Master-Detail, beides Bewegungsdaten. Auf das Produkt, das sie transportiert, zeigt sie mit einer Nachschlagebeziehung, weil ein Produkt Referenzdaten mit eigenem Leben sind und niemand will, dass das Löschen eines Produkts jahrelangen Lieferverlauf mitnimmt. Die Lieferposition ist immer noch ein logisches Verbindungsobjekt zwischen einer Lieferung und den Produkten darauf; sie ist nur kein Salesforce-Verbindungsobjekt.

Selbstbeziehungen: wenn die Linie zurückkommt

Ein Objekt kann sich auf sich selbst beziehen: ein übergeordneter Account, eine Führungskraft, ein Verteilzentrum, das einem regionalen Knotenpunkt untersteht. Zwei davon baut Salesforce ein, und Sie begegnen ihnen in fast jeder Org: Account zu Account, das Feld Parent Account (Übergeordneter Account), das die Account-Hierarchie bildet, und Case zu Case, der Parent Case (übergeordneter Case) aus Modul 2, der zusammengehörige Cases gruppiert. Eine Selbstbeziehung muss eine Nachschlagebeziehung sein, und ein Datensatz kann nicht auf sich selbst zeigen, wohl aber können zwei Datensätze aufeinander zeigen (Considerations for Object Relationships (opens in a new tab), auf Englisch). Auf dem Objekt User ist es ein eigener, besonderer Typ, die hierarchische Beziehung, die etwa für die Führungskraft eines Benutzers verwendet wird. Die Mechanik ist einfach; die Benennung zählt. Eine Nachschlagebeziehung von Verteilzentrum zu Verteilzentrum namens Distribution_Center__c hilft niemandem. Übergeordnet? Ersatz? Überlauf? Benennen Sie die Beziehung nach der Rolle, nicht nach dem Objekt, auf das sie zeigt.

Click to enlarge

Hierarchisch: die eigene Beziehung des Objekts User

Diese ist klein, und sie ist genau die Art wenig bekannter, einzigartiger Tatsache, aus der eine Prüfung meiner Erwartung nach schöpft. Hierarchisch ist eine besondere Nachschlagebeziehung, die es nur auf dem Objekt User gibt. Sie verbindet einen Benutzer mit einem anderen Benutzer, und Salesforce lässt die Kette nicht im Kreis laufen: Ein Benutzer kann nicht auf sich selbst zeigen, weder direkt noch indirekt (Object Relationships Overview (opens in a new tab), auf Englisch). Wenn Marias Führungskraft Dev ist, kann Devs Führungskraft nicht Maria sein, und auch niemand, der an Maria berichtet.

Das ist der Unterschied zu den Selbstbeziehungen oben. Auf Account oder einem benutzerdefinierten Objekt können zwei Datensätze aufeinander zeigen. Auf User muss die Hierarchie eine Hierarchie bleiben. Und es ist der einzige Weg, User mit User zu verbinden: Eine gewöhnliche Nachschlagebeziehung von User auf sich selbst wird nicht angeboten.

Eine haben Sie schon. Das Standardfeld Manager auf User ist eine hierarchische Beziehung, und Genehmigungen können es verwenden: Diese Anfrage geht an die Führungskraft der einreichenden Person. Sie können auch eigene anlegen, etwa einen Eskalationskontakt oder eine Ersatzgenehmigung, und eine Genehmigung kann genauso daran entlanglaufen (ApprovalProcess, Metadata API (opens in a new tab), auf Englisch). Verwechseln Sie sie nicht mit der Rollenhierarchie, die den Datensatzzugriff steuert. Ein hierarchisches Feld ist nur eine Beziehung zwischen Benutzern; es gibt keinen einzigen Datensatz frei.

Prüfungswissen. Die hierarchische Beziehung gibt es nur auf dem Objekt User, wie das Standardfeld Manager, und ein Benutzer kann nicht auf sich selbst zeigen, weder direkt noch indirekt. Sie ist nicht die Rollenhierarchie.

Auch Beziehungen haben Grenzen

Jedes Objekt kann höchstens zwei Master-Detail-Beziehungen haben. Nachschlage- und Master-Detail-Felder zählen zusammen als Beziehungsfelder: standardmässig 40 pro Objekt, auf Anfrage höchstens 50. Rollup-Zusammenfassungsfelder: standardmässig 25 pro Objekt, höchstens 40 (Increase the Maximum Relationships Allowed per Object (opens in a new tab); Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab), auf Englisch). Salesforce fügt hinzu, dass das Anheben einer dieser Grenzen die Leistung beeinträchtigen kann.

Sie müssen nicht auf diese Zahlen hin entwerfen; Sie müssen bemerken, wenn Sie in ihre Nähe kommen. Ein Objekt, an dem Beziehung um Beziehung hängt, sagt Ihnen etwas. Vielleicht ist es wirklich so zentral. Oder vielleicht ist das Modell falsch. (Und die Spielraumregel aus Kapitel 18 gilt: Bleiben Sie deutlich unter einer Grenze, gemessen am dritten Jahr.)

Die Frage der 10’000 untergeordneten Datensätze

Dann gibt es den übergeordneten Datensatz mit zu vielen untergeordneten. Die eigene Empfehlung von Salesforce lautet, etwa 10’000 untergeordnete Datensätze pro Master-Detail-Elternteil nicht zu überschreiten (Considerations for Object Relationships (opens in a new tab), auf Englisch), und sein Leitfaden zum Datensatzzugriff im grossen Massstab sagt dasselbe für Eltern-Kind-Beziehungen allgemein (Parent-Child Data Skew (opens in a new tab), auf Englisch). Datensatz 10’001 legt die Org nicht lahm. Aber jenseits davon kann das Speichern eines untergeordneten Datensatzes den übergeordneten sperren, und Freigabeänderungen am übergeordneten wirken sich auf jeden untergeordneten aus.

Wenn ich also einen übergeordneten Datensatz mit enormen Mengen untergeordneter sehe, frage ich: Warum stehen sie alle unter demselben, wem gehören sie, wie werden sie abgefragt, und welche Automatisierung berührt den übergeordneten? Jede Lieferung unter einem einzigen Account «Steve Trucking» würde in ein paar Tagen 10’000 überschreiten. Eine harmlose Eins-zu-viele-Beziehung wird zu einem Problem der Datenschieflage (Data Skew). Das nächste Modul gibt einen Ausblick auf die Schieflage, und Teil 2 geht in die Tiefe.

Entwerfen Sie die Linie nicht nach der Funktion

Das ist die Gewohnheit, die ich aus diesem Modul möchte. Beginnen Sie nicht bei «Ich brauche ein Rollup», «Ich brauche es erforderlich», «Ich will vererbte Freigabe». Das sind Hinweise zur Umsetzung. Beginnen Sie beim Geschäft: Hat das untergeordnete Element ein eigenes Leben, wem gehört es, kann es allein existieren, kann es umziehen, was passiert, wenn das übergeordnete geht, trägt die Beziehung Daten, und wie gross kann jede Seite werden? Dann wählen Sie die Beziehung, die die Antworten umsetzt.

Click to enlarge

Über die Prüfung hinaus: Was KI ändert. KI kann Beziehungen in Sekunden vorschlagen. Sie kann Ihnen nicht sagen, ob das Geschäft das übergeordnete Element je löschen wird. Schnelleres Zeichnen macht eine falsche Beziehung nicht billiger rückgängig zu machen, sobald Millionen Datensätze und Dutzende Automatisierungen davon abhängen.

Was Architekt:innen hier entscheiden

• Ob das untergeordnete Element einen eigenen Lebenszyklus hat oder wirklich zum übergeordneten gehört, und ob Eigentümerschaft und Zugriff eigen oder geerbt sein sollen.
• Ob das untergeordnete Element ohne übergeordnetes existieren, zwischen übergeordneten wechseln oder das Löschen des übergeordneten überstehen kann.
• Was jede Nachschlagebeziehung tut, wenn ihr übergeordneter Datensatz gelöscht wird: leeren, blockieren oder kaskadieren.
• Ob eine Viele-zu-viele-Beziehung eine Leitung oder ein Geschäftskonzept ist, ob das logische Verbindungsobjekt zu einem Salesforce-Verbindungsobjekt wird, welcher Elternteil primär ist und was beide Eltern für den Zugriff bedeuten.
• Ob das Modell zur Form der Plattform passt: drei benutzerdefinierte Detailebenen tief, zwei Master-Detail-Eltern breit, die Grenzen für Beziehungen und Rollups.
• Ob die erwartete Zahl und Verteilung der untergeordneten Datensätze ein Schieflagerisiko schafft, das den Entwurf ändern sollte.

Eine Beziehung ist eine Reihe von Versprechen darüber, wie sich zwei Stücke Daten zusammen verhalten. Geben Sie sie bewusst.

Weiterlesen

• Salesforce-Hilfe, Considerations for Object Relationships (opens in a new tab) (auf Englisch), geprüft am 2026-10-13.
• Salesforce-Hilfe, Object Relationships Overview (opens in a new tab) und Create a Many-to-Many Object Relationship (opens in a new tab) (auf Englisch), geprüft am 2026-10-13.
• Salesforce-Hilfe, Roll-Up Summary Field (opens in a new tab) (auf Englisch), geprüft am 2026-10-13.
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab) (auf Englisch), geprüft am 2026-10-13.
• Salesforce-Hilfe, Lookup Filters (opens in a new tab) (auf Englisch), geprüft am 2026-10-13.
• Salesforce-Hilfe, Increase the Maximum Relationships Allowed per Object (opens in a new tab) und Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.