Daten konsistent halten

🌐 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 9 von 10 im Kapitel Salesforce-Datenarchitektur, Kapitel 3 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Eigentümerschaft und Lebenszyklus · Weiter: Das physische Salesforce-Modell entwerfen

Die Frage, die dieses Modul beantwortet: Wie halte ich Daten konsistent, und was kostet jede Schicht?

Alle wollen saubere Daten. Ich habe noch nie eine Anforderungsbesprechung erlebt, in der jemand sagte: «Am liebsten hätten wir inkonsistente Daten.» Der Streit kommt später: Wo setzen wir die Regeln durch? Auf dem Bildschirm? Ein Pflichtfeld? Eine Auswahlliste, eine Validierungsregel, eine Duplikatsregel, ein Flow, Apex? Alle helfen. Sie sind nicht austauschbar, und jede Schicht hat ihren Preis.

Meine allgemeine Regel lautet: Schieben Sie die Regel so weit nach unten, wie es vernünftig geht. Wenn ein Wert immer nur eines von fünf Dingen sein kann, lassen Sie die Leute nicht beliebig tippen und räumen es später mit Automatisierung auf. Wenn zwei Datensätze nie dieselbe Kennung haben dürfen, verlassen Sie sich nicht darauf, dass es jemand in einem Bericht bemerkt. Wenn eine Regel gelten muss, egal ob der Datensatz von einem Bildschirm, einer API, einer Integration, einem Datenladevorgang oder einem Agenten kommt, setzen Sie sie nicht nur in der Oberfläche durch. Je näher die Regel an den Daten sitzt, desto schwerer lässt sie sich umgehen. Ich nenne das die Konsistenzleiter.

Erste Sprosse: der Feldtyp und das Vokabular

Die erste Konsistenzregel ist die aus Modul 6: Wählen Sie den richtigen Typ. Ein Datum ist ein Datum, ein Zeitpunkt ist Datum/Uhrzeit, Geld ist Währung. Das ist Konsistenz, bevor irgendjemand eine Regel schreibt.

Machen Sie den Status einer Lieferung zu einem Textfeld, und Sie bekommen Delivered, delivered, DELIVERED, Complete, Done und Dropped off, und jemand muss herausfinden, ob diese sechs dasselbe bedeuten. Oder definieren Sie das Vokabular einmal: Geliefert, ein Wert, eine Bedeutung. Machen Sie es zu einer eingeschränkten Auswahlliste, damit sie alles ablehnt, was nicht auf der Liste steht, auch über die API, und zu einer globalen Werteliste, wenn mehrere Felder die Liste teilen (Modul 6 hat die Einzelheiten).

Aber verwenden Sie keine Auswahlliste, nur um Leute am Tippen zu hindern. Ist es wirklich ein Wert oder eine weitere Entität? Neun Verteilzentren mit je einem Namen sehen vielleicht wie eine Auswahlliste aus; neun mit Adressen, Leitungen, Kapazität und Lastwagen sind Datensätze. Die Regel soll das Modell stärken, nicht ein schlechtes ausgleichen. Und wenn es wirklich ein kontrolliertes Vokabular ist, kontrollieren Sie es am Feld. Lassen Sie nicht erst Chaos zu, um dann einen Flow zu bauen, der AZ, Arizona, Ariz und Phoenix area in den Wert verwandelt, den Sie von Anfang an wollten.

Zweite Sprosse: erforderlich und eindeutig

Erforderlich und Eindeutig sind verlockend, weil sie einfach sind: Kästchen ankreuzen, Problem gelöst. Manchmal. Wenn jeder Lastwagen vom Tag seiner Erstellung an eine Flottennummer hat und keine zwei Lastwagen dieselbe, drücken beide Kästchen echte Geschäftsregeln aus. Das ist starke Konsistenz.

Aber sobald die Plattform eine Regel durchsetzt, ist es ihr egal, dass Ihr Prozess am Dienstagnachmittag eine Ausnahme hat. Dieses Beispiel verwende ich seit Jahren im Kurs. Ein Objekt gibt es schon eine Weile, mit vielen Datensätzen. Jemand fügt ein Feld hinzu und kreuzt Erforderlich an. Er testet das Erstellen eines Datensatzes: funktioniert wunderbar. Dann Samstagnacht, Deployment, die Tests laufen, und eine alte Testklasse erstellt das Objekt ohne das neue Feld. Bumm. Oder jemand bearbeitet einen alten Datensatz von vor der Existenz des Felds. Oder die Integration schickt dieselbe Nutzlast, die sie seit fünf Jahren schickt. Bumm. «Aber wir haben dieses Feld nicht geändert.» Der Plattform ist das egal: Sie haben den Vertrag geändert, was ein gültiger Datensatz ist. Eine neue Regel betrifft nicht nur neue Daten; sie ändert, was Sie mit den alten Daten tun können.

Dritte Sprosse: Validierungsregeln

Mit Validierungsregeln können wir viel reichere Dinge sagen. Wenn der Status Geliefert ist, muss die tatsächliche Lieferzeit ausgefüllt sein. Wenn der Stopp eine Installation ist, muss die Checkliste vollständig sein, bevor der Stopp abgeschlossen werden kann. Sie laufen, wenn der Datensatz gespeichert wird, also schützen sie den Datensatz, egal ob er von einer Seite, der API, einem Datenladevorgang, einer Integration oder einem Agenten gespeichert wurde. Darum geht es. Wenn die Regel den Datensatz schützen muss, setzen Sie sie dorthin, wo jeder Schreibvorgang auf sie trifft.

Sie haben auch Biss. Das ist ihre Stärke und ihr Preis.

Das Problem der alten Datensätze

Hier wird es hässlich. Sie haben eine Million Datensätze und fügen heute eine Regel hinzu: Die Lieferzeit darf nicht vor der Abfahrt der Tour liegen. Vernünftig. Aber zwanzigtausend alte Datensätze verletzen sie, dank einer Migration vor sieben Jahren. Ein Benutzer öffnet einen davon und ändert die Telefonnummer. Speichern. Die Regel feuert. «Ich habe eine Telefonnummer geändert. Warum erzählen Sie mir von einer Lieferzeit aus 2019?» Berechtigte Frage.

Eine Validierungsregel sollte also nicht nur sagen, was wahr sein muss. Sie sollte sagen, wann es durchgesetzt wird. Funktionen wie ISNEW() und ISCHANGED() erlauben Ihnen, eine Regel auf neue Datensätze zu beschränken oder auf Speichervorgänge, bei denen sich die betreffenden Felder tatsächlich ändern (Validation Rule Considerations (opens in a new tab), auf Englisch).

Aber ein Datensatz ändert sich nicht nur, wenn eine Person ihn bearbeitet, und viele der Gründe liegen ausserhalb Ihrer Kontrolle. Die Integration aktualisiert über Nacht den Status. Ein Flow stempelt ein Datum. Eine Führungskraft weist ein Gebiet neu zu, und auf zehntausend Datensätzen ändert sich der Eigentümer. Jemand bearbeitet eine Lieferposition, das Rollup auf der Lieferung wird neu berechnet, und das speichert die Lieferung, sodass die Validierungsregel der Lieferung für einen Benutzer feuert, der sie nie angefasst hat (Roll-Up Summary Field (opens in a new tab) warnt, dass Validierungsfehler auf dem Detail oder dem Master erscheinen können; auf Englisch). Jeder dieser Speichervorgänge trifft auf Ihre neue Regel. Fragen Sie also bei jeder neuen Regel: Soll diese Regel für diesen Speichervorgang gelten?

Das sind die Möglichkeiten, und Sie weben sie in die Regel ein:

• Immer, bei jedem Speichern. Richtig, wenn es bei der Regel wirklich um den Datensatz geht und die alten Daten sie erfüllen. Aber wissen Sie, was «jedes Speichern» bedeutet: Auch ein Batch-Job, der nur den Eigentümer ändert, oder jede kleine Bearbeitung irgendeines Felds irgendwo auf dem Datensatz muss sie erfüllen.
• Nur für neue Datensätze, mit ISNEW(). Die Regel prüft den Datensatz einmal, wenn er erstellt wird, und nie wieder. Die Vergangenheit bleibt, wie sie war, aber die Zukunft auch: Eine spätere Bearbeitung kann einen neuen Datensatz die Regel verletzen lassen, und niemand hält sie auf. Wenn das zählt, kombinieren Sie sie mit der nächsten.
• Nur wenn sich die betreffenden Felder ändern, mit ISCHANGED(). Das Bearbeiten der Telefonnummer weckt die Lieferzeitregel nicht auf.
• Nicht für bestimmte Schreibende. Eine benutzerdefinierte Berechtigung, in der Formel als $Permission geprüft, lässt den Integrationsbenutzer oder eine Datenmigration durch, während Menschen weiterhin auf die Regel treffen (How to Reference a Custom Permission in a Validation Rule (opens in a new tab), auf Englisch). Vergeben Sie sie bewusst und an wenige.
• Ab einem Stichtag, indem Sie CreatedDate mit dem Tag vergleichen, an dem die Regel live ging, wenn «neu» bedeutet «seit wir das durchsetzen». Anders als ISNEW() prüft das diese Datensätze bei jedem späteren Speichern weiter, also gilt dieselbe Warnung: Eine kleine Änderung, etwa ein Batch-Update des Eigentümers, kann bei einem Datensatz scheitern, der inzwischen abgedriftet ist.

Fügen Sie eine Regel zu Datensätzen hinzu, die Sie schon haben? Durchdenken Sie die Folgen, bevor Sie sie einschalten. Jeder vorhandene Datensatz muss sie jetzt bei seinem nächsten Speichern erfüllen, und dieses Speichern kommt vielleicht von einer Stelle, mit der Sie nicht gerechnet haben: einer nächtlichen Integration, einem Batch-Eigentümerwechsel, einem Rollup, einer Massenaktualisierung aus einer Listenansicht. Welche davon werden auf sie treffen, und was passiert mit diesem Job, wenn ein Datensatz scheitert? Der Abschnitt Bevor Sie sie einschalten zeigt die Reihenfolge, die ich verwende.

Schreiben Sie die Historie nicht um, um die Regel zufriedenzustellen

Was ist mit den zwanzigtausend alten Datensätzen? Wenn die Daten falsch sind und Sie die richtigen Werte kennen, korrigieren Sie sie. Aber ich habe eine andere Art von «Korrektur» gesehen: Niemand kennt die historische Wahrheit, man braucht nur Datensätze, die durchgehen, also aktualisiert man sie mit Werten, die die heutige Regel erfüllen. Das mag ich nicht. Alte Datensätze zu aktualisieren, damit sie die Regel erfüllen, ändert LastModifiedDate und zerstört wichtige historische Informationen, und Werte zu erfinden heisst, so zu tun, als wüssten wir etwas über die Vergangenheit, das wir nicht wissen. Geben Sie der Regel eine Umgehung für Datensätze, die älter sind als sie, statt die Historie umzuschreiben. Das kann hässlich sein, aber es ist ehrlich.

Validierung in der Oberfläche ist keine Datenvalidierung

Machen Sie ein Feld in einem Seitenlayout erforderlich, und Benutzer können ohne es nicht speichern. Dann fügt die nächtliche Integration 50’000 Datensätze ein. Hat sie Ihre Seite verwendet? Nein. Der Massenladevorgang, der API-Client und der Agent auch nicht. Eine Anforderung in der Oberfläche schützt diesen Bildschirm, nicht die Daten. Feldvalidierung in dynamischen Formularen lässt sich auf dieselbe Weise umgehen. Fragen Sie also: Wo können diese Daten hereinkommen? Lightning, das Portal, mobil, die Integration, die API, ein Massenladevorgang, Flow, Apex, ein Agent. Je mehr Türen es gibt, desto weniger traue ich einer Regel, die nur eine davon bewacht.

Vierte Sprosse: Duplikatsregeln

Jetzt gehen wir von der Konsistenz innerhalb eines Datensatzes zur Konsistenz über Datensätze hinweg. Acme Corporation, ACME Corp, Acme Inc.: vier Kunden oder einer? Keine Feldregel kann das beantworten. Abgleichsregeln legen fest, wie Datensätze verglichen werden; Duplikatsregeln entscheiden, was passiert, wenn ein wahrscheinliches Duplikat gefunden wird: mit Warnung zulassen, blockieren oder melden. Sie können bis zu fünf aktive Duplikatsregeln pro Objekt haben und bis zu drei Abgleichsregeln in jeder, und Abgleichsschlüssel beschränken jeden Vergleich auf die 100 wahrscheinlichsten Duplikate (Things to Know About Duplicate Rules (opens in a new tab), auf Englisch).

Ihr Preis ist Reibung. Wenn bei jedem Account, den jemand im Vertrieb anlegt, Mögliches Duplikat gefunden erscheint, ist das manchmal genau das, was Sie wollen, und manchmal lernen die Leute, sich ohne Lesen durchzuklicken. Legitime Datensätze können sich ähneln, und eine Integration braucht vielleicht ein anderes Verhalten als eine Person. Und die Warnung ist die von Salesforce selbst: Ihr Hinweis und ihre Liste möglicher Duplikate fügen sich vielleicht nicht in einen eigenen Bildschirm ein, den Sie gebaut haben, und wenn das Speichern ohne Oberfläche (headless) geschieht, durch eine Integration, einen Datenladevorgang, einen Agenten, gibt es gar keinen Bildschirm, auf dem sie erscheinen könnte. Entscheiden Sie also für jeden Weg, wie ein Duplikat sichtbar wird: eine Warnung für eine Person, ein blockiertes Speichern und ein Fehler für die API oder die Option «Report» (Melden) und Duplikatdatensatzgruppen, die später jemand prüft. Gute Architektur ist nicht maximale Durchsetzung; sie ist die richtige Durchsetzung.

Und prüfen Sie, welche Türen eine Duplikatsregel tatsächlich bewacht (Things to Know About Duplicate Rules (opens in a new tab), auf Englisch). Über die API und die Datenimport-Werkzeuge sieht niemand die Warnung: Eine Regel, die auf Warnen steht, blockiert das Speichern einfach. Manche Wege umgehen die Regeln ganz: Quick Create, die Schaltfläche Undelete (Wiederherstellen), eine manuelle Zusammenführung, Datensätze, die Lightning Sync oder Einstein Activity Capture hinzufügen. Und Datensätze, die im selben Moment gespeichert werden, werden nicht miteinander verglichen, nur mit Datensätzen, die schon in Salesforce sind. Laden Sie eine Datei, in der derselbe Kunde zweimal steht, und beide Zeilen können durchkommen. Eine Duplikatsregel ist ein gutes Netz. Sie ist kein Schloss an der Tür.

Prüfungswissen. Duplikatsregeln vergleichen Datensätze, die im selben Moment gespeichert werden, nicht miteinander, nur mit Datensätzen, die schon in Salesforce sind. Über die API und die Import-Werkzeuge gibt es keinen Hinweis: Ein Duplikat, das die Regel erkennt, wird einfach nicht gespeichert. Und ein Speichervorgang mit allem, was er auslöst, läuft als eine Transaktion: Scheitert irgendein Teil, wird alles zurückgerollt.

Eine Grenze. Duplikatsregeln halten eine Org sauber. Sie lösen nicht die Identität im Unternehmen. Wenn Salesforce Acme Corporation hat, das ERP ACME-10382 und die Abrechnung Kunde 77193, kann Ihnen eine Duplikatsregel nicht sagen, dass das dasselbe Unternehmen ist. Das sind Stammdaten, Kapitel 6.

Fünfte Sprosse: Automatisierung

Manche Regeln sind zu komplex für die unteren Sprossen: Sie brauchen verknüpfte Datensätze, ein anderes System, abhängige Datensätze, einen mehrstufigen Prozess. Das ist Flow, Apex, manchmal Integrationslogik. (Nicht Workflow-Regeln oder Process Builder; die werden nicht mehr unterstützt.) Automatisierung ist mächtig und teurer: mehr bewegliche Teile, mehr Tests, mehr Fehlerbehandlung, mehr Wege, auf denen eine Automatisierung über eine andere stolpert. Und Code bringt eigene Fehler mit. Wenn der Feldtyp es durchsetzen kann, schreibe ich kein Apex. Wenn eine Validierungsregel es klar sagt, baue ich keinen Flow, nur weil es Flow gibt. Lösen Sie kein Feldproblem mit einer Prozess-Engine.

Alles oder nichts: wenn sich Datensätze gemeinsam ändern

Bisher schützt jede Sprosse ein Speichern. Aber Datensätze ändern sich gemeinsam: eine Lieferung und ihre Positionen, ein Auftrag und seine Zeilen, ein Flow, der drei Objekte aktualisiert. Hier gibt Ihnen die Plattform eine starke Garantie. Ein Speichervorgang und alles, was er auslöst, die Trigger, die Flows, die Klassen, die sie aufrufen, laufen als eine Transaktion: Scheitert irgendein Teil, wird das Ganze zurückgerollt und nichts festgeschrieben (Apex Transactions (opens in a new tab), auf Englisch). Sie bekommen keine halbe Lieferung.

Massenarbeit ist die Ausnahme, die Sie wählen. Ein Datenladevorgang oder eine Apex-Database-Methode kann teilweisen Erfolg zulassen: Die guten Datensätze werden gespeichert, die schlechten kommen mit ihren Fehlern zurück, und jemand muss sich um sie kümmern (DML Statements vs. Database Class Methods (opens in a new tab), auf Englisch). Für einen Ladevorgang mit einer Million Zeilen ist das oft richtig, aber dann ist Konsistenz ein Prozess: Wer liest die Fehlerdatei, und was passiert mit den Datensätzen, die gescheitert sind?

Und dann ist da das Timing. Zwei Speichervorgänge im selben Moment können beide eine Prüfung bestehen, an der jeder allein scheitern würde. Ein Flow, der nach einem vorhandenen Auftrag sucht und dann einen anlegt, kann zwei durchlassen, und wir haben gerade gesehen, dass Duplikatsregeln gleichzeitig gespeicherte Datensätze nicht vergleichen. Ein als Eindeutig (Unique) gekennzeichnetes Feld oder eine externe ID wird von der Plattform bei jedem Speichern geprüft, also gewinnt nur einer von beiden. Das ist ein weiterer Grund, die Eindeutigkeit bis aufs Feld hinunterzuschieben. Sperren, Konkurrenz um Ressourcen und Wiederholungsversuche sind ein eigenes Thema; Kapitel 11, Transaktionen, Nebenläufigkeit und Zuverlässigkeit, geht in die Tiefe.

Schieben Sie die Regel nach unten, bis sie dort nicht mehr hingehört

«So weit nach unten, wie es vernünftig geht» heisst nicht «immer ganz unten». Wenn ein Feld erst erforderlich ist, sobald eine Opportunity eine bestimmte Phase erreicht, ist es falsch, es im Schema erforderlich zu machen; die Regel ist bedingt, also ist eine Validierungsregel die richtige Sprosse. Wenn ein Duplikat eine Person warnen soll, aber eine genehmigte Integration ihren eigenen Abgleich hat, entwerfen Sie für beide Wege. Das Ziel: die unterste Schicht, die die Geschäftsregel korrekt abbildet.

Jede Schicht hat ihren Preis

Click to enlarge

Das ist die Abwägung, die ich Ihnen zeigen möchte. Feldtypen und kontrollierte Werte sind einfach und stark, aber nur für das, was ein Feld ausdrücken kann. Erforderlich und Eindeutig sind grob: Einmal eingeschaltet, muss jeder Schreibvorgang sie erfüllen. Validierungsregeln drücken reichere Bedingungen aus, können aber Bearbeitungen alter Datensätze blockieren und ein Deployment überraschen. Duplikatsregeln schützen über Datensätze hinweg, bringen aber Reibung für Benutzer und Integrationen. Automatisierung kann alles, aber Sie müssen Orchestrierung, Fehler, Tests und Leistung verantworten. Es gibt keine kostenlose Schicht. Wählen Sie die Schicht jeder Regel im Wissen, wie sie scheitert.

Bevor Sie sie einschalten

Eine Regel in eine bestehende Org einzuführen ist ein Rollout, kein Kontrollkästchen. Wie viele Datensätze verletzen sie heute, und warum? Sind sie tatsächlich falsch? Können wir den richtigen Wert kennen? Gilt die Regel historisch oder erst ab jetzt? Welche Integrationen, Tests und Automatisierungen werden auf sie treffen? Eine gute Reihenfolge: messen, bereinigen, was nachweislich falsch ist, die Regel eingrenzen, eine bewusste Umgehung für legitime Historie hinzufügen, jeden Schreibweg testen, dann durchsetzen. Messen und Bereinigen sind eigene Disziplinen, Profiling, Standardisierung, Überwachung, Stewardship, und Kapitel 5, Datenqualität und Governance, behandelt sie. Viel besser, als am Freitag ein Kästchen anzukreuzen und die Folgen am Samstagabend zu entdecken.

Über die Prüfung hinaus: Was KI ändert. Ein Agent kann Datensätze schneller erstellen als jede Person, und schlechte Datensätze genauso schnell. «Die Benutzer wissen, dass man das nicht tut» ist kein Schutz, wenn der Benutzer ein Agent ist. Legen Sie die wichtigen Regeln in die Datenschicht, wo jeder Schreibende auf sie trifft, damit der Agent sich nicht an die ungeschriebenen Regeln des Unternehmens erinnern muss.

Steve Trucking: Schützen Sie die Lieferung

Nehmen Sie eine Lieferung. Ihr Status kommt aus einem Vokabular: eine Auswahlliste, eingeschränkt. Die Auftragsreferenz des Handelspartners muss pro Partner eindeutig sein, also ist sie eine externe ID, als eindeutig gekennzeichnet, verwendet für den Upsert der Ladeliste. Die tatsächliche Lieferzeit ist erforderlich, sobald der Status Geliefert ist: eine Validierungsregel, beschränkt auf diese Änderung. Ein Installationsstopp kann nicht abgeschlossen werden, bis seine Checkliste vollständig ist und die erforderlichen Fotos aufgenommen sind (bei einem Geschirrspüler der Wasseranschluss, der Abfluss und die Waagerechte): eine Validierungsregel oder eine Automatisierung, wenn sie die ausserhalb der Plattform gespeicherten Fotos prüfen muss. Derselbe Auftrag, der zweimal aus einer erneut gesendeten Ladeliste kommt, wird von der externen ID abgefangen; zwei verschiedene Aufträge, die sich ähneln, sind eine Frage des Abgleichs.

Beachten Sie, dass ich nicht gesagt habe: «Packen Sie alles in einen Flow.» Jede Regel sitzt auf ihrer eigenen Sprosse. Fragen Sie bei jeder Regel: Was ist die unterste Schicht, die das für jeden relevanten Schreibweg korrekt durchsetzt?

Was Architekt:innen hier entscheiden

• Auf welche Sprosse jede Regel gehört: Feldtyp, kontrolliertes Vokabular, erforderlich oder eindeutig, Validierungsregel, Duplikatsregel oder Automatisierung.
• Welche Schreibwege geschützt werden müssen: Oberfläche, Portal, mobil, Integrationen, Massenladevorgänge, APIs, Automatisierung und Agenten.
• Ob eine neue Regel für historische Datensätze gilt oder auf neue und geänderte Daten beschränkt ist, mit einer Umgehung für die Vergangenheit.
• Ob vorhandene schlechte Daten anhand von Belegen korrigiert werden können, statt umgeschrieben zu werden, damit sie durchgehen.
• Wie viel Reibung, Komplexität und Wartung eine Regel wert ist.

Saubere Daten entstehen nicht dadurch, dass man Menschen bittet, gute Daten einzugeben. Sie entstehen durch eine Architektur, die das Richtige leicht macht, das Falsche schwer und die wichtigen Regeln schwer zu umgehen. Als Nächstes setzen wir das Kapitel an einem Ausschnitt von Steve Trucking zusammen.

Weiterlesen

• Salesforce-Hilfe, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) und Roll-Up Summary Field (opens in a new tab) (auf Englisch), geprüft am 2026-10-13.
• Salesforce-Hilfe, Picklist Limitations (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.
• Salesforce-Hilfe, Validation Rule Considerations (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.
• Salesforce-Hilfe, Things to Know About Duplicate Rules (opens in a new tab) (auf Englisch), geprüft am 2026-10-13: die Grenzen, die Wege, auf denen Regeln nicht laufen, API- und Import-Speichervorgänge ohne Hinweis blockiert, gleichzeitige Speichervorgänge nicht verglichen.
• Apex Developer Guide, Apex Transactions (opens in a new tab) und DML Statements vs. Database Class Methods (opens in a new tab) (auf Englisch), geprüft am 2026-10-13: Eine Transaktion wird als Einheit zurückgerollt; Database-Methoden können teilweisen Erfolg zulassen.
• Salesforce-Hilfe, Workflow Rules & Process Builder End of Support (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.