Salesforce-Datenarchitektur

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · 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) · Deutsch (Schweiz)

Mit KI erstelltes Bild

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

Lernleitfaden zu Kapitel 3 des Kurses Data Architect. Lesen Sie zuerst die zehn Module; diese Seite hilft Ihnen zu prüfen, was hängen geblieben ist.

Über diesen Lernleitfaden. Er beruht ausschließlich auf den Inhalten dieses Kurses und der veröffentlichten Liste der Prüfungsziele im Prüfungsleitfaden von Salesforce. Er basiert niemals auf echten Prüfungsfragen und behauptet nicht zu wissen, was in der Prüfung vorkommt. Wenn Sie die Prüfung abgelegt haben, schicken Sie mir bitte keine Fragen daraus: Die Zertifizierungsvereinbarung verbietet es, sie weiterzugeben, und Antworten auswendig zu lernen ist ohnehin der falsche Weg in die Architektur.

In diesem Kapitel trifft das Modell auf die Plattform, und es trägt einen großen Teil der Prüfung. Es speist die beiden größten Bereiche, Data Modeling and Database Design und Salesforce Data Management, jeweils ein Viertel der Prüfung. Die Zahlen der Plattform ändern sich: Die Liste nennt die, die die Module zitieren, mit dem Prüfdatum. Lernen Sie, wofür jede Grenze da ist, und prüfen Sie die aktuelle Zahl, bevor Sie sich darauf verlassen.

Für die Prüfung

Haken Sie die Punkte ab. Jeder verweist auf die Stelle, an der er behandelt wird.

DM-1: das Datenmodell auf der Plattform entwerfen

• Ich weiß, dass Salesforce eine mandantenfähige, metadatengesteuerte Plattform ist: Ein Objekt ist Metadaten, keine neue Tabelle, und jedes Objekt hat seine APIs, sobald es existiert. (Metadaten sind der Bauplan, Ihre API kam mit dem Objekt)
• Ich weiß, dass es Governor-Limits gibt, damit kein Mandant die gemeinsamen Ressourcen in Beschlag nehmen kann. (Sie können den Aufzug nicht in Beschlag nehmen)
• Ich kann die Standarddatenmodelle lesen: die Lead-Umwandlung in Account, Kontakt und Opportunity; ein Opportunity-Produkt verweist auf einen Preisbucheintrag, der auf Product2 verweist; und Kundenvorgang, Asset und Berechtigung (Entitlement) auf der Serviceseite. (Das Sales-Modell, Das Service-Modell)
• Ich weiß, was der Bildschirm „New Custom Object“ (Neues benutzerdefiniertes Objekt) entscheidet: einen Datensatznamen als Text oder als Automatische Nummer; die Object Classification (Objektklassifizierung: mit eingeschaltetem Sharing, Bulk API und Streaming API ist es ein Enterprise-Application-Objekt, mit ausgeschalteten ein Light-Application-Objekt); und Allow Search (Suche zulassen), standardmäßig aus. (Der Bildschirm „New Custom Object“)
• Ich kann einen API-Namen lesen: Standardobjekte und -felder haben weder Präfix noch Suffix; benutzerdefinierte Objekte und Felder enden auf __c; ein verwaltetes Paket fügt sein Namespace-Präfix hinzu (abc__); und ein Feld, das Sie dem Objekt eines Pakets hinzufügen, bekommt __c, aber nie das Präfix des Anbieters. (Präfixe und Suffixe)
• Ich kann den Test der sauberen Passung für ein Standardobjekt anwenden und weiß, wann Bedeutung oder Gewicht auf ein benutzerdefiniertes Objekt hindeuten. (Der Test der sauberen Passung)
• Ich weiß, wofür Asset und Personenaccounts da sind, dass ein Personenaccount etwa doppelt so viel Speicher braucht wie ein Firmenaccount und dass Personenaccounts, einmal aktiviert, nicht mehr deaktiviert werden können. (Asset ist ein gutes Beispiel, Personenaccounts, Wann ist die Person der Account?)
• Ich wähle einen Feldtyp nach dem Verhalten, das ich brauche (eine Flottennummer ist keine Zahl), und weiß, dass Datum/Uhrzeit in GMT gespeichert und in der Zeitzone der jeweiligen Lesenden angezeigt wird, also mit Bereichen verglichen wird, nicht auf Gleichheit. (Eine Zahl ist nicht immer eine Zahl, Datum, Datum/Uhrzeit und Uhrzeit)
• Ich weiß, dass es Text in zwei Arten gibt: bis zu 255 Zeichen auf dem Datensatz (indizierbar, als eindeutiges Feld oder externe ID nutzbar) und Long oder Rich Text darüber, ohne Index, ohne Filtern per WHERE und ohne Formeln. (Die Textfamilie)
• Ich weiß, wann ein Name mit automatischer Nummer passt, und dass er nicht die ID des Datensatzes ist. (Muss ein Mensch es erkennen?)
• Ich weiß, wie eine externe ID einer Integration einen Upsert erlaubt und das Laden untergeordneter Datensätze über die externe ID ihres übergeordneten. (Externe IDs)
• Ich weiß, wann ein Wert per Formel abgeleitet werden sollte und wann er eine historische Tatsache ist, die gespeichert werden muss. (Gespeichert oder abgeleitet?)
• Ich kenne den Unterschied zwischen einem logischen Verbindungsobjekt (die Modellierungsidee: ein Objekt, das zwei andere in einer Viele-zu-viele-Beziehung verbindet, mit eigenen Attributen) und einem Salesforce-Verbindungsobjekt (Junction Object: ein benutzerdefiniertes Objekt mit zwei Master-Detail-Beziehungen), und weiß, dass Salesforce das zweite meint. (Zwei Eltern breit)
• Ich kenne die hierarchische Beziehung: eine besondere Nachschlagebeziehung nur auf dem Objekt User, wie das Standardfeld Manager, die weder direkt noch indirekt auf denselben Benutzer zurückverweisen kann und nicht die Rollenhierarchie ist. (Hierarchisch)
• Ich kenne den Unterschied zwischen Nachschlagebeziehung und Master-Detail: Eigentümerschaft, Freigabe, erforderliches übergeordnetes Element, kaskadierendes Löschen, Rollup-Zusammenfassungsfelder. (Nachschlagebeziehung, Master-Detail)
• Ich weiß, dass man auf einem Objekt mit Daten keine Master-Detail-Beziehung anlegen kann (Nachschlagebeziehung anlegen, befüllen, umwandeln), dass man nur ohne Rollups auf dem Master zurück in eine Nachschlagebeziehung wechseln kann und dass Neuzuordnung zulassen nötig ist, um ein untergeordnetes Element zu verschieben. (Kann das untergeordnete Element das übergeordnete wechseln?)
• Ich kenne die Form der Plattform bei Master-Detail: bis zu drei benutzerdefinierte Detailebenen tief (eine Nachschlagebeziehung kann die Kette an jeder Stelle unterbrechen) und zwei Master-Detail-Eltern breit. In einem Salesforce-Verbindungsobjekt ist die zuerst erstellte Master-Detail-Beziehung die primäre (Eigentümer, Erscheinungsbild, Division), die zweite die sekundäre, und der Zugriff braucht beide Eltern: Die restriktivste gewinnt. (Drei Ebenen tief, Zwei Eltern breit)
• Ich kenne die drei Möglichkeiten einer Nachschlagebeziehung, wenn das übergeordnete Element gelöscht wird: das Feld leeren (der Standard), das Löschen verhindern oder kaskadieren, was ausgeschaltet ist, bis Salesforce es aktiviert, und die Freigabe umgeht. (Nachschlagebeziehung)
• Ich weiß, dass eine Selbstbeziehung eine Nachschlagebeziehung sein muss, und kenne die beiden eingebauten: Parent Account (übergeordneter Account) beim Account und Parent Case (übergeordneter Kundenvorgang) beim Kundenvorgang. (Selbstbeziehungen)
• Ich weiß, dass die Neuberechnung von Rollups dauern kann, dass ein Rollup keine Formel mit NOW(), TODAY() oder einem objektübergreifenden Verweis verwenden kann und dass man Master-Detail nicht nur wählen sollte, um ein Rollup zu bekommen: Die Alternative ist ein gespeichertes Feld, das ein Flow oder Trigger aktuell hält. (Rollups sind nützlich, aber nicht kostenlos)
• Ich kenne die Beziehungsgrenzen, die das Modul nennt: zwei Master-Detail-Beziehungen pro Objekt; 40 Beziehungsfelder standardmäßig (höchstens 50); 25 Rollups standardmäßig (höchstens 40). (Auch Beziehungen haben Grenzen)

DM-2: ein Modell, das die Freigabe respektiert und skaliert

• Ich weiß, dass ein Master-Detail-Kind weder eigenen Eigentümer noch eigene Freigabetabelle hat: Der Zugriff folgt dem Master. (Die Eigentümerschaft fährt mit)
• Ich kenne die Eltern-Kind-Schieflage: Die Empfehlung von Salesforce lautet, etwa 10.000 untergeordnete Datensätze pro übergeordnetem nicht zu überschreiten. (Die Frage der 10.000 untergeordneten Datensätze)
• Ich kenne die Eigentümerschafts-Schieflage (ein Benutzer besitzt mehr als 10.000 Datensätze eines Objekts) und die Empfehlungen: Eigentümerschaft verteilen oder diesen Benutzer aus der Rollenhierarchie heraushalten bzw. allein ganz oben, und aus öffentlichen Gruppen, die Freigaberegeln verwenden. (Eigentümerschaft kann zum Volumenproblem werden)
• Ich kenne die Freigabetabelle: Das Freigabeobjekt eines benutzerdefinierten Objekts ist Object__Share; ein Detailobjekt hat keines, sein Zugriff kommt vom Master; und ein Eigentümerwechsel entfernt manuelle Freigaben, behält aber die Apex-Freigabe mit eigener Ursache. (Die Freigabetabelle)
• Ich kann entscheiden, wem die von Integrationen und Agenten erstellten Datensätze gehören, je nachdem, ob die Eigentümerschaft die Freigabe steuert. (Wem gehören Datensätze, die Systeme erstellen?)

DM-4: Big Objects gegenüber Standard- und benutzerdefinierten Objekten

• Ich kenne die drei Zuhause für Daten: auf dem Core (sObjects, täglich bearbeitet), referenziert (ein anderes System ist die Quelle der Wahrheit: externe Objekte von Salesforce Connect, __x, oder eigene Aufrufe) und archiviert (auf dem Core in Big Objects, __b, oder außerhalb des Core in einem Data Warehouse). (Auf dem Core und außerhalb des Core)
• Ich weiß, dass externe Objekte bei jedem Zugriff einen Callout machen, also zählen Latenz und Verfügbarkeit des Quellsystems. (Referenziert)
• Ich kenne Big Objects: riesige Mengen, über ihren Index per exakter Übereinstimmung oder Bereich abgefragt, ohne Standardoberfläche und Standardberichte, nur mit Objekt- und Feldberechtigungen, ohne Automatisierung. (Archiviert)
• Ich weiß, dass die meisten Datensätze mit etwa 2 KB Datenspeicher zählen, egal wie viele Felder sie haben, und dass Dateien getrennt im Dateispeicher gezählt werden. (Zwei Spalten oder zweihundert, Dateien und Anhänge)

SDM-1: Lizenzen und die Objekte, die Menschen nutzen können

• Ich kenne die drei internen Lizenzen, Sales Cloud, Service Cloud und Platform, und weiß, was jede nutzen kann. (Drei interne Lizenzen)
• Ich weiß, dass Lizenzen Teil des Datenmodells sind: Salesforce-Platform-Benutzer haben keine Leads, Kampagnen, Opportunities oder Prognosen, und Customer-Community-Benutzer können keine Opportunities nutzen. (Jetzt mache ich alles kompliziert: Lizenzen)
• Ich kenne die Stufen der externen Lizenzen: Customer Community, Customer Community Plus (Berichte, Dashboards, Standardfreigabe), Partner Community (Vertriebsobjekte); und dass Partner Community nicht mit Personenaccounts verwendet werden kann. (Das Stadion)
• Ich kenne mitgliederbasierte gegenüber anmeldungsbasierter Lizenzierung und weiß, zu welcher Gruppe jede passt. (Wie sie bezahlen, ändert den Entwurf)
• Ich weiß, dass manche Plattformlizenzen Benutzer auf eine App mit höchstens zehn benutzerdefinierten Objekten beschränken, und kenne das Muster über Datensatztypen, um innerhalb dieser Grenze zu arbeiten. (Wenn die Lizenz das Modell formt)
• Ich weiß, dass die Lizenz Salesforce Integration für Benutzer zwischen Systemen gedacht ist, nur API. (Menschen sind nicht mehr die einzigen Benutzer)
• Ich weiß, dass SLA-Berichte Berechtigungen und Meilensteine brauchen, die Service-Lizenzen erfordern. (Jetzt mache ich alles kompliziert: Lizenzen)

SDM-2: Daten konsistent halten

• Ich kann eine Regel auf die richtige Sprosse der Konsistenzleiter setzen: Feldtyp und Vokabular, erforderlich und eindeutig, Validierungsregeln, Duplikatsregeln, Automatisierung. (Daten konsistent halten)
• Ich weiß, dass eine eingeschränkte Auswahlliste Werte ablehnt, die nicht auf der Liste stehen, auch über die API, und dass eine globale Werteliste eine Liste mit mehreren Feldern teilt (bis zu 1.000 Werte). (Erste Sprosse)
• Ich weiß, dass eine Anforderung im Seitenlayout nur diesen Bildschirm schützt, nicht die Daten, und dass Validierungsregeln bei jedem Speichern laufen. (Validierung in der Oberfläche ist keine Datenvalidierung, Dritte Sprosse)
• Ich kann eine Validierungsregel mit ISNEW() und ISCHANGED(), einer benutzerdefinierten Berechtigung oder einem Go-live-Datum eingrenzen und weiß, welche Speichervorgänge (auch solche, die ich nicht steuere, wie ein Eigentümerwechsel per Batch oder ein Rollup) jede dieser Möglichkeiten weiterhin prüft. (Das Problem der alten Datensätze)
• Ich kenne Abgleichsregeln und Duplikatsregeln, die Grenzen, die das Modul nennt (fünf aktive Duplikatsregeln pro Objekt, je drei Abgleichsregeln), und weiß, dass sie die Identität über Systeme hinweg nicht lösen. (Vierte Sprosse: Duplikatsregeln)
• Ich weiß, dass Duplikatsregeln Datensätze, die im selben Moment gespeichert werden, nicht miteinander vergleichen, dass Speichervorgänge über API und Import ohne Warnung blockiert werden und dass ein Speichervorgang mit allem, was er auslöst, als eine Transaktion zurückgesetzt wird. (Vierte Sprosse, Alles oder nichts)
• Ich weiß, dass Workflow-Regeln und Process Builder nicht mehr unterstützt werden; Automatisierung heißt Flow oder Apex. (Fünfte Sprosse: Automatisierung)

Über die Prüfung hinaus

Die Prüfung ist der Boden, nicht die Decke. Das sind die Gewohnheiten aus diesem Kapitel, die Architekt:innen brauchen, ob eine Frage je danach fragt oder nicht.

• Die Plattform hat eine Form. Entwerfen Sie für die Plattform, auf der Sie sind, nicht für eine generische Datenbank.
• Schauen Sie aufs Mutterschiff. Sehen Sie, wie Salesforce ein Konzept modelliert, bevor Sie eines erfinden.
• Jedes Objekt ist eine Verpflichtung: Speicher, Grenzen, Freigabemodell, Lizenzen und Abhängigkeiten.
• Fragen Sie, wo die Daten liegen, bevor Sie ein Objekt wählen: auf dem Core, referenziert oder archiviert.
• Lesen Sie einen API-Namen, und Sie wissen, wer ihn erstellt hat, und was Sie ändern können.
• Wenn Sie heute nicht archivieren, werden Sie es dann je tun?
• Bauen Sie einen Prototyp eines Big Objects, bevor Sie es vorschlagen.
• Verschiedene Geschäftsnamen bedeuten nicht automatisch verschiedene Objekte.
• Fragen Sie, welche Identitäten die Daten brauchen: Menschen, Kunden, Partner, Integrationen und Agenten.
• Jedes Feld bekommt eine Beschreibung, und eine Klassifizierung, wo sie zählt.
• Beschreiben Sie zuerst das Verhalten der Beziehung; die Konfiguration setzt es um. Verbiegen Sie das Modell nicht, um eine Funktion zu bekommen.
• Die Löschfrage: Was soll mit den untergeordneten Datensätzen passieren, wenn jemand den übergeordneten löscht?
• Wählen Sie, welches Glied die Kette unterbricht: Setzen Sie die Nachschlagebeziehung dort, wo das untergeordnete Element wirklich ein eigenes Leben hat.
• Eigentümerschaft vom primären, Zugriff von beiden: Die restriktivste gewinnt.
• Trennen Sie inaktiv von weg, und machen Sie die Aufbewahrung zu einer Geschäftsregel.
• Setzen Sie die Regel so tief, wie sie korrekt hingehört, und geben Sie legitimer Historie eine Umgehung, statt sie umzuschreiben.
• Das Schema ist nicht die Architektur. Können Sie jede Struktur zu einem geschäftlichen Grund zurückverfolgen?

Wichtige Begriffe

Begriff	In einer Zeile
Metadatengesteuert	Objekte und Felder sind Definitionen, die die Plattform zur Laufzeit liest, keine neuen physischen Tabellen
Mandantenfähigkeit	Viele Orgs teilen sich die Infrastruktur, jede isoliert, wie Wohnungen in einem Haus
Governor-Limits	Grenzen, die verhindern, dass ein Mandant die gemeinsamen Ressourcen in Beschlag nimmt
Externes Objekt	Daten, die über Salesforce Connect in Salesforce angezeigt und bei jedem Zugriff aus der Quelle geholt werden
Big Object	Speicher für sehr große, selten genutzte Daten, über ihren Index abgefragt
Personenaccount	Eine Einzelperson, als Account dargestellt, für B2C-Modelle
Saubere Passung	Ein Geschäftskonzept, das zum vorgesehenen Zweck eines Standardobjekts passt
Externe ID	Ein Feld mit der Kennung eines anderen Systems, verwendet für Upserts und Zuordnungen
Upsert	Den Datensatz aktualisieren, wenn er existiert, sonst erstellen
Nachschlagebeziehung	Eine Beziehung, in der das untergeordnete Element seinen eigenen Eigentümer und sein eigenes Leben behält
Master-Detail	Eine Beziehung, in der das untergeordnete Element zum übergeordneten gehört: Eigentümer und Freigabe geerbt, kaskadierendes Löschen, Rollups
Logisches Verbindungsobjekt	Die Modellierungsidee: ein Objekt, das zwei andere in einer Viele-zu-viele-Beziehung verbindet und eigene Attribute trägt, egal wie es gebaut ist
Salesforce-Verbindungsobjekt (Junction Object)	Was Salesforce mit „Junction Object“ meint: ein benutzerdefiniertes Objekt mit zwei Master-Detail-Beziehungen
Primärer und sekundärer Master	Die zuerst erstellte Master-Detail-Beziehung eines Salesforce-Verbindungsobjekts (Eigentümer, Erscheinungsbild, Division) und seine zweite (Berichtsumfang; wird primär, wenn die erste entfernt wird)
Hierarchische Beziehung	Eine besondere Nachschlagebeziehung nur auf dem Objekt User, wie Manager, die nicht auf denselben Benutzer zurückverweisen kann
Namespace-Präfix	Das Präfix des Anbieters auf den Objekten und Feldern eines verwalteten Pakets, wie abc__Inspection__c
Freigabetabelle	Das Freigabeobjekt (AccountShare, Truck__Share), das den Großteil der Freigaben eines Datensatzes enthält, eine Zeile pro Benutzer oder Gruppe, mit ihrer Ursache
Rollup-Zusammenfassung	Ein Feld auf dem Master, das seine Details zählt, summiert oder deren Minimum oder Maximum findet
Datenschieflage (Data Skew)	Zu viele Datensätze unter einem übergeordneten oder einem Eigentümer, was Sperren und lange Freigabe-Neuberechnungen verursacht
Mitgliederbasiert / anmeldungsbasiert	Pro externem Benutzer zahlen oder pro Anmeldung im Monat
Konsistenzleiter	Die Schichten, die Datenregeln durchsetzen, vom Feldtyp bis zur Automatisierung
Eingeschränkte Auswahlliste	Eine Auswahlliste, die jeden Wert ablehnt, der nicht auf ihrer Liste steht, egal woher er kommt
Datenklassifizierung	Feldmetadaten zu Eigentümer, Nutzung, Sensibilität und Compliance-Kategorie

Prüfen Sie sich

Kurze Szenarien im Stil des Kurses. Entscheiden Sie sich für Ihre Antwort, bevor Sie sie aufklappen.

1. Benutzer müssen Auftragsdetails sehen, die das ERP besitzt und den ganzen Tag aktualisiert. Sie bearbeiten sie nicht in Salesforce. Kopieren oder nicht?

Referenzieren: Externe Objekte über Salesforce Connect halten das ERP als Quelle der Wahrheit, ohne Kopie, die synchronisiert werden muss. Nehmen Sie in Kauf, dass jede Anzeige einen Callout macht, also zählen Latenz und Verfügbarkeit des ERP, und dass es besser zum Lesen passt als zu viel Bearbeitung oder Berichten. Lesen Sie noch einmal Referenziert.

2. Das Geschäft will Distributoren, Lieferanten und Handelspartner erfassen. Drei benutzerdefinierte Objekte?

Nein. Das sind alles Unternehmen, also passt Account sauber; die verschiedenen Namen sind Rollen, getragen von einem Typ, einem Datensatztyp oder einer Beziehung. Lesen Sie noch einmal Der Test der sauberen Passung.

3. Ein Entwurf verwendet die Opportunity, aber die meisten Menschen, die die Daten brauchen, haben Salesforce-Platform- oder Customer-Community-Lizenzen. Und jetzt?

Diese Lizenzen können die Opportunity nicht nutzen, also ist die Lizenz eine Architektureinschränkung: andere Lizenzen kaufen, das Erlebnis verlagern oder umgestalten, meist hin zu einem benutzerdefinierten Objekt. Lesen Sie noch einmal Jetzt mache ich alles kompliziert: Lizenzen.

4. Das ERP schickt jede Nacht Account-Aktualisierungen. Wie soll die Integration den richtigen Datensatz finden, ohne Salesforce-IDs nachzuschlagen?

Speichern Sie die Kundennummer des ERP in einem Feld mit externer ID und führen Sie darüber einen Upsert aus: Aktualisierung, wenn gefunden, sonst Erstellung. Untergeordnete Datensätze können ihren übergeordneten ebenfalls über dessen externe ID angeben. Lesen Sie noch einmal Externe IDs.

5. Eine Lieferposition kann ohne ihre Lieferung nicht existieren, zieht nie um und braucht keinen eigenen Eigentümer. Eine Lieferung existiert, bevor sie verplant wird, und kann auf eine andere Tour wechseln. Welche Beziehung jeweils?

Lieferposition zu Lieferung: Master-Detail (sie gehört lebenslang zum übergeordneten, erbt den Zugriff, kaskadierendes Löschen). Lieferung zu Tour: eine Nachschlagebeziehung (eigenes Leben, anfangs optional, verschiebbar, und das Löschen einer Tour sollte nie Lieferungen löschen). Lesen Sie noch einmal Beginnen Sie mit der geschäftlichen Beziehung.

6. Eine Integration erstellt 3.300 Lieferungen am Tag, alle im Besitz des Integrationsbenutzers, der eine Rolle in der Mitte der Hierarchie hat. Was ist das Risiko, und die Lösung?

Eigentümerschafts-Schieflage: Jenseits von 10.000 Datensätzen löst das Verschieben dieses Benutzers oder das Ändern seiner Gruppen lange Freigabe-Neuberechnungen aus. Verteilen Sie die Eigentümerschaft, wenn sie für den Zugriff zählt; sonst halten Sie den Integrationsbenutzer aus der Rollenhierarchie heraus oder allein in einer Rolle ganz oben, und aus Gruppen, die Freigaberegeln verwenden. Lesen Sie noch einmal Eigentümerschaft kann zum Volumenproblem werden.

7. Sie fügen eine Validierungsregel hinzu, und 20.000 alte Datensätze verletzen sie. Ein Benutzer ändert bei einem davon eine Telefonnummer, und das Speichern schlägt fehl. Was hätte die Regel tun sollen?

Sagen, wann sie gilt, nicht nur, was wahr sein muss: sie mit ISNEW() oder ISCHANGED() auf die betreffenden Felder beschränken und den Datensätzen, die älter sind als die Regel, eine bewusste Umgehung geben, statt ihre Historie umzuschreiben. Lesen Sie noch einmal Das Problem der alten Datensätze.

8. Das Geschäft will jedes Lieferfoto „in Salesforce“: vier bis fünf Millionen im Jahr, mit 30 % Wachstum. Was schlagen Sie vor?

Zugriff und Speicherort trennen. Halten Sie die Dateien in einem Speicher, der für dieses Volumen gebaut ist, außerhalb der Core-Org, und behalten Sie in Salesforce eine Referenz, eine Anzahl oder einen Indexdatensatz, damit die Benutzer sie finden und sehen können. Lesen Sie noch einmal Fotos.

9. Eine Crew-Zuweisung hat Master-Detail-Beziehungen zur Crew (zuerst erstellt) und zum Lkw. Eine Person in der Disposition kann die Crew sehen, aber nicht den Lkw. Kann sie die Crew-Zuweisung sehen?

Nein. Die Crew ist der primäre Master, sie gibt der Zuweisung also ihren Eigentümer und ihr Erscheinungsbild, aber der Zugriff braucht beide Eltern: Die Person in der Disposition braucht Zugriff auf die Crew und den Lkw, auf der Stufe, die die Sharing Setting (Freigabeeinstellung) jedes Master-Detail-Felds verlangt. Die restriktivste gewinnt. Lesen Sie noch einmal Zwei Eltern breit.

10. Ein Partner schickt eine Ladelistendatei erneut, und darin erscheint derselbe Kunde zweimal. Sie haben auf Account eine Duplikatsregel, die auf Blockieren steht. Sind Sie sicher?

Nicht durch die Duplikatsregel allein. Datensätze, die im selben Moment gespeichert werden, werden nicht miteinander verglichen, nur mit Datensätzen, die schon in Salesforce sind, also können beide Zeilen durchkommen. Schieben Sie die Eindeutigkeit nach unten ins Feld: eine eindeutige externe ID, die die Plattform bei jedem Speichern prüft, sodass nur einer gewinnt. Lesen Sie noch einmal Vierte Sprosse: Duplikatsregeln und Alles oder nichts.

Weiterlesen

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-09-25): die offizielle Liste der Ziele und ihrer Gewichtung. Prüfen Sie immer die aktuelle Fassung, bevor Sie die Prüfung buchen.
• Der Abschnitt Weiterlesen jedes Moduls nennt die Salesforce-Dokumentation hinter seinen Plattformfakten, mit dem Prüfdatum.