Auch Felder sind Architektur

🌐 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 6 von 10 im Kapitel Salesforce-Datenarchitektur, Kapitel 3 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Das richtige Objekt wählen · Weiter: Beziehungen haben Folgen

Die Frage, die dieses Modul beantwortet: Wie sollte Salesforce jedes Stück Daten physisch darstellen?

Ein Feld zu erstellen dauert etwa eine Minute. Neues Feld, Typ wählen, benennen, Weiter, Weiter, Speichern. Genau deshalb werden Felder nicht als Architektur behandelt.

Gehen Sie in eine Org, die es seit zehn Jahren gibt, und öffnen Sie den Account. Fünfhundert Felder. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Drei verschiedene Kundennummern. Ein Kontrollkästchen, das niemand löscht, weil niemand weiss, welche Integration es noch verwendet. Das Feld zu erstellen dauerte eine Minute. Damit zu leben dauert Jahre. Die Idee dieses Moduls ist also einfach: Ein Feld ist eine Architekturentscheidung. Nicht immer eine grosse, aber jedes Feld legt etwas über die Bedeutung, das Verhalten, die Identität oder die Qualität der Daten fest, und wie Objekte lassen sich Felder leicht hinzufügen und überraschend schwer wieder entfernen.

Was bedeuten diese Daten eigentlich?

In Kapitel 2 haben wir unseren Entitäten Attribute gegeben: Eine Lieferung hat ein geplantes Zeitfenster, ein Lastwagen hat eine FIN. Jetzt setzen wir sie um, und hier springen die Leute direkt zu «Textfeld». Moment. Vor dem Typ möchte ich wissen, was die Daten bedeuten. Ist es eine Zahl oder eine Kennung, die zufällig aus Ziffern besteht? Ein Datum oder ein Zeitpunkt? Freitext oder einer aus einer genehmigten Menge? Von einer Person eingegeben oder im Besitz eines anderen Systems? Kann es sich ändern? Muss es eindeutig sein? Kann es fehlen? Sollte es überhaupt gespeichert oder berechnet werden? Das sind keine Setup-Fragen. Es sind Fragen der Datenarchitektur, und der Feldtyp kommt, nachdem wir sie beantwortet haben.

Eine Zahl ist nicht immer eine Zahl

Steve Trucking gibt jedem Lastwagen eine Flottennummer, sagen wir 001247. Zahlenfeld? Wahrscheinlich nicht. Addieren wir Flottennummern? Ist Lastwagen 1247 minus Lastwagen 1246 ein Lastwagen? Es ist eine Kennung, die zufällig Ziffern enthält, und ein Zahlenfeld würde sogar die führenden Nullen verlieren. Dasselbe gilt für Postleitzahlen, Produktcodes, Kontonummern und Sendungsnummern. Wie der Wert aussieht, sagt Ihnen nicht, was er bedeutet. Wählen Sie den Typ nach dem Verhalten, das Sie brauchen, nicht danach, wie die Beispieldaten aussehen.

Muss ein Mensch es erkennen?

Jedes benutzerdefinierte Objekt bekommt ein Feld Name, und die erste Entscheidung ist Text oder Automatische Nummer. Ich frage: Muss ein Mensch dieses Ding erkennen? Menschen kennen einen Handelspartner beim Namen und einen Lastwagen an seiner Flottennummer. Aber eine Ladeliste, die das System jede Nacht erzeugt? Niemand sollte «Ladeliste 10-02 Nummer 3» tippen müssen, nur weil Salesforce einen Namen verlangt hat. Geben Sie ihr eine automatische Nummer. Verwechseln Sie diesen erzeugten Namen nur nicht mit der Identität des Datensatzes: Die automatische Nummer hilft den Benutzern, die Salesforce-ID identifiziert den Datensatz, und die eigene Ladelistenreferenz des Handelspartners identifiziert dasselbe Ding vielleicht über Systeme hinweg. Drei verschiedene Aufgaben.

Der Detailbildschirm

Typ wählen, auf Weiter klicken, und das Setup fragt nach den Details. Auf diesem Bildschirm fallen die meisten Entscheidungen dieses Moduls tatsächlich, meistens in Eile.

New Custom Field (Neues benutzerdefiniertes Feld), Schritt 2: die Details (Screenshot, 2026-10-12). Volle Grösse

Zwei Kästchen sehen gleich aus und erfüllen verschiedene Aufgaben. Description (Beschreibung) ist für die Menschen, die die Org pflegen, und jetzt auch für die KI-Werkzeuge, die sie lesen: was das Feld bedeutet, wem es gehört, woher es kommt. Help Text (Hilfetext) ist für die Person am Bildschirm: was hier einzutragen ist. Füllen Sie beide aus. Dann kommen Required (Erforderlich), Unique (Eindeutig) und External ID (externe ID), und jedes davon verdient einen eigenen Abschnitt. Darunter kann Default Value (Standardwert) eine Formel sein, sodass ein neuer Datensatz mit einem sinnvollen Wert beginnen kann statt mit einem leeren.

Erforderlich ist eine grössere Entscheidung, als es aussieht

Im Feldassistenten gibt es ein kleines Kontrollkästchen mit der Beschriftung Erforderlich, und wie wir in Kapitel 1 gesehen haben, kann es eine Zeitbombe sein. Sie haben ein Objekt seit fünf Jahren und zwei Millionen Datensätze, und jetzt entscheidet jemand, dass ein neues Feld immer einen Wert haben muss. Was ist mit den zwei Millionen Datensätzen, die älter sind? Den Integrationen, die es nicht senden? Der Automatisierung, die den Datensatz erstellt, bevor der Wert bekannt ist? Dem Prozess, in dem der Wert erst drei Schritte später auftaucht?

«Erforderlich» klingt nach einer Entscheidung zur Datenqualität, und manchmal ist es eine. Aber wann ein Wert bekannt wird, ist Teil des Geschäftsprozesses. Kreuzen Sie also Erforderlich nicht an, weil jemand sagt «Das wollen wir immer». Fragen Sie, wann er bekannt ist, wer ihn liefert und was passiert, wenn er fehlt. Wir setzen das in Modul 7 auf die vollständige Konsistenzleiter.

Auch eindeutig bedeutet etwas

Wenn ich ein Feld als eindeutig kennzeichne, mache ich eine Aussage über das Geschäft: nicht «Es wiederholt sich meistens nicht», sondern «Zwei Datensätze dürfen niemals diesen Wert haben.» Das ist stark. Und der Bildschirm lässt Sie noch etwas entscheiden: Sind «ABC» und «abc» derselbe Wert oder verschiedene? Ohne Unterscheidung von Gross- und Kleinschreibung ist die sicherere Voreinstellung für alles, was ein Mensch eintippt. Die Schlüsselregel aus Kapitel 2, eindeutig, unveränderlich, bedeutungslos, niemals personenbezogen, gilt hier. Wenn mir jemand sagt, die dienstliche E-Mail-Adresse von Mitarbeitenden sei eindeutig, beginne ich zu fragen: Kann sie sich ändern, kann jemand gehen und zurückkommen, können Adressen wiederverwendet werden, was passiert nach einer Übernahme? E-Mail kann nützlich sein, heute sogar eindeutig. Das macht sie nicht zu einer guten Identität.

Externe IDs: Identität über die Grenze hinweg

Hier zahlen sich externe IDs aus. Der Bildschirm beschreibt es gut: Das Feld wird zu «the unique record identifier from an external system», der eindeutigen Datensatzkennung aus einem externen System. Das ERP hat den Kunden 873492; Salesforce hat seine eigene Datensatz-ID. Wenn das ERP eine Aktualisierung schickt, woher wissen wir, zu welchem Datensatz sie gehört? Kennzeichnen Sie ein Feld als externe ID, und eine Integration kann darüber einen Upsert ausführen: den Datensatz erstellen, wenn er nicht existiert, und aktualisieren, wenn doch (Upsert a Record Using an External ID (opens in a new tab), auf Englisch). Und wenn Sie untergeordnete Datensätze laden, können Sie auf den übergeordneten über seine externe ID verweisen, statt zuerst die Salesforce-ID abzufragen. Ich sage gern: Sie lassen Salesforce das Nachschlagen für Sie erledigen. Sehr mächtig.

Beachten Sie, dass die Nummer des ERP nicht zur Identität des Salesforce-Datensatzes wird. Sie ist ein Attribut, und ein Datensatz kann mehrere tragen: eine ERP-Kunden-ID, eine Alt-ID, die ID eines Partners. Das ist in Ordnung. Eine Geschäftsentität kann mehreren Systemen unterschiedlich bekannt sein. Die Architekturfrage ist, welchem System jede Kennung gehört und welches Versprechen sie gibt: Kennzeichnen Sie sie nur als eindeutig, wenn das Geschäft das wirklich garantiert.

Feldtyp für Feldtyp

Jetzt die Typen selbst. Öffnen Sie New Field (Neues Feld) bei einem beliebigen Objekt, und das Setup zeigt Ihnen die ganze Liste, so gruppiert, wie ich sie durchgehe: die Felder, die Salesforce für Sie berechnet, die Beziehungsfelder und dann die Datentypen.

Setup, New Custom Field, Schritt 1: die Datentypen (Screenshot, 2026-10-12). Volle Grösse

Hier die ganze Liste auf einen Blick, mit dem einen, was Sie sich zu jedem merken sollten.

Gruppe	Typ	Merken
Berechnet	Automatische Nummer	Bis zu 30 Zeichen, davon 20 für Präfix oder Suffix; ein Etikett für Menschen, nicht die Identität des Datensatzes
	Formel	Beim Lesen berechnet, nicht gespeichert; 3’900 Zeichen
	Rollup-Zusammenfassung	Anzahl, Summe, Minimum oder Maximum der Details; nur bei Master-Detail
Beziehungen	Nachschlagen, Master-Detail, externes Nachschlagen	Modul 7
Daten	Kontrollkästchen	Wahr oder falsch, mit einer gewählten Voreinstellung; in Flows kann trotzdem null auftauchen
	Zahl, Prozent, Währung	Rundungsregeln; führende Nullen fallen weg; 15 Nachkommastellen
	Datum, Datum/Uhrzeit, Uhrzeit	Ein Tag, ein Zeitpunkt oder eine Tageszeit; Zeitpunkte werden in UTC gespeichert
	E-Mail, Telefon, URL	Beim Speichern formatiert und geprüft: 80, 40 und 255 Zeichen
	Geolocation, Adresse	Zusammengesetzte Felder, die mehr als ein Feld kosten: 3 und 9
	Auswahlliste, Mehrfachauswahl	Ein kontrolliertes Vokabular, im Besitz der Administration
	Text, Textbereich, lang, Rich, verschlüsselt	Bis 255 am Datensatz und indizierbar; darüber kein Index und keine Filterung

Die Felder, die Salesforce berechnet

Automatische Nummer (Auto Number) vergibt jedem neuen Datensatz die nächste Nummer einer Folge, in einem Format, das Sie festlegen, etwa T-{000000}. Nutzen Sie sie, wenn ein Mensch einen handlichen Namen braucht und niemand einen erfinden sollte. Der ganze Wert hat bis zu 30 Zeichen, und 20 davon sind für das Präfix oder Suffix reserviert. Denken Sie nur an Kapitel 2: Sie ist ein Etikett für Menschen, nicht die Identität des Datensatzes, und die Nummern sind nicht immer streng fortlaufend.

Formelfelder (Formula) berechnen einen Wert aus anderen Feldern. Sie sind mächtig, und sie werden berechnet, wenn der Datensatz gelesen wird, nicht wenn er gespeichert wird, es gibt also nichts Gespeichertes, das veralten könnte. Sie wählen, was die Formel zurückgibt: ein Kontrollkästchen, eine Währung, ein Datum, Datum/Uhrzeit, eine Zahl, einen Prozentwert, Text oder eine Uhrzeit.

New Custom Field, Formel: den Rückgabetyp wählen (Screenshot, 2026-10-12). Volle Grösse

Dann schreiben Sie die Formel selbst, mit Feldern, Operatoren und Funktionen, und prüfen ihre Syntax. Beachten Sie die Schaltfläche Use Formula Assistant (Formel-Assistent verwenden): Die KI von Salesforce hilft Ihnen jetzt, die Formel zu schreiben. Nutzen Sie sie, und lesen Sie dann, was sie geschrieben hat. Die Formel gehört Ihnen, nicht dem Assistenten.

Der Formeleditor mit dem Formel-Assistenten (Screenshot, 2026-10-12). Volle Grösse Eine Formel kann bis zu 3’900 Zeichen lang sein und darf beim Speichern oder Kompilieren 15’000 Byte nicht überschreiten; eine lange Formel lässt sich auf mehrere Formelfelder aufteilen, die aufeinander verweisen. Lange Textbereiche, verschlüsselte Felder und Beschreibungsfelder können darin nicht verwendet werden.

Rollup-Zusammenfassungsfelder (Roll-Up Summary) sitzen auf dem Master und zählen, summieren oder nehmen das Minimum oder Maximum seiner Detaildatensätze. Sie funktionieren nur über eine Master-Detail-Beziehung, und das ist einer der grössten Gründe, überhaupt Master-Detail zu wählen. Wir kommen in Modul 7 auf sie und ihre Grenzen zurück.

Gespeichert oder abgeleitet?

Müssen wir diesen Wert überhaupt speichern? Wenn ich Menge und Stückpreis habe, muss dann jemand, oder eine Automatisierung, eine Summe pflegen? Vielleicht sollte eine Formel sie ableiten: eine Quelle für die Berechnung, beim Lesen neu berechnet, sodass bei einer Änderung der Menge die Antwort folgt. Formeln haben eigene Grenzen (Grösse beim Speichern und angezeigte Länge; Formula Field Limits and Restrictions (opens in a new tab), auf Englisch), und komplexe werden schwer zu warten.

Aber manchmal will das Geschäft nicht die heutige Antwort. Es will die Antwort, wie sie damals war. Wenn sich die Rabattregel nächstes Jahr ändert, sollte die Rechnung vom letzten Jahr dann plötzlich einen anderen Betrag zeigen? Natürlich nicht. Die Frage ist also nicht «Kann Salesforce das berechnen?» Sie lautet: «Ist das eine aktuelle Berechnung oder eine historische Tatsache?» Historische Tatsachen werden gespeichert.

Die Beziehungsfelder

Nachschlage-, Master-Detail- und externe Nachschlagebeziehungen (Lookup, Master-Detail, External Lookup) sind ebenfalls Felder, und mit ihnen werden die Linien Ihres Modells real. Die Nachschlagebeziehung ist die lose Verbindung; Master-Detail bindet Leben, Eigentümerschaft und Sicherheit des untergeordneten Datensatzes an den übergeordneten; die externe Nachschlagebeziehung erreicht ein externes Objekt aus Modul 4 und gleicht über dessen externe ID ab. Die Wahl zwischen ihnen ist eine so grosse Entscheidung, dass sie ein eigenes Modul bekommt.

Kontrollkästchen

Ein Kontrollkästchen (Checkbox) ist das einfachste Feld, das es gibt: wahr oder falsch, aktiviert oder nicht aktiviert. Es passt perfekt zu einer Ja/Nein-Tatsache über den Datensatz: Ist aktiv, Installation erforderlich, Empfang quittiert. Wenn Sie eines erstellen, lässt Salesforce Sie seinen Standardwert wählen, aktiviert oder nicht aktiviert, und das ist eine echte Entscheidung: Damit beginnt jeder neue Datensatz, auch Datensätze, die eine Integration erstellt, ohne das Feld zu senden. Berichte und Listenansichten filtern es als True und False; die Importwerkzeuge und der wöchentliche Export zeigen es als 1 und 0.

Eine Falle sollten Sie kennen. Das Feld am Datensatz hat zwei Werte, aber die Automatisierung darum herum kann einen dritten haben. In einem Flow ist eine Kontrollkästchen-Variable, die nie gesetzt wurde, null, nicht false, und sie in einem Datensatz zu speichern schlägt fehl (Trailblazer Community (opens in a new tab), auf Englisch; siehe auch das bekannte Salesforce-Problem W-11208535 (opens in a new tab)). Wählen Sie eine sinnvolle Voreinstellung, und lassen Sie Ihre Flows und Ihren Code null bewusst behandeln.

Zahl, Prozent und Währung

Zahl (Number) speichert eine reelle Zahl und lässt führende Nullen weg, und genau deshalb ist eine Flottennummer wie 001247 keine Zahl. Salesforce rundet Zahlenfelder kaufmännisch, weg von null: Aus 12,345 wird 12,35, und aus −12,345 wird −12,35. Und in Seriendruckfeldern rundet es nach dem Gebietsschema der Benutzer, nicht nach den Nachkommastellen, die Sie am Feld eingestellt haben.

Prozent (Percent) speichert eine Dezimalzahl und zeigt einen Prozentwert: Geben Sie 0,10 ein, und Sie sehen 10 %. Nach 15 Nachkommastellen verlieren Werte an Genauigkeit.

Währung (Currency) ist für Geldbeträge formatiert, und in einer Org mit mehreren Währungen trägt sie ihren Währungscode und kann Wechselkurse nutzen; mit der erweiterten Währungsverwaltung (opens in a new tab) (Advanced Currency Management, auf Englisch) können Opportunities datierte Wechselkurse nutzen, den Kurs für den Zeitraum, in dem der Deal abgeschlossen wurde. Nur Opportunities und das, was zu ihnen gehört (Produkte, Zeitpläne, Aufteilungen und ihre Berichte), nutzen datierte Kurse; Währungsfelder anderer Objekte behalten den einen statischen Kurs. Achten Sie auf die Rundung: Ohne Nachkommastellen schneidet Salesforce einfach ab (aus 23,5 wird 23); mit einer oder mehr rundet es kaufmännisch, weg von null.

Datum, Datum/Uhrzeit und Uhrzeit

Drei Typen, drei verschiedene Bedeutungen. Ein Datum (Date) ist ein Tag: Ein Vertrag läuft an einem Datum aus. Ein Datum/Uhrzeit (Date/Time) ist ein Zeitpunkt: Die Lieferung kam an jenem Morgen um 9:42 Uhr an. Eine Uhrzeit (Time) ist eine Tageszeit ganz ohne Datum: Die Filiale öffnet jeden Tag um 7:00 Uhr.

Die Falle ist der Zeitpunkt. Salesforce speichert Datum/Uhrzeit-Werte in GMT (UTC). Die Uhrzeit, die ein Benutzer eintippt, wird in seiner Zeitzone gelesen, umgerechnet und gespeichert; wenn jemand sie liest, wird sie wieder in die Zeitzone der lesenden Person umgerechnet. Meistens ist das genau, was Sie wollen. Aber hier das Beispiel, das ich im Kurs gebe: Jemand aus der Koordination in Los Angeles erfasst eine Lieferung spät am Sonntagabend, um 22 Uhr pazifischer Zeit. Darunter hat Salesforce Montagmorgen gespeichert, 5 Uhr GMT. Ein Bericht, der in einer anderen Zeitzone nach Tag gruppiert, oder eine Integration, die den Rohwert liest, kann diese Sonntagslieferung auf Montag legen. «Der Tag, an dem es passiert ist» hängt davon ab, wessen Uhr Sie fragen. Achten Sie auf die Zeitzonen der Benutzer, und entscheiden Sie, welche das Geschäft meint.

Und seien Sie vorsichtig beim Vergleichen. Darunter ist ein Datum/Uhrzeit-Wert eine grosse Zahl: Apex liest ihn als die Anzahl der Millisekunden seit dem 1. Januar 1970, 00:00:00 GMT (Datetime Class (opens in a new tab), auf Englisch). Er ist ein präziser Zeitpunkt, kein Tag. Zu fragen, ob zwei Datum/Uhrzeit-Werte gleich sind (==), tut also fast nie, was Sie wollen: 9:42:00 und 9:42:01 sind nicht gleich, und «Montag» und irgendein Zeitpunkt am Montag auch nicht. Fragen Sie stattdessen nach einem Bereich: am oder nach dem Beginn (>=) und am oder vor dem Ende (<=). «Jede Lieferung am Montag» ist jede Lieferung >= Montag 00:00 und <= Montag 23:59:59, in der Zeitzone, von der Sie entschieden haben, dass das Geschäft sie meint.

Und eine nette Kleinigkeit: Salesforce kann nicht jedes beliebige Datum speichern. Gültige Daten reichen vom 1. Januar 1700 bis zum 31. Dezember 4000, und Salesforce nennt denselben Bereich für Datum und Datum/Uhrzeit (Data Import Dates (opens in a new tab), auf Englisch). Selbst die Ränder sind Zeitpunkte in GMT, für einen Benutzer in pazifischer Zeit ist der früheste gültige Wert also 16 Uhr am 31. Dezember 1699. Das Gründungsdatum Ihres Geschichtsvereins passt vielleicht nicht hinein. Und der klassische Trick für «kein Enddatum», der 31. Dezember 9999, wird abgelehnt; wenn Sie einen Platzhalter in ferner Zukunft brauchen, muss er im Jahr 4000 oder davor liegen.

E-Mail, Telefon und URL

Das sind die formatierten Felder, und sie tun mehr, als Zeichen zu speichern. E-Mail (Email) fasst bis zu 80 Zeichen und wird auf ein korrektes Format geprüft; bei Kontakten und Leads startet ein Klick darauf eine E-Mail an diese Adresse. Telefon (Phone) fasst bis zu 40 Zeichen, wird als Telefonnummer formatiert und wird zu Click-to-Dial, wenn die Org eine Telefonanlage angebunden hat. URL fasst bis zu 255 Zeichen und öffnet sich als Link. Das ist Verhalten, das Ihnen die Plattform umsonst gibt, und deshalb würde ich eine Telefonnummer nie in einem einfachen Textfeld speichern.

Auch Integrationen werden geprüft. Ein Wert, der nicht zum Format des Felds passt, etwa eine falsch gebildete E-Mail-Adresse, besteht die Validierung nicht, und der ganze Datensatz wird abgelehnt, nicht nur dieses Feld. Wenn die Daten des Quellsystems also unsauber sind, bereinigen Sie sie, bevor sie ankommen, oder planen Sie für die Datensätze, die nicht geladen werden.

Geolocation und Adresse

Geolocation hält einen Breitengrad und einen Längengrad. Darunter besteht ein Feld namens Location__c eigentlich aus zwei Werten, die Sie einzeln lesen und setzen können, Location__Latitude__s und Location__Longitude__s. Und Sie können danach abfragen: Die SOQL-Funktionen DISTANCE und GEOLOCATION finden Datensätze innerhalb eines Radius oder sortieren sie nach Entfernung. «Jede offene Lieferung im Umkreis von 25 Meilen um diesen Lastwagen» ist eine Abfrage: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab), auf Englisch). Adresse (Address) hält eine ganze Adresse, Strasse, Ort, Bundesland oder Provinz, Postleitzahl und Land, und Benutzer können nach einer Adresse suchen und die Teile ausfüllen lassen.

Beide sind zusammengesetzte Felder: ein Feld auf dem Bildschirm, mehrere darunter. Und sie kosten mehr als ein Feld gegenüber der Grenze Ihres Objekts: Eine Geolocation zählt als drei benutzerdefinierte Felder, eine Adresse als neun. Bei einem Objekt, das schon voll ist, spielt das eine Rolle.

Auswahlliste und Mehrfachauswahl

Eine Auswahlliste (Picklist) steuert, was Benutzer eingeben können: einen Wert aus einer Liste, die Sie festlegen. Status? Wahrscheinlich eine Auswahlliste. Aber die Werte sind Metadaten, und die Administration muss sie hinzufügen oder ändern. Also frage ich trotzdem, wem die Werte gehören, wie oft sie sich ändern, ob mehrere Objekte dieselbe Liste brauchen, ob die Werte eigene Informationen tragen und ob ein anderes System das Vokabular besitzt.

Wo die Werte liegen, ist ebenfalls eine Entscheidung. Wenn eine Liste einmal verwendet wird, an einem Feld, halten Sie die Werte am Feld selbst, am Objekt; das tut Salesforce standardmässig. Wenn aber dieselbe Wertemenge an mehreren Stellen auftaucht, eine Region am Account, an der Lieferung und am Lager, machen Sie daraus eine globale Werteliste, bevor die Kopien auseinanderlaufen. Eine globale Werteliste hält eine Liste für alle, bis zu 1’000 Werte, aktive und inaktive zusammen (Picklist Limitations (opens in a new tab), auf Englisch). Die Beschreibung im Setup selbst sagt, warum das wichtig ist: Die Werteliste «is restricted so users can’t add unapproved values through the API», ist also so eingeschränkt, dass niemand über die API nicht genehmigte Werte hinzufügen kann. Eine Liste, eine verantwortliche Stelle, und keine Integration schmuggelt eine neue Schreibweise hinein.

Dieser letzte Punkt ist der Unterschied zwischen eingeschränkt und uneingeschränkt. Bei einer eingeschränkten Auswahlliste sind nur die Werte erlaubt, die die Administration festgelegt hat, von überall her: Ein Benutzer, ein Import oder eine Integration, die etwas anderes sendet, bekommt einen Fehler, «bad value for restricted picklist field», und der Datensatz wird nicht gespeichert. Bei einer uneingeschränkten Auswahlliste wählen Benutzer auf dem Bildschirm weiterhin aus der Liste, aber API, Importe und Automatisierung können jeden Wert senden, und Salesforce speichert ihn und fügt ihn als inaktiven Wert hinzu (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab), auf Englisch). So landet eine Org bei «Delivered», «delivered» und «Dlvrd». Globale Wertelisten sind immer eingeschränkt. Meine Voreinstellung ist eingeschränkt; uneingeschränkt ist eine bewusste Wahl für den Fall, dass wirklich ein anderes System die Werte besitzt, und dann ist jemand dafür verantwortlich, die inaktiven aufzuräumen.

Setup, Picklist Value Sets: eine neue globale Werteliste (Screenshot, 2026-10-12). Volle Grösse

Eine Mehrfachauswahlliste (Multi-Select Picklist) lässt Benutzer mehrere Werte wählen, zusammen gespeichert und durch Semikolons getrennt. Bequem auf dem Bildschirm, umständlich überall sonst: schwerer zu filtern, auszuwerten und zu integrieren, und sie lässt sich nicht im Filter einer Rollup-Zusammenfassung verwenden. Mehrere Werte für einen Datensatz bedeuten meist die Lektion aus Kapitel 2: Da will ein untergeordnetes Objekt heraus.

Eine Auswahlliste hat ausserdem einen Wert mehr als die, die Sie festgelegt haben: leer. Ein Datensatz kann ohne Auswahl dastehen, und das erwischt Leute. In einer Formel oder Validierungsregel können Sie eine Auswahlliste nicht allein mit ISBLANK prüfen; Sie schreiben ISBLANK(TEXT(Field__c)) oder ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab), auf Englisch). Entscheiden Sie also für jede Auswahlliste, was «kein Wert» bedeutet: Ist es erlaubt, und was bedeutet es, wenn es vorkommt? Dann sorgen Sie dafür, dass Ihre Formeln, Validierungsregeln und Filter damit umgehen.

Und manchmal ist ein Attribut eigentlich eine Entität. Jemand möchte eine Auswahlliste der Verteilzentren. Es gibt neun. Leicht. Dann erfahren wir, dass jedes eine Adresse, eine Leitung, Öffnungszeiten, Kapazität, eine Region und Lastwagen hat. Das ist keine Auswahlliste; das ist ein Ding. Machen Sie aus einer Entität keine Auswahlliste, nur weil es noch nicht viele davon gibt. Im ersten Jahr fühlt es sich grossartig an, im fünften furchtbar. (Modul 5 von Kapitel 2 enthält meine Faustregeln dafür, wann eine Liste ein eigenes Objekt verdient.)

Die Textfamilie

Ich unterrichte Text als zwei Arten, und die Grenze zwischen ihnen liegt bei 255 Zeichen.

Bis 255: mit dem Datensatz gespeichert. Text fasst bis zu 255 Zeichen, und Sie können ihn fast überall verwenden: in Formeln, Filtern, Berichten, Listenansichten, als eindeutiges Feld oder als externe ID, und er kann indiziert werden. Textbereich (Text Area) fasst ebenfalls 255, auf mehreren Zeilen, wie eine kurze Notiz.

Über 255: per Verweis gespeichert. Textbereich (lang) (Text Area (Long)) fasst bis zu 131’072 Zeichen, und Textbereich (Rich) (Text Area (Rich)) dasselbe mit Formatierung, Links und Bildern. Ich stelle sie mir als seitlich abgelegt vor, wobei der Datensatz einen Zeiger hält, und so verhalten sie sich auch: kein Index, Sie können sie also nicht eindeutig oder zur externen ID machen; Sie können in einer SOQL-WHERE-Klausel nicht nach ihnen filtern (SOQL WHERE (opens in a new tab), auf Englisch); Formeln können sie nicht verwenden (Formula Field Limits and Restrictions (opens in a new tab), auf Englisch); und Berichte zeigen bei einem benutzerdefinierten nur die ersten 254 Zeichen, wobei Berichtsfilter nur etwa die ersten 255 durchsuchen (Filter Restrictions for Text Area (Long) Fields (opens in a new tab), auf Englisch). Bilder, die in ein Rich-Text-Feld hochgeladen werden, dürfen je bis zu 1 MB gross sein, und sie zählen gegen den Dateispeicher, während der Text gegen den Datenspeicher zählt (Rich Text Area Field Considerations (opens in a new tab), auf Englisch). Wenn also irgendjemand nach dem Wert suchen, sortieren, abgleichen oder darüber berichten muss, halten Sie ihn unter 255 und halten Sie ihn als Textfeld.

Text (verschlüsselt) (Text (Encrypted)) speichert bis zu 175 Zeichen in verschlüsselter Form, mit Classic Encryption. Wenn Ihre Org Shield Platform Encryption nutzt, verschlüsseln Sie stattdessen ein gewöhnliches Textfeld, und viele andere Typen lassen sich auf diese Weise ebenfalls verschlüsseln.

Geben Sie jedem Feld eine Beschreibung

Mein Standard: Jedes Feld bekommt eine Beschreibung. Davon bin ich seit Langem überzeugt, und in der Zeit der KI ist es wichtiger denn je: Jedes KI-Werkzeug und jeder Agent, der Ihre Org liest, liest die Beschreibungen, um zu verstehen, was ein Feld bedeutet. Eine leere Beschreibung ist eine Vermutung, die nur darauf wartet, zu passieren. Was bedeutet Customer_Status__c? Wem gehört es? Woher kommt es? Können Benutzer es bearbeiten, oder überschreibt das ERP es heute Nacht? In sechs Monaten weiss ich es nicht mehr, und in drei Jahren weiss es die Person, die die Org administriert, nicht, wenn wir es ihr nicht gesagt haben. Die Beschriftung ist keine Dokumentation, und der API-Name auch nicht.

Bei stark gemeinsam genutzten Objekten (Account, Kontakt, Opportunity) verwende ich für Spezialfelder auch Namenspräfixe, sodass Herkunft und Zweck im Namen selbst sichtbar sind: Alles, was das ERP besitzt, beginnt zum Beispiel mit demselben Präfix. Ich will keine API-Namen mit zwölf Wörtern. Ich will, dass das Modell sich selbst erklärt.

Klassifizieren Sie, was zählt: die Taxonomiefelder

Salesforce gibt jedem Feld eine Reihe von Klassifizierungsmetadaten. Ich nenne sie die Taxonomiefelder. Sie können die Dateneigentümerschaft (Data Owner) festhalten; die Feldnutzung (Field Usage: Active, DeprecateCandidate, Hidden); die Sensibilitätsstufe der Daten (Data Sensitivity Level: Public, Internal, Confidential, Restricted, MissionCritical); und die Compliance-Kategorisierung: PII, HIPAA, GDPR, PCI, CCPA und andere. Sie funktionieren bei Standardfeldern ebenso wie bei benutzerdefinierten (Data Classification Metadata Fields (opens in a new tab), auf Englisch).

Warum der Aufwand? Weil Prozesse sie lesen können. Kennzeichnen Sie ein Feld mit GDPR, und ein Prozess kann jedes GDPR-Feld auf einem Datensatz finden und maskieren oder entfernen. Und wenn die Vertrauensschicht von Salesforce einen Prompt an ein grosses Sprachmodell schickt, kann sie genau diese Klassifizierung nutzen, um sensible Felder zu maskieren: Sie tauscht den Namen eines Kunden, sagen wir «Maria Lopez», auf dem Hinweg gegen einen Platzhalter, das Modell sieht den Namen nie, und auf dem Rückweg wird der Name wieder in die Antwort eingesetzt (Einstein Trust Layer (opens in a new tab), auf Englisch).

Eine Aktualisierung. Salesforce dokumentiert inzwischen, dass die muster- und feldbasierte Maskierung für LLMs bei Agenten deaktiviert ist: Die Maskierung kann den Kontext entfernen, den ein Agent für seine Antwort braucht (Data Masking Limitations in Agentforce (opens in a new tab), auf Englisch). Die Klassifizierung steuert die Maskierung für andere generative KI-Funktionen weiterhin, aber verlassen Sie sich nicht darauf, dass sie personenbezogene Daten von einem Agenten fernhält; das ist eine Entscheidung über Zugriff und Entwurf (Kapitel 12).

Meine Position: Klassifizierung ist zu den entscheidenden Zeitpunkten wichtig. Machen Sie daraus keine drei Wochen, in denen jedes Kästchen ausgefüllt wird, weil die Governance es verlangt hat. Nutzen Sie sie, wo es zählt: personenbezogene Daten, Finanzdaten, regulierte Daten und Felder, bei denen das Geschäft einen benannten Eigentümer braucht. Es geht darum, dass Sensibilität kein Wissen mehr im Kopf von jemandem ist, sondern Teil des Felds wird.

Über die Prüfung hinaus: Was KI ändert. Schlechte Felddokumentation hat früher die nächste Person in der Administration bestraft. Jetzt führt sie jedes KI-Werkzeug und jeden Agenten in die Irre, der das Schema liest: Ist Flag2__c sensibel, massgeblich, noch in Gebrauch? KI erzeugt Felder auch schneller als jedes Team, also sind Namen, Beschreibungen und Klassifizierung Teil der Architektur, nicht Haushaltsführung.

Jedes Feld ist eine Verpflichtung

Sobald ein Feld draussen Daten sammelt, fängt alles an, sich darauf zu stützen. Bildschirme zeigen es an, Flows verzweigen danach, Validierungsregeln prüfen es, Berichte gruppieren danach, Integrationen senden und lesen es, und jetzt denken KI-Werkzeuge darüber nach. Jedes davon trifft Annahmen über das Feld: seinen Typ, seine Länge, ob es je leer ist und was seine Werte bedeuten. Ändern Sie das Feld später, müssen Sie zuerst jede dieser Annahmen finden. Einen Auswahllistenwert umbenennen, ein Textfeld kürzen oder ein Textfeld in eine Auswahlliste umwandeln klingt nach einer kleinen Änderung, und es kann eine Integration im System eines anderen Unternehmens kaputt machen. Deshalb ist ein Feld eine Verpflichtung.

Click to enlarge

Ich möchte nicht, dass Sie dieses Modul mit Angst vor dem Erstellen von Feldern verlassen. Salesforce ist dafür gebaut, erweitert zu werden; nutzen Sie das. Ich möchte, dass sich die Frage ändert, von «Welchen Feldtyp soll ich nehmen?» zu «Was bedeuten diese Daten, und auf welches Verhalten verpflichten wir uns?» Typ, erforderlich, eindeutig, externe ID, Auswahlliste, Formel, Beschreibung, Klassifizierung: Zusammen sind sie der physische Ausdruck des logischen Modells aus Kapitel 2.

Was Architekt:innen hier entscheiden

• Was der Wert bedeutet, bevor der Feldtyp gewählt wird, und ob es ein Attribut, eine Kennung, ein kontrolliertes Vokabular oder eigentlich eine weitere Entität ist.
• Ob ein Wert eine aktuelle Berechnung ist, die abgeleitet werden kann, oder eine historische Tatsache, die gespeichert werden muss.
• Welchem System jede Kennung gehört und ob ihre Eindeutigkeit ein echtes Versprechen des Geschäfts ist.
• Wann ein erforderlicher Wert tatsächlich bekannt ist und was mit Datensätzen und Integrationen passiert, die ihn nicht haben.
• Welche Beschreibung, Benennung und Klassifizierung das Feld braucht, damit Menschen, Prozesse und KI es sicher nutzen können.

Weiterlesen

• Salesforce-Hilfe, Data Classification Metadata Fields (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.
• Salesforce-Hilfe, Einstein Trust Layer: Designed for Trust (opens in a new tab) und Data Masking Limitations in Agentforce (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.
• Salesforce-Hilfe, Picklist Limitations (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.
• Salesforce-Hilfe, Formula Field Limits and Restrictions (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.