Blog · 14. September 2023 · Steve Simpson · Datenarchitektur

Steves Datenmodellierung: von Auswahllisten bis zur Unendlichkeit und noch viel weiter

Einführung:

Willkommen zu einer weiteren Folge der Reihe Steve’s Data Modeling! In diesem Beitrag sehen wir uns die vielseitige Nutzung von Auswahllisten an und besprechen Szenarien, in denen Sie für anspruchsvollere Datenmodelle Alternativen erwägen sollten.

Auswahllisten verstehen

Auswahllisten sind ideal für ein Feld mit einer festen Wertemenge. Sie bieten eine saubere Benutzererfahrung, haben aber einige Grenzen:

Zum Hinzufügen von Werten braucht es erweiterte Administrationsrechte.
Neue Werte müssen über Sandboxes bereitgestellt werden.

Es kommt zu Validierungsfehlern, wenn Werte aus Drittanbieter-Integrationen nicht vorher in Salesforce angelegt wurden.

Optionen für Auswahllisten

Hier einige Optionen, die Sie erwägen sollten:

Option 1: globale Wertegruppen

Das ist die Standardoption von Salesforce, mit der sich Listen objektübergreifend nutzen lassen.

Option 1, Auswahllisten und globale Wertegruppen. Vorteil: eine saubere Benutzererfahrung. Nachteile: Die Administration muss Werte anlegen, Änderungen müssen in Sandboxes bereitgestellt werden, externe Systeme machen Probleme, und ein Wert kann keine zugehörigen Felder tragen

Globale Wertegruppen eignen sich am besten für Werte, die an mehreren Stellen genutzt werden. Sie können zum Beispiel zwei globale Wertegruppen für «Rohrgrösse» und «Rohrstärke» anlegen und Nutzenden so eine saubere Oberfläche zur Auswahl bieten.

[caption id="" align=“alignnone” width=“1372”] Beispiel-Wertegruppen [/caption] [caption id="" align=“alignnone” width=“1814”] Beispielwerte [/caption] [caption id="" align=“alignnone” width=“676”] Aus einer Liste wählen [/caption]

Option 2: Textfelder

Ein einfaches Textfeld ohne Validierung.

Option 2, Textfelder. Vorteil: Sie nehmen jeden Wert an. Nachteile: keine Datenvalidierung und eine schlechte Benutzererfahrung

Wenn Datenwerte über Integrationen hereinkommen, könnten Sie Textfelder in Betracht ziehen. Dabei geht jedoch die Validierung verloren: Nutzende können beliebige Daten eingeben, was zu Inkonsistenzen führen kann.

Das kann eine Option sein, wenn die Felder in Salesforce schreibgeschützt sind und Sie die Werte nur anzeigen.

[caption id="" align=“alignnone” width=“678”] Keine Validierung [/caption]

Option 3: gemeinsames Referenzobjekt

Option 3, ein gemeinsames Referenzobjekt mit Datensatztypen und nach Datensatztyp gefilterten Nachschlagefeldern. Vorteile: Daten lassen sich dynamisch hinzufügen, dazu einige zugehörige Felder. Nachteile: Datenladen in Sandboxes, und das Quellobjekt enthält einen Schlüssel statt des Werts

Ein gemeinsames Referenzobjekt mit mehreren Datensatztypen lässt sich für Datenladevorgänge nutzen. Dabei entstehen zwei Nachschlagefelder auf dem Hauptobjekt, die auf das Referenzobjekt statt auf die Werte selbst verweisen. Neue Werte lassen sich auch ohne Administrationsrechte dynamisch hinzufügen, was die Flexibilität erhöht.

[caption id="" align=“alignnone” width=“1462”] Datensatztypen verwenden [/caption] [caption id="" align=“alignnone” width=“1700”] Ein gefiltertes Nachschlagefeld verwenden [/caption] [caption id="" align=“alignnone” width=“1434”] Werte hinzufügen [/caption] [caption id="" align=“alignnone” width=“658”] So sieht die Auswahl eines Werts aus. Die Sortierung stimmt nicht, und beim ersten Laden werden nicht alle Werte gezeigt, sodass man suchen muss. Entfernen Sie ausserdem «Erstellen» aus Profilen und Berechtigungssätzen, damit niemand spontan weitere Datensätze anlegt. [/caption]

Abschnitt 3: erweiterte Optionen

Für anspruchsvollere Szenarien kommen diese Optionen infrage:

Option 4: eigene Masken mit Referenzobjekt

Option 4, ein Referenzobjekt plus Textfeld, mit einer Lightning-Webkomponente, die die Listenwerte aus dem Referenzobjekt liest. Vorteile: Daten lassen sich dynamisch hinzufügen, und das Quellobjekt behält die Werte. Nachteil: erfordert LWC-Entwicklung und eigene Seiten

Wenn Sie eigene Lightning-Webkomponenten (LWCs) für Ihre Bearbeitungsmasken nutzen, können Sie ein Referenzobjekt verwenden, um Werte zu lesen und anzuzeigen, und dabei die tatsächlichen Werte statt Nachschlagefeldern speichern.

Option 5: eigenständige Objekte

Option 5, eigenständige Referenzobjekte, eines pro Liste. Vorteile: Daten lassen sich dynamisch hinzufügen, ein sauberes Datenmodell und viele zugehörige Felder. Nachteile: Datenladen in Sandboxes, Schlüssel statt Werte und viele Objekte

Wenn Nachschlagewerte an Bedeutung gewinnen, sollten Sie für jeden ein eigenständiges Objekt mit eigenen Nachschlagefeldern anlegen. So lassen sich Daten dynamisch hinzufügen, das Datenmodell bleibt sauber, und jedes Objekt kann weitere zugehörige Felder tragen.

Praktische Beispiele

Hier praktische Beispiele zu jeder Option:

Standard-Auswahllisten: eine saubere Oberfläche mit festen Werten.

Textfelder ohne Validierung: flexibel, aber ohne Datenvalidierung.

Nachschlagen in Referenzobjekten: dasselbe Objekt mit gefilterten Datensatztypen, für mehr Flexibilität.

Eigenständige Objekte: ein eigenes Objekt pro Nachschlagefeld, für ein sauberes und flexibles Datenmodell.

Fazit

Die Feinheiten von Auswahllisten und ihren Alternativen zu verstehen, ist für wirksame Datenmodellierung entscheidend. Von Standard-Auswahllisten bis zu eigenständigen Objekten hat jede Option eigene Vorteile für bestimmte Anforderungen.

Schauen Sie bald wieder vorbei!

Weitere Einblicke und Tipps gibt es hier auf www.SteveTechArc.com und auf dem YouTube-Kanal @SteveTechArc (opens in a new tab). Abonnieren Sie und bringen Sie Ihre Datenmodellierung mit uns zum Glänzen!

Die Welt ein Stück verändern, indem ich gute Gedanken mit anderen Architekt:innen und allen auf dem Weg dorthin teile!

Transkript mit Unterstützung von KI

STA 2.2