# architect Gut durchdacht (well-architected) - Full Documentation > Lesen Sie [hier](/docs/architect/de-de/well-architected/guide/contributors) unsere Aktualisierungspläne. ## Einführung Eine **anpassungsfähige** Salesforce-Lösung entwickelt sich mit dem Unternehmen weiter. Eine Lösung, die so konzipiert ist, dass sie **anpassungsfähig** ist, ist belastbar und zusammengesetzt. **Resiliente** Lösungen können Veränderungen gut verarbeiten.
**Zusammensetzbare** Lösungen passen sich schnell und stabiler an. Der Bedarf an Geschäftsänderungen kann aus vielen Quellen stammen: Kundenanforderungen, Markt- oder Branchenstörungen oder Chancen der digitalen Transformation. Manchmal sind Änderungen klein. Manchmal sind Veränderungen tiefgreifend. Auf den tiefgreifendsten Ebenen kann eine Änderung es erforderlich machen, dass Unternehmen ihre Kerngründe für den Betrieb überdenken und verschieben und das Was, Wie und Wo ihrer Kundenangebote neu bewerten. **Anpassbare** Architekturen helfen Unternehmen nicht nur dabei, zu überleben und sich von einer Unterbrechung zu erholen, sondern schaffen auch das Potenzial für Unternehmen, in Zeiten tiefgreifender Veränderungen innovativ zu sein und erfolgreich zu sein. Die Entwicklung von **anpassungsfähigen** Systemen erfordert kreatives und präzises architektonisches Denken. Beginnen Sie mit einem genauen Verständnis des kurz- und langfristigen Geschäftsverlaufs. Beim Auswerten einzelner Implementierungsdetails müssen Sie die Auswirkungen über mehrere Dimensionen und Detailebenen hinweg berücksichtigen. Sie müssen in Bezug auf Menschen, Prozesse und Technologie denken. Und Sie müssen gleichzeitig Auswirkungen auf Makro- und Mikroebene prognostizieren – für den aktuellen und alle künftigen Status. In den folgenden Abschnitten finden Sie eine ausführlichere Anleitung für jedes der Kernverhaltensweisen einer **anpassungsfähigen** Lösungsarchitektur. ## Anpassbare Übersicht

Elastisch
Resiliente Lösungen verarbeiten Veränderungen gut. Resiliente Architekturen können schnell und auf vorhersehbare Weise zu erwartetem Verhalten und erwarteten Vorgängen zurückkehren.
Anwendungslebenszyklus-Verwaltung	Vorfallsreaktion	Kontinuitätsplanung
Versionsverwaltung Umweltstrategie Teststrategie	Zeit zum Wiederherstellen Möglichkeit zum Triage Überwachung und Warnung	Geschäftskontinuität Technologiekontinuität
Composable
Zusammensetzbare Lösungen passen sich schnell und stabiler an. Komposible Architekturen werden in Einheiten erstellt, die graziös miteinander arbeiten und ein- und ausgeschaltet werden können.
Trennung von Bedenken	Interoperabilität	Paketierbarkeit
Funktionale Einheiten Bundesstaatsverwaltung	Messaging und Eventing API Management	Lose Kupplung Abhängigkeitsverwaltung

> Lesen Sie [hier](/docs/architect/de-de/well-architected/guide/contributors) unsere Aktualisierungspläne. ## Einführung Systeme demonstrieren automatisiertes Verhalten, indem sie es Unternehmen ermöglichen, wichtige Ziele schneller und skalierbarer zu erreichen. Durch die gesunde Automatisierung können sich Benutzer auf hochwertige Arbeit konzentrieren und die Zeit für sich wiederholende manuelle Aufgaben oder komplexe Dateneingaben reduzieren. Meistens bedeutet Automatisierung, Geschäftsprozesse von einem Formular in ein anderes zu übersetzen: von einem papierbasierten Formular in ein digitales Formular, von einem alten System in ein neues. Jede Geschäftsprozessübersetzung bietet die Möglichkeit zur Transformation. Bei der Transformation geht es nicht darum, neue Technologien zu verwenden, um störende und verwirrende Änderungen für Benutzer einzuführen. Bei der Transformation geht es darum, einfachere Möglichkeiten für die Arbeit zu schaffen, Unternehmen ein reibungsloses Wachstum zu ermöglichen und es Geschäftsbenutzern zu ermöglichen, sich stärker auf das zu konzentrieren, was für ihre Beteiligten wirklich wichtig ist. Aus architektonischer Sicht geht es dabei darum, Aufgaben zu identifizieren, die komplett entfallen oder automatisch bearbeitet werden können. Sie erfordert eine klare Verbindung zwischen der Art und Weise, wie Technologie verwendet wird, und ihren messbaren Auswirkungen auf das Unternehmen. Wichtiger Hinweis zur Automatisierung mit Salesforce: Sie kann mit einer Vielzahl von Tools durchgeführt werden, wobei programmgesteuerte und deklarative Fertigkeiten verwendet werden. Beim Entwerfen von gut strukturierten Automatisierungen geht es nicht darum, sich für die Erstellung mit nur einem Automatisierungstool zu entscheiden. Es geht darum, konsistente und vorhersehbare Ansätze zu verwenden und Teams in die Lage zu versetzen, die von Ihnen entworfenen Automatisierungen zu entwickeln, zu testen, bereitzustellen und zu warten. Ihre Automatisierungen sollten eine möglichst [wartungsfreundliche und lesbare](/docs/architect/de-de/well-architected/guide/intentional) Form annehmen. In diesem Abschnitt wird erläutert, wie Automatisierungen entworfen und refaktoriert werden, damit Unternehmen wichtige Ziele schneller und skalierbarer erreichen können. Sie können die Architektur Ihrer Automatisierungen in Salesforce verbessern, indem Sie sich auf Effizienz und Datenintegrität konzentrieren. ## Effizienz Beim Erstellen von Effizienz in Ihren Automatisierungen geht es nicht darum, wie gewohnt mit Salesforce-Technologien Geschäfte neu zu erstellen. Es geht darum, die wichtigsten Kennzahlen und Geschäftsergebnisse, für die Teams verantwortlich sind, genau zu verstehen und die [Funktionseinheiten](/docs/architect/de-de/well-architected/guide/composable#funktionale-einheiten) innerhalb und über die von Ihnen automatisierte Arbeit hinweg anzuzeigen. Es geht darum, zu ermitteln, wie Sie mit Ihren Automatisierungen Muster erstellen können, die es dem Unternehmen ermöglichen, effektiver und schneller zu arbeiten und dabei den richtigen Maßstab zu schaffen. Effiziente Automatisierungslogik macht Ihre Systeme zu Folgendem: - Skalierbarer und nützlicher für das Unternehmen - Hilfreicher für Benutzer - Besser [anpassbar](/docs/architect/de-de/well-architected/guide/adaptable-overview) und in der Lage, die sich ändernden Geschäftsanforderungen zu erfüllen Sie können die Effizienz Ihrer Automatisierungen durch Prozessdesign und Betriebslogik verbessern. ### Prozessdesign Das Prozessdesign beinhaltet die Definition der Art und Weise, wie Arbeit erledigt wird. Die Entwicklung wirklich effizienter und effektiver Prozesse bedeutet, dass Ihre Designs nicht nur aktuelle Arbeitsweisen widerspiegeln. Es ist wichtig, ineffektive oder unklare Schritte zu identifizieren und zu entfernen. Optimierte Prozesse sollten ohne unnötige Schritte einen messbaren Geschäftswert schaffen (siehe [KPIs](/docs/architect/de-de/well-architected/guide/automated#kpis)). Unklare oder unnötige Schritte werden wahrscheinlich zu technischen Schulden führen und zu nicht wartbaren Automatisierungen führen. Oftmals liegt die Verantwortung für das Erkennen und Dokumentieren von Geschäftsprozessen in der Verantwortung eines Geschäftsanalysten oder sogar eines Systemadministrators. Architekten sind dafür verantwortlich, mit diesen Mitgliedern Ihres Teams zusammenzuarbeiten, um sicherzustellen, dass Ihre Prozessentwürfe technisch fundiert und gut strukturiert sind. Wenn Sie Ihr Knowledge über Salesforce Platform so früh wie möglich anwenden, kann Ihr Team Prozesse identifizieren, die durch Automatisierung oder Prozesse optimiert werden sollen, die geändert werden müssen, um kostspielige Anpassungen zu vermeiden. Berücksichtigen Sie zum Erstellen optimierter Prozesse für Salesforce Folgendes: - **Definieren Sie Prozesse sorgfältig**. Prozesse mit unklaren Zwecken oder mehrdeutigen Definitionen werden zum Zeitpunkt des Designs eher falsch interpretiert. Dies führt zu fehlerhaften Designs, die auf Annahmen basieren, was zu falschen oder ineffizienten Automatisierungen führt. Stellen Sie sicher, dass die Geschäftsprozesse, die Sie automatisieren möchten, die folgenden Standards erfüllen: - Auf eine einzelne, bestimmte Funktion beschränkt (siehe [Funktionseinheiten](/docs/architect/de-de/well-architected/guide/composable#funktionale-einheiten)) - Hat klar definierte, messbare Ausgaben (siehe [Geschäftswert](/docs/architect/de-de/well-architected/guide/automated#geschäftswert)) - Hat klar definierte Ein- und Ausgaben - Machen Sie **Prozessschritte deutlich**.\* Auch wenn es manchmal verlockend sein kann, zusätzliche Schritte hinzuzufügen, die "in Zukunft hilfreich sein könnten", ist dies niemals ein guter Ansatz. Jeder Schritt in einer Automatisierung ist für das Ergebnis des Gesamtprozesses relevant. Stellen Sie sicher, dass jeder Prozessschritt die folgenden Merkmale aufweist: - Führt eine bestimmte, detaillierte Aufgabe aus (siehe [zusammensetzbar](/docs/architect/de-de/well-architected/guide/composable)) - Erforderlich, damit der Prozess seine definierte Ausgabe generiert (alle nicht wesentlichen Schritte entfernen) - Kann mit einer minimalen Anzahl an Ressourcen abgeschlossen werden - Verwendet vorhandene Systemdaten, statt nach Möglichkeit nach Benutzereingaben zu fragen (siehe [Interagieren](/docs/architect/de-de/well-architected/guide/engaging)). - Bietet Eingabeoptionen, die Benutzer verstehen können, ohne wissen zu müssen, wie die zugrunde liegenden Systeme funktionieren (Siehe [hilfreich](/docs/architect/de-de/well-architected/guide/engaging#hilfreich)) Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/automated#effizienzmuster-und-antimuster) zeigt, wie eine ordnungsgemäße (und schlechte) Optimierung in einer Salesforce-Organisation aussieht. Sie können sie verwenden, um Ihre Automatisierungsentwürfe vor dem Erstellen zu validieren oder Automatisierungen zu identifizieren, die weiter optimiert werden müssen. Weitere Informationen zu den von Salesforce verfügbaren Prozessautomatisierungstools finden Sie unter [Für Automatisiert relevante Tools](/docs/architect/de-de/well-architected/guide/automated#für-automatisiert-relevante-tools). ### Betriebslogik Die Betriebslogik befasst sich damit, wie effektiv ein Prozess von seinem Design in eine tatsächliche Implementierung übersetzt wird. Automatisierungen mit starker Betriebslogik funktionieren weiterhin gut, unabhängig von Spitzen bei Transaktionsvolumen oder der Anzahl der gleichzeitig ausgeführten Instanzen. Logisch fundierte Automatisierungen helfen Unternehmen, einfacher skaliert zu werden, um bei höheren Anforderungen zu arbeiten. Die Integration einer starken Betriebslogik in Ihre Automatisierungen hängt direkt mit der allgemeinen [Zuverlässigkeit](/docs/architect/de-de/well-architected/guide/reliable) Ihres Systems zusammen. Automatisierungen, die nicht effektiv funktionieren, bieten schlechte Benutzer- und Kundenerfahrungen, was zu potenziellen Umsatzverlusten und zum Verlust des Customer Trust führt. Sie haben auch höhere Wartungskosten und können zu Engpässen werden, die zugehörige Prozesse verzögern und zu allgemeinen Problemen mit der Systemleistung beitragen. Berücksichtigen Sie zum Erstellen einer effektiven Betriebslogik in Automatisierungen Folgendes: - **Stellen Sie sicher, dass jeder, der Automatisierungen erstellt, den richtigen Weg dafür kennt**. Schlechte Designentscheidungen können mit jeder Art von Automatisierungstool getroffen werden. Code ist nicht weniger anfällig für Fehler oder schlechte Implementierungsoptionen als klickbasierte Tools. Bei der Verwendung hartcodierter Referenz-IDs handelt es sich beispielsweise um ein Anti-Pattern, das in Flow und Code angezeigt wird. Klickbasierte Tools sollten nicht als Lizenz angesehen werden, damit jeder und jede eine Automatisierung in die Produktion freigeben kann. Jedes Teammitglied, das eine Automatisierung erstellt, muss wissen, wie sie richtig erstellt wird. Weitere Informationen zur Definition und Anwendung effektiver Standards in Ihren Systemen finden Sie unter [Lesbarkeits-](/docs/architect/de-de/well-architected/guide/intentional#lesbarkeit) und [Designstandards](/docs/architect/de-de/well-architected/guide/intentional#design-standards). - **Dokumentieren Sie alle Ausführungspfade eindeutig**. Die zunehmende Nutzung von Automatisierungen erhöht nicht nur potenzielle Datenvolumen, sondern auch ungeplante Aufrufkontexte. Sie müssen verstehen, wie unterschiedliche Automatisierungen aufgerufen werden können, und sicherstellen, dass in allen Automatisierungen mit mehreren Eingangspunkten ordnungsgemäße Transaktionssteuerungen (siehe Datenverarbeitung) angezeigt werden. Bildschirm-Flows werden beispielsweise nicht mit Massendaten geladen, wohl aber mit Apex-Auslösern und ausgelösten (und automatisch gestarteten) Flows. Die klare Dokumentation geplanter und potenzieller Ausführungspfade für Automatisierungen ist ein wichtiger Aspekt, um zu verstehen, welche logischen Bedingungen Sie während der Implementierung berücksichtigen müssen. - **Alle Datenvorgänge (einschließlich SOQL) „in Massenvorgängen“ verarbeiten**. Jeder Datenvorgang (Einfügen, Aktualisieren usw.) sollte für Sammlungen ausgeführt werden. Immer. Ohne Ausnahmen. Dies wird unter "Massenvorgang" verstanden. Obwohl die Plattform Singleton-Datenvorgänge unterstützen kann, sollten Sie niemals zulassen, dass Singleton-Muster implementiert werden. - **Verwenden Sie SOSL für Suchvorgänge**. Es besteht ein Irrglaube, dass Datenvorgänge nicht für über SOSL zurückgegebene Datensätze ausgeführt werden können. Es stimmt, dass DML nicht direkt anhand von SOSL-Ergebnissen aufgerufen werden kann. Code kann jedoch SOSL-Ergebnisse analysieren und eine Sammlung erstellen, auf die in DML- oder Datenbankklassenmethoden verwiesen werden kann. Die wichtigsten Unterschiede zwischen SOSL und SOQL sind die Rückgabetypen für jeden und wie sie auf generalisierte oder Platzhaltersuchen reagieren. SOSL kann für verschiedene sObject-Typen verwendet werden (deshalb unterscheidet sich der Rückgabetyp) und Platzhalter- und generalisierte Zeichenfolgensuchen können mit besserer Leistung als SOQL verarbeitet werden. - **Behandeln Sie SOQL wie einen Datenvorgang**. Verwenden Sie SOQL nicht zum Suchen von Datensätzen, sondern zum Eingrenzen Ihrer Datenvorgänge. SOQL- und Datenvorgänge können sich sehr ähnlich auf die Leistung der [zugrunde liegenden relationalen Datenbank](/docs/architect/de-de/fundamentals/guide/platform-multitenant-architecture#die-plattformdatenebene) auswirken. SOQL kann sogar [einen expliziten DML-Indikator](https://developer.salesforce.com/docs/atlas.en-us.238.0.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_for_update.htm?q=for%20update) übergeben, der Datenbankzeilen im Vorgriff auf Datenvorgänge sperrt. Stellen Sie zum Erstellen skalierbarer Automatisierungen sicher, dass Sie SOQL mit einer ähnlichen Sorgfaltspflicht behandeln: Verwenden Sie es nicht ohne sehr spezifische, wohlgeformte Auswahlkriterien, lassen Sie keine Fremdfeldverweise zu und fordern Sie einen sorgfältigen Abgleich von Datentypen zwischen Feldern und Filtereingaben in der `WHERE`-Anweisungslogik. Ihr Code sollte auch über entsprechende Steuerelemente verfügen, um sicherzustellen, dass eine Abfrage niemals in nicht in Massenvorgängen ausgeführten Kontexten oder anhand von Null- oder Leerfilterkriterien ausgeführt wird. - **Konzentrieren Sie sich bei synchronen Vorgängen streng auf die Arbeit, die einem Benutzer in Echtzeit hilft.** Identifizieren Sie während Ihrer [Prozessoptimierung](/docs/architect/de-de/well-architected/guide/automated#prozessdesign) Logik, die für die von Benutzern in Echtzeit oder nahezu in Echtzeit durchzuführenden Vorgänge relevant ist und die in eine asynchrone (asynchrone) Transaktion zurückgestellt werden kann. Weitere Überlegungen zum Entwerfen von Synchronisierungs-/asynchronen Vorgängen finden Sie unter [Datenverarbeitung](/docs/architect/de-de/well-architected/guide/automated#datenverarbeitung). Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/automated#effizienzmuster-und-antimuster) zeigt, wie eine ordnungsgemäße (und schlechte) Betriebslogik in der Salesforce-Automatisierung aussieht. Sie können sie verwenden, um Ihre Automatisierungsentwürfe vor dem Erstellen zu validieren oder Automatisierungen zu identifizieren, die weiter optimiert werden müssen. Weitere Informationen zu den von Salesforce verfügbaren Tools, die Ihnen bei der Skalierungsplanung helfen können, finden Sie unter [Für Automatisiert relevante Tools](/docs/architect/de-de/well-architected/guide/automated#für-automatisiert-relevante-tools). ### KPIs Automatisierungs-KPIs messen die Auswirkungen einer Automatisierung im Zeitverlauf. Ohne sie können Sie nicht sagen, ob eine Automatisierung wirklich einen Mehrwert für Ihr Unternehmen bringt oder eine ungewollte Komplexität für Ihre Benutzer schafft. Jede von Ihnen erstellte Automatisierung sollte an eine klare, messbare Reihe von KPIs gebunden sein. Gute KPIs werden durch einen messbaren Wert zusammen mit einem zugeordneten Zeitrahmen definiert. Beispiele: - \[X Zahl] Gesparte Arbeitsstunden pro Monat - Verarbeitungsfehler durch manuelle Dateneingabe um \[Y%] pro Woche reduziert Sobald Sie über klare, messbare KPIs verfügen, müssen Sie auch verstehen, ob und wie eine Automatisierung in Salesforce Daten generiert, die für die Berichterstattung über diese KPIs relevant sind. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/automated#effizienzmuster-und-antimuster) zeigt, wie richtige (und schlechte) KPIs in Bezug auf Salesforce-Automatisierungen aussehen. Sie können diese verwenden, um Ihre vorhandenen KPIs zu validieren, oder ermitteln, wo Sie KPIs vor dem Erstellen besser identifizieren müssen. Weitere Informationen zu den von Salesforce verfügbaren Tools für Hilfe bei KPIs finden Sie unter [Relevante Tools für Automatisiert](/docs/architect/de-de/well-architected/guide/automated#für-automatisiert-relevante-tools). ### Effizienzmuster und Antimuster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie mehr Muster für Effizienz im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/easy-efficiency) Anti-Muster.

	Muster	Anti-Muster
Prozessdesign	In Ihrer Organisation: - Jeder Flow dient einem einzelnen, spezifischen Zweck - Jeder Schritt führt eine bestimmte, detaillierte Aufgabe aus - Flows sind in einer hierarchischen Struktur organisiert, die aus einem Haupt-Flow und unterstützenden Subflows besteht - Alle Benutzereingaben haben einen klaren Zweck innerhalb des Flows - Benutzer werden nur aufgefordert, Daten anzugeben, wenn vorhandene Systemdaten nicht verwendet werden können	In Ihrer Organisation: - Flows dienen mehreren Zwecken und erfordern zusätzliche Eingaben, um Kontext bereitzustellen - Flows erfordern Eingaben, deren Daten nicht verwendet werden - Gruppen von verwandten Schritten enthalten Funktionen, die sich mit Gruppen von Schritten in anderen Flows überschneiden - Flows fragen nach Benutzereingaben, wenn gespeicherte Daten stattdessen verwendet werden können
Prozessdesign	In Apex: - Jede Klasse dient einem einzelnen, spezifischen Zweck - Jede Methode führt eine bestimmte, detaillierte Aufgabe aus - Alle Eingabevariablen haben einen klaren Zweck innerhalb der Klasse - Codeausführung erfordert eine minimale Anzahl an Ressourcen	In Apex: - Klassen dienen mehreren Zwecken - Methoden führen mehrere Aufgaben aus oder Methoden führen Aufgaben aus, die nicht mit dem angegebenen Zweck der Klasse übereinstimmen, zu der sie gehören - Eingabevariablen werden in Methoden nicht verwendet - Methoden rufen unnötig Daten aus der Datenbank oder aus externen Systemen ab
Betriebslogik	Im Flow: - Keine Variablen beziehen sich auf hartcodierte Werte (für Datensatztypen, Benutzer usw.) - Alle automatisch gestarteten Flows und Prozesse verwenden Entscheidungs- und/oder Pausenelemente, um Eingabekriterien auszuwerten und Endlosschleifen oder Ausführungen bei großen Datenmengen zu verhindern - Flows (einschließlich Prozessen) übergeben Logik in Kontexten mit großem Datenvolumen an Apex - Subflows werden für die Abschnitte eines Prozesses verwendet, die im gesamten Unternehmen wiederverwendet werden müssen	Im Flow: - Variablen haben hartcodierte Werte - Flows (einschließlich Prozessen) müssen vor dem Laden von Massendaten manuell deaktiviert werden - Flows (einschließlich Prozessen) lösen Hinweise zu "unbehandelten Ausnahmen" aus - Selbst einfache Flows verursachen regelmäßig Fehler in Bezug auf Obergrenzen - Teile eines Flows werden über Flows hinweg wiederholt, statt Subflows zu verwenden
	In Apex: - Keine Variablen beziehen sich auf hartcodierte Werte (für Datensatztypen, Benutzer usw.) - Alle Platzhalterkriterien werden in SOSL angezeigt - SOQL ist in `Try-Catch` eingeschlossen - In einer Schleife wird keine SOQL angezeigt - SOQL-Anweisungen sind selektiv, einschließlich: -- keine Verwendung von `LIKE-`Vergleichen oder Teiltextvergleichen -- Vergleichsoperatoren verwenden positive Logik (d. h. `EINSCHLIESST`, `IN`) als primäre oder einzige Logik -- Verwendung von `= NULL`, `!= NULL` ist selten und/oder folgt immer einem positiven Vergleichsoperator -- es werden keine `LIMIT 1`-Anweisungen angezeigt -- keine Verwendung des Stichworts `ALL ROWS`	In Apex: - Variablen haben hartcodierte Werte - SOSL wird selten oder nicht konsequent für Platzhalterauswahlkriterien verwendet - SOQL ist nicht in `Try-Catch` eingeschlossen - SOQL wird in Schleifen angezeigt - SOQL-Anweisungen sind nicht selektiv, einschließlich: -- `Gefällt mir` und Platzhalterfilterkriterien werden angezeigt -- Vergleiche mit den Kriterien `NOT`, `NOT IN` werden als primärer oder einziger Vergleichsoperator verwendet -- `= NULL`, `!= NULL-`Kriterien werden als primärer oder einziger Vergleichsoperator verwendet -- `LIMIT 1`-Anweisungen werden angezeigt -- Stichwort `ALL ROWS` wird verwendet
	In Ihren Designstandards und in Ihrer Dokumentation: - Geplante und potenzielle Ausführungspfade für Automatisierungen sind klar umrissen - Die Anwendungsfälle für synchrone und asynchrone Vorgänge innerhalb von Automatisierungen sind als Teil von Designstandards klar umrissen	In Ihren Designstandards und in Ihrer Dokumentation: - Automatisierungsaufruf wird nicht dokumentiert - Anwendungsfälle für synchrone und asynchrone Vorgänge werden nicht behandelt
KPIs	In Ihrer Dokumentation: - Ausgaben für jede Automatisierung sind messbar und zeitgebunden - Verantwortliche Beteiligte werden für jeden KPI aufgelistet	In Ihrer Dokumentation: - KPIs sind für Automatisierungen nicht vorhanden oder weisen unklare Zeitrahmen für Messungen auf - KPIs sind ohne verantwortliche Beteiligte vorhanden
KPIs	In Berichten und Dashboards: - Alle Kennzahlen zu KPIs sind in mindestens einem Bericht oder Dashboard enthalten	In Berichten und Dashboards: - KPI-Berichte sind nicht vorhanden oder es fehlen Berichte mit Kennzahlen zu einigen KPIs

## Datenintegrität Bei der Datenintegrität geht es darum, wie gut ein System genaue und vollständige Daten verwaltet. Die Salesforce Platform verfügt über eine zuverlässige, [integrierte Verarbeitungslogik](/docs/architect/de-de/fundamentals/guide/architecture-basics#datenbankmanipulation), die die Integrität der in der relationalen Datenbank einer einzelnen Organisation gespeicherten Daten schützt. Eine der Grundlagen für die Erstellung gesunder Automatisierungen besteht darin, das integrierte Verhalten der Datenintegrität von Salesforce zu verstehen und sicherzustellen, dass alle Ihre Automatisierungsdesigns mit diesem Verhalten übereinstimmen (und es anerkennen). Die größten Anti-Patterns im Automatisierungsdesign ergeben sich daraus, dass die leistungsstarken [Datenintegritätsservices von Salesforce](/docs/architect/de-de/fundamentals/guide/architecture-basics#datenbankmanipulation) nicht erkannt und [Standardfunktionen](/docs/architect/de-de/well-architected/guide/intentional#standard--und-benutzerdefinierte-funktionen) nicht verwendet werden, die diese Services nutzen. Damit Sie Automatisierungen entwerfen können, die die Datenintegrität schützen und aufrechterhalten, müssen Sie mit der grundlegenden Reihenfolge des Betriebsverhaltens von Salesforce vertraut sein. Die ordnungsgemäße Erweiterung der Datenintegrität in Ihre benutzerdefinierten Automatisierungen bedeutet, dass Ihr System: - ohne manuelle Eingriffe bei Massen- und großen Datenmengen arbeiten, - Erzwingen von Benutzersicherheitsrichtlinien bei Bedarf und Wechseln zum Systemkontext bei Bedarf, - treten während der Laufzeit Fehler auf und folgen vorhersehbaren Wiederherstellungs- oder Fehlerpfaden. Durch die richtige Datenverarbeitung und Fehlerbehandlung können Sie die Datenintegrität in Ihre Salesforce-Automatisierungen verbessern. ### Datenverarbeitung Der erste Schritt zum Entwerfen einer ordnungsgemäßen Datenverarbeitung in Salesforce besteht darin, zu verstehen, wie die Multi-Mandanten-Plattform [Transaktionen](/docs/architect/de-de/fundamentals/guide/architecture-basics#transaktionen) verarbeitet. Dazu gehört auch das Verständnis der integrierten [Reihenfolge der Ausführungsverhalten](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm), die die Salesforce Platform verwendet, um die Datenintegrität bei Datenvorgängen auf Datensatzebene sicherzustellen. Weitere Informationen zu den Auswirkungen dieses Verhaltens finden Sie unter [Datenbankmanipulation](/docs/architect/de-de/fundamentals/guide/architecture-basics#datenbankmanipulation) in Salesforce Architecture Basics. Die schlechte Datenverarbeitung in Ihren Automatisierungen kann zu den am schwierigsten zu identifizierenden und vollständig zu behebenden Anti-Patterns gehören. Die rekursive und sich überschneidende Ausführungsreihenfolge der Plattform kann es erschweren, festzustellen, woher die Probleme stammen. Der spezifische Abschnitt des Codes oder Flows, der einen fatalen Fehler auslöst oder die Obergrenzen überschreitet, ist möglicherweise nicht die Ursache für ein zugrunde liegendes Datenverarbeitungsproblem. _Transaktionsbewusstsein_ ist der Schlüssel zur Erstellung von Automatisierungen, die mit Salesforce zuverlässig und skalierbar funktionieren. Das bedeutet, dass jeder Schritt in einer Automatisierung mit dem Knowledge, wo er sich in Bezug auf die plattformgesteuerte [Ausführungsreihenfolge](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm) befindet, ausgelegt ist, seine Funktion ordnungsgemäß ausführen kann und Informationen ordnungsgemäß an den nächsten Schritt weitergibt. Unabhängig vom verwendeten Automatisierungstool folgt die richtige Transaktionswahrnehmung ähnlichen Mustern und erfordert allgemeine Überlegungen: - Angenommen, jede Automatisierung wird aufgefordert, große Datenmengen ohne vorherige Ankündigung jederzeit auszuführen. Automatisierungen sollten Pfade aufweisen, die die Batch- oder Massenausführung ermöglichen (siehe [Skalierbarkeit](/docs/architect/de-de/well-architected/guide/reliable#skalierbarkeit)). - Mischen Sie System- und Benutzerkontextdatenvorgänge nicht in derselben Transaktion. - Reservieren Sie Synchronisierungsdatenvorgänge für [_vorherige_ Kontexte](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm) und verwenden Sie asynchrone Vorgänge für alle Aktionen _nachher_. - Verwenden Sie [Messaging und Benachrichtigungen](/docs/architect/de-de/well-architected/guide/engaging#benachrichtigungen-und-nachrichten), um zu vermeiden, dass Benutzer Erfahrungen in der Anwendung erstellen, bei denen sie auf Daten warten müssen, die auf den Ergebnissen eines asynchronen Vorgangs basieren. Neben dem Transaktionsbewusstsein gibt es noch eine zweite Dimension der Datenverarbeitung: das Wissen, wann Logik in verschiedenen [Ausführungskontexten](/docs/architect/de-de/fundamentals/guide/architecture-basics#ausführungskontext) ausgeführt werden muss. Zu den häufigen Gründen für die Aufteilung von Automatisierungen in verschiedene Ausführungskontexte zählen: - **Großes Volumen und/oder komplexe Datenvorgänge** - [Durch Massenvorgänge](/docs/architect/de-de/well-architected/guide/automated#datenverarbeitung) kann nicht garantiert werden, dass große Datenmengen ordnungsgemäß verarbeitet werden. Wenn das Volumen der in einer Automatisierung enthaltenen Datenvorgänge pro Transaktionsobergrenze überschreitet, müssen Sie Datenvorgänge mit Funktionen ausführen, die für große Datenmengen spezifisch sind (z. B. über Batch-Apex oder die [Bulk 2.0-API](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/asynch_api_intro.htm)). Diese weisen unterschiedliche Transaktionsobergrenzen auf, die für große Datenmengen geeignet sind. - Datenvorgänge, die komplexe Beziehungshierarchien durchlaufen oder komplexe Neuberechnungen (ohne Formelfelder) datensatzübergreifend durchführen müssen, können bei Massenvorgängen die Obergrenzen pro Transaktion leicht überschreiten. Überlegen Sie, wie störend eine Aktualisierung eines Datensatzes in Bezug auf die Vorgänge mit den zugehörigen Daten oder die SOQL ist, die zum Ausführen nachfolgender Aktionen im System erforderlich sind. - Die an der gesamten Kette einer Automatisierung beteiligten sObject-Typen können es erfordern, dass Sie Datenvorgänge in separate Transaktionen aufteilen, um [gemischte DML](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_dml_non_mix_sobjects.htm)-Fehler zu vermeiden. - **Logik, die im Benutzer- oder Systemkontext ausgeführt werden muss** - Die Salesforce Platform erzwingt die [Freigabe und Sichtbarkeit](/docs/architect/de-de/well-architected/guide/secure#freigabe-und-sichtbarkeit) im Benutzerkontext. Wenn Sie Vorgänge ausführen müssen, die über die Berechtigungsebenen der Benutzer Ihrer Automatisierung hinausgehen, müssen Sie sicherstellen, dass diese Vorgänge im Systemkontext ausgeführt werden. - Unterschiedliche Tools werden in unterschiedlichen Kontexten ausgeführt: - Apex wird standardmäßig im Systemkontext ausgeführt. Mithilfe von [Freigabestichwörtern](https://developer.salesforce.com/docs/atlas.en-us.238.0.apexcode.meta/apexcode/apex_classes_keywords_sharing.htm?q=run%20as%20user) in einer Apex Klassendefinition können Sie steuern, ob und wie Apex Verhaltensweisen Freigaberegeln auf Benutzerebene erzwingen. - Flow weist kein einzelnes Standardverhalten auf. Ein Flow wird im Benutzer- oder Systemkontext ausgeführt, [je nachdem, wie der Flow gestartet](https://help.salesforce.com/s/articleView?id=sf.flow_distribute_context.htm&type=5) wird. Sie haben die Möglichkeit, die Freigabe im Systemkontext zu erzwingen. - Prozesse (d. h. mit dem Prozessgenerator erstellte Automatisierungen) werden ohne Freigabeüberlegungen im Systemkontext ausgeführt. (Hinweis: Es wird empfohlen, Low-Code-Automatisierungen mit Flow zu erstellen. - **Logik, die asynchron ausgeführt werden muss** - Externe Systemvorgänge: Synchrone Callouts oder Aktionen, die auf externe Daten zugreifen, sind in keinem Plattform-Rollback-Verhalten enthalten. Um diese Verhaltensweisen nutzen zu können, müssen Sie Aktionen, die externe Systeme betreffen, in separate Transaktionen platzieren (mit asynchronen [Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_async_overview.htm)-Methoden, [asynchronen Pfaden](https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_builder_asynchronous_path.htm&type=5&release=234) oder [aufrufbaren Aktionen](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_forcecom_flow_invocable_action_callout.htm)). - Eventing and messaging (Ereignis und Messaging): Platzieren Sie alle Aktionen im Zusammenhang mit Messaging oder Ereignissen mithilfe von asynchronen Apex-Methoden in [_nachgeordneten_ Kontexten](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm), um den Fluss von Ereignissen oder Nachrichten im Zusammenhang mit Datenvorgängen zu steuern (und das Plattform-Rollback-Verhalten zu nutzen). Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/automated#datenintegritätsmuster-und-antimuster) zeigt, wie eine ordnungsgemäße (und schlechte) Datenverarbeitung in Salesforce-Automatisierungen aussieht. Sie können sie verwenden, um Ihre Automatisierungsentwürfe vor dem Erstellen zu validieren oder Automatisierungen zu identifizieren, die neu faktorisiert werden müssen, um die Datenverarbeitung zu verbessern. Weitere Informationen zu den von Salesforce für die Datenverarbeitung in der Automatisierung verfügbaren Tools finden Sie unter [Für Automatisiert relevante Tools](/docs/architect/de-de/well-architected/guide/automated#für-automatisiert-relevante-tools). ### Fehlerbehandlung Die Fehlerverarbeitung ist für die Datenintegrität entscheidend. Dank der starken Fehlerbehandlung kann Ihr System zudem besser skaliert und altern und ist [widerstandsfähiger](/docs/architect/de-de/well-architected/guide/resilient). Eine unsachgemäße Fehlerbehandlung in Automatisierungen kann zu Folgendem führen: - Datensatzinkonsistenzen und andere Datenintegritätsprobleme - Senden ungenauer Benachrichtigungen an Benutzer und andere Systeme - Verschwenden von Zeit und Ressourcen bei manueller oder wiederholter Verarbeitung - Gesamtmangel an [Trust](/docs/architect/de-de/well-architected/guide/trusted-overview) in einem System Bei der Fehlerbehandlung in Automatisierungen muss jeder ausgeführte Prozess die Möglichkeit haben, einen Fehler nach Informationen zu analysieren, auf Logik zuzugreifen, was die nächsten Schritte auf Fehlerinformationen basieren sollten, und dann den richtigen Pfad zu befolgen. Diese Funktionen müssen nicht bei jeder Automatisierung immer wieder neu erstellt werden (das ist ein [Optimierungs-Anti-Pattern](/docs/architect/de-de/well-architected/guide/automated#prozessdesign)). Stattdessen sollte jede Automatisierung im System in der Lage sein, eine Verbindung mit den entsprechenden [Komponenten zur](/docs/architect/de-de/well-architected/guide/composable#lose-kupplung) Fehlerbehandlung herzustellen. Stellen Sie sich die folgenden Fragen, um die richtigen Fehlerbehandlungssteuerungen in Ihre Automatisierungen zu integrieren: - Was ist ein "fataler" Fehler? - Was ist ein Fehler, der behoben werden kann? - Wie kann die Automatisierung bei Automatisierungen, die durch Benutzeraktionen ausgelöst werden, Fehler erkennen und den Benutzer benachrichtigen, bevor er versucht, Änderungen zu übernehmen? Sobald Sie sich entschieden haben, wie Sie mit diesen Fehlern umgehen, können Sie mit der effektiven Fehlerverarbeitung in Ihre Automatisierungen beginnen. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/automated#datenintegritätsmuster-und-antimuster) zeigt, wie eine ordnungsgemäße (und schlechte) Fehlerverarbeitung in einer Salesforce-Automatisierung aussieht. Sie können sie verwenden, um Ihre Automatisierungsentwürfe vor dem Erstellen zu validieren oder Automatisierungen zu identifizieren, die neu faktorisiert werden müssen, um die Fehlerverarbeitung zu verbessern. Weitere Informationen zu den von Salesforce für die Fehlerbehandlung verfügbaren Tools finden Sie unter [Für Automatisiert relevante Tools](/docs/architect/de-de/well-architected/guide/automated#für-automatisiert-relevante-tools). ### Datenintegritätsmuster und Antimuster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Datenintegrität im [Explorer für Muster](/docs/architect/de-de/well-architected-tools/guide/easy-data-integrity) und Anti-Muster.

	Muster	Anti-Muster
Datenverarbeitung	In Ihrem Datenwörterbuch: - Feldebenendaten und Priorisierungslogik für alle Datenquellen und Data-Lake-Objekte vorhanden - Feldzuordnung von Data-Lake-Objekt zu Datenmodellobjekt vorhanden	In Ihrem Datenwörterbuch: - Feldebenendaten und Priorisierungslogik für Datenquellen und Data-Lake-Objekte sind nicht enthalten - Die Feldzuordnung von Data-Lake-Objekten zu Datenmodellobjekten ist nicht enthalten
	In Ihrem Apex: - Alle synchronen DML-Anweisungen oder Datenbankklassen-Methoden werden vor Auslöserausführungskontexten ausgeführt - Asynchrone Apex Aufrufe verwenden Warteschlangen, um komplexe DML transaktionsübergreifend zu verketten - Batch Apex wird ausschließlich für große Datenmengen verwendet - `@future` Apex wird nicht oder sparsam für Callouts oder Systemobjekt-DML verwendet	In Ihrem Apex: - DML-Anweisungen werden regelmäßig in Code angezeigt, der nach Auslöserkontexten aufgerufen wird - Asynchrones Apex wird selten verwendet - Asynchrone Apex Funktionen werden beliebig verwendet, einschließlich: -- Künftige Methoden und warteschlangenfähiger Apex werden inkonsistent oder austauschbar verwendet -- Datenbankvorgänge verfügen nicht über eine klare, konsistente Logik, um die Ausführung bei Bedarf an Batch Apex weiterzugeben
	Im Flow: - Alle im Benutzerkontext gestarteten Flows abstrahieren alle Systemkontexttransaktionen in Subflows, die konsistent nach einem Pausenelement platziert werden, um eine neue Transaktion zu erstellen - Komplexe Sequenzen zugehöriger Datenvorgänge werden mit Orchestrator erstellt (anstatt mehrere Subflows innerhalb eines monolithischen Flows aufzurufen) - Bei allen durch einen Datensatz ausgelösten Flows werden Auslöserreihenfolgenwerte ausgefüllt - Flows mit externen System-Callouts oder langfristigen Prozessen verwenden asynchrone Pfade	Im Flow: - Große monolithische Flows versuchen, komplexe Sequenzen von zugehörigen Datenoperationen (mit oder ohne Subflows) zu koordinieren - Durch einen Datensatz ausgelöste Flows verwenden keine Auslöserreihenfolgenattribute oder keine durchgängigen Werte für Auslöserreihenfolgen - Asynchrone Pfade werden nicht einheitlich oder gar nicht verwendet
	In Ihrer Organisation: - Schlichtungsregeln für die Identitätsbestimmung folgen der Priorisierungslogik in Ihrem Datenwörterbuch	In Ihrer Organisation: - Schlichtungsregeln für die Identitätsbestimmung folgen nicht der Priorisierungslogik im Datenwörterbuch
Fehlerbehandlung	In Apex: - Code umschließt alle DML-, SOQL-, Callout- und anderen wichtigen Prozessschritte in `Testfangblöcken` - Benutzerdefinierte Ausnahmen werden verwendet, um erweiterte Fehlermeldungen und Logik zu erstellen - In asynchronen und Massenkontexten werden anstelle von DML Datenbankklassenmethoden verwendet - Datenbankklassenmethoden können ausschließlich für alle Datenvorgänge (anstelle von DML) verwendet werden	In Apex: - DML, SOQL, Callouts oder andere wichtige Prozessschritte werden nicht konsistent in `Try-Catch`-Blöcke eingeschlossen - `System.debug`-Anweisungen werden im Produktionscode angezeigt (und nicht auskommentiert) - Es werden keine Datenbankklassenmethoden verwendet - Datenvorgänge werden ausschließlich mit DML ausgeführt
	In Lightning Web Components (LWC): - JavaScript umschließt alle Datenvorgänge und wichtigen Prozessschritte in `If ()`- oder `Over If ()`-Blöcken - Alle `@wire-`Funktionen verwenden die von der API bereitgestellten `Daten`- und `Fehlereigenschaften` - Alle `wenn (Fehler)`- oder `wenn (Fehler)`-Anweisungen Logik enthalten, um Fehler zu verarbeiten und informative Meldungen bereitzustellen	In LWC: - JavaScript verwendet nicht konsistent `wenn ()` oder `wenn ()` mit Datenvorgängen oder wichtigen Prozessschritten blockiert wird - `@wire`-Funktionen verwenden keine `Daten` und `Fehlereigenschaften` der API (oder verwenden sie nicht einheitlich) - Wenn überhaupt verwendet, `wenn (Fehler)` oder `wenn (Fehler)`-Anweisungen keine Logik enthalten, um Fehler zu verarbeiten und nützliche Fehlermeldungen bereitzustellen
	In Aura: - JavaScript umschließt alle Datenvorgänge und wichtigen Prozessschritte in `Test-Catch`-Blöcken - In `Testfangblöcken` wird nativer JavaScript-`Fehler` in throw-Anweisungen verwendet (keine Verwendung von `$A.error()`) - Alle behebbaren Fehlerlogiken werden in `Fanganweisungen` angezeigt und bieten klare Benutzermeldungen	In Aura: - JavaScript umschließt Datenvorgänge und wichtige Prozessschritte nicht konsistent in `Test-Catch`-Blöcken - Komponenten verwenden `$A.error()` - Die behebbare Fehlerlogik wird in `Fanganweisungen` nicht konsistent angezeigt und Fehlermeldungen an Benutzer sind nicht eindeutig
	Im Flow: - Bildschirm-Flows verwenden konsistent Fehler-Konnektoren, um Benutzern Fehler anzuzeigen - Benutzerdefinierte Fehlermeldungen werden für Fehler konfiguriert, die auf dem Bildschirm angezeigt werden - Flows mit Datenvorgängen, Callouts und anderen wichtigen Verarbeitungslogiken weisen Fehlerpfade für alle wichtigen Aktionen auf	Im Flow: - Flows verwenden Fehlerpfade nicht einheitlich oder überhaupt - Benutzerdefinierte Fehlermeldungen werden nicht verwendet, sodass Benutzern die Standardmeldung "Ein nicht bearbeiteter Fehler ist in diesem Flow aufgetreten" angezeigt wird

## Geschäftswert Beim Konzept des Geschäftswerts geht es im Kontext der Automatisierung darum, wie gut Prozesse messbare positive Auswirkungen auf die Beteiligten haben. Im Idealfall können Benutzer durch die Prozessautomatisierung weniger Zeit mit sich wiederholenden Aufgaben mit geringem Wert verbringen. Außerdem wird die Datenintegrität erhöht, indem manuelle Verarbeitungsaktivitäten, die zu Fehlern führen könnten, vermieden werden. Ähnlich wie beim [Prozessdesign](/docs/architect/de-de/well-architected/guide/automated#prozessdesign) erfordert das Identifizieren und Bereitstellen von Automatisierungen, die den tatsächlichen Geschäftswert steigern, Arbeit, die über die grundlegende Entdeckung und Geschäftsanalyse hinausgeht. Manchmal scheint es, als ob die beste Möglichkeit, dem Unternehmen einen Mehrwert zu bieten, darin besteht, einfach jeden von einem Geschäftsbenutzer angeforderten Prozess zu automatisieren, entweder in der Reihenfolge, in der er in Ihrem Rückstand (oder in der Ticketing-Warteschlange) angezeigt wird, oder basierend auf politischen Faktoren in Ihrer Organisation. Dies kann zu zwei verwandten Problemen führen: der Erstellung von Automatisierungen in einer suboptimalen Reihenfolge und der Erstellung der falschen Automatisierungen. Das erste Problem, die schlechte Priorisierung, verhindert, dass Prozesse mit hohem Wert implementiert werden, wenn sie es sollten, was das Wachstum potenziell verlangsamt. Das zweite Problem, die Erstellung falscher Automatisierungen, verzögert nicht nur die Bereitstellung hochwertiger Automatisierungen, sondern führt auch zu Zeitverschwendung, unnötigen Kosten und erhöhter Frustration bei den Zustellungsteams. Sie können einen höheren Geschäftswert erzielen, indem Sie sich auf KPIs und die Priorisierung konzentrieren. ## Für "Automatisiert" relevante Tools

Tool	Beschreibung	Effizienz	Datenintegrität	Geschäftswert
Apex Batching	Zusammenfassen von Batch-Datensätzen und Verarbeiten verwaltbarer Blöcke	X	X
Künftige Apex-Methoden	Apex Methoden im Hintergrund asynchron ausführen	X	X
Apex Queueing	Hinzufügen von Apex Aufträgen zu einer Warteschlange und Überwachen dieser Aufträge	X	X
Apex Scheduler	Asynchrones Ausführen von Apex Klassen zu angegebenen Zeiten	X	X
Genehmigungen	Angeben der erforderlichen Schritte zum Genehmigen von Datensätzen	X	X
Asynchronous Apex	Apex Code asynchron ausführen	X	X
Automatische Aktionen	Ausführen von Feldaktualisierungen, E-Mail-Sendungen und anderen Aktionen im Hintergrund	X	X
Einstein Next Best Action	Anzeigen der richtigen Empfehlungen an die richtigen Personen zur richtigen Zeit	X		X
E-Mail-Benachrichtigung	Erstellen und Senden automatisierter E-Mails	X		X
Eskalationsaktionen	Angeben automatisierter Aktionen für Kundenvorgangseskalationen	X	X
Feldaktualisierung	Aktualisieren von Feldwerten anhand der Automatisierung	X	X
Flow Builder	Erstellen von Automatisierungen mit einer Zeigen-und-Klicken-Oberfläche	X		X
Flow-Erweiterungen	Zugreifen auf gespeicherte Variablen als Komponenteneingaben in Flows	X
Bibliothek für Flow-Vorlagen	Verwenden von Vorlagen zum Entwerfen branchenspezifischer Flows	X		X
Flow-Auslöser	Automatisieren komplexer Geschäftsprozesse	X
Aufrufbare Aktionen	Hinzufügen von Apex-Funktionen zu Flows	X		X
Orchestrator	Erstellen und Verwalten von Automatisierungen in mehreren Schritten	X	X
Ausgehende Nachricht	Senden von Informationen aus einem automatisierten Prozess mit Belegen und Wiederholungen		X
Plattformereignisse mit Flow veröffentlichen	Veröffentlichen von Ereignissen über Benutzerinteraktionen und Automatisierungen	X
Abfrageoptimierung	Verwenden von Selektivität und Indizes zum Verbessern der Leistung von Abfragen, Berichten und Listenansichten	X	X
Salesforce-Flow	Erstellen deklarativer Prozessautomatisierungen mit Flow Builder	X	X
Benachrichtigungen mit Flows senden	Senden von Nachrichten über SMS, WhatsApp oder Facebook Messenger	X		X
Benachrichtigungen mit Prozessen senden	Senden von Nachrichten über SMS, WhatsApp oder Facebook Messenger	X		X
Modifikator 'SOQL FÜR AKTUALISIEREN'	Sperren von Datensätzen zum Verhindern von Race-Bedingungen und Thread-Sicherheitsproblemen		X
Strategy Builder	Identifizieren von Empfehlungen, die auf Datensatzseiten angezeigt werden sollen	X		X
Subflows	Reduzieren der Flow-Komplexität durch Wiederverwendung	X
Plattformereignisse mit Flow abonnieren	Empfangen von über Automatisierungen veröffentlichten Nachrichten	X
Aufgabenaktionen	Bestimmen von Zuweisungsdetails, die einem Benutzer von einer Automatisierung bereitgestellt werden	X

## Für "Automatisiert" relevante Ressourcen

Ressource	Beschreibung	Effizienz	Datenintegrität	Geschäftswert
Obergrenzen für Apex Execution	Erfahren Sie, wie das Apex-Laufzeitmodul Obergrenzen durchsetzt	X	X
Batch-Verwaltungsressourcen	Erstellen, Verwalten, Planen und Überwachen von Batchaufträgen	X	X
Bewährte Vorgehensweisen für SOQL und SOSL	Verbessern der Abfrageleistung von Anwendungen mit großen Datenvolumen		X
Vorlage 'Designstandards'	Erstellen von Designstandards für Ihre Organisation	X	X	X
Flow-Massenverarbeitung in Transaktionen	Entwerfen von Flows für Inkassovorgänge	X	X
Überlegungen zu Flow-Daten	Informationen zu durch einen Zeitplan ausgelösten Flows für Batchdaten	X	X
Flow-Debugging	Testen und Beheben von Fehlern bei Flows		X
Verarbeitung von Anforderungen	Erfahren Sie, wie Salesforce Aufträge schnell verarbeitet und Fehler minimiert	X	X
KPI-Tabellenblattvorlage	Bestimmen des Geschäftswerts einer bestimmten Kennzahl	X		X
Aufrufbare Aktionen zum Senden von Callouts an externe Systeme	Aufrufen externer Systeme über einen Flow mit Apex	X
Gemischte DML-Vorgänge	Wissen, welche sObjects zusammen für DML in derselben Transaktion verwendet werden können	X	X
Ausführungsreihenfolge	Verstehen der Reihenfolge von Ereignissen für Einfügungen, Aktualisierungen und Aktualisierungen	X	X
Häufig gestellte Fragen zum Abfrageplan	Optimieren von Abfragen mit großen Datenmengen	X	X
Überlegungen zu durch einen Zeitplan ausgelösten Flows	Grundlegendes zu den besonderen Verhaltensweisen von durch einen Zeitplan ausgelösten Flows	X
Transaktionssteuerung	Generieren eines Speicherpunkts, der den aktuellen Datenbankstatus angibt	X	X
Was geschieht, wenn ein Flow fehlschlägt?	Grundlegendes zur Fehlerbehandlung in Flows	X	X
Bewährte Vorgehensweisen für die Workflow-Automatisierung	Erste Schritte mit der Salesforce-Automatisierung	X	X	X
Arbeiten mit sehr großen SOQL-Abfragen	Schreiben effizienterer SOQL-Abfragen		X

Dies ist ein Diagramm, das zeigt, wie sich die Themen im zusammengesetzten Zustand über drei verschachtelte Karten verhalten. Die innerste Karte ist eine Funktionseinheit, die nächste Ebene ist die Interoperabilität und die äußere Ebene ist die Paketierbarkeit.

Ein zusammengesetztes System:

## Trennung von Bedenken Die _Trennung von Anliegen_ ist ein grundlegendes Konzept im Software Engineering und in der Systemarchitektur und beinhaltet die Identifizierung verschiedener Anliegen in einem größeren System, das in modulare Einheiten unterteilt werden kann. Um eine starke Trennung von Bedenken innerhalb eines Systems zu erreichen, müssen sinnvolle Einheiten für die Anwendungslogik und -funktionen im gesamten System erstellt werden. Kleinere Einheiten erleichtern es Anwendungszustellungs- und Wartungsteams, nachzuvollziehen, wie und wo Änderungen vorgenommen werden können, ohne dass das größere System unterbrochen wird. Kleinere Einheiten machen zudem deutlicher, wie und wo Sie sich bei der Bewältigung [technischer Schulden](/docs/architect/de-de/well-architected/guide/intentional#technische-schulden) auf die Arbeit konzentrieren sollten, und tragen zur allgemeinen [Lesbarkeit](/docs/architect/de-de/well-architected/guide/intentional#lesbarkeit) Ihres Systems bei. Sie können Ihre Salesforce-Organisation besser voneinander trennen, indem Sie sich an der Geschäftsfähigkeit orientieren und den Status verwalten. ### Funktionale Einheiten Bei Salesforce-Systemen wendet der beste Ansatz zur Trennung von Bedenken eine geschäftsorientierte Perspektive an, um modulare Einheiten (oder Funktionen) im System zu identifizieren und zu organisieren. Dies ist im Gegensatz zu einer auf Technik ausgerichteten Ansicht, die Einheiten anhand ihrer technischen Funktion identifiziert. Eine geschäftsorientierte Perspektive zur Trennung von Bedenken erfordert die Organisation des Codes und der Anpassungen in Ihrem System anhand des Service, den sie für Geschäfts- und Geschäftsbenutzer bereitstellen. Dieser Ansatz bedeutet nicht, dass das Potenzial für redundante oder doppelte technische Funktionen in einem System ignoriert wird. Vielmehr bedeutet dies, dass technische Dienstleistungen eindeutig einem Organisationsprinzip zugeordnet sind, das für das Unternehmen letztlich transparent ist. Durch die Ausrichtung auf Geschäftsfunktionen wird sichergestellt, dass die Übergabe zwischen Geschäftsanalyse- und Discovery-Teams an Bereitstellungsteams so einfach wie möglich ist. Wenn Anwendungsgeneratoren keine Ahnung haben, wo ihre Arbeitseinheiten in Ihrer zusammengesetzten Architektur zugeordnet sind, besteht ein Chaos und keine zusammengesetzte Anwendungslandschaft. Unklare Zuordnungen zwischen dem für das Unternehmen erforderlichen Endstatus und den modularen Einheiten in einer Organisation erhöhen zudem die Wahrscheinlichkeit, dass Entwicklungsteams oder -anbieter redundante Funktionen in das System integrieren. Beachten Sie Folgendes, um Funktionseinheiten an der Geschäftsfähigkeit auszurichten: - **Beginnen Sie mit zu erledigenden Aufträgen**. Konzentrieren Sie sich auf die zu erledigenden Aufgaben der Benutzer und das Unternehmen selbst. Der JTBD-Ansatz wurde von Tony Ulwick entwickelt und konzentriert sich auf das Verständnis des „Jobs“ oder des wahren Zwecks, den Menschen mit einem Produkt oder Service erreichen möchten. Es ist eine höhere Abstraktionsebene als die rollenbezogenen Aufgaben der Benutzer oder die einzelnen Schritte in einem Geschäftsprozess. Aufgaben wie Duplikatsprüfungen und Adressvalidierungen können beispielsweise in die übergeordnete Funktion "Einzelansicht des Kunden einrichten" fallen. Nachdem Sie einen klaren Eindruck von diesen übergeordneten Geschäftsfunktionen erhalten haben, können Sie beginnen, ihnen Teile Ihres Systems zuzuordnen. - **Orientieren Sie sich an Funktionen und nicht an Berichtsstrukturen**. Die interne Hierarchie Ihrer Geschäftseinheiten ist kein Proxy für sinnvolle Funktionen oder zu erledigende Aufgaben. Die interne Hierarchie Ihres Unternehmens hat wesentliche Auswirkungen auf Prozesse und Teamstrukturen (ganz zu schweigen von Budgets). Das sind wichtige logistische Überlegungen. Aber die funktionalen Anforderungen des Unternehmens funktionieren auf einer höheren Abstraktionsebene als die Logistik. Wenn Sie ein Modul erstellen, um eine Berichtsstruktur anstelle einer übergeordneten Funktion bereitzustellen, sollten Sie beachten, dass Sie möglicherweise zusätzliche Schritte ausführen müssen, um zu ermitteln, wie sich dieses Modul auf die Geschäftsfunktionen bezieht. - **Seien Sie iterativ**. Arbeiten Sie zunächst mit dem Unternehmen zusammen, um zu ermitteln, welche Funktionen für ein minimal lebensfähiges Produkt (MVP) funktionieren könnten. Wenn Sie eine Funktion identifizieren, erstellen Sie diesen MVP. Identifizieren Sie beim Erstellen die Prozesse, Metadaten und [Ereignisse oder Nachrichten](/docs/architect/de-de/well-architected/guide/composable#messaging-und-eventing), die für die von Ihnen erstellte Funktionseinheit zentral sind. Identifizieren Sie alle Prozesse, Metadaten und Ereignisse oder Nachrichten, bei denen es sich um externe Abhängigkeiten handelt. Implementieren Sie [die API-Verwaltung](/docs/architect/de-de/well-architected/guide/composable#api-management) und die [Abhängigkeitsverwaltung](/docs/architect/de-de/well-architected/guide/composable#abhängigkeitsverwaltung), um Einheiten zu erstellen, die gut miteinander funktionieren (anstatt isolierte Einheiten zu erstellen). Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/composable#trennung-von-bedenkenmustern-und-antimustern) zeigt, wie eine ordnungsgemäße (und schlechte) Orientierung an Geschäftsfunktionen in einer Salesforce-Lösung aussieht. Sie können diese verwenden, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu den von Salesforce verfügbaren Tools zur besseren Orientierung an den Geschäftsfunktionen finden Sie unter [Tools Relevant to Composable](/docs/architect/de-de/well-architected/guide/composable#für-composable-relevante-tools) (Für Composable relevante Tools). ### Bundesstaatsverwaltung Die Verwaltung des Bundesstaats konzentriert sich auf die Bewegung von Informationen in einem System zu verschiedenen Zeitpunkten. Durch eine effektive Statusverwaltung können Anwendungen komplexe Datenflüsse oder Interaktionen mit einem Minimum an ungeplanten oder unbestimmten Ergebnissen verarbeiten. Die Verwaltung des Status in einer modularen Salesforce-Organisation bedeutet, klare Pfade für Logik-Flows innerhalb und zwischen Einheiten sowie anmutige Pfade für ungeplantes Ausführungsverhalten zu erstellen. Mit der Statusverwaltung können kohärente Logikströme aus modularen Salesforce-Anwendungseinheiten gebildet werden. In den meisten Fällen erfordert dies eine [Interoperabilität](/docs/architect/de-de/well-architected/guide/composable#interoperabilität), um den Informationsfluss zwischen Einheiten zu strukturieren. Schwierigkeiten bei der Verwaltung des Status über lose gekoppelte Einheiten hinweg führen häufig zu einer monolithischen Anwendungsentwicklung in Salesforce. Sie können dies in großen "Monoflows" sehen, die in dem Versuch erstellt wurden, einen komplexen Prozess innerhalb eines einzelnen Flows zu orchestrieren. Ein weiteres Beispiel sind massive Apex Klassen, die komplexe Prozesse über _Spaghetti Code_ orchestrieren, oder eine lange Reihe von Single-Use Methoden. Diese Arten von Anwendungsarchitekturen erschweren das Refaktorisieren und Debuggen und erhöhen die Einarbeitungszeiten für neue Teammitglieder oder -anbieter. Sie verringern auch den Wert der Anwendungen, die an das Unternehmen bereitgestellt werden, da die Funktionen nicht wiederverwendet werden können. Beachten Sie Folgendes, um den Status in einer modularen Salesforce-Organisation zu verwalten: - **Entscheiden Sie, wann zustandsbasierte und wann zustandslose Muster verwendet werden sollen**. Bundesstaatliche Muster speichern Informationen über einen Ausführungspfad hinweg, zustandslose Muster hingegen nicht. In einem lose gekoppelten System ermöglichen zustandslose Muster eine schnellere und nebenwirkungsärmere Refaktorisierung von Komponenten. Statuslose Muster sind jedoch nicht für alle Anwendungsfälle geeignet. Wenn Sie Komponenten für Datenvorgänge erstellen, können Stateful Patterns die Datenintegrität und Konsistenz in Ihren Systemen verbessern. Verwenden Sie ein Bundesstaatsmuster, wenn Ihre Komponente eines der folgenden Kriterien erfüllt: - Die Kenntnis der Platzierung innerhalb eines größeren Ausführungspfads ist für das Verhalten der Komponente entscheidend - Das Verhalten der Komponente muss sich basierend auf den Ergebnissen einer nachgelagerten Aktion ändern (beispielsweise muss sie die Ausführung basierend auf Rollback-/Fehler-/Erfolgsmeldungen aus nachgelagerten Komponenten ändern). - Die Komponente muss auf Antworten von einem externen oder nachgelagerten System warten, um ihre Arbeit abzuschließen. - **Erstellen Sie aussagekräftige Kategorien für aussagekräftige Informationen.** _Status_ ist ein mehrdeutiger Begriff, der auf eine so umfassende und breite Palette von Informationen innerhalb (und darüber hinaus) einer Salesforce-Organisation angewendet werden kann, dass er für sich genommen fast bedeutungslos ist. Ein notwendiger erster Schritt zum Erstellen von zustandsbasierten Mustern besteht daher darin, _sinnvolle_ Kategorien für die wichtigsten zustandsbasierten Ausführungspfade (oder Arten von zustandsbasierten Verhaltensweisen) in Ihrem System zu erstellen. Einige zu berücksichtigende Kategorien: - Navigation und Formulare - Datenbankvorgänge - Batch- und Massenvorgänge - Fehler - **Definieren Sie datenbezogene Status in Form von [Datenbanktransaktionen](/docs/architect/de-de/fundamentals/guide/architecture-basics#datenbankmanipulation)**. Die integrierten Verhaltensweisen der Plattform werden die meisten Überlegungen zu den Bundesstaaten für Daten in Salesforce umschreiben. Versuchen Sie nicht, dieses Verhalten zu umgehen. Design für und mit ihm. Entwerfen Sie Lösungen, die die Logik verteilter Transaktionen minimieren oder eliminieren. (Weitere Details finden Sie unter [Datenverarbeitung](/docs/architect/de-de/well-architected/guide/automated#datenverarbeitung)). - **Identifizieren Sie Status, die innerhalb (und übergreifend) von Funktionseinheiten auftreten**. Achten Sie beim Zusammenstellen von Funktionseinheiten in größeren Systemen darauf, wann Sie das Verhalten von zustandslosen und zustandsbasierten Komponenten mischen, und verhindern Sie Kombinationen, die zu Endlosschleifen oder Lücken in der Verarbeitung führen könnten. - **Definieren Sie Übergaben**. Überlegen Sie, welche [Messaging- oder Ereignismuster](/docs/architect/de-de/well-architected/guide/composable#messaging-und-eventing) Komponenten verwenden, um zustandsbezogene Daten an einen anderen Teil des Systems zu übertragen. Stellen Sie sicher, dass Sie Transaktionsbewusstsein aufbauen und Ihre Komponenten [verarbeiten](/docs/architect/de-de/well-architected/guide/automated#datenverarbeitung). Fügen Sie keine verteilte Transaktionslogik in Ihre Übergaben ein. - **Erstellen Sie Zuordnungen zwischen Ihren Prozessdiagrammen und -status**. Prozessdiagramme enthalten Details zu den Schritten, mit denen Informationen zu verschiedenen Zeitpunkten durch Ihr System geleitet werden. In einem Zustandsdiagramm werden die tatsächlichen Änderungen der Informationen (der Status) angezeigt. Verwenden Sie den Abschnitt "Metadatenfußzeile" der [Salesforce-Diagrammformen](/docs/architect/de-de/reference-diagrams/guide/kit-of-parts), um den sich ändernden Status der Informationen in jedem Schritt Ihres Prozesses zu erfassen. Wenn Sie Prozessdiagramme und Statusdiagramme trennen, verknüpfen Sie sie. Dieses Konzept sollte nicht mit der Erfassung des aktuellen und zukünftigen Zustands von Prozessen oder Systemlandschaften während des Entwurfs und der Implementierung verwechselt werden, da es nicht um die Informationen geht, die durch das System fließen. In der folgenden Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/composable#trennung-von-bedenkenmustern-und-antimustern) wird gezeigt, wie eine ordnungsgemäße (und schlechte) Zustandsverwaltung in einer Salesforce-Lösung aussieht. Sie können sie verwenden, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools für die Statusverwaltung finden Sie unter [Tools Relevant to Composable](/docs/architect/de-de/well-architected/guide/composable#für-composable-relevante-tools) (Für Composable relevante Tools). ### Trennung von Bedenkenmustern und Antimustern In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster zur Trennung von Bedenken im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/adaptable-separation-of-concerns) Anti-Muster.

	Muster	Anti-Muster
Funktionale Einheiten	In Ihren Designstandards: - Benennungskonventionen behandeln die Angabe einer Funktionseinheit - Eine Liste aller aktuell definierten Funktionseinheiten (und zugehöriger Benennungskonventionen) ist vorhanden - Es gibt Standards zum Vorschlagen von Funktionseinheiten-Ergänzungen oder -Änderungen	In Ihren Designstandards: - Designstandards sind nicht vorhanden oder betreffen keine Funktionseinheiten und Anwendungsfälle
	In Ihrer Dokumentation: - Systemlandschaftsdiagramme zeigen die Funktionseinheiten in einer Organisation übersichtlich an - In allen Dokumentations- und Implementierungsdiagrammen ist die Funktionseinheit(en) für Komponenten übersichtlich dargestellt - Die Dokumentation für einzelne Komponenten enthält die Zuordnung der Funktionseinheiten für die Komponente - Alle Komponenten innerhalb einer Funktionseinheit sind durchsuchbar und leicht zu finden	In Ihrer Dokumentation: - Komponentendokumentation nicht vorhanden - In der Komponentendokumentation wird die Funktionseinheit beschrieben, zu der eine Komponente gehört. Dies ist jedoch der einzige Ort, an dem die Definition dieser Funktionseinheit angezeigt wird. - Sie können nicht nach einer bestimmten Funktionseinheit suchen und/oder Suchvorgänge helfen nicht, alle Komponenten innerhalb einer Funktionseinheit zu identifizieren
	In Ihrer Organisation: - Es ist möglich, die Ausrichtung von Funktionseinheiten für bestimmte Metadaten (z. B. einen Flow, eine Apex-Klasse oder eine Lightning-Seite) schnell zu identifizieren - Funktionseinheiten sind geschäftsfreundlich gekennzeichnet	In Ihrer Organisation: - Es ist nicht möglich, die Ausrichtung der Funktionseinheit für Metadaten zu identifizieren - Informationen zu Funktionseinheiten sind inkonsistent oder ungenau - Informationen zu funktionalen Einheiten werden in Engineering-orientierten Begriffen gekennzeichnet, die für Geschäftsbenutzer bedeutungslos sind
Statusverwaltung	In Ihren Designstandards: - Anwendungsfälle für Stateful vs. Stateless Designs sind klar - Genehmigte Muster für die Kommunikation ohne Status vorhanden - Genehmigte Muster für die Stateful Communication vorhanden - Klare Kategorien für Bundesstaat vorhanden	In Ihren Designstandards: - Designstandards sind nicht vorhanden oder behandeln keine Muster und Anwendungsfälle ohne Bundesstaat
	In Ihrer Dokumentation: - Jede Komponente, die die zustandsbasierte und/oder zustandslose Kommunikation verarbeitet, gibt an, welches Muster implementiert wurde - Es ist möglich, alle Komponenten zu suchen und zu finden, die ein bestimmtes stateful/stateless-Muster implementiert haben - Prozess- und Interaktionsdiagramme bieten Details zu Statuskategorien und Übergaben	In Ihrer Dokumentation: - Komponentendokumentation nicht vorhanden - In der Komponentendokumentation wird das implementierte Muster ohne Status beschrieben, aber nur dort wird die Definition angezeigt. - Es ist nicht möglich, nach einem bestimmten Muster zu suchen und/oder Suchvorgänge helfen nicht, alle Komponenten zu identifizieren, die dieses Muster verwenden
	In Apex: - Speicherpunkte und Rollback-Verhalten werden bei allen Datenvorgängen verwendet	In Apex: - Speicherpunkte und Rollback-Verhalten werden nicht verwendet
	Im Flow: - Fehlerpfade und das Element "Datensätze zurücksetzen" wird verwendet	Im Flow: - Das Element 'Datensätze zurücksetzen' wird nicht verwendet

## Interoperabilität In einem auf Interoperabilität ausgelegten System können Komponenten Informationen austauschen und effektiv zusammenarbeiten. Interoperabilität ist ein Schlüssel, um ein modulares System zusammengesetzt und nicht isoliert zu gestalten. Die Interoperabilität kann in einem [lose gekoppelten](/docs/architect/de-de/well-architected/guide/composable#lose-kupplung) System schwierig zu erreichen sein. Sie müssen Standards für konsistente Integrationsmethoden festlegen, die die Unabhängigkeit zwischen Einheiten und die allgemeine [Trennung von Bedenken](/docs/architect/de-de/well-architected/guide/composable#trennung-von-bedenken) im gesamten System nicht untergraben. Die Interoperabilität wirkt sich auch auf die Qualität Ihrer Benutzererfahrungen aus. Ihre Benutzer erwarten, dass in einem Bereich erstellte Daten (wie Auftragsinformationen) in einem anderen Bereich (wie Marketingkampagnen) verwendet werden können, und Ihre Ersteller erwarten, dass sie, wenn sie etwas lernen (wie das Erstellen eines Flows oder die Authentifizierung bei einer API), feststellen, dass vertraute Techniken funktionieren, wenn sie zum nächsten Problem übergehen. Wenn die Interoperabilität nicht ausgelegt wird, führt dies zu redundanten Architekturen, replizierten Daten, Prozessineffizienzen und höheren Entwicklungs- und Supportkosten. Sie können Interoperabilität in modularen Systemen mit Messaging und Eventing sowie mit der API-Verwaltung herstellen. ### Messaging und Eventing Nachrichten und Ereignisse sind zwei Möglichkeiten, mit denen Sie Komponenten in einem System das Senden und Empfangen von Informationen ermöglichen können. In Bezug auf die Inhalte, die sie übertragen können, ähneln sich Ereignisse und Nachrichten. Ein wesentlicher Unterschied besteht im Verhalten des Absenders. Eine Komponente, die eine _Nachricht_ sendet, sendet in der Regel Daten an ein bestimmtes Ziel und wartet auf eine Antwort des Empfängers. Im Gegensatz dazu sendet eine Komponente ein _Ereignis_, wenn etwas passiert ist. Es gibt weder ein bestimmtes Ziel noch eine Antwort. Diese Verhaltensunterschiede unterstützen unterschiedliche Kommunikationsmuster. Nachrichten unterstützen zustandsbasierte Kommunikationsmuster und Ereignisse unterstützen zustandslose Kommunikationsmuster. (Weitere Informationen zu dieser Unterscheidung finden Sie unter [Statusverwaltung](/docs/architect/de-de/well-architected/guide/composable#bundesstaatsverwaltung).) Es ist wichtig, Teams auf Protokolle und Anwendungsfälle für Messaging und Eventing abzustimmen. Unklare Standards können zu einer Mischung von Mustern in Ihrem System führen, was zu Folgendem führt: - Leistungs- und Skalierbarkeitsprobleme, bei denen die falschen Muster auf einen bestimmten Anwendungsfall angewendet werden - Inkonsistente Verarbeitung, die das System für Endbenutzer instabil erscheinen lässt - Längere Fehlerbehebungszeiten und komplexere Wartungsprozesse Beachten Sie beim Entwerfen von Nachrichten und Ereignissen Folgendes, um losere gekoppelte Strukturen in Ihrer Salesforce-Organisation zu erstellen: - **Identifizieren Sie synchrone und asynchrone Anwendungsfälle**. Eventing ermöglicht lose gekoppelte, zustandslose und asynchrone Kommunikation über ein System hinweg. Messaging ermöglicht strenger gesteuerte, zustandsgesteuerte und synchrone Kommunikationsmuster. Wenn Sie entscheiden, wann Nachrichten oder Ereignisse verwendet werden sollen, müssen Sie entscheiden, ob Ihre Kommunikation synchron (und potenziell blockiert) und nicht asynchron und nicht blockiert sein soll. - **Definieren Sie Datenstrukturen sorgfältig**. Die Struktur der Informationen, die Komponenten zwischen ihnen übertragen, ist ein wichtiger Teil, um ein lose gekoppeltes System überschaubar und kohärent zu halten. (Weitere Informationen finden Sie unter [API-Verwaltung](/docs/architect/de-de/well-architected/guide/composable#api-management).) Eine wichtige Überlegung beim Entwerfen einer Nachricht oder eines Ereignisses ist, wie oft sich die Struktur der Informationen ändern muss. Sobald eine Nachricht oder Ereignisstruktur in Ihrem System definiert und implementiert ist, kann es schwierig sein, Aktualisierungen zu verarbeiten, insbesondere wenn das Ereignis oder die Nachricht bereits zum Senden von Informationen an ein externes System verwendet wird. - **Meldungen in richtiger Größe**. Im Allgemeinen empfiehlt es sich, die Nachrichtengrößen klein zu halten. Es gibt jedoch auch einen Balanceakt zwischen der _Größe_ der Nachricht und dem _Volumen_ der Nachricht. Systeme können kleinere Datenmengen schneller verarbeiten. Der Verarbeitungsvorgang ist mit einem zusätzlichen Mehraufwand verbunden, da Empfänger Informationen entpacken, interpretieren und bestimmen müssen, was mit ihnen geschehen soll. Die Durchführung dieser Schritte kann vernachlässigbar viel Zeit in Anspruch nehmen, sie können sich jedoch aufbauen und eine Belastung für Systeme im großen Umfang verursachen. Vermeiden Sie Designs, bei denen Komponenten im System viele kleine Nachrichten nacheinander verarbeiten müssen, um eine Arbeit zu erledigen. Wenn Sie die richtige Größe Ihrer Nachrichten festlegen möchten, sollten Sie darüber nachdenken, die nachgelagerten Komponenten so zu gestalten, dass sie die gesendeten Informationen nur auf ein Minimum verarbeiten können, ohne auch nur davon auszugehen, dass jede nachgelagerte Komponente in der Lage ist, zahlreiche Folgenachrichten anzufordern oder zu verarbeiten. - **Design für Skalierbarkeit**. Durch lose gekoppelte Komponenten kann Ihre Architektur einfacher skaliert werden. Durch die Eliminierung komponentenübergreifender Abhängigkeiten können Teams an der Verbesserung der Leistung oder Skalierbarkeit einer einzelnen Komponente mit minimalen Auswirkungen auf die anderen arbeiten. Locker gekoppelte Komponenten führen jedoch auch zu einer erheblichen Komplexität in Ihrer Architektur (insbesondere in Bezug auf den [Verwaltungsstatus](/docs/architect/de-de/well-architected/guide/composable#bundesstaatsverwaltung)). Identifizieren Sie Prozesse, die aus gültigen Gründen der Benutzererfahrung oder aus Gründen der Datenintegrität enger mit Logik oder Abhängigkeiten verknüpft sein müssen, und versuchen Sie nicht, asynchrone/ereignisbasierte Muster in diese Prozesse einzuführen. Verwenden Sie stattdessen synchronisierungs-/meldungsbasierte Muster und eine ordnungsgemäße Fehlerbehandlung. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/composable#interoperabilitätsmuster-und-antimuster) zeigt, wie richtiges (und schlechtes) Messaging und Eventing in einer Salesforce-Lösung aussehen. Sie können sie verwenden, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Messaging- und Eventing-Tools finden Sie unter [Tools Relevant to Composable](/docs/architect/de-de/well-architected/guide/composable#für-composable-relevante-tools) (Für Composable relevante Tools). Weitere Informationen zur Auswahl eines Eventing-Musters oder -Tools für einen bestimmten Anwendungsfall finden Sie im [Architektenhandbuch zur ereignisgesteuerten Architektur mit Salesforce](/docs/architect/de-de/decision-guides/guide/event-driven#key-takeaways). ### API Management Durch das Erstellen einer ordnungsgemäßen Verwaltung der Anwendungsprogrammierschnittstelle (API) in einer Salesforce-Lösung können einzelne Komponenten Ihres Systems vorhersehbaren Kommunikationsmustern folgen. Salesforce bietet integrierte, sichere APIs für die Kommunikation mit Systemen außerhalb von Salesforce. (Weitere Informationen zu Salesforce Platform-APIs finden Sie unter [Architekturgrundlagen](/docs/architect/de-de/fundamentals/guide/architecture-basics#plattform-apis).) Eine effektive API-Verwaltung innerhalb von Salesforce-Lösungen ist der Schlüssel zum Erstellen wirklich komposibler Architekturen. Dadurch können Komponenten in einer Salesforce-Organisation Informationen effizient senden und empfangen. Außerdem können Lösungsentwickler klare Protokolle für die Kommunikation der von ihnen erstellten Komponenten mit anderen Komponenten im System befolgen und schlechte Implementierungen frühzeitig erkennen. Darüber hinaus können sich Lösungsentwickler enger auf die jeweilige Komponente konzentrieren, die sie erstellen oder refaktorieren, was die Produktivität und Qualität steigert. Die API-Verwaltung auf Unternehmensebene ist ein separates Thema und lässt sich am besten mit einem umfassenden API-Verwaltungstool erreichen. (Weitere Informationen zur MuleSoft-Perspektive zu diesem Thema finden Sie unter [Was ist API-Verwaltung?](https://www.mulesoft.com/resources/api/what-is-api-management#:~:text=API%20management%20is%20the%20process,create%20are%20consumable%20and%20secure.).) Beachten Sie Folgendes, um API-Verwaltungsfunktionen in Ihren Salesforce-Lösungen zu erstellen: - **Stellen Sie sich APIs als _vorhersehbare_ Muster oder Verträge für die Kommunikation vor.** Der Datentyp der Eingabe- oder Ausgabevariablen, Variablennamen und die Informationen, die in einem bestimmten Muster angezeigt werden sollen (oder nicht), sind die Schlüssel für eine effektive API-Verwaltung. Diese Definitionen sollten in Ihren Designstandards angezeigt werden und Teams sollten in der Lage sein, über Ihre Dokumentation herauszufinden, wie diese Definitionen in bestimmten Teilen Ihres Systems implementiert wurden. Eine Möglichkeit, Schwierigkeiten beim Zusammenführen von Änderungen aus einer neuen Entwicklung in eine Integrationsumgebung anzuzeigen, besteht darin, sie als Beleg dafür zu betrachten, wo Sie die API-Kommunikation schlecht implementiert haben (oder möglicherweise gar keine API-Definition). - **Beschränken Sie Ihre Überlegungen zu APIs nicht nur auf Code**. Was eine API in diesem Kontext definiert, ist die Konsistenz der Nachrichtenstrukturen und Variablen in dieser Nachricht. Solange diese Konsistenz gewahrt bleibt, kann eine API sowohl in Code als auch in deklarative Anpassungen implementiert werden, beispielsweise in modularen automatisch gestarteten (oder durch Plattformereignisse ausgelösten) Flows oder sogar in Flow-Vorlagen. Legen Sie bei Ihren Entscheidungen nicht die API-Implementierung zugrunde, sondern die [Paketfähigkeit](/docs/architect/de-de/well-architected/guide/composable#paketierbarkeit) und [Testbarkeit](/docs/architect/de-de/well-architected/guide/resilient#anwendungslebenszyklus-verwaltung). - **Halten Sie Ihren Lebenszyklus und Ihre Versionierung einfach**. Wie alle Teile der Anwendungsentwicklung haben APIs einen Lebenszyklus: Definieren, Erstellen, Testen, Bereitstellen und Verwalten (einschließlich Außerbetriebnehmen). Salesforce Platform-APIs veröffentlichen aufgrund des schnellen Versionszyklus der Plattform mehrere Versionen innerhalb eines Kalenderjahres. (Weitere Informationen zu diesem Verhalten finden Sie unter Salesforce [Architecture Basics](/docs/architect/de-de/fundamentals/guide/architecture-basics#plattform-apis).) Das bedeutet, dass Plattform-APIs einen relativ komplexen Lebenszyklus aufweisen, da mehrere Versionen einer bestimmten API gewartet werden müssen und für Salesforce-Kunden verfügbar sein müssen. Dieser Komplexitätsgrad ist für PaaS-Anwendungsfälle angemessen, es handelt sich jedoch höchstwahrscheinlich um unnötige Komplexität für Ihre On-Platform-Lösungsarchitekturen (siehe: [Lesbarkeitsantimuster](/docs/architect/de-de/well-architected/guide/intentional#lesbarkeitsmuster-und-antimuster)). Konzentrieren Sie sich auf die Definition eines klaren Zwecks für eine API (z. B. Fehlerbehandlung) und klare Basisdefinitionen. Ziel ist es, nur über eine Version jeder API zu verfügen. - **Machen Sie Ihre APIs auffindbar, zugänglich und verwaltbar**. [Dokumentieren Sie Ihre APIs](/docs/architect/de-de/well-architected/guide/intentional#design-standards), damit potenzielle Verbraucher ohne Weiteres die verfügbaren APIs finden, die mit ihnen verbunden sind. APIs müssen als Teil einer [Funktionslandschaft](/docs/architect/de-de/well-architected/guide/composable#funktionale-einheiten) reibungslos funktionieren. - **Seien Sie iterativ**. Konzentrieren Sie sich darauf, jeweils nur eine interne API zu definieren und zu implementieren. Auf diese Weise können Sie sich darauf konzentrieren, die API-Definition schnell zu wiederholen, das richtige Formular für Ihre _eine_ unterstützte Version zu finden und bewährte Vorgehensweisen aus der Implementierungserfahrung zu erstellen. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/composable#interoperabilitätsmuster-und-antimuster) zeigt, wie eine ordnungsgemäße (und schlechte) API-Verwaltung in einer Salesforce-Lösung aussieht. Sie können diese verwenden, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu den von Salesforce verfügbaren Tools, mit denen Sie mehr Interoperabilität aufbauen können, finden Sie unter [Für Composable relevante Tools](/docs/architect/de-de/well-architected/guide/composable#für-composable-relevante-tools). ### Interoperabilitätsmuster und Antimuster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Interoperabilität im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/adaptable-interoperability) Anti-Muster.

	Muster	Anti-Muster
Messaging und Eventing	In Ihren Designstandards: - Es gibt klare Standards für die Verwendung synchroner Muster (Messaging) und asynchroner Muster (Abend) - Es gibt klare Standards für Ereignis- und Nachrichtenstrukturen	In Ihren Designstandards: - Designstandards sind nicht vorhanden oder es fehlen klare Standards für Synchronisierungs- vs. asynchrone Muster und klare Standards für Nachrichten- oder Ereignisstrukturen.
	In Ihrer Organisation: - Plattformereignisse, die für interne Systemnachrichten verwendet werden, sind eindeutig gekennzeichnet - Salesforce-Flow-Tools verweisen auf systemweite Messaging- oder Eventing-Services - Konsistente Messaging- und Ereignismuster werden in Flows und Code angezeigt	In Ihrer Organisation: - Plattformereignisse, die für interne Systemnachrichten verwendet werden, sind nicht eindeutig gekennzeichnet oder nicht vorhanden - Unterschiedliche Strategien für Messaging- und Eventing-Muster werden über Flow und Code hinweg angezeigt
	In Apex or LWC: - Benutzerdefinierte Ereignisdefinitionen sind im Umfang begrenzt (es werden keine systemweiten Ereignisse oder Nachrichten im Code definiert) - Systemweite Messaging- oder Eventing-Services in Apex sind so gekennzeichnet, dass sie in Salesforce-Flow-Tools verfügbar sind	In Apex or LWC: - Systemweite Nachrichten- und/oder Ereignisstrukturen werden in Apex oder JavaScript definiert - In Apex definierte systemweite Ereignis- oder Nachrichtenstrukturen sind in Tools wie Flow nicht verfügbar
API Management	In Ihren Designstandards: - Es gibt klare Protokolle für die komponentenübergreifende Kommunikation (d.h. APIs) - Protokolle/APIs werden in logischen Gruppen beschrieben, nach denen Ersteller suchen und suchen können - Protokolle/APIs definieren Variablendatentypen, Variablennamen, was erforderlich oder optional ist und bieten eine klare Beschreibung, wann die Verwendung erfolgen soll	In Ihren Designstandards: - Designstandards sind nicht vorhanden oder definieren keine APIs und Anwendungsfälle
	In Ihrer Dokumentation: - In der Dokumentation jeder Komponente ist klar aufgeführt, welches API/Kommunikationsprotokoll implementiert wurde - Es ist möglich, nach einer bestimmten API oder einem Protokoll zu suchen und Komponenten zu identifizieren, in denen es implementiert ist	In Ihrer Dokumentation: - Komponentendokumentation nicht vorhanden - In der Komponentendokumentation wird die in einer Komponente implementierte API beschrieben, aber nur dort wird die API-Definition angezeigt. - Es ist nicht möglich, nach einer bestimmten API oder einem bestimmten Protokoll zu suchen und/oder Suchvorgänge helfen nicht, Komponenten zu identifizieren, bei denen eine API oder ein Protokoll implementiert wurde
	In Ihrer Organisation: - API-Nachrichtenformate und Variablen für die interne Kommunikation werden mit benutzerdefinierten Metadatentypen definiert - API-Nachrichtenformate und Variablen für die interne Kommunikation werden mit Plattformereignissen definiert - Code und deklarative Anpassungen verweisen auf den entsprechenden benutzerdefinierten Metadatentyp (oder Plattformereignis), um Informationen zu senden oder zu empfangen	In Ihrer Organisation: - Die Kommunikation zwischen Komponenten des Systems (Code und deklarative Anpassungen) erfolgt ad hoc - APIs sind ausschließlich für die Kommunikation zwischen Salesforce und externen Systemen definiert

## Paketierbarkeit Durch das Erstellen der Paketierbarkeit in einer Salesforce-Organisation werden Funktionen in der Organisation aus Einheiten bereitgestellt, die unabhängig und zuverlässig als Pakete entwickelt und bereitgestellt werden können. Idealerweise sind diese Einheiten als Pakettyp der [zweiten Generation](https://developer.salesforce.com/docs/atlas.en-us.218.0.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_plan_pkg_types.htm) definiert (entweder als entsperrtes Paket oder als verwaltetes Paket für ISVs). Hinweis: Da gut konzipierte Lösungen ausschließlich diese Pakettypen verwenden, werden verwaltete Pakete der ersten Generation hier nicht abgedeckt. Es ist eine Sache, [Bedenkentrennungen](/docs/architect/de-de/well-architected/guide/composable#trennung-von-bedenken) zu definieren und Funktionseinheiten in einer Salesforce-Organisation zu erstellen. Es ist eine weitere Sache, Abhängigkeiten klar genug zu entwirren und zu verwalten, um diese Einheiten erfolgreich als Paketartefakte zu versionieren. Um diesen Grad an Stabilität und Metadatenisolation zu erreichen, ist ein erheblicher Grad an DevOps (und Architektur) erforderlich. Darüber hinaus wird die Entwicklungszeit beschleunigt, die Erfahrung im Anwendungsgenerator verbessert und die Vorhersagbarkeit und Kontrolle der Versionen und der Versionsverwaltung verbessert. Nicht jede Organisation kann die Infrastruktur unterstützen, die zum Definieren, Verwalten und Entwickeln effektiver Pakete erforderlich ist. Die Paketierbarkeit sollte jedoch für fast jede Salesforce-Organisation das oberste Ziel sein. Sie können die Paketierbarkeit in Ihren Salesforce-Lösungen erstellen, indem Sie sich auf die lose Kopplung und die Abhängigkeitsverwaltung konzentrieren. ### Lose Kupplung Bei einem System mit loser Kopplung sind Einzelstücke nicht fest miteinander verbunden. Viele Vorteile eines zusammengesetzten Systems ergeben sich aus der losen Kopplung. In paketfähigen Systemen können Sie durch die lose Kopplung zwischen Paketen (und die Installation von Organisationen) über gut definierte Pakete und produktivere Entwicklungszyklen für Teams verfügen, die mit Paketen arbeiten. Auf der Salesforce Platform können Sie Pakete erstellen, die [eng mit einer bestimmten Organisation](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_org_dependent.htm) verknüpft sind. Diese Funktion ist nützlich, um Funktionseinheiten zu definieren und mit der richtigen [Trennung von Bedenken](/docs/architect/de-de/well-architected/guide/composable#trennung-von-bedenken) in Ihrer Organisation zu experimentieren, während Sie die Paketerstellung vorantreiben. Wenn Sie sich für diesen Ansatz entscheiden, werden Sie jedoch einige der Vorteile wirklich paketfähiger Metadaten erkennen, einschließlich der quellgesteuerten Entwicklung, der Möglichkeit der Versionierung und der Artefaktstabilität. Stattdessen werden Sie wahrscheinlich weiterhin die Nachteile eines eng gekoppelten Systems erleben, einschließlich: - Einzelne Fehlerpunkte, die zu Ausfällen und Leistungsproblemen führen - Langsame, unvorhersehbare Bereitstellungen - Schwierige, komplexe Debugging- und Fehlerbehebungszyklen - Probleme mit [Skalierung](/docs/architect/de-de/well-architected/guide/reliable#skalierbarkeit) und [Leistung](/docs/architect/de-de/well-architected/guide/reliable#leistung) Das Endziel für jedes paketfähige Salesforce-System sind lose gekoppelte Pakete. Beachten Sie beim Trennen Ihrer Salesforce-Metadaten in effektive Pakete Folgendes: - **Welche Anpassungen sind Daten im Vergleich zu Metadaten**? In Bezug auf die Paketierbarkeit behandelt Salesforce Platform Daten und Metadaten sehr unterschiedlich. Es ist wichtig zu verstehen, welche Funktionen in Ihrer Organisation [Metadaten oder Daten](/docs/architect/de-de/fundamentals/guide/architecture-basics#metadaten-im-vergleich-zu-daten) sind. Sie können keine Daten in Paketeinheiten aufnehmen. Wenn Sie entscheiden, wo Sie mit der Abstraktion von Funktionen in einer Paketeinheit beginnen möchten, müssen Ihre Teams entscheiden, ob als Daten gespeicherte Anpassungen vollständig aus dem Paket ausgeschlossen oder in eine metadatenbasierte Implementierung refaktoriert werden sollen. - **Wie sich die Paketerstellung auf Teams auswirkt**. Eine logistische Realität der Salesforce-Paketerstellung besteht darin, dass für die Erstellung und Veröffentlichung einer Paketversion viel Geschick mit der Salesforce CLI und/oder der CI/CD-Technologie erforderlich ist. Das bedeutet, dass sowohl Low-Code- als auch programmgesteuerte Anpassungen Zeit und Aufmerksamkeit von jemandem erfordern, der in der Lage ist, mit paketbezogener DevOps-Technologie zu arbeiten. Je nachdem, wie Ihr Team die Funktionszustellung verwaltet, kann die Paketakzeptanz zu erheblichen Verzögerungen oder Blockaden für verschiedene Teams in einer Organisation führen. Sie müssen ermitteln, ob Teams die Funktionszustellung über die Paketerstellung verwalten können, und einen Plan erstellen, um Fertigkeits- oder Personallücken zu schließen. Zu den Lösungen zählen beispielsweise die Übernahme der Paarprogrammierung oder die Implementierung von CI/CD-Aufträgen für Entwicklungsumgebungen. - **Wie Paketerstellung Umweltstrategien verändern** wird. In einem paketgesteuerten Entwicklungslebenszyklus sollte in [Kratzorganisationen](https://developer.salesforce.com/docs/atlas.en-us.238.0.sfdx_setup.meta/sfdx_setup/sfdx_setup_next_steps.htm?q=scratch%20org) frühzeitig gearbeitet werden. Diese temporären, quellgesteuerten Entwicklungsumgebungen ermöglichen schnellere, iterativere Zyklen. Außerdem unterstützen sie genauere Zugriffssteuerungen für Umgebungen für Ihre Entwicklungsteams und eine bessere Isolation von der Produktion. Je mehr Abhängigkeiten Ihre Pakete von nicht im Paket enthaltenen Metadaten oder Daten aufweisen, die nur in einer Sandbox- oder Produktionsumgebung vorhanden sind, desto unwahrscheinlicher ist es, dass Teams Testorganisationen tatsächlich verwenden können. Sie können die Quellverfolgung [in Sandbox-Instanzen aktivieren](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_setup_enable_source_tracking_sandboxes.htm), um quellgesteuerte Entwicklungsmuster in Umgebungen zu ermöglichen, in denen es nicht um Testorganisationen geht. Ihre Entwicklungsteams profitieren jedoch nicht von der Geschwindigkeit und Iterationsgeschwindigkeit von Testorganisationen. - **Beziehung von Paketversionen zu Versionen**. Planen Sie, wie oft und in welcher Phase die Versionierung von Entwicklungspaketen erfolgen soll. Paketversionsanforderungen sind (pro Organisation) auf einer rollierenden 24-Stunden-Basis begrenzt. Als allgemeine bewährte Vorgehensweise sollten Sie ein Paket nur dann als Version verwenden, wenn Sie sicher sind, dass sich keiner der Paketinhalte ändern muss. Idealerweise stellen Sie Paketversionen nach Abschluss der Qualitätssicherungsprozesse bereit. Lassen Sie nicht zu, dass Entwicklungsteams den Erfolg oder Misserfolg von Paketerstellungsanforderungen als "Tests" dafür verwenden, wie gut sie Paketgrenzen definiert haben. Es gibt Möglichkeiten, dies zu tun, ohne zu versuchen, ein Paketartefakt zu versionieren. - **Was der ideale Endzustand unterstützen sollte**. Die ideale Paketerstellungsstrategie ermöglicht kontrollierte, stabile Salesforce-Versionen, die schnell entwickelt und bereitgestellt werden können. Wenn Sie zu viele Pakete in Ihrer gesamten Organisation definieren, kann dies zu neuen Komplexitäten und Engpässen für Entwicklungsteams führen. Eine zu modularisierte Organisation kann auch dazu führen, dass die Versionen langsam und schwierig sind. Beginnen Sie mit dem Erstellen und Veröffentlichen einiger Versionen eines einzelnen, aussagekräftigen Pakets. Leiten Sie Folgepakete inkrementell ab. Stellen Sie die Einführung von Paketen ein, wenn Sie über einen Versionsrhythmus verfügen, der Ihrem Unternehmen gut dient. Faktorpakete im Laufe der Zeit, wenn sich die Geschäftsanforderungen ändern oder die Versionsqualität sinkt. Der ideale Paketendzustand ist subjektiv. Unabhängig davon, wie Sie Ihre Pakete definieren, werden Sie ein lose gekoppeltes Paket nur durch effektive [Abhängigkeitsverwaltung](/docs/architect/de-de/well-architected/guide/composable#abhängigkeitsverwaltung) erfolgreich versionieren. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/composable#paketierbarkeitsmuster-und-anti-muster) zeigt, wie die ordnungsgemäße (und schlechte) lose Kopplung für Salesforce-Pakete aussieht. Sie können diese verwenden, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools, mit denen Sie mehr Paketierbarkeit erstellen können, finden Sie unter [Tools Relevant to Composable](/docs/architect/de-de/well-architected/guide/composable#für-composable-relevante-tools) (Für Composable relevante Tools). ### Abhängigkeitsverwaltung Im Kontext einer Salesforce-Lösung bedeutet Abhängigkeitsverwaltung, die Beziehungen zwischen den Metadaten in Ihren Paketen und den Metadaten in den Organisationen zu identifizieren und zu strukturieren, in denen diese Pakete installiert werden. Die Abhängigkeitsverwaltung ist ein wichtiger Bestandteil der Entwicklung stabiler Paketartefakte. Abhängigkeiten stehen möglicherweise im Widerspruch zu Bemühungen, perfekt getrennte, [lose gekoppelte](/docs/architect/de-de/well-architected/guide/composable#lose-kupplung) Funktionseinheiten zu erstellen. Im idealen Engineering-Zustand weist ein lose gekoppeltes System keine Abhängigkeiten zwischen Einheiten auf. In der realen Welt ist es jedoch nicht sinnvoll, alle Abhängigkeiten zu beseitigen. Oftmals erfordert die Balance zwischen der [Lesbarkeit](/docs/architect/de-de/well-architected/guide/intentional#lesbarkeit) von Systemen und der Verwendung geschäftsfreundlicher [Funktionseinheiten](/docs/architect/de-de/well-architected/guide/composable#funktionale-einheiten) einen Kompromiss in Bezug auf eine perfekte Isolierung zwischen den Einheiten in einem System. Pragmatischer ausgedrückt: Die von der [Standardfunktionalität](/docs/architect/de-de/well-architected/guide/intentional#standard--und-benutzerdefinierte-funktionen) der Salesforce Platform bereitgestellten Kernservices schaffen wichtige nettopositive Abhängigkeiten für jede Salesforce-Lösung. Viele integrierte Skalierbarkeits-, Leistungs- und Sicherheitsvorteile ergeben sich daraus, wie tief sie in die Plattform integriert sind. Beim Entwerfen von paketfähigen Salesforce-Lösungen sollten Sie beachten, dass Paketabhängigkeiten nicht von Natur aus schlecht sind. Schlechte Abhängigkeitsverwaltung _ist_ schlecht. Eine effektive Abhängigkeitsverwaltung mit Salesforce-Paketerstellung bedeutet, dass Entwicklungs- und Wartungsteams folgende Möglichkeiten haben: - Schnelleres Onboarding in neue Projekte und eingeschränkter Umgebungszugriff - Schnelles Entwickeln und Testen von Änderungen - Verstehen, wie komplexe Funktionen in kleineren, spezifischen Verpflichtungen bereitgestellt werden sollten - Steuern von Versionsrhythmen und Reduzieren von Systemwartungs-/Versionsausfallfenstern - Prognostizierbares Wiederherstellen negativer Änderungen in jeder Umgebung Die Techniken für die Abhängigkeitsverwaltung mit Salesforce sind ziemlich einfach: - Verwenden Sie [Messaging und Eventing](/docs/architect/de-de/well-architected/guide/composable#messaging-und-eventing), um anmutige Übergaben von zustandsbasierten oder zustandslosen Informationen zwischen Komponenten zu verarbeiten. - Verwenden Sie benutzerdefinierte Metadatentypen, um dynamische Laufzeitinformationen bereitzustellen und Abhängigkeitsinjektionsmuster zu unterstützen. - Lassen Sie Apex Entwickler [abstrakte oder virtuelle Klassen](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_extending.htm) verwenden. Am Ende müssen Sie entscheiden, welche Designmuster in Ihrer Organisation bei der deklarativen und programmgesteuerten Entwicklung zulässig sind. Die wichtigsten Überlegungen (architektonisch) sind, zu definieren, wo Sie mehr technische Komplexität hinzufügen möchten, um weniger Abhängigkeiten zu haben, und wo Sie mehr Abhängigkeiten tolerieren müssen, um Workflows im Anwendungsgenerator zu vereinfachen. Beachten Sie beim Erstellen von Abhängigkeitsverwaltungsstrategien in Ihren Paketen die beiden primären Organisationsprinzipien für Paketeinheiten: horizontal und vertikal. - **Horizontale Grenzen**. In horizontalen Paradigmen werden Funktionen, die von mehreren Paketen benötigt werden, in eine horizontale Ebene abstrahiert. Horizontale Ebenen werden dann zur Quelle allgemeiner Funktionen und der Zugriff erfolgt über eine deklarierte Abhängigkeit. Die Minimierung redundanter Funktionen über Pakete hinweg wird der Minimierung von Abhängigkeiten vorgezogen. - **Vertikale Grenzen**. Vertikale Paradigmen maximieren die Isolation und lockere Kopplung zwischen Teilen des Systems. Die freigegebenen Funktionen sind eingeschränkt und ähnliche Arbeiten werden möglicherweise einheitenübergreifend angezeigt. Abhängigkeiten sind streng begrenzt, um die Isolation zwischen Paketeinheiten zu maximieren. Beachten Sie, dass dies keine Entweder-oder-Entscheidung ist. Sie können vertikale und horizontale Paradigmen nach Bedarf kombinieren. Häufig besteht der schnellste Weg, mit einem Paket zu beginnen, darin, horizontale Serviceebenen zu erstellen. Wenn die Skalierung und Komplexität Ihrer Paketakzeptanz wächst, können Sie durch Abstraktion weiterer vertikaler Einheiten Setup-Prozesse für komplexe Umgebungen oder die Einarbeitung von Entwicklern vereinfachen. Beispielsweise kann ein System mit zwei Funktionseinheiten (A und B) mit Paketabhängigkeiten strukturiert werden, die in vertikalen, horizontalen und vertikal-horizontalen Hybridparadigmen angeordnet sind.

Dies ist ein Diagramm, das zwei Pakete (A und B) zeigt, die so erstellt wurden, dass sie keine gemeinsamen Abhängigkeiten aufweisen (vertikaler Slice), die für viele gemeinsame Services (horizontal) und eine Kombination aus beiden (Hybrid) erstellt wurden.

Unabhängig vom Organisationsparadigma des Pakets, das Sie auswählen, sollten Sie einige Absolutwerte beachten: - **Duplizieren Sie Metadaten nicht paketübergreifend.** Metadaten, die von mehreren Paketen benötigt werden, sollten in ein oder mehrere Pakete abstrahiert werden, die als Abhängigkeiten deklariert sind. - **Nutzen Sie die integrierten Abhängigkeiten von Salesforce Platform-Metadaten.** Für Anwendungsgeneratoren bieten die integrierten Services der Salesforce Platform zahlreiche Funktionen, die schnell konfiguriert werden können. Viele dieser Services verfügen über integrierte Abhängigkeiten, die es schwierig machen, sie in Funktionseinheiten auf niedriger Ebene zu abstrahieren. Für einen bestimmten Metadatentyp müssen Sie verstehen, wo sie im [Spektrum der integrierten Abhängigkeiten](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail) liegen, und dieses Verständnis verwenden, um [Ihre Paketabhängigkeitsketten zu definieren](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2). Beginnen Sie nicht mit der Paketakzeptanz, indem Sie versuchen, die lose Kopplung in eine standardmäßige Plattformfunktion mit vielen integrierten Abhängigkeiten zu erzwingen. Dadurch wird die Komplexität (kein Wert) erhöht, wenn Sie Funktionen höherer Ordnung erreichen. Es ist auch eine andere Möglichkeit, in [standardmäßige und benutzerdefinierte](/docs/architect/de-de/well-architected/guide/intentional#standard--und-benutzerdefinierte-funktionen) [Antimuster](/docs/architect/de-de/well-architected/guide/intentional#wartungsmuster-und-antimuster) zu fallen. Paketmetadaten von unten (wenigste Abhängigkeiten) nach oben – und wiederholen sich im Laufe der Zeit. - **Beobachten Sie Ihre Abhängigkeitsketten**. Vermeiden Sie das Erstellen von Paketabhängigkeitsketten, bei denen Entwickler ihre Änderungen jederzeit in viele verschiedene Pakete aufteilen müssen. - **Überlegen Sie, was für die Quellcodeverwaltung sinnvoll ist.** Es gibt zwei grundlegende Möglichkeiten, Ihre Pakete in der Quellcodeverwaltung zu verwalten. Bei der ersten handelt es sich um ein einzelnes _Monorepository_ mit Paketen, die in Ordnern isoliert sind. Bei der zweiten handelt es sich um mehrere Repositorys, deren Pakete in ihren eigenen Repositorys isoliert sind. Die Verwaltung jeder Art von Quellstrategie ist langfristig komplex. Bei der Einarbeitung von Entwicklern sind vertikale Grenzen in mehreren Repository-Paradigmen effizienter. Horizontale Grenzen sind in einem Monorepo besser verständlich. Wieder können Sie Strategien mischen und abgleichen, während Ihre Architektur reift. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/composable#paketierbarkeitsmuster-und-anti-muster) zeigt, wie eine ordnungsgemäße (und schlechte) Abhängigkeitsverwaltung mit Salesforce-Paketen aussieht. Sie können diese verwenden, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools für die Abhängigkeitsverwaltung finden Sie unter [Tools Relevant to Composable](/docs/architect/de-de/well-architected/guide/composable#für-composable-relevante-tools) (Für Composable relevante Tools). ### Paketierbarkeitsmuster und Anti-Muster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Paketierbarkeit im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/adaptable-packageability) Anti-Muster.

	Muster	Anti-Muster
Loses Koppeln	In Ihren Designstandards: - Benennungskonventionen behandeln die Angabe von Paketeinheiten - Es ist möglich, eine Liste aller aktuell definierten Paketeinheiten (und zugehöriger Benennungskonventionen) zu suchen und zu finden - Es gibt Standards zum Vorschlagen von Paketeinheiten-Ergänzungen oder -Änderungen - (Optional) Alle genehmigten Anwendungsfälle für benutzerdefinierte Einstellungen sind klar aufgeführt (sofern vorhanden)	In Ihren Designstandards: - Designstandards sind nicht vorhanden oder betreffen keine Paketeinheiten und Anwendungsfälle
	In Ihrer Organisation: - Benutzerdefinierte Metadatentypen bieten dynamische Laufzeitinformationen für Code und deklarative Anpassungen - Es sind keine benutzerdefinierten Einstellungen vorhanden oder es sind nur wenige benutzerdefinierte Einstellungen vorhanden und keine sind mit Paketfunktionen verbunden - Es sind keine benutzerdefinierten Objekte vorhanden, um dynamische Laufzeitinformationen für Code oder deklarative Anpassungen bereitzustellen	In Ihrer Organisation: - Benutzerdefinierte Einstellungen werden verwendet - Benutzerdefinierte Objekte sind vorhanden, um dynamische Laufzeitinformationen für Code oder deklarative Anpassungen bereitzustellen - Benutzerdefinierte Metadatentypen werden nicht verwendet (oder werden nicht konsistent verwendet), um dynamische Laufzeitinformationen für Code und deklarative Anpassungen bereitzustellen
	In Apex: - Allgemeine Services und Boilerplate-Code werden mit abstrakten oder virtuellen Apex Klassen definiert - Von dynamischen Laufzeitinformationen abhängige Methoden verweisen auf entsprechende benutzerdefinierte Metadatentypen	In Apex: - Allgemeine Services und Boilerplate-Code sind nicht leicht von anderen Klassen zu unterscheiden - Interne Verweise über Klassen und Methoden hinweg sind schwer zu befolgen und inkonsistent in der gesamten Codebasis - Methoden verwenden keinen konsistenten Ansatz für den Zugriff auf dynamische Informationen, Laufzeitinformationen oder Methoden, die benutzerdefinierte Objekte nach Informationen zum Laufzeitverhalten abfragen, oder Codeverweise auf benutzerdefinierte Einstellungen
	In Quellcodeverwaltungs- und Entwicklungsumgebungen: - package.xml-Dateien werden nur in der frühen Phase oder Proof-of-Concept-Projektmanifesten angezeigt	In Quellcodeverwaltungs- und Entwicklungsumgebungen: - package.xml-Dateien werden zum Steuern von Metadatenbereitstellungen verwendet
	In Paketen: - Organisationsabhängige entsperrte Pakete werden nur für Experimente in der Frühphase oder zum Proof-of-Concept verwendet - Keine nicht verwalteten Pakete in Produktions- oder Sandbox-Instanzen definiert	In Paketen: - Alle Pakete sind organisationsabhängige entsperrte Pakete - Nicht verwaltete Pakete werden in Produktions- oder Sandbox-Instanzen definiert
Abhängigkeitsverwaltung	In Ihren Designstandards: - Standards zum Deklarieren von Abhängigkeiten vorhanden - Es gibt Standards zum Einbringen oder Ändern von Abhängigkeiten	In Ihren Designstandards: - Designstandards sind nicht vorhanden oder befassen sich nicht damit, wie Abhängigkeiten deklariert werden
	In der Quellcodeverwaltung: - Paketversionen für entsperrte Pakete verwenden Aliasing (`LATEST`), um Abhängigkeiten in `sfdx-project.json-`Manifesten zu deklarieren - Entwickler können Testorganisationen erstellen und Paketmetadaten erfolgreich über die Quellcodeverwaltung bereitstellen	In der Quellcodeverwaltung: - Paketversionen für entsperrte Pakete werden explizit (ohne `NEUES` Aliasing) in `sfdx-project.json`-Manifesten deklariert - Entwickler können nicht erfolgreich mit Testorganisationen mit Quellcodeverwaltung arbeiten
	In Ihren Paketen: - Keine Metadaten werden paketübergreifend dupliziert - Für die Paketentwicklung werden alle frühen Entwicklungsarbeiten in Testorganisationen durchgeführt	In Ihren Paketen: - Abhängigkeiten werden durch Duplizieren von Metadaten in verschiedenen Paketen umgangen - Die frühzeitige Paketentwicklung erfolgt in Entwickler-Sandbox-Instanzen oder die frühzeitige Paketentwicklung kann nicht in Testorganisationen erfolgen
	Siehe auch: Loses Koppeln

## Für Composable relevante Tools

Tool	Beschreibung	Trennung von Bedenken	Interoperabilität	Paketierbarkeit
Apex REST Web Services	Bereitstellen Ihrer Apex-Klassen und -Methoden für externe Anwendungen über REST		X
Apex SOAP-Webservices	Bereitstellen Ihrer Apex-Klassen und -Methoden für externe Anwendungen über SOAP		X
Datenerfassung ändern	Veröffentlichen von Änderungen an Salesforce-Datensätzen		X
Benutzerdefinierte Metadatentypen	Definieren wiederverwendbarer, anpassbarer, paketfähiger Funktionen			X
Dekorateure	Öffentliches Anzeigen von Funktionen oder Eigenschaften als Api	X	X
Dev Hub	Verwalten Sie Testorganisationen, Pakete der zweiten Generation und Einstein Funktionen.	X	X	X
Allgemeine Ereignisse (alt)*	Senden von benutzerdefinierten Ereignissen, die nicht an Salesforce-Datenänderungen gebunden sind		X
Lightning Data Service	Zwischenspeichern und Freigeben von Daten zwischen Komponenten	X	X
Metadata API	Bereitstellen von Anpassungen zwischen Salesforce-Umgebungen			X
Bericht zur Metadatenabdeckung	Bestimmen der unterstützten Metadatenabdeckung über mehrere Kanäle hinweg			X
MuleSoft Composer	Erstellen einer Prozessautomatisierung für Daten mithilfe von Klicks anstelle von Code		X
Ausgehende Nachrichten	Senden von Nachrichten an externe Endpunkte, wenn Feldwerte aktualisiert werden		X
Plattformereignisse	Senden sicherer und skalierbarer Nachrichten, die Ereignisdaten nahezu in Echtzeit enthalten		X
Pub/Sub API	Abonnieren von Plattformereignissen, Datenerfassung ändern oder Echtzeit-Ereignisüberwachung		X
PushTopic-Ereignisse (alt)*	Benachrichtigungen zu Änderungen an Sende- und Empfangsdaten, die mit einer benutzerdefinierten SOQL-Abfrage übereinstimmen		X
Salesforce CLI	Entwickeln und Erstellen von Automatisierungen bei der Arbeit mit Ihrer Salesforce-Organisation			X
Salesforce-Diagramme	Erstellen von Diagrammen zum Anzeigen von Geschäftsfunktionen und technischen Details	X
Salesforce-Erweiterungen für Visual Studio Code (erweitert)	Offizielle VS Code-Erweiterungen für die Salesforce-Entwicklung			X
Testorganisationen	Bereitstellen von Salesforce-Code und -Metadaten in einer Einwegorganisation			X
Verwaltete Pakete der zweiten Generation	Entwickeln und Verteilen von Anwendungen für AppExchange			X
Tooling-API	Erstellen von benutzerdefinierten Entwicklungstools oder -anwendungen für Lightning Platform-Anwendungen			X
Entsperrte Pakete	Organisieren von Metadaten, Erstellen von Paketen für eine Anwendung oder Erweitern einer AppExchange-Anwendung			X
* Salesforce wird PushTopic und allgemeine Ereignisse weiterhin im Rahmen der aktuellen Funktionsfunktionen unterstützen, plant jedoch keine weiteren Investitionen in diese Technologie.

## Für Composable relevante Ressourcen

Ressource	Beschreibung	Trennung von Bedenken	Interoperabilität	Paketierbarkeit
Primitive Betrachtung der digitalen Integration	Entwickeln einer gemeinsamen Sprache für Konnektivitätskonzepte		X
Anwenden von domänengesteuertem Design mit Salesforce	Ausrichten Ihrer Lösungen auf Geschäftsfunktionen	X
Bewährte Vorgehensweisen für Pakete der zweiten Generation	Grundlegendes zu 2GP-Paketerstellungsmustern und -praktiken			X
In verwalteten Paketen verfügbare Komponenten	Grundlegendes zu Metadatenkomponenten für verwaltete Pakete			X
Vorlage 'Designstandards'	Erstellen von Designstandards für Ihre Organisation	X	X	X
Entscheidungsleitfaden für ereignisgesteuerte Architektur	Vergleichen von ereignisgesteuerten Architekturmustern und -tools		X
Anti-Patterns für Ereignisse	Identifizieren von Anti-Patterns, die beim Verwenden von Ereignissen vermieden werden sollen		X
Entwerfen von nachrichtengesteuerten und ereignisgesteuerten APIs	Lesen Sie die Unterschiede in einem MuleSoft-Entwicklerhandbuch.	X	X
Informationen zum Framework für zu erledigende Aufträge	Erkunden von JTBD auf Trailhead	X
Verwalten des globalen Status in B2C Commerce	Einfaches Weitergeben von Daten zwischen Komponenten zum Beibehalten des Status	X
Messaging-Richtlinien	Kommunizieren relevanter Informationen und Schaffen von Momenten der Freude		X
Messaging-Typen	Verstehen verschiedener Messaging-Typen anhand der Art der Benutzerinteraktion		X
Metadatentypen	Grundlegendes zu den verschiedenen Metadatentypen in Ihrer Salesforce-Organisation	X		X
Benachrichtigungstypen für mobile Anwendungen	Grundlegendes zu Benachrichtigungstypen für mobile Salesforce-Anwendungen		X
Optimieren des Anzeigestatus	Beibehalten des Status auf einer Visualforce Seite	X
Salesforce Developer Experience (DX)	Verwalten und Entwickeln von Anwendungen auf der Lightning Platform	X	X	X
Nicht unterstützte Metadatentypen	Identifizieren von Komponenten, die in der Metadaten-API nicht verfügbar sind			X

Absichtlich
Intentionale Lösungen bieten sofortigen und langfristigen Geschäftswert. Intentionale Architekturen werden strategisch geplant und bereitgestellt, können effektiv gewartet werden und sind für Menschen leicht lesbar und verständlich.
Strategie	Wartbarkeit	Lesbarkeit
Priorisierung Roadmapping Governance	Standard vs Benutzerdefiniert Technische Schulden	Design Standards Dokumentation
Automatisiert
Automatisierte Lösungen ermöglichen es Unternehmen, ihre Arbeit schneller und skalierbarer zu erledigen. Eine gesunde Automatisierung reduziert den Zeitaufwand für sich wiederholende manuelle Aufgaben oder komplexe Dateneingaben.
Effizienz	Datenintegrität
Prozessdesign Betriebslogik KPIs	Datenverarbeitung Fehlerbehandlung
Interagieren
Ansprechende Lösungen begeistern Benutzer und steigern die Akzeptanz. "Architektur für Engagement" bedeutet, intuitive, hilfreiche Benutzererfahrungen zu schaffen.
Streamlined	Hilfreich
Anwendungskomplexität Formulare Formfaktor	Benachrichtigungen und Messaging Hilfestellung in der Anwendung Anerkennung und Belohnungen

> Lesen Sie [hier](/docs/architect/de-de/well-architected/guide/contributors) unsere Aktualisierungspläne. ## Einführung Systeme zeigen ansprechende Verhaltensweisen, indem sie es Personen erleichtern, auf Anwendungen zuzugreifen und sie zu verwenden, Benutzern das Gefühl geben, dass sie hochwertigere Arbeit erledigen, und sie dazu veranlassen, Anwendungen im System zu verwenden. Das Bereitstellen eines ansprechenden Verhaltens ist für das Unternehmen wichtig, da es direkt mit der Benutzerakzeptanz sowie der allgemeinen Mitarbeiter- und Kundenzufriedenheit korreliert. Interaktionsverhaltensweisen helfen auch, Supportanforderungen zu reduzieren und die Qualität der Funktionsanforderungen von Benutzern zu erhöhen. Eine der Herausforderungen bei der Erstellung ansprechender Verhaltensweisen besteht darin, dass sie sich nur anhand objektiver Kennzahlen messen lassen. Stattdessen wird sie an den subjektiven Erfahrungen der Benutzer gemessen. Benutzer sind der Meinung, dass ansprechende Anwendungen echten Wert bieten. Auf ansprechende Anwendungen kann [zugegriffen](/docs/architect/de-de/well-architected/guide/compliant#barrierefreiheit) werden, sie sind nicht aufdringlich und leicht verständlich. Sie erfordern ein Minimum an Einarbeitung und Schulung. Außerdem verwenden sie klare Methoden, um Benutzerfehler proaktiv zu verhindern. Eine weitere Herausforderung besteht darin, dass die Engagementziele oft mit den verschiedenen Arten von Benutzerinteraktionen in Ihrem System variieren. Beispielsweise können Sie über eine Reihe von Zielen für interne Benutzer verfügen, die Kundenvorgänge verwalten, und eine andere für externe Benutzer, die Informationen über ein Formular auf Ihrer Website senden. Wenn Sie ansprechende Systeme entwerfen möchten, müssen Sie sorgfältig überlegen, welche Art von Engagements Sie erstellen möchten und warum Benutzer interagieren möchten, bevor Sie mit der Zusammenstellung von Funktionen und Seiten beginnen. Durch die Zusammenarbeit mit Benutzererfahrungs-Designern (UX) können Sie bei der Bereitstellung ansprechender Anwendungen viel effektivere Entscheidungen treffen. Aus architektonischer Sicht sind Akzeptanz und Bindung von Benutzern wichtige Komponenten eines gesunden Systems. Durch ansprechende Architekturen wird die Wahrscheinlichkeit von Datenqualitätsproblemen reduziert, die dadurch verursacht werden, dass Benutzer Prozesse schnell durchlaufen oder Schritte überspringen, um Zeit in einem System verbringen zu müssen, das ihnen nicht gefällt. Bei externen Systemen kann eine ansprechende Architektur den Umsatz und die Kundenbindung erhöhen, da Kunden, die Ihre Systeme einfacher verwenden können, sich für mehr Geschäfte mit Ihrer Organisation entscheiden. Sie können ansprechendere Anwendungen erstellen, indem Sie sich auf die Bereitstellung optimierter und hilfreicher Erfahrungen konzentrieren. ## Streamlined Optimierte Anwendungen sind einfach zu navigieren, stellen Informationen und Dateneingabeaufgaben übersichtlich dar und passen sich an verschiedene Formfaktoren an. Optimierte Anwendungen weisen zudem Erfahrungsmuster auf, an die sich Benutzer in anderen häufig verwendeten Anwendungen gewöhnt haben. Beispielsweise wird in den meisten Webbrowsern "In neuer Registerkarte öffnen" als oberste Option angezeigt, wenn Benutzer mit der rechten Maustaste auf einen Link klicken. Eine optimierte Anwendung mit Registerkarten folgt demselben Muster. Die Auswirkungen ineffizienter Anwendungserfahrungen können weit über eine einzelne Anwendung hinausgehen. Schlechte Anwendungserfahrungen untergraben das Trust der Benutzer. Da mehr Arten von geschäftskritischen und kundenorientierten Anwendungen auf digitale Kanäle umsteigen, kann dies Unternehmen die Loyalität wichtiger Beteiligter kosten. Sie können Ihre Anwendungen besser optimieren, indem Sie bewusst an die Komplexität, das Formdesign und die Formfaktoren herangehen. ### Anwendungskomplexität Durch die Minimierung der Anwendungskomplexität werden Benutzern nur relevante Menüelemente, Registerkarten und Navigationssteuerungen angezeigt. Sie müssen Zuordnungen zwischen Benutzergruppen, Benutzerberechtigungen und der richtigen Anwendungserfahrung erstellen. Verwenden Sie diese Zuordnungen, um nachzuvollziehen, welche Anwendungserfahrung einem bestimmten Benutzer angezeigt werden soll, und stellen Sie dann sicher, dass Ihre Anwendung über die logischen Steuerelemente verfügt, die zum Bereitstellen dieser Erfahrung erforderlich sind. Anwendungen, die Benutzern zu viel Komplexität bieten, können zu einer Vielzahl schlechter Erfahrungen führen: - Benutzern werden häufig unnötige oder irrelevante Registerkarten angezeigt, sie navigieren zu leeren Bildschirmen und es werden deaktivierte oder blockierte Links angezeigt. - Unnötige oder nicht hilfreiche Anweisungen wie "Diese Registerkarte ignorieren, wenn Ihre Rolle "X" lautet" werden in Schulungs- und Aktivierungsmaterialien angezeigt. - Überladene Navigationsmenüs zwingen Benutzer, zusätzliche Zeit damit zu verbringen, die Elemente zu finden, die sie benötigen, um ihre Arbeit zu erledigen. Diese schlechten Erfahrungen führen zu niedrigen Akzeptanzraten und Zufriedenheitswerten. Beachten Sie beim Bestimmen der richtigen Anwendungskomplexität Folgendes: - Organisieren Sie Menüs, Registerkarten und andere Navigationssteuerungen anhand der Priorität der Arbeit, die Benutzer erledigen müssen. - Vermeiden Sie die Einführung neuer Verhaltensweisen, die ein Benutzer nur lernen muss, damit er Ihre Anwendung verwenden kann. - Entfernen Sie nicht den Zugriff auf Funktionen, mit denen Benutzer Aspekte ihrer Benutzeroberfläche anpassen können. - Verwenden Sie Berechtigungssätze, um erweiterte oder reduzierte Navigationsoptionen bereitzustellen. - Vereinfachen Sie [die Aktivierungszuweisungen](https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm) für Lightning-Seiten. Minimieren Sie die Anzahl der aktiven Lightning-Seiten pro Anwendung. Verwenden Sie dynamische Formulare, Berechtigungssätze und bedingtes Rendering, um Lightning-Seiten in Ihrer Anwendung Elemente hinzuzufügen. Führen Sie dies aus, statt mehrere Lightning-Seiten zu verwalten, die aktiviert und nach Profil zugewiesen sind. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/engaging#optimierte-anwendungsmuster-und-anti-muster) zeigt, wie die ordnungsgemäße (und schlechte) Verwaltung der Anwendungskomplexität in einer Salesforce-Organisation aussieht. Sie können sie verwenden, um Ihre Anwendungsdesigns zu validieren oder zu verbessern. Weitere Informationen zu Salesforce-Tools, mit denen Sie die Komplexität von Anwendungen verwalten können, finden Sie unter [Interaktionsrelevante Tools](/docs/architect/de-de/well-architected/guide/engaging#für-die-interaktion-relevante-tools). ### Formulare Optimierte Formulare organisieren Informationen in logischen Sequenzen, unterstützen die schnelle Dateneingabe und minimieren erforderliche Schritte. Außerdem ermöglichen sie [hilfreiche](/docs/architect/de-de/well-architected/guide/engaging#hilfreich) clientseitige Datenvalidierungsmeldungen und vermeiden wiederholte Formularsendezyklen. Beachten Sie beim Entwerfen von Formularen Folgendes: - **Gruppieren Sie verwandte Felder**. Gruppieren Sie Felder, die sich auf denselben Schritt in einer Prozess- oder Dateneingabeaufgabe beziehen. Entfernen Sie Felder, die für die jeweilige Aufgabe nicht direkt relevant sind. - **Schieben Sie die Dateneingabe und -validierung frühzeitig**. Felder, für die Benutzer Daten eingeben müssen, sollten frühzeitig in Ihren Formularen angezeigt werden. Es empfiehlt sich, Probleme mit der Datenformatierung oder fehlende Daten so schnell wie möglich auf Feldebene zu erkennen (d. h. bevor ein Benutzer versucht, zum nächsten Schritt zu navigieren oder das Formular zu senden). Vermeiden Sie zudem die Anzeige von Fehlern auf Feldebene, bevor Benutzer Daten in die Felder eingeben konnten. - **Minimieren Sie Dateneingabeaufgaben**. Füllen Sie möglichst viele Felder voraus oder füllen Sie sie automatisch aus, um Fehler bei der Dateneingabe zu minimieren und die Effizienz zu steigern. Bitten Sie Benutzer nur, wichtige oder wichtige Daten einzugeben. Entfernen Sie alle Dateneingaben, die für den vorliegenden Geschäftsprozess nicht relevant sind. Verwenden Sie nach Möglichkeit Auswahllisten anstelle von Freiformtextfeldern, um die Auswahl gültiger Optionen zu erzwingen und Variationen derselben Antwort zu reduzieren. - **Minimieren Sie Einreichungen an den Server**. Formulare mit mehreren Schritten dürfen keine Daten mehrfach an den Server senden. Stellen Sie sicher, dass alle benutzerdefinierten [LWC-](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching) oder [Aura-](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_storable_actions.htm)Komponenten die clientseitige Zwischenspeicherung verwenden, um Navigations- oder Paginierungsaktionen zu verarbeiten. (Salesforce Lightning Experience und die mobile Salesforce-Anwendung verwenden standardmäßig die clientseitige Zwischenspeicherung.) Gestalten Sie Formulare so, dass Benutzer nur einmal Daten an den Server senden. Validieren Sie Benutzereingaben auf Client-Seite, bevor Formulare gesendet werden. Dadurch werden unerwünschte Benutzereinsendungen minimiert, doppelte oder schmutzige Transaktionen können die Bandbreite im Backend nicht verbrauchen und Sie können eine bessere [Datenverarbeitung](/docs/architect/de-de/well-architected/guide/automated#datenverarbeitung) planen. - **Formularstatus verwalten**. Die clientseitige Zwischenspeicherung hilft nicht nur bei Verhaltensweisen wie Navigation und Paginierung, sondern minimiert auch den Datenverlust aufgrund von Verbindungsproblemen. Die effektive Verwaltung des Status bedeutet auch, dass Anwendungen die Datenübermittlung an den Server angemessen orchestrieren und doppelte Transaktionen verhindern können. Außerdem können sie Benutzern basierend auf dem Status serverseitiger Aktionen relevante und zeitnahe Nachrichten präsentieren. Optimierte Formulare senden Datenvorgänge nur einmal und Benutzer müssen nicht auf den Abschluss langfristiger Vorgänge auf dem Server warten. - **Befolgen Sie Standards für** den barrierefreien Zugriff. Wenn Sie die Zielgruppe für Ihre Anwendungen maximieren und sicherstellen möchten, dass sie alle Ihre Kunden einbeziehen, erzwingen Sie Standards für den [Zugriff](/docs/architect/de-de/well-architected/guide/compliant#barrierefreiheit) in Ihren Formularentwürfen. Optimierte Formulare tragen dazu bei, die [Datenintegrität](/docs/architect/de-de/well-architected/guide/automated#datenintegrität) in Ihren Anwendungen zu erhöhen und die Benutzerfreundlichkeit Ihrer Anwendungen zu [erhöhen](/docs/architect/de-de/well-architected/guide/engaging#hilfreich). Außerdem können sie Support-Tickets und -Anforderungen reduzieren, da Benutzer Fehler besser beheben und den Status ihrer Formularsendungen klar nachvollziehen können. Darüber hinaus ermöglichen optimierte Formulare eine schnelle und effiziente Dateneingabe und stellen sicher, dass Benutzer nicht auf länger ausgeführte Prozesse warten müssen, um weitere Arbeit auszuführen. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/engaging#optimierte-anwendungsmuster-und-anti-muster) zeigt, wie das richtige (und schlechte) Formulardesign in einer Salesforce-Organisation aussieht. Sie können sie verwenden, um Ihre Formularentwürfe zu validieren oder zu verbessern. Weitere Informationen zu Salesforce-Tools, mit denen Sie optimierte Formulare erstellen können, finden Sie unter [Interaktionsrelevante Tools](/docs/architect/de-de/well-architected/guide/engaging#für-die-interaktion-relevante-tools). Genauere Anleitungen zur Auswahl des richtigen Formulartools für Ihren Anwendungsfall finden Sie im Decision Guide to Building Forms with Salesforce (Entscheidungsleitfaden zum Erstellen von Formularen mit [Salesforce)](/docs/architect/de-de/decision-guides/guide/build-forms#wichtige-takeaways). ### Formfaktor Ansprechende Anwendungen passen sich an verschiedene Geräte und Interaktionstypen oder Formfaktoren an. Je nach Gerätetyp werden verschiedene Arten von Benutzerinteraktionen einfacher (oder schwieriger) und die Lesbarkeit für Formulare und Felder ändert sich. Beachten Sie, dass sich der Formfaktor neben den Bildschirmdimensionen auch auf die Interaktion Ihrer Benutzer mit dem Bildschirm bezieht. Immer mehr Geräte verfügen nun über Touchscreens und einige Benutzer verwenden möglicherweise auch spezielle Geräte für den [Zugriff](/docs/architect/de-de/well-architected/guide/compliant#barrierefreiheit). Beachten Sie beim Entwerfen von Formularen die folgenden Faktoren. Wenn Formfaktorvariationen nicht berücksichtigt werden, kann dies zu einer Vielzahl von Problemen führen, darunter: - Schlechte Datenqualität - Nicht verwendbare Anwendungsoberflächen - Weitere Sitzungen zur Fehlerbehebung oder "Auftrag im Namen von" für Supportagenten - Schlechte Benutzerakzeptanz, geringe Anzahl aktiver Benutzer und hohe Raten an "Aufgeben" der Anwendung Beachten Sie Folgendes, um die Interoperabilität zwischen Formfaktoren in Ihren Salesforce-Anwendungen zu gestalten: - **Identifizieren Sie unterstützte Formfaktoren für jede Anwendung**. - **Identifizieren Sie Eingabemethoden und die Anforderungen an den barrierefreien Zugriff Ihrer Benutzer**. Weitere Informationen finden Sie unter [Barrierefreiheit](/docs/architect/de-de/well-architected/guide/compliant#barrierefreiheit). - **Verwenden Sie [Standardfunktionen](/docs/architect/de-de/well-architected/guide/intentional#standard--und-benutzerdefinierte-funktionen), um nach Möglichkeit geräteübergreifende Anpassungserfahrungen bereitzustellen.** - Von Salesforce bereitgestellte [Lightning Page-Vorlagen](https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5) unterstützen standardmäßig unterschiedliche Formfaktoren. Wenn Sie benutzerdefinierte Lightning-Seitenvorlagen mit Aura entwickeln, müssen Entwickler Formfaktorinformationen in die Komponenten-Designdatei integrieren. - Die von Salesforce bereitgestellten [Standardseitenkomponenten](https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5) verarbeiten das Rendering für alle unterstützten Formfaktoren. Wenn Sie benutzerdefinierte Komponenten mit LWC oder Aura erstellen, müssen Entwickler die Breitenwahrnehmung (es gibt Implementierungsunterschiede zwischen [Aura](https://developer.salesforce.com/docs/atlas.en-us.238.0.lightning.meta/lightning/components_config_for_app_builder_width_aware.htm?q=width) und [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_width_aware)) handhaben und die Formfaktorunterstützung in der Designdatei ihrer Komponenten angeben. - **Befolgen Sie die Anleitung für optimierte [Formulare auf allen Geräten](/docs/architect/de-de/well-architected/guide/engaging#formulare)**. - **Erstellen Sie Testpläne (und gute Tests) für wichtige Formfaktoren.** Idealerweise testen Sie alle Geräte und Formfaktoren für alle Ihre Anwendungen. Die Einrichtung der richtigen Geräte (oder Gerätesimulatoren) für Formfaktortests kann jedoch eine erhebliche Investition darstellen. Wenn Sie wissen, dass eine bestimmte Anwendung oder ein bestimmter Satz von Anwendungen über einen bedeutenden Satz an Benutzern auf Mobilgeräten oder Tablets verfügt, priorisieren Sie genaue Tests für diese Anwendungen auf Mobilgeräten und Tablets. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/engaging#optimierte-anwendungsmuster-und-anti-muster) zeigt, wie die richtige (und schlechte) Formfaktorwahrnehmung in einer Salesforce-Organisation aussieht. Sie können sie verwenden, um Ihre Designs vor dem Erstellen zu validieren oder Seiten zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools für die effektive Gestaltung von Formfaktoren finden Sie unter [Interaktionsrelevante Tools](/docs/architect/de-de/well-architected/guide/engaging#für-die-interaktion-relevante-tools). ### Optimierte Anwendungsmuster und Anti-Muster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für optimierte Anwendungen im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/easy-streamlined) Anti-Muster.

	Muster	Anti-Muster
Anwendungskomplexität	In Ihrer Organisation: - Anwendungen haben weniger als 10 Registerkarten in der vom Administrator bereitgestellten Standardkonfiguration - In keiner Anwendung ist "Personalisierung von Navigationselementen durch Endbenutzer in dieser Anwendung deaktivieren" auf true festgelegt	In Ihrer Organisation: - Anwendungen haben routinemäßig mehr als 10 Registerkarten in der vom Administrator bereitgestellten Standardkonfiguration - In vielen Anwendungen ist "Personalisierung von Navigationselementen durch Endbenutzer in dieser Anwendung deaktivieren" auf true festgelegt oder die Berechtigung zum Anpassen von Navigationselementen ist organisationsweit deaktiviert
Formulare	In Ihren Anwendungen: - Felder folgen logischen Gruppierungen - Dateneingabefelder werden zusammen in Gruppen von fünf oder weniger angezeigt - Dateneingabefehler sind eindeutig und werden auf Feldebene angezeigt, bevor Benutzer wegnavigieren oder Daten senden - Paginierungssteuerungen ermöglichen Bewegung zwischen Schritten - Die Datenübermittlung erfolgt einmal - Bezeichnungen für Aktionen und Navigation sind klar - Rechtzeitiges und visuelles Feedback zur Bestätigung von Benutzeraktionen wie Schaltflächenklicks - Navigationsschaltflächen (z. B. "Gehe", "Weiter" und "Zurück") werden einheitlich auf der gesamten Benutzeroberfläche platziert	In Ihren Anwendungen: - Dateneingabefelder werden nicht logisch gruppiert, was eine umfangreiche Kontextumschaltung durch Benutzer erfordert, die Formulare ausfüllen - Dateneingabefehler enthalten kryptische Informationen, die nur von jemandem interpretiert werden können, der die interne Funktionsweise des Systems versteht - Dateneingabefehler werden nur angezeigt, wenn auf die Schaltfläche "Senden" eines Formulars geklickt wird - Schritte und Gruppierungen sind nicht klar definiert, was die Navigation erschwert - Die Datenübermittlung erfolgt während des gesamten Dateneingabeprozesses mehrfach - Bezeichnungen für Aktionen und Navigation sind für Benutzer verwirrend, die mit der zugrunde liegenden Systemfunktion nicht vertraut sind - Visuelle Bestätigung von Benutzeraktionen wird nicht bereitgestellt - Navigationsschaltflächen werden an beliebigen Stellen auf der Benutzeroberfläche angezeigt
Formulare	In Ihrer Formularlogik: - Felder werden so weit wie möglich vorausgefüllt oder automatisch ausgefüllt - Benutzer müssen nicht warten, bis langfristige serverseitige Aktionen abgeschlossen sind - Benutzerdefinierte Komponenten verwenden `cacheable=true` für serverbasierte Aktionen ohne Datenvorgänge - Datenvorgänge werden einmal ausgeführt - In LWC verarbeiten `@wire`-Adapter alle Aktionen ohne Datenvorgänge	In Ihrer Formularlogik: - Felder, die vorausgefüllt oder automatisch ausgefüllt werden könnten, müssen manuell eingegeben werden - Benutzer müssen während des Einreichungsprozesses die Arbeit einstellen, um auf den Abschluss serverseitiger Aktionen zu warten - Benutzerdefinierte Komponenten `cacheable=false` festlegen
Formfaktor	In Ihrer Organisation: - Von Salesforce bereitgestellte Lightning-Seitenvorlagen werden für alle oder die meisten Seiten verwendet - Benutzerdefinierte Lightning-Seitenvorlagen verwenden `design:supportedFormFactors` und `design:supportedFormFactor` in Aura-Komponenten-Designdateien - Benutzerdefinierte LWC- oder Aura-Komponenten, die im Anwendungsgenerator verfügbar sind, deklarieren unterstützte Formfaktoren in ihren jeweiligen Designdateien und implementieren breitenbasierte Stilmuster	In Ihrer Organisation: - Classic ist noch aktiv - Benutzerdefinierte Lightning-Seitenvorlagen verwenden nicht einheitlich `design:supportedFormFactors` und `design:supportedFormFactor` in Aura-Komponenten-Designdateien - Benutzerdefinierte LWC- oder Aura-Komponenten, die im Anwendungsgenerator verfügbar sind, deklarieren nicht einheitlich unterstützte Formfaktoren in ihren jeweiligen Designdateien - In benutzerdefinierten LWC- oder Aura-Komponenten wird der breitenbasierte Stil nicht durch von Salesforce bereitgestellte Schnittstellen implementiert. - In benutzerdefinierten LWC- oder Aura-Komponenten wird der Stil für unterschiedliche Formfaktoren ausschließlich durch hartcodierte `px-` oder `%-`Werte in CSS gesteuert
	Auf dem Desktop: - Dateneingabefelder und Navigationssteuerungen passen auf den Bildschirm und können wie vorgesehen interagiert werden - Datensatz- und Anwendungsseiten werden basierend auf Zuweisungsregeln für die Seitenaktivierung richtig angezeigt	Auf dem Desktop: - Dateneingabefelder und Navigationssteuerungen werden nicht an ihren vorgesehenen Stellen auf dem Bildschirm angezeigt - Interaktionen mit Dateneingabefeldern und Navigationssteuerungen stimmen nicht mit dem erforderlichen Verhalten überein - Fehlende Zuweisungsregeln für die Seitenaktivierung bedeuten, dass allen Benutzern derselbe Datensatz und dieselben Anwendungsseiten angezeigt werden
	Auf Mobilgeräten und Tablets: - Dateneingaben und Navigationssteuerungen werden korrekt angezeigt - Benutzer können Daten einfach eingeben - Mobile Navigationsmenüs, optimiert für kleinere Formfaktoren, werden angezeigt - Kompakte Layouts werden auf Datensatzebene angezeigt	Auf Mobilgeräten und Tablets: - Dateneingaben und Navigationssteuerungen werden nicht konsistent oder richtig dargestellt - Benutzer können Daten nicht einfach eingeben - Mobile Navigationsmenüs sind nicht von der Desktop-Navigation zu unterscheiden - Kompakte Layouts werden nicht auf Datensatzebene konfiguriert

## Hilfreich Hilfreiche Anwendungen ermöglichen es Benutzern, sich stärker und effektiver zu fühlen, ohne Ablenkungen oder Unterbrechungen. Hilfreiche Anwendungen helfen, die [Datenintegrität](/docs/architect/de-de/well-architected/guide/automated#datenintegrität) aufrechtzuerhalten, indem sie manuelle Fehler minimieren und Benutzern Feedback geben, wann und wo sie es benötigen. Sie helfen Benutzern, zu verstehen, auf welche Aktionen sie sich jetzt und als Nächstes konzentrieren müssen, und bieten relevante Informationen, damit Benutzer ihre eigenen Probleme schneller lösen können. Sie stellen eine klare Verknüpfung zwischen den Aktionen eines Benutzers und aussagekräftigen Auswirkungen oder Erfolgen her. Sie können hilfreichere Anwendungen mit drei wichtigen Gewohnheiten erstellen: Benachrichtigungen und Nachrichten, Hilfestellung in der Anwendung sowie Anerkennung und Belohnungen. ### Benachrichtigungen und Nachrichten Mithilfe von Benachrichtigungen und Nachrichten bleiben Benutzer auf dem Laufenden. Ein gut konzipiertes Benachrichtigungs- und Messaging-System kann das Engagement und die Produktivität steigern, indem es Benutzern die Informationen bereitstellt, die sie benötigen, um wichtige Entscheidungen zeitnah zu treffen. Ein schlecht konzipiertes Benachrichtigungs- und Messaging-System – eines, das weder relevante noch aktuelle Nachrichten anzeigt – wird das Gegenteil bewirken. Interne Benutzer werden Benachrichtigungen schnell deaktivieren oder ignorieren, wodurch sie legitime Nachrichten verpassen, die wichtige Geschäftsprozesse beeinträchtigen können. Kunden oder andere externe Benutzer, die es satt haben, bedeutungslose Benachrichtigungen zu erhalten, können sich entscheiden, Ihre Systeme ganz zu verwenden. Beachten Sie bei der Entscheidung, wie Anwendungen das Senden von Benachrichtigungen und Nachrichten an Benutzer handhaben, Folgendes: - **Verwenden Sie bei Fehlern als letztes Mittel Benachrichtigungen und Meldungen.** Gestalten Sie die [Fehlerbehandlung](/docs/architect/de-de/well-architected/guide/automated#fehlerbehandlung) in Ihrem System mit Backend-Verarbeitung, die bestimmte Fehlertypen ohne menschliches Zutun korrigieren kann. Senden Sie Benutzern nur Nachrichten zu wichtigen Fehlern, die sie daran hindern, Aufgaben zu erledigen. Ebenso können Sie Geschäftsbenutzern nur Fehlermeldungen senden, wenn sie selbst Korrekturmaßnahmen ergreifen können (und müssen). Zusätzliche Fehlermeldungen oder Details können über Berichte zur Verfügung gestellt und/oder an Mitarbeiter des technischen Supports gesendet werden, indem asynchrone Methoden zur weiteren Nachverfolgung verwendet werden. - **Wählen Sie Nachrichtentypen basierend auf Relevanz, Dringlichkeit und Aktualität aus**. Unterschiedliche Nachrichtentypen weisen unterschiedliche Blockierungs- oder Unterbrechungsverhaltensstufen auf. Bei Benachrichtigungen handelt es sich um eine "blockierende" Art von Nachricht, da sie von Benutzern bestätigt werden müssen, bevor sie ihre Arbeit fortsetzen können. Wie bei Fehlermeldungen sollten Hinweise sparsam verwendet werden. Toast-Benachrichtigungen sind [nicht blockierend](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_toast), können unterschiedliche Persistenzverhaltensweisen aufweisen und verschiedene Arten von Nachrichtenanwendungsfällen unterstützen. Die am wenigsten aufdringlichen Nachrichten sind Benachrichtigungen [innerhalb der Anwendung](https://help.salesforce.com/s/articleView?id=sf.notif_builder.htm&type=5) oder E-Mails. Diese werden am besten verwendet, um Informationen bereitzustellen, mit denen Benutzer wann und wie sie möchten umgehen können. - **Überlegen Sie, was als Nächstes geschehen muss**. Einige Benachrichtigungen sind zwar informativ (z. B. Erfolgsmeldungen), bei anderen müssen Benutzer jedoch möglicherweise eine bestimmte Aktion ausführen. Beachten Sie beim Entwerfen von Benachrichtigungen nicht nur die Benachrichtigung selbst, sondern auch alle zusätzlichen Informationen, die ein Benutzer möglicherweise ergreifen muss. Fügen Sie in allen handlungsrelevanten Benachrichtigungen klare Anweisungen oder Links dazu ein, wo Benutzer zusätzliche Informationen finden oder Folgeschritte ausführen können. - **Konzentrieren Sie sich auf Lesbarkeit**. Stellen Sie sicher, dass Sie den Zweck jeder Benachrichtigung und die nächsten Schritte, die ein Benutzer als Reaktion ausführen muss, klar kommunizieren. Nachrichten sollten für Geschäftsbenutzer verständlich sein, die nicht mit der inneren Funktionsweise der zugrunde liegenden Systeme vertraut sind. Befolgen Sie beim Erstellen von Nachrichten die [Standards für den barrierefreien](/docs/architect/de-de/well-architected/guide/compliant#barrierefreiheit) Zugriff und stellen Sie sicher, dass sie lokalisiert sind, um Benutzer in den Regionen zu unterstützen, in denen sie möglicherweise angezeigt werden. Fügen Sie Muster für die Verwendung von Benachrichtigungen oder verschiedenen Fehlertypen in Ihre [Designstandards](/docs/architect/de-de/well-architected/guide/intentional#design-standards) ein, um sicherzustellen, dass Anwendungsgeneratoren konsistente Vorgehensweisen einhalten. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/engaging#hilfreiche-anwendungsmuster-und-anti-muster) zeigt, wie ordnungsgemäße (und schlechte) Benachrichtigungen und Nachrichten in einer Salesforce-Organisation aussehen. Sie können sie verwenden, um Ihre Designs vor dem Erstellen zu validieren oder Nutzungen zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools für Benachrichtigungen und Messaging finden Sie unter [Interaktionsrelevante Tools](/docs/architect/de-de/well-architected/guide/engaging#für-die-interaktion-relevante-tools). ### Hilfestellung in der Anwendung Die Hilfestellung in der Anwendung kann eine leistungsstarke Möglichkeit sein, komplexe Workflows zu entmystifizieren (obwohl Sie sicherstellen sollten, dass Sie sie zuerst [optimiert](/docs/architect/de-de/well-architected/guide/automated#prozessdesign) haben) oder neue Mitarbeiter einzuarbeiten. Dies kann eine großartige Möglichkeit sein, Prozessänderungen einzuführen, neue Funktionen hervorzuheben oder Schulungen automatisiert und skalierbar zu verteilen. Wenn sie jedoch nicht sorgfältig implementiert wird, kann die Hilfestellung in der Anwendung überbeansprucht werden. Häufige Popups oder Benachrichtigungen können zu enormen Störungen und Unterbrechungen für Benutzer führen, was zu Produktivitätseinbußen führt. Die Hilfestellung in der Anwendung kann auch zu wenig genutzt werden, was zu umständlicheren Versions- und Änderungsverwaltungsprozessen führt (insbesondere bei einfachen Funktionen). Letztlich führen sowohl die Über- als auch die Unternutzung der Hilfestellung in der Anwendung zu einer Reihe von Problemen, die Risiken für das Unternehmen darstellen, darunter: - Geringere Datenintegrität - Erhöhte Benutzerfehler - Höhere Benutzerfrustration und geringere Benutzerzufriedenheit - Geringere Benutzerproduktivität Beachten Sie, dass Sie die Hilfestellung in der Anwendung in verschiedenen Szenarien möglicherweise anders verwenden möchten, da die Denkweise eines Benutzers vorgibt, wie viel Hilfestellung "zu viel" oder "nicht genug" ist. Benutzer, die zum ersten Mal in ein neues System eingeführt werden, benötigen wahrscheinlich häufiger Nachrichten als Benutzer, die sich lediglich mit einer neuen Funktion in einem ihnen bereits vertrauten System vertraut machen. Im Folgenden finden Sie einige Schlüssel zum Erstellen einer effektiven Hilfestellung in der Anwendung: - **Entwickeln Sie Designstandards**. Beachten Sie, dass eine übermäßige Exposition gegenüber Hilfestellung in der Anwendung dazu führen kann, dass Benutzer Nachrichten routinemäßig verwerfen oder ignorieren. An diesem Punkt wird die Hilfestellung in der Anwendung zu einem Ärgernis und nicht zu einer Ressource. Definieren Sie [Designstandards](/docs/architect/de-de/well-architected/guide/intentional#design-standards), um klarzustellen, wann Eingabeaufforderungen, schrittweise Anleitungen, Hilfetext auf Feldebene, Validierungsmeldungen, Pfade, Bildschirm-Flows usw. verwendet werden sollen. - **Erstellen Sie ein Priorisierungssystem für Anleitungsimplementierungen**. Nicht jeder Anwendungsfall für die Hilfestellung in der Anwendung sollte implementiert werden. Ziehen Sie stattdessen die folgenden Fragen in Betracht, die priorisiert werden sollten. Wo können Sie einfach bessere Feldnamen, explizitere Bezeichnungen für Schaltflächen, besseres [Formulardesign](/docs/architect/de-de/well-architected/guide/engaging#formulare) und [Prozessoptimierung](/docs/architect/de-de/well-architected/guide/automated#prozessdesign) verwenden, um intuitivere Workflows zu erstellen? Wo können Sie einem Pfad hilfreicheren Text oder Links hinzufügen? Welche [Auswirkungen auf die Geschäftskosten](/docs/architect/de-de/resources/guide/kpi-spreadsheet-template) hat die Hilfestellung in der Anwendung? Wie oft möchten Sie Ihren Benutzern Nachrichten zustellen? Stellen Sie außerdem sicher, dass alle Implementierungen in Ihrer [Roadmap](/docs/architect/de-de/well-architected/guide/intentional#roadmapping) enthalten sind, damit alle Beteiligten sichtbar sind. - **Zuordnen von Benutzern zur aktiven (und vorgeschlagenen) Hilfestellung in der Anwendung** Durch die Zuordnung von Benutzern zur Hilfestellung in der Anwendung können Sie "Hilfsbereitschaftsüberlastung" erkennen und verhindern, da Benutzern zu viele Hilfestellungen in der Anwendung angezeigt werden. Oft ist dies das Ergebnis einer isolierten Entwicklung, da Teams zu eng über ihren jeweiligen Anwendungsfall nachdenken. Die Beibehaltung einer ganzheitlichen Sicht darauf, was Benutzern angezeigt wird, ist besonders für große Organisationen wichtig. Die Aufnahme von Anleitungsimplementierungen in Ihre Roadmap kann ebenfalls hilfreich sein. - **Sammeln und nutzen Sie Feedback, um Verbesserungen vorzunehmen**. Überprüfen Sie Daten zur Nutzung der Hilfestellung in der Anwendung und verwenden Sie sie, um die Wirksamkeit von Bereitstellungen der Hilfestellung in der Anwendung zu beurteilen. Stellen Sie sicher, dass Sie Benutzern die Möglichkeit geben, auch offenes Feedback zu geben, um Anleitungserstellern zu helfen. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/engaging#hilfreiche-anwendungsmuster-und-anti-muster) zeigt, wie eine ordnungsgemäße (und schlechte) Hilfestellung in der Anwendung in einer Salesforce-Organisation aussieht. Sie können sie verwenden, um Designs vor dem Erstellen zu validieren und Implementierungen zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools für die Hilfestellung in der Anwendung finden Sie unter [Interaktionsrelevante Tools](/docs/architect/de-de/well-architected/guide/engaging#für-die-interaktion-relevante-tools). ### Anerkennung und Belohnungen Durch die Integration von Anerkennung und Belohnungen in eine Anwendung fühlen sich Einzelpersonen, die diese Anwendung verwenden, besser mit den Auswirkungen ihrer Arbeit verbunden und können den Wert ihrer Beiträge, Produktivität und Leistung besser nachvollziehen. Es ist auch eine leistungsstarke Möglichkeit, Loyalität und Engagement zu erschließen. Nicht für die Erkennung oder Belohnung von Anwendungserfahrungen zu entwerfen, kann zu einer Vielzahl von Problemen beitragen, einschließlich: - Benutzer, die Schwierigkeiten haben, ihren Fortschritt oder ihre Geschwindigkeit zu verstehen - Verwirrung über den Fortschritt bei Zielen oder nicht abgeschlossene Arbeit - Mehr unproduktive Benutzer, die keine Verbindung zwischen ihren Aufgaben und dem Gesamtbild sehen - Verschwendete Verwaltungszeit für manuelle Berichte zu Zielen auf niedriger Ebene Die Belohnung von Anwendungserfahrungen kann schwierig zu entwerfen und bereitzustellen sein, da sie von der Unternehmenskultur, den Richtlinien und Standards sowie dem Kontext und den Präferenzen einzelner Benutzer abhängen. Funktionen, mit denen Desktop-Benutzer Momente der Freude oder Wertschätzung spüren können, können für einen Benutzer auf Mobilgeräten oder für einen Benutzer, der versucht, in einem lauten, geschäftigen Home Office zu arbeiten, zu einer Nervensäge werden. Personen, die eine Anwendung verwenden, um mit Informationen zu arbeiten, die privat oder hochsensibel sind, schätzen die Kommunikation über Meilensteine in Form von Konfettifeiern oder Badges möglicherweise nicht. Ein verteiltes Vertriebsteam hingegen sieht in einer solchen Gamification möglicherweise eine angemessen lohnende Anwendungserfahrung. Letztlich können die von Ihnen ausgewählten Implementierungsmuster am besten durch die Zusammenarbeit mit Benutzererfahrungs-Designern in einem Team bestimmt werden. In Bezug auf die Architektur ist es wichtig zu ermitteln, wie und wo Anwendungen Funktionen implementieren können, mit denen sich Benutzer erkannt und belohnt fühlen. Es ist auch wichtig zu verstehen, wie und wo diese Funktionen die [Wiederverwendbarkeit](/docs/architect/de-de/well-architected/guide/composable) von Anwendungen verringern oder [einen echten Geschäftswert](/docs/architect/de-de/well-architected/guide/automated#geschäftswert) schaffen könnten. Im Folgenden finden Sie einige Fragen, die beim Auswerten der Anerkennung und Belohnungen in Salesforce-Anwendungen zu berücksichtigen sind: - **Wie und wo können Benutzer ihren eigenen Fortschritt sowie die Gesamtteamstatistiken anzeigen?** Berichte sind wichtig, enthalten jedoch häufig Zusammenfassungsdaten, die den Kontext der täglichen Arbeit übersehen können. Sie können ein Tool wie den Lightning-Anwendungsgenerator verwenden, um Diagramme oder Dashboards auf Datensatzbildschirmen im Kontext einer Anwendung einzubetten und Benutzern so zu helfen, ihre Auswirkungen oder Fortschritte während ihrer täglichen Aufgaben nachzuvollziehen. - **Wie sollen Benutzer erkannt werden?** Dies kann je nach Team oder individuellen Voreinstellungen variieren. In einigen Fällen möchten Supervisors möglicherweise Nachrichten über den Benutzerfortschritt anzeigen, damit sie für eine größere Gruppe freigegeben werden können. Anerkennung kann auch ein zusätzlicher Vorteil sein, um die Moral der Mitarbeiter zu verbessern. In anderen Fällen möchten Benutzer möglicherweise einfach nur über ihren Fortschritt bei einer bestimmten Aufgabe oder einem bestimmten Projekt informiert werden. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/engaging#hilfreiche-anwendungsmuster-und-anti-muster) zeigt, wie die ordnungsgemäße (und schlechte) Anerkennung und Belohnungen in einer Salesforce-Organisation aussehen. Sie können sie verwenden, um Designs vor dem Erstellen zu validieren und Implementierungen zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools für Anerkennung und Belohnungen finden Sie unter [Interaktionsrelevante Tools](/docs/architect/de-de/well-architected/guide/engaging#für-die-interaktion-relevante-tools). ### Hilfreiche Anwendungsmuster und Anti-Muster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für hilfreiche Anwendungen im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/easy-helpful) Anti-Muster.

	Muster	Anti-Muster
Benachrichtigungen und Nachrichten	Ihre Designstandards umfassen: - Genehmigte Anwendungsfälle für Benachrichtigungen, Toasts und Hinweise - Designmuster für Toast-Varianten und Benachrichtigungen - Designmuster für Fehlermeldungen	Wenn überhaupt Designstandards definiert sind, werden Fehler und Benachrichtigungen nicht berücksichtigt.
	In Ihrer Organisation: - Benachrichtigungen sind das vorherrschende Messaging-Format - Toast-Meldungen verwenden Varianten - Toast-Meldungen mit dem auf `sticky` gesetzten `Modus` sind nicht vorhanden - Hinweise werden selten oder gar nicht verwendet - Generative Antworten identifizieren immer verwendete Datenquellen - Bots identifizieren sich eindeutig vor der ersten Interaktion mit Benutzern - Haftungsausschlüsse für Risiken im Zusammenhang mit generativer AI werden Benutzern vor der ersten Interaktion angezeigt - AI-Haftungsausschlüsse sind in klarer und verständlicher Sprache für Benutzer	In Ihrer Organisation: - E-Mails sind das vorherrschende Messaging-Format - Es gibt keinen einheitlichen Ansatz für Nachrichtentypen - Toast-Meldungen verwenden nicht durchgängig Varianten - Toast-Meldungen mit dem auf `sticky` gesetzten `Modus` sind vorhanden - Hinweise werden ad hoc verwendet - Generative Antworten identifizieren keine verwendeten Datenquellen - Bots identifizieren sich nicht eindeutig vor der ersten Interaktion mit Benutzern - Benutzern werden keine Haftungsausschlüsse für generative AI-Risiken angezeigt - AI-Haftungsausschlüsse sind für Benutzer nicht in klarer und verständlicher Sprache
	In Ihren Anwendungen: - Es werden keine generativen Antworten direkt an Endbenutzer ohne menschliche Beteiligung gesendet	In Ihren Anwendungen: - Generative Antworten werden direkt an Endbenutzer gesendet, ohne dass es zu menschlichen Interaktionen kommt
Siehe auch: Fehlerbehandlung
Hilfestellung in der Anwendung	Ihre Designstandards und Dokumentationen umfassen Folgendes: - Genehmigte Anwendungsfälle für die Hilfestellung in der Anwendung - Designmuster für Eingabeaufforderungen und schrittweise Anleitungen - Eine klare Matrix von Benutzern, Anwendungen und aktiver Hilfestellung in der Anwendung	Wenn Designstandards und Dokumentation vorhanden sind, gilt Folgendes: - Keine Adressierung der Hilfestellung in der Anwendung - Fügen Sie keine übersichtliche Matrix hinzu, die Benutzer, Anwendungen und aktive Hilfestellung in der Anwendung anzeigt
Hilfestellung in der Anwendung	In Ihrer Organisation: - Die Einstellung für "Verzögerung zwischen Hilfestellung in der Anwendung" verwendet den Standardwert oder einen benutzerdefinierten Wert, der länger ist als der von Salesforce angegebene Standardzeitraum (24 Stunden). - Keine Anwendungen haben mehr als eine aktive schrittweise Anleitung - Keine schrittweisen Anleitungen haben die Einstellung "Anzeigezeiten", die höher als 10 ist - Es werden keine Eingabeaufforderungen für "Beliebige Seite, beliebige Anwendung" oder "Diese Seite, beliebige Anwendung" aktiviert	In Ihrer Organisation: - Die Einstellung für "Delay Between In-App Guidance" (Verzögerung zwischen Hilfestellung in der Anwendung) ist auf einen Zeitraum festgelegt, der kürzer ist als der von Salesforce angegebene Standardzeitraum (24 Stunden). - Anwendungen haben mehr als eine aktive schrittweise Anleitung - Viele schrittweise Anleitungen haben die Einstellung "Anzeigezeiten", die höher als 10 ist (und einige haben den maximalen Wert von 30). - Eingabeaufforderungen werden ad hoc aktiviert, viele mit der Einstellung "Beliebige Seite, beliebige Anwendung" oder "Diese Seite, beliebige Anwendung"
Anerkennung und Belohnungen	In Ihrer Organisation: - Anwendungen verwenden eingebettete Analysen, um Benutzern relevante Zielfortschritts- und Produktivitätsstatistiken anzuzeigen - Pfadfeiern werden nur mit Benutzereinwilligung aktiviert - Benachrichtigungen und Nachrichten enthalten die Benutzererkennung und berücksichtigen Benutzerpräferenzen bei der Gestaltung der Benachrichtigungen und Auslöser von Benachrichtigungen	In Ihrer Organisation: - Analysen zum Zielfortschritt und Produktivitätsstatistiken sind nur in Berichten oder Manager-Dashboards verfügbar - Pfadfeiern werden ohne Überprüfung der Benutzereinwilligung aktiviert - Benachrichtigungen und Messaging enthalten keine Benutzererkennung oder spiegeln die Präferenzen der Benutzer nicht wider und fühlen sich verrauscht oder ungeschickt an

## Für die Interaktion relevante Tools

Tool	Beschreibung	Streamlined	Hilfreich
Aktivieren Ihrer Lightning-Anwendungsseite	Seitenverfügbarkeit, Benennung, Sichtbarkeit und Positionierung verwalten	X
Akzeptanz-Dashboards	Anmeldeverlauf, Funktionsakzeptanz und Produktivität überprüfen	X	X
Warnung	Benachrichtigungen über Sitzungen beibehalten und ohne Benutzerinitiierung anzeigen		X
Clientseitige Zwischenspeicherung von Apex Methodenergebnissen	Auswerten der Leistung mit zwischengespeicherten clientseitigen Daten	X
Dynamische Formulare	Zeigen Sie Benutzern nur Pflichtfelder und Seitenabschnitte an	X
Engagementstatistiken	Überwachen der aktuellen Benutzeraktivität und Ergreifen von Maßnahmen nach Bedarf	X	X
Hilfestellung in der Anwendung <	Verwenden von Aufforderungen und schrittweisen Anleitungen für Schulungen und Einarbeitungen		X
Lernprogramme	Personalisieren von Benutzerlernerfahrungen		X
Lightning-Anwendungsgenerator	Erstellen von benutzerdefinierten mobilen und Lightning-Seiten ohne Code	X
Lightning Data Service	Zwischenspeichern und Freigeben von Daten zwischen Komponenten	X
Lightning Design System Validator für VS Code	Markup anhand von SLDS Richtlinien validieren	X	X
Lightning-Seitenvorlagen	Erstellen von Lightning-Seiten für unterschiedliche Formfaktoren	X
Nachschlagefilter	Filterwerte für Nachschlage-, Master-Detail- und hierarchische Beziehungen	X
Mehrere Währungen verwalten	Verwenden mehrerer Währungen in Transaktionen		X
Messaging <	Senden von SMS-, Facebook Messenger- oder WhatsApp-Nachrichten		X
Mobile Publisher	Erstellen mobiler Versionen von Lightning-Anwendungen und Experience Cloud-Sites	X
Mobile-Ready-Komponenten	Erstellen von Komponenten, die über mobile Erfahrungen hinweg gut funktionieren	X
Mehrsprachige Sites	Erstellen verschiedener Sprachversionen Ihrer Site	X	X
Benachrichtigungsgenerator	Erstellen von benutzerdefinierten Benachrichtigungen zum Darstellen von Informationen		X
Pfad	Benutzer durch Geschäftsprozesse führen und Erfolge feiern	X	X
Plattform-Cache	Verbessern der Leistung und Zuverlässigkeit beim Zwischenspeichern von Daten	X
Vorschau der Seiten der mobilen Anwendung im Lightning-Anwendungsgenerator	Vorschau von Datensatz- und Anwendungsseiten auf einem Mobilgerät	X
Prompt	Benachrichtigen von Benutzern über systembezogene Probleme und Aktualisierungen		X
Anerkennungs-Badges	Anerkennen und Feiern von Benutzerleistungen		X
Erkennung mit WDC	Fertigkeiten bestätigen und danken		X
Datensatztypen	Personalisieren von Geschäftsprozessen, Auswahllistenwerten und Seitenlayouts	X	X
Ansehensübersicht	Anerkennung von Teilnahme und Knowledge Sharing		X
Einschränkungsregeln	Verhindern, dass Benutzer auf Datensätze zugreifen, die unnötige Daten enthalten können	X
Standardseitenkomponenten	Grundlegendes zu Salesforce Lightning-Standardkomponenten	X
Übersetzungen	Verwalten von Übersetzungen für globale Benutzer	X	X
Validierungsregeln	Überprüfen, ob Daten vor dem Speichern bestimmte Standards erfüllen	X

## Für das Engagement relevante Ressourcen

Ressource	Beschreibung	Streamlined	Hilfreich
Architektenhandbuch zum Erstellen von Formularen	Auswerten von Überlegungen zum Formulardesign und Auswählen des besten Tools	X
Konfigurieren Ihrer Komponente für unterschiedliche Formfaktoren	Konfigurieren von Komponenten zum Rendern auf Desktops und Telefonen	X
Hilfeinhalt anpassen	Anpassen von Hilfeinhalten an Ihre individuelle Implementierung		X
Standardfeldwerte	Definieren von Standard-, dynamischen oder statischen Feldwerten	X
Gestaltungsrichtlinien	Erstellen von Benutzeroberflächen gemäß bewährten Vorgehensweisen	X	X
Vorlage 'Designstandards'	Erstellen von Designstandards für Ihre Organisation	X	X
Designtestfertigkeiten (Trailhead)	Planmethoden zum Validieren und Testen von Designs	X	X
Richtlinien für Feedback in der Anwendung	Überprüfen von Richtlinien zum Sammeln von Feedback aus Ihrem System	X	X
Statische Lightning Design System Android-Bibliothek	Erstellen nativer Android-Anwendungen mit dem Erscheinungsbild von Lightning-Seiten	X
Statische Lightning Design System iOS-Bibliothek	Erstellen nativer iOS-Anwendungen mit dem Erscheinungsbild von Lightning-Seiten	X
Messaging-Richtlinien	Kommunizieren relevanter Informationen und Schaffen von Momenten der Freude		X
Messaging-Typen	Grundlegendes zu den verschiedenen Messaging-Typen anhand der Benutzerinteraktion		X
Navigationsrichtlinien	Unterstützen von Benutzern beim Wechsel zwischen Seiten und bei der Positionierung in einer Anwendung	X
Testen auf Webzugriff (Trailhead)	Verwenden von automatisierten und manuellen Tests zur Gewährleistung des barrierefreien Zugriffs	X	X
Richtlinien für Benutzerengagement	Richtlinien für die Einarbeitung, Akzeptanz, Unterstützung und Lerninhalte überprüfen	X	X

## Teilen Sie uns Ihre Meinung mit Helfen Sie uns, Salesforce Well-Architected für Sie relevant zu halten. Nehmen Sie an unserer [Umfrage teil](https://sfdc.co/bxNtvh), um Feedback zu diesen Inhalten zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten. > Lesen Sie [hier](/docs/architect/de-de/well-architected/guide/contributors) unsere Aktualisierungspläne. ## Einführung Intentionale Lösungen bieten sofortigen und langfristigen Geschäftswert. Intentionale Architekturen werden strategisch geplant und bereitgestellt, können effektiv gewartet werden und sind für Menschen leicht lesbar und verständlich. Funktionen und Korrekturen werden priorisiert und auf eine Weise bereitgestellt, die für Beteiligte aus Wirtschaft und Technologie transparent ist. Durch technische Entscheidungen werden Implementierungen erstellt, mit denen Zustellungs- und Wartungsteams ohne zusätzliche Funktionen oder Komplikationen einfach arbeiten können. Intentionale Architekturen sind einfacher zu besitzen, zu pflegen und mit dem Unternehmen zu entwickeln, da sie klaren und konsistenten Implementierungsmustern folgen. Generatoren können Designs für neue Funktionen interpretieren und implementieren und Wartungsteams können die Dokumentation der implementierten Funktionen nachvollziehen. Sie können gezieltere Systeme erstellen, indem Sie sich auf drei Schlüsselbereiche konzentrieren: Strategie, Wartbarkeit und Lesbarkeit. ## Strategie Strategie in der Architektur bedeutet, dass Systeme durchdacht geplant und bereitgestellt werden. Das bedeutet, dass die Zustellungs- und Wartungsteams einen klaren Überblick über die heute und in Zukunft zu erledigende Arbeit haben und sich alle über das "Warum" der zu erledigenden Arbeit im Klaren sind. Das bedeutet, dass dringende Anforderungen effektiv und effizient bearbeitet werden können und die Beteiligten die Auswirkungen und Kompromisse von Anforderungen klar verstehen können. Sie können eine klarere Strategie in Ihre Architektur integrieren, indem Sie sich auf Priorisierung, Roadmapping und Governance konzentrieren. ### Priorisierung Priorisierung bedeutet, die Reihenfolge und den Umfang der von Ihnen zu erbringenden Arbeit zu planen. Die Priorisierung beinhaltet das Verständnis der tatsächlichen Auswirkungen von Ergebnissen auf das Unternehmen, die Auswertung dieser Auswirkungen im Vergleich zu anderen Arbeitsanforderungen und die Gesamt-Roadmap für Ihr Produkt oder Programm. Eine Möglichkeit, die Auswirkungen eines bestimmten Arbeitselements zu bewerten, besteht darin, sich die tatsächlichen Kosten oder den tatsächlichen Nutzen für das Unternehmen anzusehen. Nachdem Sie die [KPIs](/docs/architect/de-de/well-architected/guide/automated#kpis) für die Automatisierung identifiziert haben, können Sie ein [Arbeitsblatt zur Berechnung](/docs/architect/de-de/resources/guide/kpi-spreadsheet-template) der Geschäftsauswirkungen verwenden, um die Gesamtkosten oder den Nutzen der Implementierung zu bewerten. Diese Berechnungen können Ihnen helfen, die von Ihren Beteiligten zu erstellenden Automatisierungen in welcher Reihenfolge abzustimmen und zu übernehmen. Sie können Ihnen auch helfen, Automatisierungen zu identifizieren, die verschoben oder vermieden werden sollen. Weitere Informationen zum Identifizieren effektiver Arbeit finden Sie unter [Prozessdesign](/docs/architect/de-de/well-architected/guide/automated#prozessdesign). Durch die Einrichtung eines Priorisierungs-Frameworks für die Zustellung können Sie und Ihre Wartungsteams zudem die Erwartungen der Benutzer verwalten und sich an Ihre Roadmap halten. Zu den Überlegungen, die Sie für die Priorisierung verwenden können, zählen: - Geschäftsauswirkungen (Kosten/Nutzen) der Leistung - Erforderliche Menge an neuer Arbeit für die Leistung - Erforderlicher Arbeitsaufwand für die Wartung der Leistung Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/intentional#strategiemuster-und-antimuster) zeigt, wie eine ordnungsgemäße (und schlechte) Priorisierung in Bezug auf Salesforce-Arbeit aussieht. Sie können sie verwenden, um Ihre Implementierungspläne zu validieren, oder ermitteln, wo Sie Prioritäten vor dem Erstellen besser identifizieren müssen. Weitere Informationen zu den von Salesforce verfügbaren Tools zur Unterstützung bei der Priorisierung finden Sie unter [Tools Relevant to Intentional](/docs/architect/de-de/well-architected/guide/intentional#für-intentional-relevante-tools). ### Roadmapping Bei einer Roadmap handelt es sich um eine priorisierte, validierte und genau definierte Ansicht der zu erledigenden Aufgaben. Effektive Roadmaps bieten ein klares Bild der geschäftlichen und technologischen Auswirkungen der anstehenden Arbeit. Die Einbindung Ihrer geschäftlichen und technischen Beteiligten ist ein wichtiger Bestandteil der Roadmap. Mithilfe von Roadmaps können Sie Feedback und Buy-Ins zum Ansatz und zu den Ergebnissen erhalten, bevor Sie mit der Arbeit beginnen. Letztlich stimmen Roadmaps alle Beteiligten über das „Warum“ der anstehenden Arbeit ab. Wenn Ihr Team einen Rückstand verwendet, ist es wichtig zu wissen, dass Ihre Roadmap keine Zusammenfassung oder Liste der Elemente im Rückstand ist. Die Beziehung ist umgekehrt: Elemente sollen nur dann in den Rückstand aufgenommen werden, wenn sie eindeutig und glaubwürdig mit einem Liefergegenstand in Ihrer Roadmap verknüpft werden können. Hochwertige Roadmaps, die unter Beteiligung von Beteiligten erstellt wurden, bieten Zustellungs- und Wartungsteams einen klaren Überblick darüber, worauf sie sich konzentrieren sollten und wie sie Anforderungen priorisieren sollten, wodurch widersprüchliche Anforderungen einfacher zu sortieren und die Erwartungen der Beteiligten zu verwalten sind. Schlechte oder nicht vorhandene Straßenzuordnungen führen zu: - Unklarheit darüber, wann neue Funktionen verfügbar sein werden - Widersprüchliche Prioritäten unter Beteiligten - Eine Trennung zwischen den bereitgestellten Lösungen und der allgemeinen Organisationsvision - Schwierigkeiten beim Verständnis der laufenden Arbeit - Ungleichmäßige Arbeitslasten in Teams - Fehlende Transparenz in Beziehungen und Abhängigkeiten zwischen Arbeitselementen - Verzögerte Implementierungen aufgrund falsch verwalteter Abhängigkeiten Beteiligte benötigen oft Informationen, die auf ihre Rollen abgestimmt sind, um Entscheidungen treffen zu können. Zum Erstellen effektiver Roadmaps müssen Sie Ihre Zielgruppe und die Art der benötigten Informationen genau kennen. Roadmaps werden in zwei Stile unterteilt, um geschäftliche und technische Zielgruppen zu unterstützen. Jeder Stil enthält zwei Granularitätsebenen, um unterschiedliche Informationstypen zu unterstützen. Mithilfe von Geschäfts-Roadmaps können Beteiligte organisatorische Veränderungen planen, Wachstumschancen nutzen und hinsichtlich der Unternehmensziele auf dem Laufenden bleiben. Geschäfts-Roadmaps bieten auch eine Möglichkeit, sicherzustellen, dass die IT-Ausgaben mit der allgemeinen Geschäftsvision in Einklang stehen. - Erstellen Sie eine Roadmap für Geschäftsfunktionen, um den leitenden Beteiligten die Funktionen zu zeigen, die aktiviert werden. Diese Art von Roadmap enthält allgemeine Details zu den Funktionen selbst und dazu, wie sie mit den Geschäftszielen in Einklang gebracht werden, beispielsweise zur Steigerung der betrieblichen Effizienz oder zur Einführung einer neuen Produktlinie. - Erstellen Sie eine Roadmap für Geschäftsfunktionen, um eine bestimmte Funktion zu untersuchen und ihre unterstützenden Funktionen und Funktionen zu zeigen, wenn Sie Geschäftsbeteiligte bei der Ressourcenplanung, Budgetierung und Änderungsverwaltung unterstützen müssen. Technologie-Roadmaps helfen technischen Beteiligten bei der Budget- und Ressourcenzuteilungsplanung. Sie helfen Implementierungsteams auch, zu verstehen, wo ihre Projekte hinpassen, und so ein Gesamtbild zu erhalten und teamübergreifende Abhängigkeiten zu identifizieren. - Erstellen Sie eine Technologiesystem-Roadmap, um die spezifischen Systeme anzuzeigen, die implementiert werden, sowie alle Abhängigkeiten auf Systemebene. Dieser Roadmap-Typ zeigt allgemeine Systeminformationen und die Ausrichtung zwischen Systemen und Geschäftsfunktionen an. - Erstellen Sie eine Roadmap für Technologiekomponenten, um die spezifischen Komponenten eines Systems zu untersuchen, die bereitgestellt werden, um die Anforderungen an die Ressourcenplanung und -aktivierung zu erfüllen. Dieser Roadmap-Typ zeigt Informationen auf Komponentenebene und Implementierungsanforderungen an (z. B. deklarative Entwicklung, Pro-Code usw.). Stellen Sie sicher, dass Ihre Roadmaps realistische Zeitachsen enthalten. Ein häufiger Fehler besteht darin, nur die für die Implementierung eines Systems benötigte Zeit einzubeziehen, ohne auch die für die Durchführung der zugehörigen Aktivitäten benötigte Zeit zu berücksichtigen. Dies kann zu einer Überzuteilung der Mitglieder des Implementierungsteams und zu längeren als erwarteten Verzögerungen führen. Berücksichtigen Sie beim Erstellen einer Roadmap die Zeit, die benötigt wird, um Folgendes zu erledigen: - Dokumentation aller neuen und aktualisierten Funktionen - Wartung der vorhandenen Funktionen, die zur Unterstützung neuer Funktionen erforderlich sind - Aktualisierungen an verwandten Systemen, die zur Unterstützung von Integrationen erforderlich sind - Erhöhte Unterstützung durch Projektteams direkt nach der Liveschaltung - Testen, Schulung und Änderungsverwaltung Geschäfts- und Technologie-Roadmaps, die gut aufeinander abgestimmt sind, vermitteln eine ganzheitliche Sicht darauf, wann Funktionen live geschaltet werden und welche Technologie dahintersteckt. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/intentional#strategiemuster-und-antimuster) zeigt, wie richtige (und schlechte) Roadmaps für eine Salesforce-Organisation aussehen. Sie können sie verwenden, um Ihre Roadmapping-Strategie zu validieren oder zu verbessern. Weitere Informationen zu Salesforce-Tools, die Ihnen bei der Roadmapping helfen können, finden Sie unter [Tools Relevant to Intentional](/docs/architect/de-de/well-architected/guide/intentional#für-intentional-relevante-tools) (Für Intentional relevante Tools). ### Governance "Governance" ist die Struktur, die Sie verwenden, um die Priorisierung, Entscheidungsfindung und Änderungsverwaltung mit Ihren Beteiligten abzuwickeln. Governance macht deutlich, wie Entscheidungen getroffen und kommuniziert werden. Sie bietet konsistente Möglichkeiten für Feedback und Anfragen, in den Entscheidungsprozess einzutreten, und allen Beteiligten, den Status der Wartungs- und Entwicklungsarbeiten zu verstehen. Mithilfe von Governance können Freigabeverwaltungsprozesse klar und konsistent gestaltet werden und alle Teammitglieder können ihre Rollen und Verantwortlichkeiten nachvollziehen. Ohne eine ordnungsgemäße Unternehmensführung werden Teams mit einer Vielzahl von Problemen konfrontiert, darunter: - Anforderungen für sich überschneidende Funktionen und Funktionen gehen ad hoc ein - Implementierungsteams priorisieren "einfachere" Bemühungen oder Anfragen von einflussreicheren Beteiligten, ohne den Geschäftswert, Kompromisse oder allgemeine Organisationsziele angemessen zu berücksichtigen - Fehlende einheitliche Genehmigungs- und Überprüfungsprozesse - Inkonsistente Freigaberhythmen und -qualität - Hohe Defektraten, Überschreibungen, Konflikte und redundante Arbeit bei Entwicklungsarbeiten Das vielleicht deutlichste Zeichen dafür, dass ein System keine effektive Governance aufweist, sind langsame und umständliche Versionen. Es ist wichtig, zu erkennen, dass die Größe eines Governance-Systems kein Maß für dessen Wirksamkeit ist. Tatsächlich können komplexe Governance-Systeme (wie sie in vielen großen Unternehmen vorkommen) die Geschwindigkeit und Häufigkeit von Versionen drosseln. Bei guter Unternehmensführung geht es darum, dass fehlerhafte Anpassungen die frühen Phasen der Entwicklung nicht überstehen und gute Anpassungen vorhersehbar und konsistent in die Produktion gelangen. Zu oft sind die Bemühungen um die Regierungsführung reaktionär. Sie werden initiiert oder verdoppelt, wenn ein Problem, beispielsweise eine übermäßige technische Verschuldung, zu einem Geschäftsproblem wird. In vielen Fällen besteht die unglückliche Antwort darin, dass das Unternehmen die Entwicklungsbemühungen und -versionen sperrt, statt effektive [Designstandards](/docs/architect/de-de/resources/guide/design-standards-template) und eine Gebäudeautomatisierung zu erstellen, um diese Standards in Entwickler-Toolketten und Quellcodeverwaltungssystemen durchzusetzen. Fügen Sie beim Erstellen des Frameworks für Ihr Salesforce-Governance-System die folgenden Elemente hinzu und berücksichtigen Sie die folgenden zu beantwortenden Schlüsselfragen: - **Arbeitsanforderungen.** Wie können Benutzer nach Funktionen oder Funktionen fragen? Wie werden Fehler gemeldet? - **Priorisierung und Arbeitsplanung.** Wer entscheidet, welche Arbeitsanforderungen wichtig sind? Wie wird Arbeit eingegrenzt, priorisiert und akzeptiert oder abgezeichnet? - **Umgebungen und Versionsplanung.** Wie sieht die Umgebungspipeline für Entwicklung, Tests und Version aus? Wer macht was, um Zugriff bereitzustellen, zu aktualisieren und bereitzustellen? Wer kümmert sich um Bereitstellungen und Validierungen? Wie und wann werden Änderungen veröffentlicht? Wie handhaben Sie Bereitstellungen oder Umgebungen während eines Salesforce-Versionszyklus? (Weitere Informationen hierzu finden Sie unter [Anwendungslebenszyklus-Verwaltung](/docs/architect/de-de/well-architected/guide/resilient#anwendungslebenszyklus-verwaltung).) - **Serviceinhaberschaft und Produktionsunterstützung.** Wer unterstützt was? Wer kümmert sich um Probleme mit der Hotfix-Produktion? Wie werden diese Elemente getestet und veröffentlicht? Wer ist für die allgemeinen Sicherheitsstandards der Organisation verantwortlich? Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/intentional#strategiemuster-und-antimuster) zeigt, wie eine ordnungsgemäße (und schlechte) Verwaltung für eine Salesforce-Organisation aussieht. Sie können sie verwenden, um Ihre Governance-Strategie zu validieren oder zu verbessern. Weitere Informationen zu Salesforce-Tools, die für die Verwaltung verfügbar sind, finden Sie unter [Tools Relevant to Intentional](/docs/architect/de-de/well-architected/guide/intentional#für-intentional-relevante-tools). ### Strategiemuster und Antimuster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Strategie im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/easy-strategy) Anti-Muster.

	Muster	Anti-Muster
Priorisierung	In Ihrer Dokumentation: - Alle neuen Arbeitselemente weisen klare Geschäftswertkennzahlen auf (z. B. Umsatzsteigerungen, Kosteneinsparungen durch Prozessoptimierungen usw.) - Roadmaps zeigen Arbeit nach Geschäftswert priorisiert an	In Ihrer Dokumentation: - Geschäftswert, der mit Arbeit verbunden ist, ist unklar oder nicht vorhanden - Roadmaps sind nicht vorhanden
Priorisierung	Innerhalb Ihres Unternehmens: - Implementierungs- und Wartungskosten wurden für alle Arbeitselemente identifiziert - Anforderungen für Funktionen werden anhand der Geschäftsauswirkungen, der Menge der neu zu liefernden Arbeit und der Menge der zu wartenden Arbeit priorisiert	Innerhalb Ihres Unternehmens: - Die Kosten für die Implementierung und Wartung von Funktionen sind unklar - Anforderungen werden ad hoc oder first-in/first-out zugestellt
Roadmapping	Roadmaps: - Kommunizieren von Informationen, die auf Ihre Zielgruppe zugeschnitten sind (geschäftlich oder technisch) - Kommunizieren von Informationen auf der richtigen Detailebene - Start- und Enddatum anzeigen - Voraussetzungen und Abhängigkeiten anzeigen	Roadmaps (sofern vorhanden): - Werden als Projektstartmaterialien und nicht als Artefakte für die Zustellung verwendet - Helfen Sie nicht, Beteiligte und Bereitstellungsteams aufeinander abzustimmen - Mischen von Detailebenen (beispielsweise durch Einbeziehen von Systemen und Komponenten in dieselbe Roadmap) - Enthalten Informationen, die nicht auf ihre Zielgruppe zugeschnitten sind (z. B. Geschäftsfunktionen und Systeme innerhalb derselben Roadmap)
Roadmapping	Innerhalb Ihres Unternehmens: - Beteiligte verstehen das "Warum" von Arbeitselementen - Zustellungsteams wissen, wie Rückstandsposten mit längerfristigen Prioritäten verglichen werden - Teams wissen, wer was macht und wie Abhängigkeiten verwaltet werden - Arbeit ist beabsichtigt, auch wenn Prioritäten schnell geändert werden müssen	Innerhalb Ihres Unternehmens: - Arbeit wird von dem abgerufen, was sich im Rückstand befindet, und es gibt kein klares "Warum" - Teams haben Probleme, voneinander abhängige Arbeit zu koordinieren, und reproduzieren oft Arbeit, ohne es zu bemerken - Arbeit ist oft reaktiv - Beteiligte sind oft frustriert und verwirrt darüber, was getan wird, und wissen, wann neue Funktionen bereitgestellt werden
Governance	Innerhalb Ihres Unternehmens: - Benutzer können einfach Fehler melden und Funktionen anfordern - Der Priorisierungsprozess für Arbeitselemente ist dokumentiert und für alle Beteiligten transparent - Die Umweltstrategie ist klar dokumentiert und die Entwicklungsumgebungen stimmen mit der Dokumentation überein - Die Versionsplanung ist vorhersehbar und für alle Zustellungsteammitglieder transparent - Teammitglieder wissen, wer während des gesamten Anwendungslebenszyklus für was verantwortlich ist - Versionen sind für Benutzer und Zustellungs-/Wartungsteams klar - Produktionssupportprozesse sind klar und Hotfixes haben einen klaren Weg zur Produktion - Teams und Projekte verwenden nur für Geschäftszwecke genehmigte AI-Modelle	Innerhalb Ihres Unternehmens: - Fehlerberichte und Funktionsanforderungen sind ad hoc - Arbeitselemente haben keine eindeutige Priorisierung - Umgebungen werden ad hoc bereitgestellt und können nicht vorhersehbar aktualisiert werden. Entwickler verfügen oft nicht über die Umgebungen und den erforderlichen Zugriff - Versionen sind für Zustellungsteams und Benutzer nicht vorhersehbar - Teams wissen nicht, wer wofür verantwortlich ist - Hotfixes werden ad hoc behoben - Ihr Rückstand ist zu einer "Ideenbank" geworden, die veraltet und stagniert - Leitungsgremien fungieren als Helpdesk zur Fehlerbehebung bei Supportanfragen - Dokumentation ist nicht leicht zugänglich - Teams wählen AI-Modelle ad hoc aus

## Wartungsfähigkeit Die Wartbarkeit bedeutet, dass ein System in einem gesunden Zustand gehalten werden kann, indem neue Funktionen in das System eintreten und die technische Verschuldung regelmäßig und vorhersehbar aus dem System ausscheidet. Wartungsfähige Systeme ermöglichen es Ihren Teams, mit vorhersehbarer Geschwindigkeit und Qualität einen Mehrwert für Ihr Unternehmen zu schaffen. Die Wartbarkeit eines Systems hängt von mehreren Faktoren ab, darunter die Lesbarkeit, die lose Kopplung und die gründliche Teststrategie. Am wichtigsten ist, dass die Wartungsfähigkeit eines Systems von der Einfachheit seines Designs abhängt. In diesem Abschnitt werden Möglichkeiten zum Erstellen einfacherer Lösungsdesigns und zur Verbesserung der Wartungsfreundlichkeit beschrieben. Sie können Lösungen erstellen, die einfacher zu warten sind, indem Sie sich auf zwei Schlüssel konzentrieren: die Verwendung von standardmäßigen über benutzerdefinierte Funktionen und die Handhabung technischer Schulden. ### Standard- und benutzerdefinierte Funktionen Salesforce bietet eine Reihe vorgefertigter Lösungen – Sales Cloud, Service Cloud und viele Salesforce-Branchenlösungen – sowie die Flexibilität, Ihre eigenen benutzerdefinierten Lösungen zu erstellen. Die grundlegenden Services, die Salesforces eigene Cloud-Lösungen unterstützen, sind auch für alle benutzerdefinierten Lösungen verfügbar, die auf Salesforce Customer 360 Platform basieren. Verwenden Sie die vorgefertigten Services und Lösungen von Salesforce als vertrauenswürdige Grundlage für so viele Ihrer Lösungen wie möglich. Die Verwendung von vordefinierten Plattformservices hat zwei unterschiedliche Vorteile. Erstens profitieren Ihre Anwendungen natürlich mit jeder Version von den neuesten Salesforce-Innovationen. Zweitens können sich Ihre Entwicklungsteams auf die Erweiterung und Vertiefung der Geschäftsfunktionen Ihrer Salesforce-Lösungen konzentrieren, statt sich um grundlegende architektonische Aufgaben zu kümmern. Die richtige Auswahl, wann Standardfunktionen verwendet und wann benutzerdefinierte Funktionen erstellt werden sollen, ist aus architektonischer Sicht keine Herausforderung. Die Schlüssel lauten: - **Anpassen der Plattform bedeutet Ändern und Erweitern und nicht Kopieren**. Beim Entwerfen oder Auswerten Ihrer Architektur sollten Sie Folgendes fragen: Ist dies bereits irgendwo auf der Salesforce Platform vorhanden? Wenn die Antwort "_Ja, aber...\[Änderungen einfügen, die ein Geschäftsbeteiligter hier möchte...]"_ lautet, verwenden Sie die vordefinierte Funktion auf der Plattform. Die architektonische Arbeit besteht darin, die nützlichsten Möglichkeiten zur Konfiguration der vordefinierten Salesforce-Funktion zu ermitteln, um die Geschäftserwartungen zu erfüllen. - **Keine Anpassungen sind trivial**. Im Laufe der Zeit hat jede Änderung Konsequenzen. Wenn Sie eine benutzerdefinierte Lösung implementieren müssen, können Sie die unvermeidlichen [technischen Schulden](/docs/architect/de-de/well-architected/guide/intentional#technische-schulden) Ihres Systems verringern, indem Sie nach Möglichkeit Low-Code-Technologie verwenden und in Ihren Implementierungen [zusammensetzbare Einheiten](/docs/architect/de-de/well-architected/guide/composable) erstellen. - **Betrachten Sie das Spektrum für Build-Buy**. Bei [Salesforce AppExchange](https://appexchange.salesforce.com/) handelt es sich um einen Marktplatz mit Anwendungen und Lösungen zur Erweiterung von Salesforce. AppExchange-Anwendungen können Funktionen bereitstellen, ohne dass der Aufwand für die Erstellung und Wartung einer benutzerdefinierten Lösung entsteht. Beachten Sie beim Auswerten von AppExchange-Lösungen Folgendes: - Identifizieren Sie Lösungsfunktionen und Lücken. Idealerweise finden Sie eine Anwendung, die alle Ihre Geschäftsanforderungen erfüllt. In Wirklichkeit finden Sie möglicherweise keine perfekte Passform. Ordnen Sie beim Bewerten von Lösungen die Funktionen in der potenziellen Lösung einer priorisierten Liste von Geschäftsanforderungen zu. So finden Sie die Lösung, die Ihre wichtigsten Anforderungen am besten erfüllt. - Verwenden Sie Sandbox-Instanzen und kostenlose Testversionen. Verwenden Sie kostenlose Testzeiträume, um Anwendungen in Sandbox-Umgebungen zu evaluieren und die beste Passform zu ermitteln. Legen Sie fest, ob Sie bei Anwendungen Konfigurationsänderungen vornehmen müssen, die mit Ihrer vorhandenen Konfiguration in Konflikt stehen. - Berücksichtigen Sie kurzfristige und langfristige Kosten. Bewerten Sie die langfristigen Einsparungen bei der Anwendungswartung im Vergleich zu den wiederkehrenden Kosten von abonnementbasierten Anwendungen. Vermeiden Sie Szenarien, in denen Sie wiederkehrende Kosten für viele Funktionen zahlen müssen, die Ihre Geschäftsbeteiligten niemals nutzen werden. - **Verwenden Sie die vordefinierten Datenmodelle von Salesforce.** Salesforce bietet vorgefertigte Datenmodelle für den Vertrieb, Service und eine Vielzahl von Branchenbereichen. Durch die Verwendung der von Salesforce bereitgestellten Datenmodelle wird sichergestellt, dass die Funktionen in Ihrem System nur einmal definiert sind (ohne Redundanz und Silos), eine einzige Informationsquelle im gesamten System geschaffen wird, das Verständnis von Anwendungsdaten mit Analysen erleichtert wird, die Verwendung der vordefinierten Services für künstliche Intelligenz von Salesforce vereinfacht wird, die Wartungskosten gesenkt werden (durch Reduzierung der zu unterstützenden Anpassungen) und die technische Verschuldung reduziert wird. So einfach ist das. Wie Sie in den unten stehenden [Mustern und Anti-Mustern](/docs/architect/de-de/well-architected/guide/intentional#wartungsmuster-und-antimuster) sehen können, bestehen die Anti-Muster darin, Standardfunktionen in einer benutzerdefinierten Lösung zu replizieren oder komplexere Technologien zum Bereitstellen von Anpassungen zu verwenden. In der Praxis kann es vorkommen, dass ein Anti-Pattern für benutzerdefinierte Funktionen von Geschäftsbeteiligten als der beste oder einzige gangbare Weg angesehen wird. In diesen Fällen ist es wichtig, dass Sie den Beteiligten die Kompromisse bei der Auswahl dieses Pfads erläutern und dann die Entscheidung, ihre Gründe und ihre Umsetzung sorgfältig dokumentieren. Dies ist auch ein Bereich, in dem die frühzeitige Bereitstellung von Kernwerten und die Anpassung im Laufe der Zeit Ihren Beteiligten helfen können, den besten Weg nach vorn besser zu verstehen. Weitere Informationen zu Salesforce-Tools, mit denen Sie die Wartungsfähigkeit erhöhen können, finden Sie unter [Tools Relevant to Intentional](/docs/architect/de-de/well-architected/guide/intentional#für-intentional-relevante-tools) (Für Intentional relevante Tools). ### Technische Schulden Technische Schulden sind ein natürlicher Bestandteil jedes Systems. Die Sound-Designs von gestern können zu Anti-Patterns werden, wenn sich Technologie- oder Geschäftsanforderungen ändern. Möglicherweise wird etwas, das entwickelt wurde, um eine Lücke in der Salesforce Platform-Funktionalität zu schließen, mit einer neuen Salesforce-Version oder einer neuen Produkteinführung plötzlich überflüssig. Möglicherweise ersetzt eine leistungsfähigere oder flexiblere Technologie eine bereits implementierte Technologie. Technische Schulden können auf viele Arten entstehen. Ein wesentlicher Vorteil beim Erstellen von Anwendungen mit Salesforce Customer 360 Platform ist die [in die Plattform](/docs/architect/de-de/fundamentals/guide/architecture-basics#plattform-apis) integrierte Abwärtskompatibilität. Das bedeutet, dass neue Plattforminnovationen das Muster ändern können, das Sie für künftige Lösungen verwenden sollten. Die tägliche Funktion von Lösungen, die Sie auf vorherigen Salesforce-Technologien basieren, funktioniert jedoch weiterhin. Im Laufe der Zeit birgt jede Lösung, die auf älteren Technologien basiert, Risiken oder Engpässe beim Hinzufügen neuer Funktionen zu Ihren Anwendungen und verringert die Gesamtintegrität der Lösungen. Die Planung und Durchführung regelmäßiger Arbeiten zur Behebung technischer Schulden ist entscheidend für die Aufrechterhaltung gesunder, unkomplizierter Designs in einer Salesforce-Lösung. Wenn es nicht gelingt, technische Schulden zu planen, zu prüfen und zu beheben, ist dies eine sichere Möglichkeit, ein System zu erstellen, das schlecht konzipiert ist. Eine Möglichkeit, technische Schulden zu minimieren, besteht darin, sie so weit wie möglich einzuführen, indem Sie Abkürzungen vermeiden und [Standardfunktionen gegenüber benutzerdefinierten Funktionen](/docs/architect/de-de/well-architected/guide/intentional#standard--und-benutzerdefinierte-funktionen) bevorzugen. Tastenkombinationen wie hartcodierte Werte können verlockend sein, Zeit zu sparen, aber langfristig führen sie zu Schulden, die zurückgezahlt werden müssen. Zu den Schlüsseln für den Umgang mit technischen Schulden aus architektonischer Sicht zählen: - Ermitteln der tatsächlichen [Kosten oder Vorteile](/docs/architect/de-de/resources/guide/kpi-spreadsheet-template) von Maßnahmen im Vergleich zu Untätigkeiten - Richtige [Roadmapping](/docs/architect/de-de/well-architected/guide/intentional#roadmapping) - Erstellen von [zusammensetzbaren Lösungen](/docs/architect/de-de/well-architected/guide/composable) Die Schwierigkeit kann darin bestehen, die Beteiligten an die Durchführung von Maßnahmen anzupassen. Einige Beteiligte empfinden die laufende Wartung möglicherweise als Behebung der „Fehler von gestern“ oder als Beseitigung der Funktionen, die ihr Budget unterstützen soll. Wenn Sie die tatsächlichen geschäftlichen Auswirkungen von Maßnahmen und Untätigkeit zusammen mit klar definierten Ergebnissen und Zeitachsen aufzeigen, können Ihre Beteiligten den Wert und die relative Priorität der Bekämpfung technischer Schulden verstehen. Wenn Sie die Arbeit konsequent ausführen, um technische Schulden mit den Auswirkungen auf Unternehmen zu verbinden, können Ihre Beteiligten die zu erledigende Arbeit nicht nur besser verstehen. Außerdem können Sie so sicherstellen, dass Sie technische Schulden auf eine Weise identifizieren und beheben, die den Benutzern wirklich zugute kommt. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/intentional#wartungsmuster-und-antimuster) zeigt, wie eine ordnungsgemäße (und schlechte) technische Schuldenverwaltung für eine Salesforce-Organisation aussieht. Weitere Informationen zu Salesforce-Tools, die Ihnen bei technischen Schulden helfen können, finden Sie unter [Tools Relevant to Intentional](/docs/architect/de-de/well-architected/guide/intentional#für-intentional-relevante-tools). ### Wartungsmuster und Antimuster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Wartbarkeit im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/easy-maintainability) Anti-Muster.

	Muster	Anti-Muster
Standard vs. Benutzerdefiniert	In Ihren Designstandards: - Es gibt ein klares Leitprinzip, um Lösungen vor unnötiger Anpassung zu schützen - Das Leitprinzip für Lösungen verwendet folgende Priorität: 1. Verwenden Sie integrierte Plattformservices, 2. Bevor Sie eine benutzerdefinierte Lösung erstellen, sollten Sie AppExchange-Anwendungen in Betracht ziehen. Verwenden von Low-Code-Anpassungen vor dem Schreiben von Code	In Ihren Designstandards: - Designstandards sind nicht vorhanden oder weisen keine klare Begründung für die Vermeidung nicht benötigter Anpassungen und Code auf
	In Ihrer Dokumentation: - Entscheidungsdatensätze zeigen Berechnung für kurz- und langfristige Kosten bei der Auswahl von Lösungen an	In Ihrer Dokumentation: - Entscheidungsdatensätze berücksichtigen nicht sowohl kurz- als auch langfristige Kosten beim Erstellen oder Kauf von Lösungen
	In Datenmodellen: - Keine Objekte haben Namen oder Funktionen, die Standardobjekte duplizieren - Standardobjekte werden nicht für Zwecke verwendet, die weit außerhalb ihres vorgesehenen Umfangs liegen	In Datenmodellen: - Objekte duplizieren die Namen und/oder Funktionen von Standardobjekten - Standardobjekte werden für Zwecke verwendet, die weit über ihren vorgesehenen Umfang hinausgehen
	In LWC, Aura oder Visualforce: - Es ist kein Code vorhanden, um standardmäßige Seitenaufrufmechanismen zu überschreiben	In LWC, Aura oder Visualforce: - Code ist vorhanden, um standardmäßige Seitenaufrufmechanismen zu überschreiben, oft in Form einer Einzelseitenanwendung
	In LWC, Aura, or Apex: - Kein Code versucht, die Plattformreihenfolge der Ausführung zu überschreiben oder zu umgehen	In LWC, Aura, or Apex: - Code versucht, die Plattformreihenfolge der Ausführung zu überschreiben oder zu umgehen
Technische Schulden	In Ihrer Roadmap: - Arbeiten zur Bekämpfung von Tech-Schulden geplant - Liefertermine und Start-/Enddatum sind klar	In Ihrer Roadmap: - Keine Arbeit zur Behebung von Tech-Schulden geplant - Liefertermine sind vage, Start-/Enddatum unklar
	In Ihren Entscheidungsdatensätzen: - KPIs zur Schuldensanierung vor/nach der Technik sind klar dokumentiert - Kompromissdiskussionen für Aktionen und Untätigkeit konzentrieren sich auf Geschäftskosten oder Vorteile	In Ihren Entscheidungsdatensätzen: - Die technische Schuldensanierung weist keine messbaren KPIs auf - Tech-Schulden werden technisch oder IT-orientiert betrachtet, ohne Relevanz für das Geschäft
	In Ihrer Organisation: - Keine nicht unterstützte oder veraltete Technologie ist aktiv, einschließlich: -- Alle Benutzer arbeiten in Lightning Experience -- keine oder nur sehr wenige Verwendungen von `@future` in Apex (Warteschlange wird verwendet) -- Alle Drittanbieter-Apex gehört zu AppExchange Paketen -- keine aktiven Workflow-Regeln (Flow wird verwendet) -- keine aktiven Prozessgeneratorprozesse (Flow wird verwendet) -- PushTopic-Ereignisse (es wird die Datenerfassung geändert) -- Allgemeine Ereignisse (es werden Plattformereignisse verwendet) -- API-Versionen vor 30.0 -- Salesforce-Organisationsverbindungen verwenden organisationsübergreifenden Adapter für Salesforce Connect	In Ihrer Organisation: - Nicht unterstützte oder veraltete Technologien sind aktiv, einschließlich: -- Benutzer, die in Salesforce Classic arbeiten -- `@künftige` Verwendung in Apex -- Apex von Drittanbietern aus Nicht-AppExchange-Quellen -- Workflow-Regeln -- Prozessgeneratorprozesse -- PushTopic-Ereignisse -- Allgemeine Ereignisse -- API-Versionen vor 30.0 -- Salesforce-zu-Salesforce-Verbindungen

## Lesbarkeit Im Kern geht es beim Konzept der _Lesbarkeit_ darum, Konsistenz zu schaffen, die es den Menschen erleichtert, zu verstehen, wie die Dinge funktionieren. Durch die Erstellung lesbarer Systeme werden Zustellungs- und Wartungsteams aufeinander abgestimmt und Personen, die mit dem System nicht vertraut sind, können schnell nachvollziehen, wie Teile zusammenpassen. Das bedeutet, dass Ihr Team möglicherweise weniger von einzelnen Personen mit institutionellem oder historischem Knowledge abhängig ist, um Anbieter oder neue Teammitglieder effektiv einzuarbeiten. Das bedeutet, dass sich erfahrene Personen in einem Team auf die Qualität und die Kompromisse bei den getroffenen Entscheidungen konzentrieren können, da die Konfiguration und der Code des Systems für Menschen leicht lesbar und verständlich sind. Die Lesbarkeit kann die Verwaltung und die Qualitätssicherung beschleunigen und Teams dabei helfen, besser zu erkennen, wann sie möglicherweise redundante Anpassungen erstellen. Es kann auch die Chancen auf ein System erhöhen, das sich wiederverwendbar und testbar verhält. Sie können die Lesbarkeit durch effektive Designstandards und Dokumentation erhöhen. ### Design Standards [Designstandards](/docs/architect/de-de/resources/guide/design-standards-template) bieten Anleitungen, um alle Anpassungen auch in den ersten Entwicklungsphasen konsistent zu halten. Designstandards fungieren wie Leitplanken, sodass alle Zustellungsteams und Wartungsteams, die an Ihrem System arbeiten, hinsichtlich der Vorgehensweise und Implementierung von Anpassungen auf dem Laufenden bleiben. Durch das Definieren von Designstandards können Sie die Produktivität Ihrer Bereitstellungs- und Wartungsteams steigern, Code- und Architekturüberprüfungen einfacher durchführen und eine bessere [Dokumentation](/docs/architect/de-de/well-architected/guide/intentional#dokumentation) ermöglichen. Ohne Designstandards arbeiten Teams mit höherer Wahrscheinlichkeit in Silos. Ohne die Kohärenz, die Designstandards bieten, werden Unternehmen mit Folgendem zu kämpfen haben: - Anbieter und Entwicklungsteams verwenden lösungsübergreifend Ad-hoc-Muster und -Ansätze, wodurch potenziell Anti-Muster eingeführt und die Wiederverwendbarkeit reduziert wird (siehe [Separation of Concerns](/docs/architect/de-de/well-architected/guide/composable#trennung-von-bedenken)). - Mehr Zeit für die Lösung von Produktionsproblemen und für Supportteams, die neue Teammitglieder einarbeiten und ihnen helfen müssen, verschiedene Muster und Ansätze zu verstehen. - Schlechte teamübergreifende Zusammenarbeit, Redundanzen bei der Arbeit zwischen Teams, Zeitverlust beim Lösen von Konflikten und Fehler, die bei Integrationstests festgestellt wurden. - Mehr Frustration und höhere Fluktuationsraten. Ein wesentlicher Vorteil von Designstandards liegt in den Unterhaltungen und Entscheidungen, die Beteiligte treffen müssen, um sie zu erstellen. Insbesondere bietet der Prozess Ihren Geschäfts- und Technologieleads die Möglichkeit, sich daran auszurichten, wie das optimale Design für Ihr Unternehmen aussieht. Fügen Sie Folgendes in Ihre [Designstandards](/docs/architect/de-de/resources/guide/design-standards-template) ein: - **Benennungskonventionen für Salesforce-Metadaten**. Definieren Sie eine Reihe von Konventionen dafür, wie jede Anpassung in einem System benannt werden soll. Konventionen mit guter Benennung erzwingen nicht nur die Konsistenz zwischen den Namen von Objekten, Feldern, Code, Flows und anderen Elementen Ihres Systems. Mithilfe guter Benennungskonventionen können Entwicklungsteams auch Namen verwenden, die Informationen über den Zweck und die Funktionalität ihrer Erstellung vermitteln. Daher können andere Beteiligte eine bestimmte Anpassung besser verstehen, indem sie nur ihren Namen sehen. - **Genehmigte Designmuster und ihre Anwendungsfälle**. Richten Sie eine Bibliothek des [Explorers für Muster und](/docs/architect/de-de/well-architected-tools/guide/patterns) Anti-Muster zusammen mit wichtigen Informationen dazu ein, wann (und wann nicht) die einzelnen Muster verwendet werden sollen. Die Bibliothek enthält möglicherweise erforderliche Apex-Auslösermuster oder Flow-Orchestrierungsmuster, je nachdem, welche [Kompatibilität](/docs/architect/de-de/well-architected/guide/composable) Sie in Ihrem System wünschen. - **Entwicklungsumgebung und Werkzeugführung**. Führen Sie eine klare Liste der Tools, die Entwicklungsteams für ihre Arbeit verwenden sollen. Dies kann genehmigte Toolketten und Sprachen für alle Benutzer, die Code schreiben, oder deklarative Funktionen umfassen, die für die Low-Code-Entwicklung genehmigt sind (oder nicht). Ihre Standards können eine Liste der Quellcodeverwaltungssysteme für die Anpassung und Dokumentation sowie die erforderlichen Check-in/Check-out-Schritte enthalten. Sie können auch eine Liste der Umgebungen enthalten, die für verschiedene Arten von Entwicklungsarbeiten verwendet werden sollen. Neben der Definition dieser Standards müssen Sie entscheiden, wie und wo Sie sie pflegen und speichern möchten. Wenn Teams in Ihrem gesamten Unternehmen Ihre Designstandards nicht finden können (oder nicht einmal wissen, dass sie vorhanden sind), sind sie nicht effektiv. Idealerweise befinden sich Ihre Designstandards im selben System wie Ihre Dokumentation (weitere Informationen finden Sie im nächsten Abschnitt). Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/intentional#lesbarkeitsmuster-und-antimuster) zeigt, wie die richtigen (und schlechten) Designstandards für eine Salesforce-Organisation aussehen. Sie können sie verwenden, um Ihre Designstandards zu validieren oder zu verbessern. Weitere Informationen zu Salesforce-Tools, mit denen Sie Designstandards definieren können, finden Sie unter [Tools Relevant to Intentional](/docs/architect/de-de/well-architected/guide/intentional#für-intentional-relevante-tools) (Für Intentional relevante Tools). ### Dokumentation In der Dokumentation wird das Was, Wie und Warum Ihres Systems erläutert. Ohne aussagekräftige und konsistente Dokumentation verschwenden Teams viel Zeit mit dem Versuch, das System so zu verstehen, wie es ist (und potenziell missverstandene Funktionen und Anpassungen). Die Erstellung einer guten Dokumentation dauert einige Zeit. Die meisten Teams sind sich zwar einig, dass die Dokumentation für große Projekte wichtig ist, es kann jedoch verlockend sein, sie zu überspringen, wenn Sie schnelle Änderungen wie Konfigurationsaktualisierungen oder kleinere Anpassungen an einer Automatisierung vornehmen. Das Nichtdokumentieren der an Ihrem System vorgenommenen Änderungen ist immer ein Anti-Pattern. Durch das Überspringen der Dokumentation kann im Voraus etwas Zeit gespart werden. Die Zeit, die für die Fehlerbehebung in einer Organisation erforderlich ist, die nicht ordnungsgemäß dokumentiert ist, wird diese Zeitersparnis jedoch mehr als aufheben. Nehmen Sie in all Ihren Schätzungen immer genügend Zeit in Anspruch, um Dokumentation zu erstellen, unabhängig vom Aufwand, der für die Aktualisierungen erforderlich ist, die Sie vornehmen möchten. Das Fehlen einer eindeutigen Dokumentation kann zu einer Vielzahl von Problemen führen, darunter: - Entwicklungszyklen für die Überarbeitung bestehender Implementierungen - Wiederholende Diskussionen, die vorherige Entscheidungen erneut aufrufen oder verwirren - Längere Einarbeitung für neue Teammitglieder oder Anbieter - Überabhängigkeit von Einzelpersonen mit institutionellem oder historischem Knowledge - Redundante Architekturen zur Unterstützung gleicher oder ähnlicher Funktionen im gesamten Unternehmen - Schwierigkeiten bei der Vermittlung von Zweck und Wert Ihrer Lösung an wichtige Beteiligte Pflegen Sie für Salesforce-Lösungen die Dokumentation für: - **Lösungsübersichten**. Mit [Diagrammen](/docs/architect/de-de/reference-diagrams/guide/introduction) können Sie und Ihre Beteiligten Lösungen auf verschiedenen Detailebenen visualisieren. Mit dem Salesforce-Diagramm-Framework können Sie Diagramme erstellen, die die Geschäftsmöglichkeiten von Lösungen sowie Details zur technischen Implementierung darstellen. - **Entscheidungsdatensätze**. Halten Sie die in Betracht gezogenen Optionen, Kompromisse, endgültigen Entscheidungen und Argumente an einem zentralen Ort fest, auf den alle Teammitglieder für zukünftige Referenzzwecke zugreifen können. - **Code**. Das Format des Codes selbst ist eine wichtige Dokumentation und kann (und sollte) mit Ihren [Designstandards](/docs/architect/de-de/well-architected/guide/intentional#design-standards) übereinstimmen. Sie möchten auch über ein Protokoll mit wichtigen Informationen verfügen und es bei jeder Änderung eines Codes aktualisieren. Dokumentieren Sie für alle Klassen, Auslöser und Komponenten Folgendes: - Wer den Code verfasst hat - Wann der Code geschrieben wurde - Was der Code bewirken soll - Wichtige Abhängigkeiten - Alle Änderungen - **Deklarative Anpassung**. Salesforce bietet Teams für jede Art von Anpassung, die an den Metadaten in Ihrer Organisation vorgenommen werden kann, [integrierte Attribute](/docs/architect/de-de/fundamentals/guide/platform-multitenant-architecture#browserbasierte-no-code--und-low-code-anwendungsentwicklung), die hilfreiche Informationen zu Zweck und Intent der Metadaten bereitstellen. Geben Sie als Teil Ihrer Designstandards an, wie Teams diese integrierten Funktionen verwenden und wie sie deklarative Anpassungen benennen sollen. Führen Sie auch ein Protokoll mit wichtigen Informationen, das mit dem identisch ist, was Sie für Code verwenden. Entwickeln Sie eine Reihe von Dokumentationsstandards, um sicherzustellen, dass alle aktuellen und künftigen Teammitglieder Dokumente auf die gleiche Weise interpretieren können (dabei können [Designstandards](/docs/architect/de-de/resources/guide/design-standards-template) helfen). Es ist auch wichtig zu überlegen, wie Benutzer die Dokumentation durchsuchen können, um relevante Abschnitte oder Begriffe zu finden. Wenn Ihr System altert und komplexer wird, wird auch Ihre Dokumentation wachsen. Die Nützlichkeit der Informationen in Ihrer Dokumentation hängt direkt davon ab, wie oft, wie schnell und wie einfach Benutzer relevante Elemente suchen und finden können. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/intentional#lesbarkeitsmuster-und-antimuster) zeigt, wie eine ordnungsgemäße (und schlechte) Dokumentation für eine Salesforce-Organisation aussieht. Sie können sie verwenden, um Ihre Dokumentationsstrategie zu validieren oder zu verbessern. Weitere Informationen zu Salesforce-Tools finden Sie unter [Tools Relevant to Intentional](/docs/architect/de-de/well-architected/guide/intentional#für-intentional-relevante-tools) (Für Intentional relevante Tools). ### Lesbarkeitsmuster und Antimuster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Lesbarkeit im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/easy-readability) Anti-Muster.

	Muster	Anti-Muster
Design Standards	In Ihrer Organisation: - Code und deklarative Anpassungen haben konsistente, für Menschen lesbare Namen - Datenmodelle haben einheitliche Namen für Objekte und Felder - Überprüfungen zeigen, dass Felder konsistent ausgefüllt und in Berichten usw. referenziert werden.	In Ihrer Organisation: - Code und deklarative Anpassungen haben keine konsistenten Namen - Datenmodelle weisen inkonsistente Namen auf und viele Objekte und Felder scheinen redundant zu sein - Überprüfungen zeigen viele nicht verwendete Felder oder verschiedene Nutzungsstufen an und es gibt keinen konsistenten Link zu Berichten usw.
Design Standards	Innerhalb Ihres Unternehmens: - Teams wissen, welche Tools verwendet werden müssen (und welche nicht), um Arbeit zu erledigen - Genehmigte Designmuster sind leicht zu finden und nach Anwendungsfall zu identifizieren - Genehmigte AI-Modelle sind eindeutig identifiziert und enthalten einen vorgesehenen Zweck	Innerhalb Ihres Unternehmens: - Teams verwenden viele verschiedene Tools, um ähnliche Arbeit zu erledigen - Es gibt keine genehmigten Designmuster - Die Einarbeitung von Anbietern oder neuen Mitarbeitern erfordert viel Zeit - Genehmigte AI-Modelle sind nicht eindeutig identifiziert und ihr Zweck ist unklar
Dokumentation	In Ihrer Organisation: - Code und deklarative Anpassungen haben klare Beschreibungen	In Ihrer Organisation: - Code und deklarative Anpassungen enthalten keine Beschreibungen, schwer verständliche Beschreibungen oder Beschreibungen, die nicht mit dem übereinstimmen, was die Anpassung tatsächlich vornimmt
Dokumentation	Innerhalb Ihres Unternehmens: - Für alle Lösungen sind Diagramme für Geschäftsfunktionen und technische Implementierungsdetails vorhanden - Geben Sie an, wer/wann/welche Informationsprotokolle für Code und deklarative Anpassungen vorhanden sind - Personen können relevante Dokumentation suchen und finden	Innerhalb Ihres Unternehmens: - Das Was/Wie/Warum von Lösungen ist schwer zu finden und für die meisten Teams möglicherweise nicht verfügbar - Menschen haben Schwierigkeiten, Lösungen und das System, mit dem sie arbeiten, zu verstehen - Die Einarbeitung von Anbietern oder neuen Mitarbeitern erfordert viel Zeit

## Für Intentional relevante Tools

Tool	Beschreibung	Strategie	Wartungsfähigkeit	Lesbarkeit
ApexDoc	Dokument-Apex mit statischen HTML-Seiten		X	X
Inaktive Auswahllistenwerte per Massenvorgang löschen	Löschen inaktiver nicht verwendeter Werte aus Auswahllisten		X
Lightning Design-Systemvalidierer	Markup validieren und erfahren, wie Sie Ihren Code verbessern können		X	X
Zu Flow migrieren	Konvertieren von Workflow-Regeln und Prozessgenerator-Prozessen in Flows		X
Projektverwaltungstool von Salesforce Labs	Verwalten von Projekten in Ihrer Salesforce-Organisation	X	X
Salesforce-Erweiterungen für Visual Studio Code (erweitert)	Effizientes Analysieren von Salesforce-Code mit Visual Studio Code Extensions		X	X
Organisationsüberprüfung	Schnelles Analysieren Ihrer Organisation und ihrer technischen Schulden		X
Salesforce-Codeanalyse	Scannen von Code über IDE, CLI oder CI/CD, um sicherzustellen, dass er den bewährten Vorgehensweisen entspricht		X	X
Salesforce Roadmap Explorer	Erkunden von Salesforce-Produktinnovationen	X
Setup-Aktivierungsprotokoll	Verfolgen von Setup-Änderungen und Überprüfungsverlauf	X	X

## Für Intentional relevante Ressourcen

Ressource	Beschreibung	Strategie	Wartungsfähigkeit	Lesbarkeit
5 Dokumentationsstrategien zur Verbesserung Ihrer Salesforce-Organisation	Verbessern der Salesforce-Implementierungsdokumentation	X
Auswählen von Benennungskonventionen (Trailhead)	Erfahren Sie, wie Sie Benennungskonventionen anwenden			X
Definieren, Identifizieren und Messen von technischen Schulden	Definieren, Identifizieren und Messen der technischen Schulden	X	X
Vorlage 'Designstandards'	Erstellen von Designstandards für Ihre Organisation	X	X	X
Erste Schritte mit Salesforce-Diagrammen	Erfahren Sie, wie Sie das richtige Diagramm für Ihren Anwendungsfall erstellen			X
Erste Schritte mit Codierungskonventionen (Trailhead)	Definieren und Befolgen von Codierungskonventionen			X
Angehen auf technische Schulden (Trailhead)	Verwalten von technischen Schulden in Ihrer Salesforce-Organisation	X	X
Verbessern Ihres Apex-Codes (Trailhead)	Anwenden der Grundprinzipien der testgesteuerten Entwicklung			X
Organisationsausrichtung (Trailhead)	Erlernen des V2MOM-Prozesses für die Ausrichtung	X
Priorisieren und Planen eines Auswegs aus technischen Schulden	Erstellen eines Plans zum Reduzieren und Entfernen technischer Schulden	X	X
Vorlage 'Salesforce-Namenskonventionen'	Erste Schritte mit Benennungskonventionen		X	X
Technische Schulden: Was ist es und warum sollte es Sie interessieren?	Verstehen der Auswirkungen technischer Schulden in Ihrer Organisation		X
Verwenden des Geschäftsmodellzeichenbereichs in der Unternehmensarchitektur	Erstellen, Bereitstellen und Anzeigen von Werten in einem Geschäftsmodell	X

	Muster	Anti-Muster
Datenschutz	In Ihrer Dokumentation: - Sie verfügen über ein aktuelles Datenwörterbuch mit Feldebenennamen, Beschreibungen und Klassifizierungen - Sie verfügen über eine aktuelle Sicherheitsmatrix, die identifiziert, welche Benutzer auf welche Daten zugreifen können - Sie verfügen über eine aktuelle Designdokumentation, einschließlich Standards und Diagrammen für alle Automatisierungen, die zur Erfüllung gesetzlicher Anforderungen erstellt wurden	In Ihrer Dokumentation: - Ein Datenwörterbuch ist nicht vorhanden oder wurde nicht aktualisiert - Freigabe- und Sichtbarkeitsdokumentation ist nicht vorhanden oder wurde nicht aktualisiert - Designstandards, Diagramme und Dokumentation für Automatisierungen, die gesetzliche Anforderungen erfüllen, sind nicht vorhanden oder wurden nicht aktualisiert
Datenschutz	In Ihrer Organisation: - Für alle Objekte und Felder, die vertrauliche Informationen enthalten oder Datenschutzbestimmungen unterliegen, sind "Compliance-Kategorisierung", "Dateninhaber", "Datenvertraulichkeitsstufe" und "Feldnutzung" konfiguriert	In Ihrer Organisation: - Bei Objekten und Feldern, die vertrauliche Informationen enthalten oder Datenschutzbestimmungen unterliegen, fehlt die Konfiguration für die Compliance-Kategorisierung, den Dateninhaber, die Datenvertraulichkeitsstufe oder die Feldnutzung
Lokalisierung	In Ihrer Dokumentation: - Sie verfügen über eine Organisationsstrategie, die angibt, wo Daten gespeichert und verwaltet werden, um alle geltenden Anforderungen an die Datenresidenz zu erfüllen - Sie verfügen über eine Integrationsstrategie, die akzeptable Szenarien und Prozesse zum Replizieren von Daten über Grenzen hinweg beschreibt - Sie verfügen über eine Analysestrategie, die die Granularitätsebene beschreibt, die Berichte und Dashboards auf regionaler, nationaler und globaler Ebene enthalten können	In Ihrer Dokumentation: - Sie verfügen nicht über eine Organisationsstrategie oder Ihre Organisationsstrategie berücksichtigt die Anforderungen an die Datenlokalisierung und -residenz nicht - Sie verfügen nicht über eine Integrationsstrategie oder Ihre Integrationsstrategie berücksichtigt weder die Anforderungen an die Datenlokalisierung noch an die Residenz - Sie verfügen nicht über eine Analysestrategie oder Ihre Analysestrategie berücksichtigt weder die Anforderungen an die Datenlokalisierung noch an die Residenz.

## Ethische Standards In Geschäftskontexten sind ethische Standards die Richtlinien für das Verhalten von Unternehmen und Einzelpersonen aus wertebasierter oder moralischer Sicht. Bei Salesforce richten sich [unsere Kernwerte](https://trailhead.salesforce.com/content/learn/modules/salesforce-culture-and-values/explore-salesforce-culture-and-values) nach unseren Aufgaben als Unternehmen und Mitarbeiter. Außerdem verfügen wir über ein [Ethical Use Policy](https://www.salesforce.com/company/intentional-innovation/ethical-use-policy/) Team, das sicherstellt, dass Kunden unsere Software ethisch verwenden. Unsere [Richtlinie zur akzeptablen Nutzung](https://sfdc.co/AUP) und die Richtlinie zur [akzeptablen AI-](http://sfdc.co/AI-Policy)Nutzung sind eine Erweiterung unserer Grundwerte und helfen uns bei der Entscheidungsfindung, wenn Fragen zur Nutzung auftreten. Ihre Organisation verfügt möglicherweise über einen zusätzlichen Satz an Richtlinien, die über die einfache Einhaltung lokaler Vorschriften hinausgehen. Diese Richtlinien können verschiedene Formen annehmen. Sie reichen von der Einhaltung der Vorschriften anderer Regionen über die Ablehnung von Geschäften mit bestimmten Organisationen oder Märkten bis hin zur Überwachung der Mitarbeiter-Kunden-Interaktionen, um Diskriminierung oder verzerrte Verhaltensweisen zu verhindern. Um diese Richtlinien einzuhalten, müssen Sie möglicherweise Ihre Designstandards oder Ihre Systemkonfiguration so aktualisieren, wie Sie es aus [rechtlichen Gründen](/docs/architect/de-de/well-architected/guide/compliant#rechtliche-einhaltung) tun würden. Wenn Sie die Einhaltung ethischer Standards in Ihren Salesforce-Lösungen fördern möchten, stimmen Sie sich an die Unternehmensrichtlinien ab und bewerten Sie Ihren Einsatz künstlicher Intelligenz. ### Unternehmensrichtlinien Unternehmensrichtlinien sind Richtlinien, die festlegen, wie verschiedene Aspekte des Unternehmens (einschließlich Personen, Prozessen und Technologien) funktionieren sollen. Kunden bevorzugen Geschäfte mit Organisationen, denen sie Trusts vertrauen. Die meisten Unternehmensrichtlinien sind auf dieses Prinzip ausgelegt. Customer Trust erodiert schnell, wenn Ihre Systeme Benutzererfahrungen erstellen, die nicht mit Ihren angegebenen Richtlinien übereinstimmen. Effektive Politiken entstehen natürlich aus [einer Ethikkultur](https://www.salesforce.com/blog/new-research-ethical-leadership-business/). Jeder Mitarbeiter – vom Engineering und Design bis hin zu Data Science, Marketing und Vertrieb – muss über seine Verantwortung für die ethische Verwendung aufgeklärt werden. In einer solchen Kultur sehen Mitarbeiter klare Anreizstrukturen, um ethisches Verhalten zu belohnen, und klare, konsistente Konsequenzen für unethisches Verhalten. Beachten Sie Folgendes, um sicherzustellen, dass die Richtlinien Ihrer Organisation in Ihren Entwürfen berücksichtigt werden: - **Achten Sie auf unbeabsichtigte Folgen**. Als Architekt sind Sie dafür verantwortlich, die potenziellen Auswirkungen Ihrer Lösungen und deren Verwendung zu antizipieren. Tappen Sie nicht in die Falle, nur glückliche Pfade zu prüfen oder zu testen. Wenden Sie stattdessen Ihre Expertise beim Testen von Randfällen und Auswerten von Kompromissen an, um die ethischen Auswirkungen Ihrer Lösungen sorgfältig zu berücksichtigen. Denken Sie an alle, die von dem Produkt betroffen sein werden, insbesondere an diejenigen, die unterrepräsentiert, ausgegrenzt oder gefährdet sind. Bewerten Sie die Vielzahl der Interaktionen, die jemand oder etwas mit Ihrer Lösung ausführen kann, und führen Sie zu unbeabsichtigten Konsequenzen. Verwenden Sie das [Toolkit "Build With Intention](http://sfdc.co/BuildwithIntention)" zum Entwerfen unter Berücksichtigung der Inklusion. - **Integrieren Sie Ethik in die Richtlinie für akzeptable Nutzungen Ihres Unternehmens.** Wenden Sie sich an Ihr Rechtsteam oder einen Drittanbieter, um Ethik in Ihre Richtlinie zur akzeptablen Nutzung aufzunehmen, um sicherzustellen, dass die Verwendung Ihrer Lösungen mit den Werten Ihres Unternehmens übereinstimmt. Ihre Dokumentation sollte Informationen darüber enthalten, welche Werte und Richtlinien Ihrer Organisation von Ihren Lösungen unterstützt werden, unabhängig davon, ob sie mit Low-Code- oder Pro-Code-Tools entwickelt wurden. Veröffentlichen Sie Ihre Richtlinie zur akzeptablen Nutzung, um Ihr Engagement für den Aufbau von Trust bei Ihren Mitarbeitern und Kunden zu zeigen. - **Verwenden Sie inklusive Sprache**. Machen Sie sich mit den unterschiedlichen Möglichkeiten vertraut, mit denen Benutzer Ihre Lösung erleben, und [verbessern Sie die Sprache](https://www.salesforce.com/news/stories/salesforce-updates-technical-language-in-ongoing-effort-to-address-implicit-bias/) in Ihrer Benutzeroberfläche, Ihrem Code und Ihrer Dokumentation, um die Inklusion genauer widerzuspiegeln. Beginnen Sie, indem Sie zunächst die exklusive Sprache identifizieren und entfernen und sich dann verpflichten, die Arten von Gewohnheiten oder Praktiken zu verstehen, die zu Ausgrenzung führen können. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/compliant#muster-und-anti-muster-für-ethische-standards) zeigt, wie die ordnungsgemäße (und schlechte) Einhaltung von Unternehmensrichtlinien in einer Salesforce-Lösung aussieht. Verwenden Sie diese, um Ihre Entwürfe vor dem Erstellen zu validieren oder Bereiche in Ihrem System zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools zum Angleichen von Designs an Unternehmensrichtlinien finden Sie unter [Tools Relevant to Compliant](/docs/architect/de-de/well-architected/guide/compliant#tools-die-für-die-einhaltung-relevant-sind) (Entsprechende Tools). ### Künstliche Intelligenz Künstliche Intelligenz verwendet Rechensysteme, um Aufgaben auszuführen, die normalerweise menschliche Intelligenz erfordern, beispielsweise Argumentation, Wahrnehmung und Entscheidungsfindung. Die AI-Funktionen der Salesforce Platform umfassen Prognose-, generative und agentische Technologien und bieten eine umfassende Suite von Tools zur Verbesserung der Kundenerfahrung und der Geschäftsvorgänge: - **Prognose-AI** analysiert historische Daten und prognostiziert zukünftige Ergebnisse wie Vertriebstrends oder Kundenabwanderung. Einstein AI stellt diese Statistiken bereit, indem es Muster in Ihren Daten analysiert, um Empfehlungen zu geben und Geschäftsergebnisse zu prognostizieren. - **Die generative AI** konzentriert sich auf das Erstellen neuer Inhalte mithilfe großer Sprachmodelle. Einstein GPT ist eine Kernkomponente, die mit Ihren CRM-Daten zusammenarbeitet, um personalisierte Inhalte wie E-Mails, Chat-Antworten und Kundenkommunikation zu generieren. - Die **Agentische AI** geht mit AI noch einen Schritt weiter, indem sie Agenten in die Lage versetzt, eigenständig zu argumentieren und zu handeln, um ein bestimmtes Ziel zu erreichen. Agentforce ist die Plattform zum Erstellen dieser intelligenten Agenten, die komplexe Geschäftsprozesse wie das Lösen von Kundenvorgängen oder das Optimieren von Marketingkampagnen automatisieren kann. Diese Agenten können über Data 360 in Echtzeit mit Daten interagieren und vorhandene Workflows und APIs nutzen. Alle diese AI-Funktionen werden durch die Einstein Trust Layer geschützt, die eine ethische Verwendung gewährleistet. Die meisten der Kernalgorithmen von Einstein AI können nicht konfiguriert werden. Bei einigen Funktionen können Kunden die Modelle jedoch möglicherweise anhand ihrer eigenen Daten optimieren, wie in der Dokumentation angegeben. Darüber hinaus können Sie AI-Modelle in Ihrem eigenen CRM, Knowledge Base-Artikeln und anderen Dokumenten mithilfe von Retrieval Augmented Grounding (RAG) erstellen, um die Ausgaben für Ihre Organisation, Kunden und Anwendungsfälle noch genauer zu gestalten. Wenn Ihre zugrunde liegenden Daten jedoch verzerrt oder verzerrt sind, werden Ihre Ausgaben möglicherweise ebenfalls verzerrt und ungenau. Ein Beispiel für Verzerrungen ist, dass Mitglieder einer bestimmten Rasse, eines bestimmten Geschlechts oder einer bestimmten Ethnie nicht in Ihre Kontaktliste aufgenommen werden, obwohl Ihr Kundenstamm vielfältig ist und Mitglieder dieser Gruppe umfasst. Weitere Informationen finden Sie im Salesforce [Responsible Creation of AI Trailhead Modul](https://trailhead.salesforce.com/en/content/learn/modules/responsible-creation-of-artificial-intelligence), [Understanding Trusted Agentic AI Trailhead](https://trailhead.salesforce.com/content/learn/modules/trusted-agentic-ai), [AI Ethics Maturity Model](https://www.salesforceairesearch.com/static/ethics/EthicalAIMaturityModel.pdf), Salesforce's [Vertrauenswürdige AI Prinzipien](https://www.salesforceairesearch.com/trusted-ai), [Responsible Generative AI Guidelines](https://www.salesforce.com/news/stories/generative-ai-guidelines/) und [Responsible Agentic AI Guidelines](https://www.salesforce.com/news/stories/responsible-agentic-ai-guidelines/). Wenn Sie die geltenden gesetzlichen Vorschriften und die eigenen ethischen Standards Ihres Unternehmens nicht berücksichtigen, kann dies zu Verzerrungen innerhalb Ihrer AI führen, was zu Klagen, Umsatzeinbußen, Problemen beim Customer Trust und zu Schäden am öffentlichen Ansehen Ihres Unternehmens führt. Folgende Punkte sind für den verantwortungsvollen und ethischen Umgang mit KI zu beachten: - **Überprüfen Sie Ihre Datensets und Dokumente**. Stellen Sie sicher, dass Ihre Datensets für alle Personen repräsentativ sind, auf die sich Ihre AI-Funktionen auswirken. Dies erfordert möglicherweise eine Benutzerrecherche, um zu verstehen, wer sie sind, und um zu bestätigen, dass Ihre Daten sie alle genau darstellen, um potenzielle Verzerrungen zu vermeiden. Es ist auch wichtig, die CRM-Daten, Knowledge-Artikel und andere Dokumentationen, auf denen Sie Ihre Modelle basieren, zu überprüfen, um sicherzustellen, dass sie aktuell, genau und vollständig sind. Die Kontextbildung Ihrer Modelle in einer Vielzahl von Daten ist nicht hilfreich und kann zu Halluzinationen führen, wenn diese Daten alt, widersprüchlich oder unvollständig sind. - **[Behalten Sie einen Menschen am Ruder](https://www.salesforce.com/news/stories/human-at-the-helm/)**. Sie möchten nicht, dass Menschen in jede einzelne AI-Interaktion eingreifen, sondern Ihre Mitarbeiter in die Lage versetzen, sich auf die Elemente mit hohem Urteilsvermögen zu konzentrieren, die ihre Aufmerksamkeit am meisten benötigen. Testen Sie Ihre AI-Systeme, bis Sie sicher sind, dass sie mehr Verantwortung übernehmen und die Ergebnisse überwachen können, um sicherzustellen, dass sie weiterhin genau und effektiv funktionieren. Stellen Sie außerdem sicher, dass Ihre AI-Systeme oder -Agenten angewiesen sind, bei Anwendungsfällen mit hohem Risiko und bei niedrigem Konfidenzniveau der AI zu einem Menschen zu eskalieren. - **Priorisieren Sie die Sicherheit Ihrer Modellausgaben und -ergebnisse**. Führen Sie Verzerrungen, Erklärbarkeits- und Robustheits[-Bewertungen](https://www.salesforce.com/news/stories/developing-ethical-ai/) sowie [ethisches rotes Teaming](https://www.salesforce.com/blog/red-teaming-ai/) durch. Priorisieren Sie den Datenschutz durch Agentenantworten und Aktionen für alle personenbezogenen Daten, die in den für Schulungen verwendeten Daten enthalten sind, und erstellen Sie Leitplanken, um zusätzlichen Schaden zu vermeiden. Wenn Sie beim Testen schädliche Ergebnisse feststellen, fügen Sie Ihren Systemaufforderungen Anweisungen hinzu und testen Sie sie erneut. Möglicherweise müssen Sie auch die Qualität oder Repräsentativität der Daten verbessern, die Sie für die Abruf-erweiterte Generierung verwenden. - **Sei vorbereitet auf Vorschriften**. Zusätzlich zu den ethischen Bedenken in Bezug auf KI haben viele Regierungen Gesetze erlassen, um die Verwendung von KI durch Organisationen zu regulieren, die in ihren Rechtsordnungen tätig sind, oder sind dabei, Gesetze zu erlassen. Diese Gesetzgebung kann die Veröffentlichung von Modellkarten vorschreiben, die beschreiben, wie eine AI-Lösung erstellt wurde und funktioniert. Bevor Sie eine auf künstlicher Intelligenz basierende Lösung implementieren, sollten Sie sich darüber im Klaren sein, welche Art von KI-bezogenen Funktionen in den Regionen, in denen Ihre Systeme zum Einsatz kommen, zulässig ist oder nicht, und alle erforderlichen Anpassungen an Ihrer Strategie vornehmen. Möglicherweise müssen Sie bestimmte Funktionen in einigen Regionen deaktivieren, um die lokalen Vorschriften einzuhalten. Stellen Sie dann sicher, dass Ihre Systeme weiterhin ohne diese Funktionen funktionieren. Viele Rechtsordnungen erfordern auch Transparenz, wenn Kunden oder Endbenutzer mit AI-Systemen interagieren. - **Überwachen Sie die AI-Modelle Ihrer Organisation**. Betroffene Benutzer sollten wissen, wann eine AI verwendet wurde, und die Möglichkeit haben, ohne Weiteres Schäden zu melden und die Behebung anzufordern. Beachten Sie, dass Berichte allein möglicherweise nicht ausreichen, um festzustellen, ob Ihre AI-Funktionen Benutzern schaden. Überwachen Sie Ihre Modelle kontinuierlich auf Datenabweichungen, Änderungen bei Fairness-/Verzerrungsbewertungen, Genauigkeit und Robustheit. Stellen Sie sicher, dass Sie Pläne für die [Verarbeitung von Qualitätswarnungen](https://help.salesforce.com/s/articleView?id=sf.bi_edd_quality_alert.htm&type=5) haben und schnell reagieren können, wenn negative Auswirkungen erkannt werden. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/compliant#muster-und-anti-muster-für-ethische-standards) zeigt, wie das richtige (und schlechte) AI-Design in einer Salesforce-Lösung aussieht. Verwenden Sie diese, um Ihre Entwürfe vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools zum Implementieren von ethischeren AI-Richtlinien finden Sie unter [Tools Relevant to Compliant](/docs/architect/de-de/well-architected/guide/compliant#tools-die-für-die-einhaltung-relevant-sind). ### Muster und Anti-Muster für ethische Standards In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für ethische Standards im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/trusted-ethical-standards) Anti-Muster.

	Muster	Anti-Muster
Unternehmensrichtlinien	In Ihren Designstandards: - Standards enthalten klare Leitlinien für Bereiche, die von Unternehmensrichtlinien betroffen sind	In Ihren Designstandards: - Designstandards sind nicht vorhanden oder bieten keine klare Anleitung zu Bereichen, die den Unternehmensrichtlinien unterliegen
	In Ihrer Dokumentation: - Dokumentation für Konfiguration und Anpassungen enthält Verweise auf unterstützte Unternehmenswerte	In Ihrer Dokumentation: - Dokumentation für Konfiguration und Anpassungen verweist nicht auf Unternehmenswerte oder -richtlinien
	In Ihrer Organisation: - Für alle Objekte und Felder, die der unternehmensrichtlinienbezogenen Compliance unterliegen, sind "Compliance-Kategorisierung", "Dateninhaber", "Datenvertraulichkeitsstufe" und "Feldnutzung" konfiguriert.	In Ihrer Organisation: - Bei Objekten, die der unternehmensrichtlinienbezogenen Compliance unterliegen, fehlt die Konfiguration für "Compliance-Kategorisierung", "Dateninhaber", "Datenvertraulichkeitsstufe" oder "Feldnutzung".
Künstliche Intelligenz	In Ihren Designstandards: - Richtlinien und genehmigte Anwendungsfälle für AI-Anwendungen sind klar und leicht zu finden - Stellen Sie sicher, dass die für die RAG verwendeten Daten und Dokumente repräsentativ, vollständig, genau und aktuell sind. Suchen Sie nach Verzerrungen, toxischen und anderen schädlichen Inhalten, die sich in Ihren Datensets oder Ihrer Dokumentation befinden könnten - Generative Antworten identifizieren immer Datenquellen, die von AI-Modellen verwendet werden - Datensets, die für das prompte Engineering verwendet werden können/können, wurden dokumentiert - Bots und generative AI-Antworten werden den Benutzern eindeutig identifiziert - Standards für die Verwendung von Haftungsausschlüssen für generative AI sind klar definiert - Klare Anforderungen für die Dokumentation von Punkten menschlicher Beteiligung an AI-Lösungsdesigns vorhanden - Es gibt Standards zur Dokumentation direkter und indirekter Feedbackpfade in AI-Lösungsdesigns - Punkte, an denen AI für einen Benutzer identifiziert werden muss, sind klar definiert - Halten Sie einen Menschen am Ruder, insbesondere in regulierten oder hochriskanten Anwendungsfällen	In Ihren Designstandards: - Designstandards sind nicht vorhanden oder enthalten keine klaren Richtlinien und genehmigten Anwendungsfälle für AI-Anwendungen - Generative Antworten identifizieren keine von AI-Modellen verwendeten Datenquellen - Datensets, die für das prompte Engineering verwendet werden, werden nicht dokumentiert - Bots und generative AI-Antworten werden Benutzern nicht identifiziert - Haftungsausschlüsse bezüglich generativer Antworten fehlen - Es gibt keine Anforderungen für die Dokumentation von Punkten menschlicher Beteiligung an AI-Lösungsdesigns - Es gibt keine Standards für die Dokumentation direkter und indirekter Feedbackpfade für AI-Lösungsdesigns - Designstandards geben keine Punkte an, an denen AI für Benutzer identifiziert werden muss
Künstliche Intelligenz	In Ihrer Dokumentation: - Die Dokumentation für Konfigurationen und Anpassungen mit AI-Funktionen enthält eine ausführliche Beschreibung der gesamten Prozesslogik und wird an einem zentralen Ort gespeichert, der für Rechtsteams oder Auditoren zugänglich ist - Modelle, die Sie erstellen oder in Salesforce einbringen, sind klar dokumentiert, einschließlich aller anwendbaren Datensegmente - Unterhaltungslogik und agentische Unterhaltungen werden sorgfältig dokumentiert - Prozesse sind vorhanden, um die AI-Modelle Ihrer Organisation auf Datendrift, Änderungen bei Fairness und Verzerrungsbewertungen, Genauigkeit und Robustheit zu überwachen - Beschreibungen für die Trainings-, Evaluierungs- und Testdaten, die für alle AI-Prozesse verwendet werden, werden beibehalten - Beschreibungen werden für alle AI-bezogenen Datenbereinigungen zusammen mit Verzerrungstests, zugehörigen Ergebnissen und Leistungs-/Genauigkeitsbewertungen (z. B. F1-Bewertungen) beibehalten	In Ihrer Dokumentation: - Dokumentation für Konfigurationen und Anpassungen mit AI-Funktionen fehlt, ist unvollständig oder wird an einem nicht zugänglichen Ort gespeichert - AI-Modelle oder -Systeme werden in Ihrer Organisation ohne Dokumentation ihrer Modelle implementiert - Agenten werden in Ihrer Organisation ohne Dokumentation von Nachrichten und Unterhaltungs-Flow implementiert - AI-Überwachungsprozesse sind nicht vorhanden oder nicht dokumentiert - Informationen zu Trainings-, Evaluierungs- und Testdaten, die für alle AI-Prozesse verwendet werden, sind unklar oder nicht verfügbar - Informationen zur AI-bezogenen Datenbereinigung, Verzerrungstests und Ergebnissen sind unklar oder nicht verfügbar

## Barrierefreiheit _Barrierefreiheit_ in der Technik bezieht sich auf die Nutzbarkeit von Systemen oder Lösungen für Menschen mit unterschiedlichen Fähigkeiten. Das Entwerfen von Systemen, die für alle Benutzer unabhängig von ihren Fähigkeiten funktionieren, ist in einigen Standorten und Branchen gesetzlich vorgeschrieben. Über die gesetzlichen Anforderungen hinaus hilft Ihnen die Erstellung barrierefreier Systeme, das Trust Ihrer Beteiligten zu stärken und zu stärken. Bei kundenorientierten Anwendungen kann dies sogar den Umsatz erhöhen, da Kunden sich möglicherweise für die Verwendung Ihrer Systeme entscheiden, statt für weniger barrierefreie Alternativen. Salesforce veröffentlicht [Berichte zur Barrierefreiheitskonformität](https://www.salesforce.com/company/legal/508_accessibility/), bei denen es sich um Branchenstandarddokumente handelt, in denen erläutert wird, wie unsere Software die Standards für den barrierefreien Zugriff erfüllt. Die meisten unserer benutzeroberflächenbasierten Steuerelemente, einschließlich Lightning Web Components und Experience Cloud-Vorlagen, sind auf die Einhaltung dieser Standards ausgelegt. Auch wenn unsere grundlegenden Funktionen für den barrierefreien Zugriff für viele Unternehmen ausreichend sein können, ist es wichtig, dass Sie unsere ACRs und Versionshinweise lesen, bevor Sie mit einem Projekt beginnen. Dadurch können Sie zusätzliche Anforderungen an den barrierefreien Zugriff identifizieren und dokumentieren, die je nach Markteinführungsansatz Ihres Produkts oder Service über unsere Standards hinausgehen. Sie können die Zugänglichkeit Ihrer Systeme verbessern, indem Sie sich auf zwei Schlüsselbereiche konzentrieren: die Dateneingabe und die Navigation. ### Dateneingabe Dateneingabeaktivitäten erfolgen immer dann, wenn ein Benutzer Informationen in ein Feld, Formular oder einen anderen Teil einer Benutzeroberfläche eingeben muss. Während Tastaturen und Mäuse die häufigsten Eingabemethoden sind, können einige Benutzer auf Sprach-zu-Text- oder ähnliche Geräte zurückgreifen. Darüber hinaus können Ihre Benutzer in verschiedenen Sprachen kommunizieren. Lösungen, die nicht auf Barrierefreiheit ausgerichtet sind, können Einzelpersonen mit bestimmten Behinderungen von der Interaktion mit ihnen ausschließen. Beachten Sie beim Entwerfen für den barrierefreien Zugriff Folgendes: - **Die von Ihren Benutzern bevorzugte Sprache**. Je nachdem, wo Ihr Unternehmen tätig ist, können Sie eine einzige Standardsprache für Ihre Systeme festlegen oder mehrsprachige Funktionen anbieten. Wenn Sie Text in mehreren Sprachen anzeigen, sollten Ihre Designstandards eine Liste von Feldbezeichnungen und anderen Benutzeroberflächenelementen (wie Benachrichtigungen und Fehlermeldungen) enthalten, die übersetzt werden müssen. Wenden Sie sich an einen Muttersprachler, um die Übersetzungen auf Genauigkeit und Bedeutung zu überprüfen. Verwenden Sie Salesforce-[Übersetzungsfunktionen](https://help.salesforce.com/s/articleView?id=sf.workbench_overview.htm&type=5) für Echtzeit-Metadaten und Datenübersetzungen und testen Sie alle mehrsprachigen Funktionen sorgfältig. - **Die Typen der verwendeten Eingabegeräte.** Führen Sie alle Tools auf, die für die Dateneingabe über eine Standardtastatur und -maus hinaus in Ihren Designstandards verwendet werden können. Fügen Sie in Ihre Testpläne barrierefreie Tests ein und stellen Sie sicher, dass alle Eingaben mit mehreren Eingabegerätetypen getestet werden. - **Die Benutzerfreundlichkeit Ihrer Formulare**. Stellen Sie sicher, dass Ihre Formulare sichtbare Bezeichnungen enthalten, hilfreiche Fehlermeldungen bereitstellen, den Benutzer zum Abschluss führen, ihn über seinen Fortschritt informieren und seine Eingaben überprüfen, bestätigen und bearbeiten können. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/compliant#muster-für-den-barrierefreien-zugriff-und-anti-muster) zeigt, wie die Dateneingabe aussieht, wenn sie ordnungsgemäß (und schlecht) für den barrierefreien Zugriff in einer Salesforce-Lösung konzipiert ist. Verwenden Sie diese, um Ihre Entwürfe vor dem Erstellen zu validieren oder Bereiche in Ihrem System zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools zum Erstellen barrierefreier Dateneingaben finden Sie unter [Tools Relevant to Be Compliant](/docs/architect/de-de/well-architected/guide/compliant#tools-die-für-die-einhaltung-relevant-sind) (Konforme Tools). ### Navigation Bei der Navigation verschieben Benutzer den Fokus zwischen Bildschirmen und zwischen Feldern auf einem Bildschirm. Benutzer müssen möglicherweise auf verschiedene Weise durch die verschiedenen Benutzeroberflächenelemente in Ihrem System navigieren, beispielsweise über Klicks und Tastenanschläge, während sie sich auf ihr Sehen, Hören und Berühren verlassen. Stellen Sie sicher, dass Ihre Designstandards eine Liste der Navigationsgeräte enthalten, die Sie unterstützen möchten. Implementierungsteams sollten sich beim Testen auf diese Liste beziehen, um sicherzustellen, dass alle Navigationsmöglichkeiten berücksichtigt werden. Berücksichtigen Sie beim Entwerfen der barrierefreien Navigation die folgenden Fragen und deren Antworten: - **Wie navigieren Benutzer in Ihrer Lösung?** Führen Sie alle Geräte auf, die für die Navigation über eine Standardtastatur und -maus hinaus in Ihren Designstandards verwendet werden können. - **Ist Ihre Navigation konsistent?** Richten Sie Designstandards für Navigationssteuerungen ein, um die Konsistenz Ihres gesamten Systems zu gewährleisten. Navigationspfade sollten in Ihrem gesamten System ähnlich sein. Eine inkonsistente Navigation, beispielsweise eine blaue Schaltfläche "Weiter" unten rechts auf einem Bildschirm und eine grüne Schaltfläche "Weiter" in der Mitte des nächsten, kann für einige Benutzer ein leichtes Ärgernis darstellen, die Anwendung jedoch für Personen mit Behinderungen unbrauchbar machen. - **Berücksichtigen Ihre Tests den barrierefreien Zugriff?** Fügen Sie in Ihre Testpläne barrierefreie Tests ein und stellen Sie sicher, dass alle Navigations-Flows mit mehreren Eingabegerätetypen getestet werden. - **Ist der Tastaturfokus durchgängig sichtbar?** Zeigen Sie den aktuellen Status des Tastaturfokus immer visuell an, um Benutzern, die auf eine Tastatur angewiesen sind, die Navigation zu erleichtern. - **Hat Ihre Navigation Farbe?** Vermeiden Sie es, nur Farbe zu verwenden, um Informationen anzuzeigen oder eine Aktion anzufordern. Halten Sie sich an die [Web Content Accessibility Guidelines (WCAG) 2.0](https://www.w3.org/TR/WCAG20/#visual-audio-contrast), um die Farben richtig zu verwenden und die richtige Kontrastebene zu erreichen. - **Wurden Ihre Entwürfe überprüft?** Führen Sie regelmäßige Überprüfungen durch, um sicherzustellen, dass Ihre Benutzeroberfläche konsistent und leicht verständlich ist. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/compliant#muster-für-den-barrierefreien-zugriff-und-anti-muster) zeigt, wie die Navigation aussieht, wenn sie ordnungsgemäß (und schlecht) für den barrierefreien Zugriff in einer Salesforce-Lösung konzipiert ist. Verwenden Sie diese, um Ihre Entwürfe vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools zum Erstellen einer barrierefreieren Navigation finden Sie unter [Tools Relevant to Be Compliant](/docs/architect/de-de/well-architected/guide/compliant#tools-die-für-die-einhaltung-relevant-sind) (Konforme Tools). ### Muster für den barrierefreien Zugriff und Anti-Muster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht (oder die erstellt) werden soll, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für den barrierefreien Zugriff im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/trusted-accessibility) Anti-Muster.

	Muster	Anti-Muster
Dateneingabe	In Ihren Designstandards: - Alle Geräte, die für die Dateneingabe über eine Standardtastatur und -maus hinaus verwendet werden können, sind aufgeführt - Textwerte und ihre Übersetzungen in alle unterstützten Sprachen werden aufgeführt	In Ihren Designstandards: - Nur einige oder keine der Geräte, die für die Dateneingabe über eine Standardtastatur und Maus hinaus verwendet werden können, sind aufgeführt - Unterstützte Sprachen werden zusammen mit zu übersetzenden Benutzeroberflächenelementen aufgeführt
	In Ihren Testplänen: - Testschritte beinhalten die Verwendung mehrerer Eingabegerätetypen zur Eingabe von Daten - Testschritte beinhalten Dateneingabe in mehreren Sprachen	In Ihren Testplänen: - Barrierefreiheitstests sind nicht enthalten oder Tests auf barrierefreie Dateneingabe werden ad hoc durchgeführt
	In Ihrer Organisation: - Übersetzungen für unterstützte Sprachen werden in der Übersetzungsworkbench gespeichert	In Ihrer Organisation: - Übersetzungen werden in benutzerdefinierten Bezeichnungen gespeichert
Navigation	In Ihren Designstandards: - Alle Geräte, die zur Navigation verwendet werden können (nicht nur Standardtastatur und Maus), sind übersichtlich aufgeführt - Benutzeroberflächen-/UX-Standards geben den Typ und Stil aller Navigationssteuerungen an - Die Typen von visuellen Hinweisen, die genehmigt wurden, um Bedeutung oder Status zu vermitteln, sind klar aufgeführt und Farbe ist kein primärer Hinweis	In Ihren Designstandards: - Designstandards sind nicht vorhanden oder berücksichtigen keine Barrierefreiheitsanforderungen für Navigationssteuerungen - Benutzeroberflächen-/UX-Standards für die Navigation sind inkonsistent - Visuelle Hinweise für Bedeutung oder Status basieren auf Farbe oder es gibt keine eindeutigen Listen von visuellen Hinweisen für Ersteller
Navigation	In Ihren Testplänen: - Testschritte beinhalten die Verwendung mehrerer Eingabegerätetypen zum Navigieren - Testpläne beinhalten die Verwendung von Benutzeroberflächen-/UX-Tests, um konsistente Navigationspfade sicherzustellen	In Ihren Testplänen: - Barrierefreiheitstests sind nicht enthalten oder Tests für barrierefreie Navigation werden ad hoc durchgeführt

## Tools, die für die Einhaltung relevant sind

Tool	Beschreibung	Rechtliche Einhaltung	Ethische Standards	Barrierefreiheit
Agentforce Analytics	Abrufen von Statistiken zur Leistung Ihrer Agenten		X
Agentforce-Testcenter	Führen Sie bis zu 10 Testaufträge mit bis zu 1.000 Testfällen pro Test aus, damit Sie schnell mehrere Szenarien erstellen und bewerten können.		X
Zitate	Zitate helfen Ihnen, potenzielle Ungenauigkeiten oder Halluzinationen in den generierten Antworten zu identifizieren, was Ihre Zuversicht bei der Verwendung von AI-Tools erhöht.		X
Einwilligungs-API	Verfolgen von Kundenpräferenzen für Einwilligungen	X
Einwilligungsereignis-Stream	Senden von Benachrichtigungen über Änderungen an Einwilligungs- oder Kontaktinformationen	X
Objekte der Einwilligungsverwaltung	Verwalten von Kundenprivatsphäre und Einwilligungsvoreinstellungen	X
Datenzugriff und Übertragbarkeit	Exportieren von kundenbezogenen Daten auf Anforderung	X
Datenklassifizierung	Aufzeichnen von Informationen zur Einhaltung von Schlüsseln und zur Prüfung von Objektfeldern	X
Data 360-Berichte	Überwachen der Einhaltung von Agentenanweisungen		X
Datenlöschung	Löschen von Daten zur Einhaltung gesetzlicher Vorschriften	X
Datenschutzvoreinstellungen	Speichern von Datenschutzvoreinstellungen für Kundendaten	X	X
Datenübersetzung	Übersetzen von Benutzern präsentierten Daten	X		X
Datenerkennung	Angleichen von Kategorien und Sensibilitätsstufen an tatsächliche Daten	X
Data 360 Explorer	Verwalten von Projekt- und Objektberechtigungen für Datenwissenschaftler	X	X
Einstein-Datenprisma	Eine Kontextlösung für Anwendungen mit generativer AI in Salesforce, die die Genauigkeit von AI-Lösungen verbessert, die ihre Kontextfunktionen verwenden		X
Einstein Trust Layer	Eine Sammlung von Funktionen, Prozessen und Richtlinien zum Schutz des Datenschutzes, zur Verbesserung der AI-Genauigkeit und zur Förderung eines verantwortungsvollen Umgangs mit AI im gesamten Salesforce-Ökosystem		X
Erweiterte Ereignisprotokolle	Ereignisprotokolle erfassen die Ereignisse und Benutzermeldungen in einer Agentensitzung, um die Einhaltung der Anweisungen zu überprüfen, Ihren Agenten zu testen und Fehler zu beheben.		X
Files Connect	Durchsuchen, Suchen und Freigeben externer Dateien in Salesforce	X
Hyperforce	Einhalten der lokalen Datenspeicheranforderungen	X
Metadatenübersetzung	Übersetzen von Sprachen zum Lokalisieren von Anwendungen	X		X
Portabilitäts-API	Kompilieren der in Ihrer Übertragbarkeitsrichtlinie identifizierten Kundendaten	X	X
Voreinstellungscenter	Erfassen von Kundenkommunikationsvoreinstellungen	X	X
Datenschutzcenter	Erfüllen von Kundenanforderungen und Datenschutzgesetzen	X	X
Einschränkung der Datenverarbeitung	Einschränken der Verarbeitungsmethoden für personenbezogene Daten	X	X
Recht auf Vergessenwerden	Löschen einzelner Kundendaten auf Anforderung	X
Salesforce Files (Salesforce-Dateien)	Freigeben und privates Speichern von Dateien	X
Sicherheitscenter	Anzeigen von Sicherheits- und Datenschutzeinstellungen in mehreren Organisationen	X
Shield Platform Encryption	Verschlüsseln von Daten im Leerlauf und während der Übertragung	X
Translation Workbench	Beibehalten übersetzter Werte für Metadaten und Datenbezeichnungen	X		X

## Für die Einhaltung relevante Ressourcen

Ressource	Beschreibung	Rechtliche Einhaltung	Ethische Standards	Barrierefreiheit
5 Prinzipien für verantwortungsvolles AI-Design	Ethisches Entwerfen von Funktionen der künstlichen Intelligenz		X
Grundlagen für den barrierefreien Zugriff (Trailhead)	Erfahren Sie, warum Barrierefreiheit wichtig ist			X
Berichte zur Barrierefreiheitskonformität	Verstehen, wie Salesforce die Standards für den barrierefreien Zugriff erfüllt			X
Übersicht über den barrierefreien Zugriff	Grundlegendes zum barrierefreien Zugriff in Salesforce Lightning			X
AI-Ethik-Maturitätsmodell	Entwickeln einer Roadmap zur Operationalisierung ethischer Prinzipien		X
AI Red Teaming: Testen auf Trust	Erfahren Sie, wie die ethischen Hacker von Salesforce verantwortungsvolle AI durch rotes Teaming entwickeln.		X
Automatisieren des Gegners: Entwerfen eines skalierbaren Frameworks für die AI von Red Teaming	Erfahren Sie, wie Salesforce die Generierung kontradiktorischer Aufforderungen und die Validierung von Antworten automatisiert. Fuzzai hilft dabei, AI-Interaktionen zu schützen und gleichzeitig die Gefährdung von Menschen durch schädliche Inhalte zu reduzieren.		X
Bewährte Vorgehensweisen für die Unterhaltungsgestaltung	Befolgen bewährter Vorgehensweisen beim Entwerfen von Chatbots		X	X
Bewährte Vorgehensweisen für nachhaltiges Design (Trailhead)	Integrieren Sie Nachhaltigkeit in Ihre Designs		X
Einwilligungsverwaltung	Verfolgen und Einhalten von Einwilligungs- und Abmeldeanforderungen	X
Datenrichtlinien für Einstein	Steuern der Datennutzung über Einstein	X	X
Vorlage 'Designstandards'	Erstellen von Designstandards für Ihre Organisation	X	X	X
Ethische Hacking-Praktiken erweisen sich beim Erstellen Vertrauenswürdiger AI Produkte als erfolgreich	Erfahren Sie, wie Salesforce rote Teaming-Praktiken einsetzt, um die Sicherheit unserer AI-Produkte zu erhöhen, indem Sie Tests auf bösartige Verwendung, vorsätzliche Integritätsangriffe, gutartige missbräuchliche Verwendung durchführen und verantwortungsvolle AI-Probleme identifizieren.		X
Ethische Führung und Geschäftstätigkeit	Statistiken zu Technologie, Gleichstellung und Ethik		X
Ethische Nutzungsrichtlinie	Erkunden der Salesforce-Richtlinie zur ethischen Verwendung unserer Produkte und Services		X
Ethik nach Konzept (Trailhead)	Integrieren von ethischem Design in die Technologieentwicklung		X
Erkunden der Salesforce-Kultur und -Werte (Trailhead)	Erkunden der zentralen Werte von Salesforce		X	X
Befolgen der Richtlinien für barrierefreies mobiles Design	Befolgen Sie bewährte Vorgehensweisen, um Ihren Designs den Zugriff zu ermöglichen.		X	X
Erste Schritte mit dem barrierefreien Webzugriff (Trailhead)	Hier erfahren Sie, wie Sie Websites und Anwendungen barrierefrei gestalten			X
Wie Salesforce eine reproduzierbare Red Teaming-Infrastruktur erstellt	Vier Komponenten, die beim Entwerfen, Implementieren und Ausführen kontradiktorischer Tests empfohlen werden		X
Ausführen eines Konsequenzscan-Workshops	Berücksichtigen aller möglichen Ergebnisse bei der Innovation		X
Implementieren von Datenschutz und Privatsphäre	Auswerten von Datenschutz- und Datenschutzanforderungen	X
Inklusives Design (Trailhead)	Fördern von Innovationen mit inklusiven Designprinzipien		X	X
KPI-Tabellenblattvorlage	Festlegen wichtiger Leistungsindikatoren (KPIs) für Ihre Organisation	X
Rechtliche Hinweise	Erkunden des Rechtsinformationscenters von Salesforce	X
LWC-Cookie-Einwilligungsmodul	Steuern des Benutzer-Cookie-Zugriffs auf Experience Cloud-Sites	X	X
Datenschutzübersicht	Informationen zum Datenschutz nach Region und Branche	X
Fördern von verantwortlichen und ethischen Agenten	Erfahren Sie, wie Sie Strategien für ethisches Red-Teaming und Tests implementieren und Leitprinzipien und Standards für Ihre Organisation entwickeln.		X
Richtlinien für verantwortungsvolle Agenten-AI			X
Modul 'Verantwortungsvolle Erstellung von AI Trailhead'	Erfahren Sie, wie Sie Verzerrungen aus Ihren Daten und Algorithmen entfernen, um ethische AI-Systeme in Ihrem Unternehmen zu erstellen.		X
Richtlinien für verantwortungsvolle generative AI	Wir haben auf unseren Vertrauenswürdigen AI Prinzipien mit einem neuen Satz an Richtlinien aufgebaut, die sich auf die verantwortungsvolle Entwicklung und Implementierung generativer AI konzentrieren.		X
Salesforce-Konformitätszertifizierungen	Überprüfen der Konformitätszertifizierungen und -bescheinigungen von Saleforce	X
Nachhaltiges Design (Trailhead)	Stärkung der Beziehung zwischen Wirtschaft und Gesellschaft		X
Testen auf Webzugriff (Trailhead)	Verwenden von automatisierten und manuellen Tests zur Gewährleistung des barrierefreien Zugriffs			X
Vertrauenswürdige Agenten-AI	Erfahren Sie, wie Agentforce Sicherheitsvorkehrungen und verantwortungsvolle AI-Prinzipien zum Erstellen ethischer AI verwendet.		x

## Teilen Sie uns Ihre Meinung mit Helfen Sie uns, Salesforce Well-Architected für Sie relevant zu halten. Nehmen Sie an unserer [Umfrage teil](https://sfdc.co/bxNtvh), um Feedback zu diesen Inhalten zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten. > Lesen Sie [hier](/docs/architect/de-de/well-architected/guide/contributors) unsere Aktualisierungspläne. ## Einführung Resiliente Lösungen sorgen für eine hohe Servicequalität, selbst wenn Fehler auftreten. Wenn die Leistung nachlässt oder der Service unterbrochen wird, wird die Lösung schnell und effektiv wiederhergestellt. Die Resilienz einer Lösung basiert auf zwei Schlüsselqualitäten: - **Zähigkeit**: Wenn Probleme auftreten, widersteht die Lösung ihnen und hält sie aus. - **Elastizität**: Nachdem Probleme behoben wurden, kehrt die Lösung in ihren idealen Zustand oder ihre ideale Form zurück. Wenn Sie Ihre Lösung für Widerstandsfähigkeit entwickeln möchten, müssen Sie sowohl auf Robustheit als auch auf Elastizität ausgelegt sein und sowohl Haltbarkeit als auch schnelle Erholung bei geplanten und ungeplanten Änderungen gewährleisten. Stellen Sie sich ein System oder eine Lösung in Technologiekontexten als eine Sammlung voneinander abhängiger Komponenten vor, die aufeinander abgestimmt sind, um gemeinsame Ziele zu erreichen. Jede Komponente kann fehlschlagen. Probleme innerhalb dieser Komponenten, von Code- und Konfigurationsfehlern bis hin zu Netzwerk- und Hardwareproblemen, können zu unerwartetem, unerwünschtem Verhalten führen. Ein System zeigt ein elastisches Verhalten, wenn eine oder mehrere Komponenten ausfallen, das Gesamtsystem jedoch weiterhin funktioniert oder schnell wieder in einen stabilen Zustand zurückkehrt. Um die Widerstandsfähigkeit Ihrer Salesforce-Lösungen zu verbessern, sollten Sie sich auf drei wichtige Gewohnheiten konzentrieren. - [**Anwendungslebenszyklus-Verwaltung (Application Lifecycle Management, ALM)**](/docs/architect/de-de/well-architected/guide/resilient#anwendungslebenszyklus-verwaltung): Wie Teams Software während ihres gesamten Lebenszyklus verwalten – von der Idee bis zur Außerbetriebnahme - [**Vorfallsreaktion**](/docs/architect/de-de/well-architected/guide/resilient#vorfallsreaktion): Wie Teams Probleme identifizieren, beheben und verhindern, die sich auf die Verfügbarkeit oder Sicherheit eines Systems auswirken - [**Kontinuitätsplanung**](/docs/architect/de-de/well-architected/guide/resilient#kontinuitätsplanung): Wie Teams planen, dass ihre Mitarbeiter und Systeme weiterhin funktionieren, wenn ungeplante Ereignisse Probleme verursachen ## Anwendungslebenszyklus-Verwaltung Die Anwendungslebenszyklus-Verwaltung (Application Lifecycle Management, ALM) ist eine Praxis für die ganzheitliche Verwaltung von Software während ihres gesamten Lebenszyklus, von der Erstellung bis zur Außerbetriebnahme. ALM ist ein Eckpfeiler der Systemresilienz und umfasst Personen, Prozesse, Tools und Disziplinen, die sich auf den Anwendungslebenszyklus beziehen. Zu diesen Disziplinen zählen DevOps und Bereitstellungsmethoden, Beobachtbarkeit, Teststrategien, Governance und CI/CD. Wenn ein Unternehmen effektive ALM-Methoden anwendet, reagieren seine Teams schnell auf Änderungen und seine Anwendungen können mit den sich ändernden Geschäftsanforderungen Schritt halten, ohne die Stabilität oder Qualität zu beeinträchtigen. Ohne gesunde ALM haben Teams in jeder Phase des Anwendungslebenszyklus Probleme. Symptome einer schlechten ALM sind: - Langsame und fehleranfällige Entwicklungszyklen - Intensive und schwierige Bereitstellungen - Schwerwiegende Probleme oder Fehler, die in Produktionsumgebungen und Umgebungen nach der Qualifizierung entdeckt wurden - Halluzinationen oder inkonsistentes Verhalten von AI-Agenten - Häufige Rollbacks oder Hotfix-Bereitstellungen zum Stabilisieren von Versionen erforderlich Da ALM nahezu jeden Aspekt einer Lösung berücksichtigt, ist die Einrichtung klarer und effektiver ALM-Praktiken für Ihre Lösung ein wichtiger Bestandteil Ihrer architektonischen Arbeit. Erstellen Sie bessere ALM-Praktiken, indem Sie sich auf drei wichtige Bereiche konzentrieren. - [**Versionsverwaltung**](/docs/architect/de-de/well-architected/guide/resilient#versionsverwaltung): Planung, Sequenzierung, Steuerung und Migration von Änderungen in unterschiedliche Umgebungen - [**Umgebungsstrategie**](/docs/architect/de-de/well-architected/guide/resilient#umweltstrategie): Eine Strategie zur Verwendung und Verwaltung von Anwendungen in Zielumgebungen während der Entwicklung und des Tests - [**Signalisierungsstrategie**](/docs/architect/de-de/well-architected/guide/resilient#signalstrategie): Definition kritischer Signale und Anwendungsinstrumente zum Erkennen und Beheben von Fehlern innerhalb des Systems vor der Verschlechterung - [**Teststrategie**](/docs/architect/de-de/well-architected/guide/resilient#teststrategie): Die Grundsätze und Standards, die Sie bei der Planung und Durchführung von Tests unterstützen, um den Erfolg Ihrer Anwendungen während ALM-Prozessen zu messen ### Versionsverwaltung Die Versionsverwaltung umfasst die Planung, Sequenzierung, Steuerung und Migration von Änderungen in eine oder mehrere Umgebungen. Eine einzelne Version ist eine Gruppe geplanter Änderungen, die ein Team gleichzeitig in eine Zielumgebung verschiebt. Die Veröffentlichung einer Änderung an einem System birgt ein entsprechendes Risiko. Wenn sich das System vor der Änderung in einem stabilen Zustand befindet, wechselt es in einen neuen Zustand, in dem es auch anfälliger für Risiken durch künftige Änderungen ist. Wenn künftige Änderungen einen unkontrollierten, instabilen Zustand im System auslösen, kann dies zu einem kritischen Vorfall führen. In einer Lösungsarchitektur besteht das Entwerfen von belastbaren Versionen aus mehr als dem [effektiven Testen einzelner Änderungen](/docs/architect/de-de/well-architected/guide/resilient#teststrategie). Es beinhaltet auch die Planung, wie Sie Änderungen an Ihren Systemen und deren Benutzern sicher einführen können. Die Arbeit Ihrer Teams hängt von vorhersehbaren und genauen Versionsinformationen ab. Machen Sie sich in Ihren Änderungsverwaltungs- und Aktivierungsprozessen klar, welche Änderungen in Ihr System aufgenommen werden können. Geben Sie in Ihren Versionsverwaltungs- und Aktivierungsprozessen an, wie und wie oft Änderungen an Ihrem System veröffentlicht werden. Ihre Geschäftsbeteiligten kümmern sich auch um Versionsinformationen, insbesondere wenn sie sich auf Funktionen oder Fehlerbehebungen beziehen, die sie anfordern. Richten Sie konsistente und klare Versionspläne ein und stellen Sie stabile Versionsartefakte bereit, um Trust in Ihre Lösung aufzubauen und Ihren Beteiligten einen Mehrwert zu bieten. Einrichten einer effektiven Versionsverwaltung für Salesforce: - **Dichtung an Architektur- und Entwicklungsverwaltung**. Stellen Sie sicher, dass die Veröffentlichungen rechtzeitig geplant werden, um sie an alle relevanten Governance-Foren und -Steuerelemente anzupassen. Bevor Sie mit der Entwicklung beginnen, sollten Sie alle priorisierten Agentforce-Anwendungsfälle überprüfen und vom AI Council genehmigen lassen. Lassen Sie Agentforce-Anwendungsfälle mit hohem Risiko von Teams für rechtliche und ethische Anwendungen überprüfen.Verwenden Sie Bereitstellungs-Checklisten und -Dokumentation, um Bereitstellungsartefakte wie Agentforce Agent API-Namen anhand von Governance-Aktivitäten zu verfolgen. - **Verwenden Sie keine [organisationsbasierten Entwicklungs- oder Versionsprozesse](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models)**. Dieses Paradigma spiegelt ältere, eingeschränktere Technologien für die Entwicklung und Veröffentlichung wider. Mit der Salesforce CLI können Teams nun quellgesteuerte Entwicklungs- und Versionsfunktionen übernehmen. - **Wählen Sie einen möglichst stabilen Auslösemechanismus aus**. Mit diesem Ansatz werden zwei Dinge erreicht. Erstens wird die Dauer von Versionsfenstern und Serviceunterbrechungen minimiert. Zweitens ermöglicht sie ein stark kontrolliertes und vorhersehbares Versionsverhalten. Je stabiler Ihr Versionsmechanismus ist, desto unwahrscheinlicher ist es, dass Versionen Änderungen einführen, die Hotfixes oder Rollbacks erfordern. Wenn ein unvorhergesehenes Problem auftritt, bieten stabile Versionsmechanismen auch einfachere Möglichkeiten für Supportmitarbeiter oder Systemadministratoren, Rollbacks durchzuführen. Die besten Versionsmechanismen für Ihr Team sind die stabilsten Optionen, für die Ihr Team über die erforderlichen Fertigkeiten verfügt. Dies sind die empfohlenen Freigabemechanismen, die in der Reihenfolge der Stabilität aufgeführt sind. Alle sind miteinander kompatibel. Verwenden Sie daher mehrere davon gleichzeitig, wenn dies für Ihr Unternehmen am besten geeignet ist. - [**Entsperrte Pakete**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm): Entsperrte Pakete sind das stabilste Versionsartefakt. Die Bereitstellung von Änderungen durch die Installation eines Pakets ist die schnellste und vorhersehbarste Möglichkeit, Änderungen einzuführen. Pakete verwenden die Versionsverwaltung, die eine zuverlässige Änderungsverwaltung und detaillierte systemadministratorfreundliche Rollbacks ermöglicht. Pakete erfordern zudem ein starkes Metadatenmanagement, mit dem Sie falsch verwaltete Abhängigkeiten frühzeitig erkennen können. Außerdem erstellen sie überprüfbare Entwicklungspipelines und Artefakte. Siehe [Paketierbarkeit](/docs/architect/de-de/well-architected/guide/composable#paketierbarkeit). - [**DevOps Center**](https://help.salesforce.com/s/articleView?id=sf.devops_center_overview.htm&type=5): DevOps Center ermöglicht es Zustellungsteams mit Low-Code- oder Pro-Code-Fertigkeiten, die Quellcode-Steuerung zu verwenden, gemeinsam an Änderungen zu arbeiten und gemeinsame Versionspfade zu definieren. DevOps Center kann in die Quellcodeverwaltung integriert werden und ermöglicht die Zeigen-und-Klicken-Steuerung von Änderungen und Bereitstellungen. - **Quellgesteuerte Entwicklung und Metadatenbereitstellungen mithilfe der [Salesforce CLI](https://developer.salesforce.com/tools/sfdxcli)**: Wenn Sie keine Pakete verwenden können, verwenden Sie die Salesforce CLI für Ihre quellgesteuerte Entwicklung und Metadatenbereitstellung. Stellen Sie Metadaten nicht mit dem älteren Format package.xml bereit, das eine andere Struktur als das empfohlene [Quellformat](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_source_file_format.htm) aufweist. Das Quellformat wurde weiterentwickelt, um die Paketentwicklung, Workflows für Testorganisationen und eine detailliertere Änderungsverfolgung in Sandbox-Instanzen zu unterstützen. Das Format ist besser lesbar, ermöglicht eine bessere Entkopplung komplexer Metadatentypen und Abhängigkeiten und bietet Ihnen viel mehr Kontrolle über Bereitstellungsmanifeste. - **Benennen Sie Ihre Versionen**. Geben Sie Ihren Versionen klare Kennzeichner an die Hand, damit Ihre Teams und Beteiligten auf dem Laufenden bleiben. Bei Salesforce beginnt der Name jeder Hauptversion mit "Frühling", "Sommer" oder "Winter", gefolgt vom Jahr der Veröffentlichung (z. B. "Sommer '25"). Wenn Sie noch nicht über eine Benennungskonvention zum Definieren und Organisieren von Versionen in Ihrem Unternehmen verfügen, erstellen Sie eine und verwenden Sie sie. Durch die Verwendung klarer Versionsnamen können Sie in jeder Phase der Planung, Entwicklung und Bereitstellung in den Systemen Ihrer Teams einfacher organisiert bleiben. Verwenden Sie Ihre Versionsnamen in Ihrer [Roadmap](/docs/architect/de-de/well-architected/guide/intentional#roadmapping), um Ihren Beteiligten klar mitzuteilen, welche Änderungen wann anstehen. Verwenden Sie Ihre Versionsnamen in Ihrer Dokumentation, in Änderungsprotokollen, Arbeitsbeschreibungen, Codekommentaren und Zweigen der Quellcodeverwaltung, damit Sie Ihre Entwicklungsartefakte einfach verfolgen und überprüfen können. - **Verwalten Sie Abhängigkeiten in einem Versionsmanifest gut**. Salesforce-Metadaten verfügen über integrierte Abhängigkeiten. Salesforce-Bereitstellungen schlagen häufig fehl, da Abhängigkeiten nicht ordnungsgemäß verwaltet werden. Wenn Sie einen stabilen Versionsmechanismus auswählen, wie oben beschrieben, können Sie falsch verwaltete Abhängigkeiten früher in Ihrem Entwicklungszyklus aufdecken. Einer der Hauptgründe dafür, dass entsperrte Pakete das stabilste Versionsfahrzeug sind, ist die starke Metadatenverwaltung, die für die Paketentwicklung und -erstellung erforderlich ist. Wenn Sie oder Ihre Versionsverwaltungsteams die integrierten Abhängigkeiten zwischen Salesforce-Metadatentypen nicht verstehen, können Sie problematische Kombinationen in Ihren Bereitstellungs- und Versionsmanifesten nicht proaktiv erkennen. Siehe [Abhängigkeitsverwaltung](/docs/architect/de-de/well-architected/guide/composable#abhängigkeitsverwaltung). Die [Muster und Anti-Muster für ALM](/docs/architect/de-de/well-architected/guide/resilient#alm-muster-und-anti-muster) zeigen, wie eine ordnungsgemäße und schlechte Versionsverwaltung für eine Salesforce-Organisation aussieht. Verwenden Sie die Muster, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools für die Versionsverwaltung finden Sie unter [Salesforce Tools for Resilience](/docs/architect/de-de/well-architected/guide/resilient#salesforce-tools-für-resilienz) (Salesforce-Tools für Resilienz). ### Umweltstrategie Salesforce bietet eine Vielzahl von [Umgebungen](https://help.salesforce.com/s/articleView?id=sf.create_test_instance.htm&type=5), die Sie während der Anwendungsentwicklung und Testzyklen verwenden können. Für eine effektive Umgebungsstrategie für Salesforce müssen Sie wissen, wie Sie die Umgebungen verwenden und wie eine gute Verwaltung aussieht. Wie nützlich eine Entwicklungs- oder Testumgebung in ALM ist, hängt von ihrer Treue zur und ihrer Isolation von der Produktion ab. Eine gute Umweltstrategie bietet mehrere Vorteile. - Mehr Produktionstreue - Schnelleres Einrichten und Abreißen von Umgebungen - Agilere Entwicklung und Tests - Mehr Sicherheit in Ihrer gesamten Pipeline - Weniger Lärm und Konflikte in den Bereitstellungsphasen - Zufriedenere Entwicklungsteams Teams haben oft Schwierigkeiten, diese Vorteile zu realisieren. Herausforderungen, um Ihre Entwicklungsumgebungen und -strategie optimal zu nutzen, können aus mehreren Quellen stammen. Eine wahrscheinliche Quelle ist der Entwicklungsmodelltyp, dem Ihre Teams folgen. Im älteren organisationsbasierten Entwicklungsansatz musste jede Umgebung mehrere Funktionen erfüllen. Zusätzlich zu den Aufgaben Ihres Teams musste es auch die Quelle für Ihre Versionsartefakte sein (d. h. die Metadaten, die Sie in einer Version bereitstellen wollten). Da Umgebungen nicht einfach einzurichten oder abzureißen waren, waren sie oft überfüllt und voller Metadatenkonflikte zwischen Teams und sie bieten keine sinnvolle Geschwindigkeit oder Flexibilität für die ALM insgesamt. Durch die Verwendung eines quellbasierten Entwicklungsmodells wird die Beziehung zwischen Umgebungen und Ihren Versionen und Versionsartefakten grundlegend verschoben. In diesem Modell ist die Quellcodeverwaltung die Quelle der Metadaten, die Sie veröffentlichen möchten. Umgebungen sind nur Orte, an denen Ihre Teams ihre Arbeit erledigen. Das Befolgen des quellbasierten Entwicklungsmodells allein garantiert jedoch keine gute Umweltstrategie. Selbst mit der Quellcodeverwaltung können Teams weiterhin Schwierigkeiten haben, Bedingungen zum Testen von Integrationen in externe Systeme einzurichten. Konfigurationen, die von Metadaten abhängen, die sich nicht in der Quellcodeverwaltung befinden, beispielsweise verwaltete Pakete oder Anpassungen, die von [Daten](/docs/architect/de-de/fundamentals/guide/architecture-basics#metadaten-im-vergleich-zu-daten) abhängen, usw. Unter bestimmten Umständen ähneln die Herausforderungen eines quellbasierten Modells den Herausforderungen, die für ein organisationsbasiertes Modell typisch sind. Entwickeln einer effektiven Umweltstrategie: - **Übernehmen Sie ein quellgesteuertes Entwicklungs- und Versionsmodell**. Verwenden Sie keine [organisationsbasierten Entwicklungsmodelle](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models) mehr. Siehe [Versionsverwaltung](/docs/architect/de-de/well-architected/guide/resilient#versionsverwaltung).) Sie müssen Ihre Umgebungen von dem trennen, was Sie ihnen bereitstellen, um eine Strategie für eine gesunde Umwelt und gesündere Versionen zu erstellen. - **Kennen Sie die Arbeitstypen, die von den einzelnen Umgebungen unterstützt werden**. Die von Salesforce unterstützten Umgebungstypen weisen unterschiedliche Funktionen und Obergrenzen auf. Überlegen Sie beim Entwerfen Ihrer Umweltstrategie, was die Umgebungen können und was nicht. Stellen Sie sicher, dass Ihre Teams ihre Arbeit in einer Umgebung erledigen, die über die benötigten Funktionen verfügt. Eine Anleitung finden Sie in dieser Übersicht über die Salesforce-Entwicklungsumgebungen und ihre Funktionen.

	Testorganisation	Developer Sandbox (Entwickler-Sandbox)	Developer Pro-Sandbox	Partial Copy Sandbox	Vollständige Sandbox
Unterstützt die Organisationsform	Ja	Nein	Nein	Nein	Nein
Unterstützt die Quellverfolgung	Ja	Ja	Ja	Nein	Nein
Lebensdauer	1–30 Tage	Manuell gesteuert	Manuell gesteuert	Manuell gesteuert	Manuell gesteuert
Aktualisierungsintervall	Nicht verfügbar	1 Tag	1 Tag	5 Tage	29 Tage
Unterstützung der Versionsvorschau	Entwicklergesteuert	Basiert auf Sandbox-Instanz	Basiert auf Sandbox-Instanz	Basiert auf Sandbox-Instanz	Basiert auf Sandbox-Instanz
Bereitstellungszeit	> 5 Minuten	Stunden oder Tage	Stunden oder Tage	Stunden oder Tage	Stunden oder Tage
Metadaten bestimmt von	Quellcodeverwaltung	Produktion	Produktion	Produktion	Produktion
Daten bestimmt von	Manuelles Laden von Daten	Manuelles Laden von Daten	Manuelles Laden von Daten	Sandbox-Vorlage	Produktion
Datenobergrenze	200 MB	200 MB	1 GB	5 GB	Gleich wie in der Produktion

In dieser Tabelle erfahren Sie, welche Funktionen und Umgebungen für verschiedene allgemeine Entwicklungsaufgaben verwendet werden sollen.

Aufgabe	Organisationsform	Quellverfolgung	Häufige Aktualisierungen	Unterstützung der Versionsvorschau	Alle Metadaten aus der Produktion	Teilmetadaten aus der Produktion	Große Datensets aus der Produktion	Teildatensets aus der Produktion	Kompatible Umgebungen
Prototyping	X	X	X	X	X	X		X	Testorganisationen, Developer- und Developer Pro-Sandbox-Instanzen
Neue Funktionsuntersuchungen oder Proof-of-Concept-Entwicklung	X	X	X	X	X	X		X	Testorganisationen, Developer- und Developer Pro-Sandbox-Instanzen
Benutzerakzeptanztests		X	X	X	X	X		X	Developer, Developer Pro und Teilkopie-Sandbox-Instanzen
Leistungs- und Skalierungstests				X	X		X		Vollständige Sandbox
Benutzerschulung			X	X	X	X	X*	X	Developer Pro, Teilkopie und* Vollständige Sandbox-Instanzen
* Wenn Sie eine bestimmte Art von Arbeit ausführen müssen, verwenden Sie andernfalls eine weniger ressourcenintensive Umgebung.

Beachten Sie außerdem, dass für Agentforce Agenten, die Funktionen wie die Einstein Data Library, Knowledge-Artikel und unstrukturierte Daten verwenden, umfassende Tests nur eingeschränkt möglich sind, wenn Sie über eine Data 360-Sandbox verfügen. Außerdem benötigen Sie eine Data 360-Sandbox, um genaue Testbedingungen zu gewährleisten. - **Entkoppeln Sie Umgebungen von Versionsartefakten.** Verwenden Sie keine [organisationsbasierte Entwicklung](https://developer.salesforce.com/tools/vscode/en/user-guide/development-models). Behandeln Sie Umgebungen wie Orte, an denen Arbeit für eine bestimmte Zeit stattfindet. Betrachten Sie den Status von Metadaten in einer Umgebung als von Ihren Versionsartefakten getrennt. Wenn ein Code oder eine Konfiguration in einer Umgebung "herausgefunden" wird, sollte er bzw. sie der Quellcodeverwaltung zugewiesen werden, wodurch er bzw. sie zu einem Versionsartefakt wird. - Umgebungen sind vorübergehend. Erstellen Sie Prozesse, damit Sie sie so schnell wie möglich erstellen und vernichten können. - Artefakte halten an. Sie gehören zur Quellcodeverwaltung. - **Entkoppeln Sie Umgebungen von Versionspfaden**. Es ist üblich, obligatorische Versionspfade anzuzeigen, die für die Bereitstellung von Änderungen in bestimmten Umgebungen erforderlich sind. Häufig wird dieser Ansatz implementiert, um einen Proxy zur Validierung der Anwendungsreife oder Versionsstabilität einzurichten. Teams können damit auch versuchen, die Anzahl der Umgebungen zu minimieren, in denen sie eine komplexe Testinfrastruktur konfigurieren müssen. In quellbasierten Paradigmen haben Sie mehr Flexibilität bei der Validierung und dem Testen von Änderungen. - Versionsphasen gelten für Versionsartefakte, nicht für Umgebungen. Erstellen Sie keine Umgebung, um alle Änderungen in einer bestimmten Versionsphase zu "sammeln". Dafür ist die Quellcodeverwaltung vorgesehen, insbesondere Verzweigungen. Verwenden Sie Verzweigungsstrategien in der Quellcodeverwaltung, um zu organisieren, welche Änderungen in welchen Umgebungen bereitgestellt werden sollen. Je nach der zu erledigenden Arbeit müssen Sie möglicherweise alle Metadaten in einer Version in einer Umgebung bereitstellen. Verzweigungen ermöglichen Ihnen dies. Mit einigen Ausnahmen muss jede Entwicklungsumgebung aktualisiert oder vernichtet werden, sobald die entsprechende Arbeit abgeschlossen ist. Stellen Sie sicher, dass Sie alle Änderungen an Metadaten, die in einer bestimmten Umgebung vorgenommen werden und beibehalten werden sollen, mit der Quellcodeverwaltung synchronisieren. - Umgebungen sind nur so nützlich wie ihre Produktionstreue. Optimieren Sie die Setup-Workflows oder die Automatisierung Ihrer Umgebung, damit Sie Umgebungen so schnell wie möglich abreißen oder aktualisieren können. Stellen Sie alle Konfigurationen, die Sie daran hindern, schnellere und häufigere Umgebungsaktualisierungen durchzuführen, als ein wichtiges Risiko für die Gesamtresilienz Ihrer ALM-Prozesse dar. Wenn Sie über entsprechende Sanierungsarbeiten verfügen, fügen Sie sie Ihren Plänen hinzu und priorisieren Sie sie. Erfahren Sie, wie Sie losere, [modulare Einheiten](/docs/architect/de-de/well-architected/guide/composable) in Ihr System übernehmen können. Sie ermöglichen es Teams, mehr Entwicklungstypen in Testorganisationen auszuführen, und geben Sandbox-Zuteilungen für andere Arbeiten frei. Vergessen Sie nicht, welche Funktionen Testorganisationen zum Testen von Funktionen bereitstellen, die Sie in der Produktion nicht haben, da Sie keine Lizenzen dafür erworben oder aktiviert haben. - In Umgebungen, auf die Geschäftsbenutzer oder Endbenutzer zugreifen können, können Sie sich auf das konzentrieren, was für sie wichtig ist. Es gibt keine allgemeinen, nicht differenzierten Umgebungen, in denen viele verschiedene Gruppen von Endbenutzern oder Geschäftsbeteiligten versuchen, ALM-bezogene Arbeit zu erledigen. Laden Sie bestimmte Beteiligte ein und aktivieren Sie sie in bestimmten Umgebungen, um bestimmte Arbeiten zu erledigen. Evaluieren Sie jeden Prozess, der Endbenutzer oder Beteiligte in eine Umgebung mit mehr Daten bringt, als eine Teilkopie-Sandbox unterstützen kann, sorgfältig. Stellen Sie sicher, dass das Datenvolumen für die zu erledigende Arbeit erforderlich ist. Planen Sie Ihre Benutzerakzeptanztests und Entwicklungszyklen in der frühen Phase so, dass sie so eng wie möglich beieinanderliegen. Optimieren Sie alle Testphasen, um schnellere, frühere Feedback- und Iterationszyklen für Ihre Entwicklungsteams und Endbenutzer zu ermöglichen. Siehe [Teststrategie](/docs/architect/de-de/well-architected/guide/resilient#teststrategie). - **Erstellen Sie unterschiedliche Versionspfade für unterschiedliche Änderungstypen**. Nicht für alle Änderungen müssen dieselben ALM-Arbeitstypen in derselben Reihenfolge abgeschlossen werden. Es ist wahrscheinlich nicht sinnvoll, wenn Endbenutzer Akzeptanztests für kleinere Änderungen an Backend-Komponenten eines Systems durchführen. Benutzerakzeptanz- und Skalierungstests können jedoch in der frühen Phase der Entwicklung einer mobilen Anwendung enorm nützlich sein. Identifizieren Sie Versionspfade für verschiedene Änderungskategorien, beispielsweise hohes Risiko, mittleres Risiko und geringes Risiko. - **Hohes Risiko:** Änderungen wirken sich auf Kunden, Partner oder alle internen Benutzer aus. Änderungen wirken sich auf die Sicherheit oder Integration aus. Durch Änderungen werden komplexe neue Funktionen hinzugefügt. - **Mittleres Risiko:** Änderungen wirken sich auf mehr als einen definierten Schwellenwert interner Benutzer aus. Änderungen wirken sich auf Datenmodelle, Automatisierungen, die Datenvorgänge ausführen, oder Integrationen aus. - **Niedriges Risiko:** Wirkt sich direkt auf weniger als einen definierten Schwellenwert interner Benutzer aus. Enthält keine Änderungen an der Sicherheit, an Datenmodellen oder Automatisierungen, die Datenvorgänge oder Integrationen beinhalten. - **Lassen Sie nicht zu, dass überfüllte Umgebungen vorhanden sind**. Mangelnde Disziplin bei der Priorisierung, Begrenzung und Sequenzierung von Arbeit führt zwangsläufig zu überlasteten Entwicklungsumgebungen mit zu viel, zu vielen und zu unterschiedlichen Arbeitsvolumen. Überfüllte Umgebungen verursachen ein hohes Maß an Stress, Mehrdeutigkeiten und Konflikten zwischen Entwicklungsteams. Außerdem verursachen sie Störungen in Entwicklungspipelines und behindern die Qualitätskontrolle. Zusätzlich zu diesen negativen Auswirkungen stellen überfüllte Entwicklungsumgebungen eine ernsthafte Bedrohung für die Wartung und Sicherheit der Umgebung dar. Ziehen Sie Überbelegung als Symptom potenzieller Probleme in Ihren ALM-Prozessen in Betracht. Untersuchen Sie alle Ursachenprobleme und beheben Sie sie. Wenn Sie immer noch überfüllt sind, können Sie [zusätzliche Sandbox-Instanzen erwerben](https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5). Die Liste der [Muster und Anti-Muster für ALM](/docs/architect/de-de/well-architected/guide/resilient#alm-muster-und-anti-muster) zeigt, wie eine ordnungsgemäße und schlechte Umgebungsverwaltung in einer Salesforce-Organisation aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools für die Umgebungsverwaltung finden Sie unter [Salesforce-Tools für Resilienz](/docs/architect/de-de/well-architected/guide/resilient#salesforce-tools-für-resilienz). ### Signalstrategie Eine Signalstrategie definiert die wichtigen Signale und Anwendungsinstrumente, die zum Erkennen, Diagnostizieren und Beheben von Fehlern erforderlich sind, bevor sie in eine systemweite Verschlechterung übergehen. Eine effektive Instrumentierung wandelt Anwendungen von passiven Opfern von Fehlern in aktive Teilnehmer in ihrer eigenen Resilienz um, die Probleme erkennen, ihr Verhalten anpassen und bei Bedarf eine anmutige Verschlechterung koordinieren können. Wenn Anwendungen eine umfassende Instrumentierung implementieren, erhalten sie die Möglichkeit, sich unter Stress selbst zu regulieren, ihren Gesundheitsstatus an Bediener weiterzugeben und an koordinierten Wiederherstellungsbemühungen teilzunehmen. Diese Funktionen ermöglichen es Systemen, die Servicequalität auch dann aufrechtzuerhalten, wenn bei einzelnen Komponenten Probleme auftreten. Andererseits werden Anwendungen ohne geeignete Instrumentierung zu Blackbox-Instanzen, die so lange fehlschlagen, bis katastrophale Symptome auftreten. Teams reagieren auf Probleme erst, nachdem Benutzer sie gemeldet haben, und die Fehlerbehebung wird zu einer Übung in der Archäologie und nicht zur Beobachtung. - **Ermitteln Sie Fehler innerhalb der Anwendung**. Anwendungen müssen sich selbst instrumentieren, um häufige Fehlermuster zu erkennen und darauf zu reagieren, die unter hoher Last auftreten. Beachten Sie die Warteschlangensättigung. Wenn sich Nachrichtenwarteschlangen schneller füllen, als sie verarbeitet werden können, akzeptieren nicht instrumentierte Anwendungen weiterhin Arbeit, bis Speichererschöpfung oder Zeitüberschreitungskaskaden auftreten. Richtig instrumentierte Anwendungen überwachen die Warteschlangentiefe, Ablehnungsraten und Verarbeitungslatenz und lösen Abwehrreaktionen aus, wenn Schwellenwerte überschritten werden. - **Effektive Verarbeitung von Signalen außerhalb der Anwendung**: Die Verarbeitung von Signalen aus dem Betriebssystem stellt einen weiteren wichtigen Instrumentierungspunkt dar. Anwendungen müssen Handler für Beendigungssignale (SIGTERM, SIGINT) registrieren, um eine ordnungsgemäße Abschaltung zu ermöglichen. Während des Herunterfahrens akzeptieren ordnungsgemäß instrumentierte Anwendungen keine neue Arbeit mehr, lassen Anforderungen im laufenden Betrieb abschließen, leeren Puffer, schließen Verbindungen sauber und melden sich von der Serviceerkennung ab. Diese orchestrierte Abschaltung verhindert Datenverlust und ermöglicht es Load Balancern, den Datenverkehr ohne Unterbrechung umzuleiten. - **Instrument für komplexe Ausfallszenarien:** Über diese grundlegenden Muster hinaus müssen Anwendungen für subtilere Fehlermodi instrumentiert werden. Zum Identifizieren von grauen Fehlern, bei denen Komponenten für einige Beobachter gesund erscheinen, während sie für andere fehlschlagen, müssen interne und externe Signale miteinander korreliert werden. Eine Anwendung kann ihren Datenbankverbindungspool instrumentieren, um erfolgreiche Integritätsprüfungen zu melden und gleichzeitig Transaktionsabschlussraten zu verfolgen, die eine schleichende Verschlechterung erkennen lassen. Effektive Instrumentierungsstrategien schichten mehrere Beobachtungspunkte auf. - **Mit Geschäftskennzahlen** werden anwendungsspezifische Erfolgsindikatoren wie Auftragsabschlussraten oder die Qualität der Suchergebnisse verfolgt. - **Systemkennzahlen** überwachen die Ressourcenauslastung, Latenzverteilungen und Fehlerraten. - **Synthetische Sonden** üben kontinuierlich wichtige Pfade aus, um die Verschlechterung zu erkennen, bevor Benutzer sie bemerken. - Die **verteilte Verfolgung** bietet Transparenz auf Anforderungsebene über Servicegrenzen hinweg. Diese Signale werden über standardisierte Schnittstellen zur Verfügung gestellt, über die automatisierte Systeme und menschliche Bediener den Anwendungszustand beurteilen können. Die Instrumentierung selbst wird Teil der Resilienzstrategie der Anwendung, sodass Leistungsschalter anhand von Fehlerraten ausgelöst werden können, automatische Skalierer auf Warteschlangentiefen reagieren und [Bediener bei Vorfällen](/docs/architect/de-de/well-architected/guide/resilient#vorfallsreaktion) fundierte Entscheidungen treffen können. Die [Muster und Anti-Muster für ALM](/docs/architect/de-de/well-architected/guide/resilient#alm-muster-und-anti-muster) zeigen, wie eine richtige und schlechte Signalstrategie in einer Salesforce-Organisation aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools für eine Signalstrategie finden Sie unter [Salesforce-Tools für Resilienz](/docs/architect/de-de/well-architected/guide/resilient#salesforce-tools-für-resilienz). ### Teststrategie Eine Teststrategie ist eine Reihe von Leitprinzipien und Standards für die Planung und Ausführung von Tests, die den Erfolg und Misserfolg von Anwendungen während ALM-Prozessen messen. Eine Teststrategie hält alle Beteiligten, die an Tests beteiligt sind, über die Priorität, den Zweck und den Umfang eines bestimmten Tests auf dem Laufenden. Außerdem können Projektteams effektive und durchdachte Testpläne erstellen. In der Regel sind Entwickler oder Experten für Qualitätssicherung und Tests an der Erstellung und Ausführung spezifischer Tests beteiligt. Mithilfe einer Teststrategie kann sichergestellt werden, dass diese Personen wissen, welche Arten von Tests für ein bestimmtes Projekt durchgeführt werden müssen und in welcher Reihenfolge sie durchgeführt werden müssen. Mit einer Teststrategie können Sie zudem sicherstellen, dass Teams über die erforderlichen Informationen verfügen, um gut formulierte Tests, Testpläne und Artefakte zu erstellen (z. B. Testdatensets, Geräte und Datenverkehr oder Netzwerksimulatoren). Eine effektive Teststrategie schafft ein klares Bild davon, wie, wann, wo und warum unterschiedliche Testtypen – einschließlich Einheitentests, Benutzeroberflächentests und Regressionstests – in verschiedenen Kombinationen und Bedingungen ausgeführt werden sollen, um das Verhalten Ihres Systems und alle Änderungen im laufenden Betrieb zu ermitteln. Eine effektive Teststrategie generiert Tests, die Ihnen zeigen, wie gut ein System nicht funktionale Anforderungen erfüllt, beispielsweise Skalierbarkeit, Zuverlässigkeit und Benutzerfreundlichkeit. Diese können sich durch eine einzelne Art von Test schwer messen lassen. Erstellen effektiver Teststrategien für Salesforce: - **Testen Sie so oft wie möglich iterativ, häufig und automatisiert.** Entwerfen und implementieren Sie eine Testautomatisierung, mit der Teams eine Vielzahl von Testtypen für eine Vielzahl von Arbeitslasten ausführen können. Orchestrieren Sie verschiedene Testläufe, die automatisch ausgeführt werden, wenn Änderungen in die Quellcodeverwaltung gelangen. Durch diesen Ansatz können Teams Regressionen frühzeitig proaktiv erkennen und beheben. Verwenden Sie hierfür nach Möglichkeit die kontinuierliche Integration/kontinuierliche Bereitstellung (CI/CD). Wenn Sie dies nicht tun, erstellen Sie klare Testpläne, die es Teams ermöglichen, Testsequenzen frühzeitig und häufig auf Self-Service-Weise auszuführen. Bei Agentforce Agententests sollten Sie sich auf das Testcenter verlassen, um sicherzustellen, dass AI-Agenten mit verschiedenen Eingaben in verschiedenen Szenarien ordnungsgemäß funktionieren. - **Berücksichtigen Sie, dass nicht jede Änderung alle Arten von Tests erfordert**. So wie eine effektive Versions-Pipeline Pfade für Anwendungen mit hohem, mittlerem und niedrigem Risiko berücksichtigt, gilt auch für eine effektive Teststrategie. Legen Sie für Teams klar dar, wie ein geeignetes Testregime für Anwendungen mit verschiedenen Risikotypen, Anwendungsfällen oder Komplexität ausgewählt und befolgt werden soll. Siehe [Umweltstrategie](/docs/architect/de-de/well-architected/guide/resilient#umweltstrategie). - **Definieren Sie, welche Tests in verschiedenen Umgebungstypen durchgeführt werden können**. Die Produktionstreue ist eine wichtige Komponente genauer Tests, bedeutet jedoch für verschiedene Arten von Tests unterschiedliche Aspekte. Zum Beispiel müssen Regressionstests hinsichtlich Metadaten und einigermaßen Daten produktionstreu sein. Stellen Sie sicher, dass Sie definieren, welche Art von Produktionstreue für einen bestimmten Satz an Tests erforderlich ist, und klassifizieren Sie klar, welche Umgebungstypen die Bedingungen unterstützen können, die für unterschiedliche Tests geeignet sind. Eine Übersicht über die Arbeitstypen, die an den einzelnen Umgebungstypen ausgerichtet sind, finden Sie unter [Umweltstrategie](/docs/architect/de-de/well-architected/guide/resilient#umweltstrategie). - **Verwenden Sie Ausdauer-, Stress-, Leistungs- und Skalierungstests, um die Anwendungsreife kontinuierlich zu messen.** Diese Tests zeigen, wie versionsreif eine Anwendung im Verhältnis zu den Anforderungen auf Produktionsebene ist. Führen Sie diese Tests bei wichtigen neuen Funktionen in mehreren Intervallen im Anwendungsentwicklungszyklus aus. Es ist ein Anti-Pattern, diese Tests als Teil einer einzelnen Phase oder Phase der Entwicklung zu betrachten und nicht als Teil laufender Aufgaben. Es ist für Teams am nützlichsten, frühzeitig und oft Feedback zur Anwendungsleistung zu erhalten, wodurch sie besser verstehen können, wie nah oder weit die Anwendung von der Bereitschaft auf Produktionsebene entfernt ist. Die Möglichkeit, Probleme besser zu identifizieren und zu beheben, bevor Änderungen in die Produktion gehen, ist die zusätzliche Komplexität der häufigen Ausführung komplexerer Tests wert. - **Wissen Sie, welche Tests wichtig** sind. Wahrscheinlich haben Sie eine feste Zeit, um Ihre Skalierungs- oder Leistungstests durchzuführen, sodass es unpraktisch ist, jeden Bereich Ihres Systems zu testen. Nicht alle Funktionen werden gleich verwendet und nicht alle Skalierungsengpässe wirken sich gleichermaßen auf das Unternehmen aus. Stellen Sie sicher, dass sich Ihre Skalierungstests auf die am häufigsten verwendeten und am meisten geschätzten Teile des Systems konzentrieren. Definieren und verstehen Sie die wichtigsten Opportunities zum Überprüfen und Verbessern der Skalierung und Leistung in Ihrer Organisation. - **Wissen Sie, wie "gut genug" aussieht.** Die Definition der Erfolgskriterien für Ihre Skalierungs- und Leistungstests ist entscheidend. Stellen Sie sicher, dass Sie und Ihre Entwicklungsteams die Erfolgskriterien als Test-Benchmarks verwenden. Stellen Sie außerdem sicher, dass sie die funktionalen Anforderungen erfüllen, auf die Entwicklungsteams aufbauen. Zu diesen Kriterien zählen in der Regel die Unterstützung einer bestimmten Anzahl gleichzeitiger Benutzer mit Antwortzeiten, die unter einem vereinbarten Wert liegen, und Ihre [Service Level Objectives (SLOs)](/docs/architect/de-de/well-architected/guide/resilient#zeit-zum-wiederherstellen). Definieren Sie Ihre wichtigsten Zielkriterien und entwerfen Sie dann Skalierungs- und Leistungstests, um sicherzustellen, dass die Kriterien erfüllt sind. - **Stellen Sie sicher, dass Sie über angemessene Umgebungen verfügen.** Skalierungs- und Leistungstests erfordern eine besondere Produktionstreue. Ihre Datensets, Anforderungsdemografien, Anforderungsraten und Arbeitslasteigenschaften in Ihren Nicht-Produktionsumgebungen sollten so weit wie möglich mit dem übereinstimmen, was Sie in der Produktion sehen. Für Skalierungstests müssen Sie eine Vollständige Sandbox verwenden. Wenn Ihre Organisation nicht über eine Vollständige Sandbox für Skalierungstests verfügt, können Sie keine angemessenen Skalierungstests ausführen. - **Stellen Sie sicher, dass Testarbeitslasten Ihnen beim Messen nicht funktionaler Anforderungen helfen**. Denken Sie daran: - **Testdaten** – Alle Arten von Tests sollten anhand von Daten durchgeführt werden, die von der Produktion isoliert sind. Implementieren Sie in Apex-Einheitentests [Datenfabrikmuster](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_utility_classes.htm), um sicherzustellen, dass Code seine eigenen Testdaten isoliert von Umgebungsdaten generiert. Sie können auch Test-Datensets in einer Vielzahl von Formaten erstellen und verwalten, um das Verhalten beim Laden von Daten zu testen, Entwicklungsumgebungen mit Daten für benutzeroberflächenbasierte Tests zu füllen und Integrationstests zu unterstützen. Alle Testdaten, unabhängig davon, ob sie als externisiertes Datenset verwaltet oder nach Bedarf durch Datenfabrikcode erstellt werden, sollten von sensiblen und identifizierenden Daten bereinigt werden. Sie sollte beschädigte, unvollständige und falsch formatierte Daten enthalten, um negatives Verhalten und Verhalten bei Grenzeinheitentests zu unterstützen. - **Make-and-stub-Services**: Für Integrationstests können Sie simulierte und Stub-Services verwenden, um API-Antworten zu simulieren. Apex unterstützt eine [Stub-API](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_testing_stub_api.htm), um simulierte Frameworks für die Verwendung in Apex Tests zu erstellen. Mocking zum Erstellen simulierter Frameworks, die in Apex Tests verwendet werden können. Mithilfe von Modellen und Stubs können Sie das Verhalten eines Systems bei der Datenverarbeitung validieren, ohne auf komplexe Datenfabriken oder externe Testdatensets angewiesen zu sein. Mocks und Stubs eignen sich manchmal besser für Tests, bei denen produktionsähnlicher Datenverkehr oder Datenvolumen nicht relevant sind. - **Geräte und Hilfstechnologien** – Ein wichtiger Teil der Entwicklung [engagierender](/docs/architect/de-de/well-architected/guide/engaging) und [zugänglicher](/docs/architect/de-de/well-architected/guide/compliant#barrierefreiheit) Anwendungen besteht darin, sicherzustellen, dass sie die Erwartungen der Benutzer auf einer Vielzahl von Geräten und mit verschiedenen Arten von Hilfstechnologien erfüllen. Sinnvolle Benutzerfreundlichkeitstests erfordern möglicherweise mehr Investitionen und unterschiedliche Arten von Fachwissen, um effektiv ausgeführt zu werden. Es ist jedoch ein wesentlicher Teil davon, zu wissen, wie gut Ihre benutzerorientierten Anwendungen bei ihrer Veröffentlichung konzipiert sind. - **Simulatoren**: Wenn Sie produktionsähnliche Mengen an Benutzeranforderungen, API-Datenverkehr oder Schwankungen der Netzwerkgeschwindigkeit replizieren müssen, benötigen Sie möglicherweise Tools, die diese Bedingungen simulieren. Nicht jeder Test benötigt diese Investitionshöhe. Diese Tools sind oft am nützlichsten bei Skalierbarkeits- und Leistungstests. - **AI- und Agententests** – Ein primäres Ziel von Tests besteht darin, AI-Halluzinationen zu reduzieren. Hierbei handelt es sich um überzeugende Antworten, die fingiert und falsch sind. Stellen Sie sicher, dass AI-Anwendungsfälle getestet werden, um allgemeine Probleme hervorzuheben, die durch ein unvollständiges Verständnis des Kunden, fehlende Daten, Felder mit unvollständigen Metadaten und veraltete Daten verursacht werden. Verwenden Sie das Testcenter, um beim Erstellen der erforderlichen Testdaten für solche Tests zu helfen. ### ALM-Muster und Anti-Muster In der folgenden Tabelle finden Sie eine Auswahl an Mustern, die in Ihrer Organisation gesucht oder erstellt werden sollen, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für ALM im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/adaptable-application-lifecycle-management) Anti-Muster.

	Muster	Anti-Muster
Versionsverwaltung	In Produktion: - Metadaten zeigen die Verwendung stabiler Versionsmechanismen an, beispielsweise: -- Metadaten werden in entsperrten Paketen organisiert -- DevOps Center aktiv und installiert -- Bereitstellungen über die Metadaten-API im Quellformat - In Bereitstellungsprotokollen werden keine fehlgeschlagenen Bereitstellungen im verfügbaren Verlauf angezeigt. - Der Bereitstellungsverlauf zeigt klare Versionsrhythmen und relativ einheitliche Bereitstellungscluster innerhalb der Versionsfenster an.	In Produktion: - Metadaten geben die Verwendung von organisationsbasierten Versionsmechanismen an, beispielsweise: -- Aktive Nutzung von Änderungssets -- Bereitstellungen über die Metadaten-API verwenden das Format package.xml - Bereitstellungsprotokolle zeigen wiederholte Instanzen fehlgeschlagener Bereitstellungen im verfügbaren Verlauf an. - Bereitstellungen weisen keinen erkennbaren Rhythmus auf oder zeigen ungleichmäßige Cluster von Bereitstellungen, was Anzeichen für Hotfixes und Ad-hoc-Rollbacks sind). - DevOps Center ist nicht aktiviert und installiert.
Versionsverwaltung	In Ihrer Roadmap und Dokumentation: - Die Versionsnamen sind eindeutig. - Funktionen sind eindeutig an eine bestimmte benannte Version gebunden. - Versionsnamen können durchsucht und gefunden werden. - Teams können klare Richtlinien zum Taggen von Artefakten, Entwicklungselementen und anderen Arbeiten mit den richtigen Versionsnamen finden und befolgen. - Es ist möglich, eine klare Ansicht eines Versionsmanifests anhand eines Versionsnamens zusammenzustellen. - Qualitätsschwellenwerte für generative AI-Anwendungen sind für verschiedene Entwicklungsphasen definiert.	In Ihrer Roadmap und Dokumentation: - Versionsnamen sind nicht enthalten. - Funktionen sind nicht eindeutig an eine bestimmte Version gebunden. - Versionsnamen werden ad hoc verwendet oder sind nicht vorhanden. - Teams beziehen sich auf verschiedene Arten auf Artefakte, Entwicklungselemente und andere Arbeiten. - Es ist nicht möglich, eine klare Ansicht eines Versionsmanifests mithilfe eines Versionsnamens zusammenzustellen. - Qualitätsschwellenwerte für generative AI-Anwendungen sind nicht definiert oder falls ja, nicht für verschiedene Entwicklungsphasen.
Umweltstrategie	In Ihren Organisationen: - Es wird ein quellgesteuertes Entwicklungs- und Versionsmodell übernommen. - Die Quellverfolgung ist für Developer- und Developer Pro-Sandbox-Instanzen aktiviert. - Metadaten in einer bestimmten Umgebung sind unabhängig von Versionsartefakten. - Umgebungen entsprechen nicht direkt einem Versionspfad. - Die Freigabepfade für eine Änderung hängen vom Typ der Änderung ab (hohes Risiko, mittleres Risiko oder geringes Risiko). - Überfüllte Umgebungen sind nicht vorhanden. - Riskante Konfigurationsänderungen werden nie direkt in der Produktion vorgenommen. - Während der Hauptgeschäftszeiten erfolgen keine Freigaben. - Data 360-Sandbox-Instanzen werden zum ordnungsgemäßen Testen von Anwendungsfällen für Agenten verwendet, die Einstein Data Library, Knowledge-Artikel und unstrukturierte Daten erfordern	In Ihren Organisationen: - Es wird ein organisationsbasiertes Entwicklungs- und Versionsmodell übernommen. - Die Quellverfolgung ist für Developer- und Developer Pro-Sandbox-Instanzen nicht aktiviert. - Metadaten in einer bestimmten Umgebung sind ein Versionsartefakt. - Umgebungen entsprechen direkt einem Versionspfad. - Der Versionspfad für jede Änderung ist derselbe, unabhängig vom Änderungstyp. - Es gibt überfüllte Umgebungen. - Risikobehaftete Konfigurationsänderungen werden direkt in der Produktion vorgenommen. - Versionen erfolgen während der Hauptgeschäftszeiten. - Agentforce-Agenten, die Einstein Data Library, Knowledge-Artikel und unstrukturierte Daten benötigen, werden nicht mit Data 360-Sandbox-Instanzen getestet
Signalstrategie	In Ihren Organisationen: - Teams arbeiten zusammen an der Definition und Standardisierung von APIs und SLOs für die Integritätsprüfung. - Die regelmäßige Überprüfung und Verfeinerung von Signalisierungsstrategien sind Teil von Obduktionen und Überprüfungen der Betriebsbereitschaft. In Produktion: - Integritätsprüfungen werden für alle Anwendungen implementiert. - Anwendungen stellen explizite Signale über ihren Zustand bereit, beispielsweise ihre Auslastung und ihre Funktionen. - Anwendungen wurden so konzipiert, dass sie sich bei ungesunden Abhängigkeiten empfindlich verschlechtern. - Lastabwurf wird verwendet, um eskalierende Fehler zu verhindern. In Ihrem Design: - Staudruck- und Lastabwurfmechanismen verhindern, dass Services durch Datenverkehr überlastet werden. - Es wird davon ausgegangen, dass Abhängigkeiten letztendlich fehlschlagen. Signal-Handler wurden entwickelt, um Fehler zu beheben.	In Ihren Organisationen: - Teams arbeiten in Silos, wodurch inkonsistente und inkompatible Gesundheitssignalmechanismen entstehen. - Signalisierungsstrategien sind ein nachträglicher Gedanke, der nur bei Auftreten eines Vorfalls behandelt wird. In Produktion: - Komponenten schlagen stumm fehl, ohne ihren Gesundheitsstatus zu signalisieren. - Anwendungen wiederholen Anforderungen an ungesunde Services auf unbestimmte Zeit. - Alle Anfragen werden mit derselben Priorität behandelt, unabhängig von ihrer Bedeutung. - Zur Identifizierung von Problemen verlassen sich die Betreiber ausschließlich auf reaktive Maßnahmen, wie Benutzerbeschwerden oder kritische Systemausfälle. In Ihrem Design: - Es wird davon ausgegangen, dass alle Abhängigkeiten immer verfügbar sind und Netzwerkpartitionen, Latenzspitzen oder andere häufige Probleme nicht berücksichtigt werden. - Anwendungen akzeptieren alle eingehenden Anforderungen, auch wenn sie überlastet sind, was zu einer erhöhten Latenz und einer höheren Fehlerwahrscheinlichkeit führt
Teststrategie	In Ihrem Unternehmen: - Usability Tests verwenden eine Vielzahl von Geräten und Hilfstechnologien. - Simulatoren werden verwendet, um produktionsähnliche Bedingungen für Skalierbarkeits- und Leistungstests zu reproduzieren. - Tests werden automatisiert ausgeführt, wenn Änderungen in die Quellcodeverwaltung gelangen. - Ausdauer-, Stress-, Leistungs- und Skalierungstests werden in mehreren Intervallen im Anwendungsentwicklungszyklus ausgeführt und als fortlaufende Aufgaben betrachtet. - Sie schließen Skalierungstests als Teil Ihres Qualitätsprüfungsprozesses ein, wenn Sie über Anwendungen auf B2C-Skalierung, große Benutzermengen oder große Datenmengen verfügen. - Ihre Skalierungstests konzentrieren sich auf Aspekte mit hoher Priorität des Systems. - Ihre Skalierungstests weisen genau definierte Kriterien auf. - Sie führen Skalierungstests in einer Vollständigen Sandbox durch. - Die Eingabeaufforderungstechnik beinhaltet eine Qualitätsüberprüfung durch einen Menschen. - Agentforce-Testcenter wird für zuverlässige Agententests verwendet.	In Ihrem Unternehmen: - Benutzerfreundlichkeitstests werden nicht oder auf einem begrenzten Satz von Geräten durchgeführt. - Produktionsähnliche Mengen an Benutzeranforderungen, API-Datenverkehr und Variationen der Netzwerkgeschwindigkeit werden nicht getestet. - Testautomatisierung ist nicht vorhanden. - Ausdauer-, Belastungs-, Leistungs- und Skalierungstests gelten als Phase oder Phase der Entwicklung. - Sie führen keine Skalierungstests als Teil Ihres Qualitätsprüfungsprozesses durch und verfügen über B2C-Anwendungen, große Benutzermengen oder große Datenmengen. - Ihre Skalierungstests werden nicht priorisiert. - Ihre Skalierungstests weisen keine genau definierten Kriterien auf. - Sie führen Skalierungstests in einer Teilkopie- oder Developer Sandbox aus. - Das Eingabeaufforderungs-Engineering enthält keine Qualitätsüberprüfung durch einen Menschen. Agentforce Agenten werden nicht oder nur ad hoc mit dem Agentengenerator getestet.
	In Ihrer Organisation: - Alle Testdaten werden von sensiblen und identifizierenden Daten bereinigt.	In Ihrer Organisation: - Testdaten sind identisch mit Produktionsdaten.
	In Apex: - Datenfabrikmuster werden für Einheitentests verwendet - Mocks und Stubs werden verwendet, um API-Antworten zu simulieren.	In Apex: - Einheitentests basieren auf Organisationsdaten. - Mocks und Stubs werden nicht verwendet.
	In Ihren Designstandards und in Ihrer Dokumentation: - Umgebungen werden nach den Testtypen klassifiziert, die sie unterstützen können. - Entsprechende Testregime werden nach Risiko, Anwendungsfall oder Komplexität angegeben.	In Ihren Designstandards und in Ihrer Dokumentation: - Welche Arten von Tests die einzelnen Umgebungen unterstützen, ist nicht klar. - Testregimes werden nicht nach Risiko, Anwendungsfall oder Komplexität kategorisiert.

## Vorfallsreaktion Im Security and Site Reliability Engineering (SRE) konzentriert sich die Vorfallsreaktion darauf, wie Teams Ereignisse identifizieren und beheben, die sich auf die allgemeine Verfügbarkeit oder Sicherheit eines Systems auswirken, sowie darauf, wie Teams daran arbeiten, die Ursachen zu beheben und künftige Probleme zu verhindern. Die Vorfallsreaktion umfasst die Prozesse, Tools und Organisationsverhaltensweisen, die erforderlich sind, um Probleme in Echtzeit zu beheben und nachdem ein Problem aufgetreten ist. Als Architekt sind Sie möglicherweise nicht die Person, die den Betrieb Ihrer Lösung täglich überwacht, sobald sie live geschaltet ist. Ein Teil der Architektur für Resilienz besteht darin, Wiederherstellungsfunktionen zu entwerfen, die es Supportteams ermöglichen, Diagnosen auf der ersten Ebene durchzuführen, Systeme zu stabilisieren und die Untersuchung und die Ursachenminderung effektiv an Entwicklungs- oder Wartungsteams zu übergeben. Teams, die Benutzer täglich direkt unterstützen, verfügen möglicherweise nicht über ein tiefes Verständnis oder Fachwissen in der Architektur des Systems. Für diese Teams ist es wichtig, über die Tools und Prozesse zu verfügen, die sie benötigen, um den täglichen Betrieb zu überwachen, bei der Diagnose eines potenziellen Vorfalls auf Informationen aus dem System zuzugreifen und bei Problemen, die sich auf die Verfügbarkeit auswirken, als effektive Ersthelfer zu fungieren. Sie können verbessern, wie gut Teams auf Vorfälle in Ihren Salesforce-Lösungen reagieren, indem Sie sich auf Ihre [Wiederherstellungszeit](/docs/architect/de-de/well-architected/guide/resilient#zeit-zum-wiederherstellen), [die Triage-Möglichkeit](/docs/architect/de-de/well-architected/guide/resilient#möglichkeit-zum-triage) sowie die [Überwachung und Warnung](/docs/architect/de-de/well-architected/guide/resilient#überwachung-und-warnung) konzentrieren. ### Zeit zum Wiederherstellen Wenn ein Vorfall auftritt, muss die Wiederherstellung der Systeme in einen stabilen Betriebszustand die erste Priorität sein. Oft denken Unternehmen, dass die einzige Möglichkeit, sich von einem Vorfall zu erholen, darin besteht, das Problem zu beheben. Diese Annahme ist insofern gerechtfertigt, als Sie mit einer genauen Ursachenanalyse und -behebung letztlich wichtige Probleme in einem System lösen können. Die „Problembehebung“ in den frühen Phasen der Krisenreaktion ist jedoch nicht der praktischste Ansatz. Abhängig vom Schweregrad eines Vorfalls kann jede Sekunde davon und ihre Auswirkungen zu einem Umsatz- oder Ansehensverlust für das Unternehmen führen. Häufig führt der Versuch, Stammdaten zu diagnostizieren und zu beheben, zu Verzögerungen bei den Bemühungen, ein System wieder in Betrieb zu nehmen. Logistisch gesehen bedeutet dies, dass ein Ansatz, bei dem Vorfallshelfer aufgefordert werden, die Ursachen zu beheben, eine enorme Belastung für die Experten (KMU) und die Supportmitarbeiter in Ihrem Unternehmen darstellt. Wenn Sie _während_ eines Vorfalls nach den Ursachen suchen und sie beheben möchten, müssen KMU bei jedem Vorfall auf Abruf sein, was dazu führen kann, dass Supportmitarbeiter mit direktem Kundenkontakt keine Maßnahmen ergreifen können. Es kann auch dazu führen, dass Teams Änderungen veröffentlichen, die wiederum zu mehr Vorfällen führen. Letztlich erhöht ein solcher Ansatz die Kosten, verbraucht Bandbreite über mehrere Teams hinweg und führt zu Verhaltensweisen in Krisenzeiten, die das Trust der Kunden und das Ansehen der Marke untergraben können. Das richtige Paradigma für die Vorfallsverwaltung besteht darin, die Wiederherstellung als ersten Schritt zu priorisieren und sich darauf zu konzentrieren. Nachdem ein System wieder stabil ist, können Sie schuldlose Obduktionen, Vorfallsuntersuchungen, Ursachenbehebungen und ähnliche Aktivitäten durchführen. Diese Reihenfolge der Vorgänge ermöglicht es Mitarbeitern der Vorfallsreaktion besser, Taktiken zur Behebung von Vorfällen zu testen, zu diagnostizieren und auszuführen, wodurch relevante KMU darauf hingewiesen werden, nur bei Bedarf zu helfen. Sie ermöglicht es KMU auch, die Ursachen eines Vorfalls zu identifizieren und zu beheben, ohne den Druck durch eine tickende Uhr zu verringern. Übernehmen einer Einstellung vom Typ "Wiederherstellung zuerst" zur Vorfallsantwort: - **Erstellen und erreichen Sie Service Level Objectives SLOs**. SLOs sind Standards, die Sie zusammen mit Ihren Beteiligten für bestimmte nicht funktionale Anforderungen eines Systems wie Leistung oder Betriebszeit entwickeln. Diese Ziele werden anhand von Service Level Indicators (SLIs) über einen bestimmten Zeitraum gemessen. Ohne SLOs kann sich ein Großteil der Arbeit im Zusammenhang mit der Reaktion auf Vorfälle und der Fehlerbehebung bei komplexen Problemen unorganisiert und reaktiv anfühlen. Dies kann beispielsweise dazu führen, dass bei einer Handvoll Benutzer, die diesen Fehler gemeldet haben, schnell gehandelt wird, um "diesen spezifischen Fehler zu beenden". Dieser Zyklus ist es oft, der Teams dazu veranlasst, die Ursachenanalyse näher an die Reaktion auf Vorfälle heranzutreiben, da er anscheinend dazu beiträgt, das reaktive Verhalten zu stoppen. Das Einrichten von SLOs und SLIs ist eine effektivere Methode. Denken Sie zum Einrichten von SLOs über die folgenden Fragen nach. - **Wie hoch ist der nationale Finanzierungsrahmen Ihres Systems für die nächsten 1–3 Jahre?** Beispielsweise kann Ihr NFR die Antwortzeiten, Spitzenanforderungsraten und gleichzeitigen Benutzer enthalten, die von Ihrem System unterstützt werden müssen. - **Was sollen Ihre Kunden und ihre Benutzer erleben?** Legen Sie für Ihre SLOs die Antwort auf diese Frage zugrunde, die beispielsweise lautet: "Benutzer können Berichte schnell in Salesforce ausführen". - **Was können Sie messen und für welchen Zeitraum sollten Sie es messen?** Basieren Sie Ihre SLIs auf der Antwort auf diese Frage. Ein SLI, der mit dem vorherigen Beispiel übereinstimmt, kann "_x_ % der Berichte werden im Durchschnitt innerhalb von _n_ Sekunden geladen, gemessen über einen Zeitraum von 30 Tagen" lauten. - **Definieren und standardisieren Sie Wiederherstellungstaktiken.** Änderungs-Rollbacks und Übergangsimplementierungen können dazu beitragen, dass ein System wieder funktionsfähig wird und die Auswirkungen eines Vorfalls minimiert werden. Dokumentwiederherstellungstaktiken und -protokolle, die von den entsprechenden Mitgliedern Ihrer Support- oder Betriebsteams ausgeführt werden können. Die Wiederherstellungstaktiken unterscheiden sich je nach Vorfallstyp. Die nächste Tabelle zeigt ein allgemeines Framework, das Vorfallstypen den Wiederherstellungstaktiken zuordnet. Weitere Informationen zum Identifizieren von Fehlerpunkten und zum Definieren von Abhilfestrategien finden Sie unter [Verfügbarkeit](/docs/architect/de-de/well-architected/guide/reliable#verfügbarkeit).

Vorfallstyp	Scheinbarer Auslöser	Wiederherstellungstaktiken
Systemausfall	Beschädigte Anmeldungen oder Probleme beim Accountzugriff	Eine Richtlinie zur Accountwiederherstellung
Systemausfall	Service-Nichtverfügbarkeit	Aktivieren redundanter Sicherungsservices; manuelle Übergangslösungen
Produktionsfehler	Eine aktuelle Änderung	Bereitstellungs-Rollback oder Bereitstellung der vorherigen Version
Produktionsfehler	Ein auftauchender, nicht erklärter Fehler	Manuelle Übergangslösungen, Deaktivieren nicht wesentlicher Funktionen, Eskalation zu KMU

- **Definieren Sie klare Beendigungskriterien**. Verwenden Sie Ihre SLOs, um zu bestimmen, wann Ihr System den Vorfalls- oder Auswirkungsstatus verlässt. - **Definieren Sie Prozesse für die Überprüfung nach einem Vorfall und die Beseitigung der Ursache.** Nehmen Sie sich Zeit, um Vorfälle nach der Wiederherstellung des Service zu überprüfen. Verfolgen Sie bei Überprüfungen einen _fehlerfreien postmortalen_ Ansatz. Arbeiten Sie mit Beteiligten zusammen, um sich darauf zu konzentrieren, klare Fakten darüber zu schaffen, _was_ passiert ist und _wie_ es passiert ist, statt zu versuchen, Fehler oder Schuldzuweisungen Einzelpersonen zuzuordnen. Verwenden Sie verschiedene Überprüfungsformate, um zu untersuchen, wie Probleme langfristig behoben werden können. - Eine _Überprüfung nach der_ Aktion konzentriert sich auf die Reaktion auf den Vorfall. Dies ist nützlich, um zu bewerten, ob die entsprechenden Antwortprozesse und -taktiken vorhanden sind. - Eine _Ursachenanalyse_ konzentriert sich auf die Ursache des Vorfalls. Dadurch können Fehler oder Probleme im Design und in der Implementierung Ihres Systems identifiziert werden, die zu dem Vorfall geführt haben. - **Üben Sie Ihre vereinbarten Wiederherstellungsprotokolle regelmäßig aus**. Üben Sie Wiederherstellungsprotokolle, um sicherzustellen, dass jeder weiß, wie er Vorfälle gut verarbeiten kann. Verwenden Sie Sandbox-Instanzen und Testumgebungen, um Teams die Möglichkeit zu geben, die Simulation und Wiederherstellung von Vorfällen zu üben. Üben Sie auch Ihre Überprüfungen nach dem Vorfall. Durch all diese Übungen wird die Wiederherstellung zu einem Teil Ihrer Engineering- und Supportkultur. Die [Muster und Anti-Muster für](/docs/architect/de-de/well-architected/guide/resilient#vorfallsreaktionsmuster-und-anti-muster) die Vorfallsreaktion zeigen, wie die Planung zur Priorisierung der Wiederherstellung in einer Salesforce-Lösung aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools, die Ihnen bei der Wiederherstellung helfen, finden Sie unter [Salesforce-Tools für Resilienz](/docs/architect/de-de/well-architected/guide/resilient#salesforce-tools-für-resilienz). ### Möglichkeit zum Triage Im Kontext der Technologie beinhaltet die Triaging-Erfahrung die Zuweisung von Kategorien und Schweregraden zu Problemen und Supportanforderungen. Unabhängig davon, wie gut Ihre Lösung geplant ist, treten Probleme und Anforderungen beim Benutzersupport auf. Diese Probleme können auf ein unzureichendes Schulungs- oder Änderungsmanagement, Lücken auf der Benutzeroberfläche/UX, unerwartetes Endbenutzerverhalten und dringende Systemprobleme zurückzuführen sein, die nicht durch [Überwachung oder Warnung](/docs/architect/de-de/well-architected/guide/resilient#überwachung-und-warnung) erkannt werden. Support- und Betriebsteams müssen in der Lage sein, Benutzersupportanfragen effizient zu untersuchen und schnell zu diagnostizieren. Das Ausprobieren von Problemen, um weniger schwerwiegende Bedenken herauszufiltern und wichtige Systemvorfälle schnell zu erkennen, ist eine Schlüsselkompetenz für diese Teams. Schlechte Triaging verlangsamt alle Ebenen der Benutzerunterstützung, verlängert wichtige Vorfälle und erhöht das Risiko weiterer Unterbrechungen für Ihre Kunden und Ihr Unternehmen. Auch wenn Sie möglicherweise nicht am täglichen Betrieb und Support beteiligt sind, liegt es als Architekt in Ihrer Verantwortung, sicherzustellen, dass Ihre Support- und Betriebsteams Probleme in jeder Lösung, die Sie auf Salesforce Platform erstellen, effektiv bewältigen können. Ermöglichen, dass Teams Probleme in Ihren Salesforce-Lösungen effektiv bearbeiten können: - **Stellen Sie sicher, dass Supportteams auf nützliche Informationen zugreifen können.** - **Dokumentieren Sie Ihr System und Ihre Designmuster**. Die Gewährleistung der [Lesbarkeit](/docs/architect/de-de/well-architected/guide/intentional#lesbarkeit) und Konsistenz in Ihrer Lösung ist ein wichtiger Teil, damit die Supportmitarbeiter das System verstehen, für das sie verantwortlich sind. Überlegen Sie in Ihrer Dokumentation, wie Teams Informationen dazu finden, wie sie Probleme oder Vorfälle mit verschiedenen Teilen des Systems priorisieren können. Stellen Sie außerdem sicher, dass Teams schnell technische Informationen zu Wiederherstellungstaktiken basierend auf dem jeweiligen Auswirkungsbereich erhalten. Stellen Sie relevante Anleitungen zur Fehlerbehebung bei häufigen Agentforce-Problemen bereit, beispielsweise "Themenklassifizierung" und "Aktionsauswahl", mit denen Teams Probleme im Zusammenhang mit Berechtigungen oder Konfigurationen schnell lösen können. - **Design unter Berücksichtigung des Debuggings**. Supportteams und Organisationsadministratoren müssen das Debugging und die Diagnose aktivieren, um Benutzerprobleme in verschiedenen Umgebungen richtig zu bearbeiten. Beispiele für _debugfreundliche_ Muster sind solche, die Protokollierung und benutzerdefinierte Fehlermeldungen in Ausführungspfade im gesamten System integrieren. Aktivieren Sie Supportteams für allgemeine Agentforce-Debugging-Ansätze mit Tools wie Ereignisprotokollen und der Ansicht mit Gründen des Agentengenerators. - **Identifizieren von KMU und Beteiligten** bei Vorfällen. Erstellen Sie eine Liste der relevanten KMU oder Beteiligten, die zur Unterstützung der Wiederherstellung nach einem Vorfall zur Verfügung stehen und bei der Analyse nach einem Vorfall beteiligt sein sollten. - **Behandeln Sie Übergaben mit Bedacht**. Stellen Sie die Qualität der einzelnen Lösungsübergaben an Support- oder Betriebsteams im Rahmen der Liveschaltung sicher. Bieten Sie Supportmitarbeitern Schulungen an, um die relevante Systemarchitektur und Übungen zur simulierten Reaktion auf Vorfälle zu durchlaufen. Denken Sie an Übergaben nach einem Vorfall, einschließlich der Art und Weise, wie Teams Informationen dokumentieren sollten, die nicht in Protokollen oder Kundenvorgangsnotizen erfasst werden, und wie Vorfallshelfer zu Ursachenermittlungen beitragen oder Benutzerakzeptanztests für Korrekturen durchführen können. - **Wenn Sie konsultiert werden, konzentrieren Sie sich auf die Wiederherstellung als oberstes Anliegen.** - **Reagieren Sie schnell.** Reagieren Sie schnell auf Supportanfragen, Überwachungsbenachrichtigungen und Benachrichtigungen, die Sie erhalten. - **Helfen Sie, Symptome von Problemen zu unterscheiden.** Stellen Sie fest, ob tatsächlich ein Systemvorfall vorliegt, der behoben werden muss. Versuchen Sie, die Komponenten mit den tatsächlichen Problemen zu identifizieren. Stellen Sie sicher, dass die vereinbarten [Wiederherstellungstaktiken](/docs/architect/de-de/well-architected/guide/resilient#zeit-zum-wiederherstellen) befolgt werden, um das System schnell aus dem Vorfallsstatus zu entfernen. - Stellen Sie für Agentforce-Agenten, die wichtige Anwendungsfälle unterstützen, sicher, dass tragfähige und relevante Übergangslösungen vorhanden sind und kurzfristig als Redundanzmaßnahme aktiviert werden können. Beispiele sind der Wechsel zur manuellen Handhabung oder die Umleitung zu relevanten Dokumentationen zur manuellen Überprüfung. Die [Muster und Antimuster für](/docs/architect/de-de/well-architected/guide/resilient#vorfallsreaktionsmuster-und-anti-muster) die Vorfallsreaktion zeigen, wie die Architektur für eine effektive Triaging-Lösung in Salesforce aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools zur Unterstützung beim Triaging finden Sie unter [Salesforce-Tools für Resilienz](/docs/architect/de-de/well-architected/guide/resilient#salesforce-tools-für-resilienz). ### Überwachung und Warnung _Überwachung_ und _Warnung_ sind weit verbreitete Begriffe in der Technik der Standortzuverlässigkeit. Im Kontext der Systemresilienz wird der aktuelle Zustand eines Systems kontinuierlich durch die Überwachung bewertet und durch Warnungen werden Benachrichtigungen an Beteiligte über potenzielle Bedenken hinsichtlich des Systemzustands automatisiert. Eine effektive Überwachung und Warnung ist ein wichtiger Teil der Entkopplung von Umfang und Wachstum Ihres Systems von Umfang und Wachstum Ihrer Supportmitarbeiter. Salesforce bietet eine Vielzahl integrierter Funktionen zum Überwachen des Verhaltens in Ihrem System. Salesforce bietet auch eine [Echtzeit-Ereignisüberwachung](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/real_time_event_monitoring_overview.htm) als Add-On oder als Teil von [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/). In jeder Salesforce-Lösung bieten die für die Überwachung und Warnung konzipierten Designs Folgendes: - Funktionen für die automatische Reaktion auf Vorfälle - Relevante Informationen für die richtigen Benutzer zur richtigen Zeit - Klare Informationen für historische Ansichten und Trendanalysen Entwerfen einer effektiven Überwachung und Warnung innerhalb Ihrer Salesforce-Lösungen: - **Legen Sie die Automatisierung als Priorität fest**. Auch wenn die Benachrichtigung von Benutzern über wichtige Statusänderungen ein entscheidender Bestandteil ist, um Ihre Systeme stabil und funktionsfähig zu halten, korrigiert das System Probleme nach Möglichkeit selbst und sendet nur Benachrichtigungen für dringende, nicht behebbare Probleme. Auch ohne Funktionen zur Selbstkorrektur kann die Automatisierung Ihre Benachrichtigungen und Berichte nützlicher machen. - **Beginnen Sie mit dem, was Salesforce bereits bereitstellt**. Die Salesforce Platform stellt relevante Protokolle und APIs bereit, mit denen Sie die Vorgänge Ihrer Lösung hinsichtlich der Obergrenzen überwachen können. Darüber hinaus sendet die Plattform Benachrichtigungen bei Verstößen gegen die Obergrenze und ähnlichen Problemen. Verwenden Sie diese Protokolle und Warnungen als Grundlage für die Erkundung von Möglichkeiten zur vollständigen Automatisierung der Systemselbstwiederherstellung, Vorfallsberichte und Warnungen. Beispielsweise können Sie eine Automatisierung implementieren, die das Protokoll überwacht und dann eine Wiederherstellungsaktion ausführt, wenn ein bestimmter Ereignistyp protokolliert wird. - **Klassifizieren Sie Änderungen am Systemstatus auf vorhersehbare Weise**. Erstellen Sie bestimmte aussagekräftige Kategorien für wichtige Status, die Sie überwachen und in Berichten behandeln möchten. Richten Sie diese Kategorien an den Kategorien aus, die Sie zum Verwalten des Status in Ihren [Anwendungskomponenten](/docs/architect/de-de/well-architected/guide/composable#bundesstaatsverwaltung) definieren. Übernehmen Sie eine [API-orientierte](/docs/architect/de-de/well-architected/guide/composable#api-management) Einstellung für die Handhabung von Statusänderungsinformationen. Konsistente Nachrichtenformate und Statuskategorien vereinfachen die Automatisierung, Berichterstellung und Benachrichtigung. - **Passen Sie Ihre Automatisierungslogik an die anderen Teile Ihres Systems an.** Wenn Sie eine ordnungsgemäße Automatisierungsfehler[-Handhabung](/docs/architect/de-de/well-architected/guide/automated#fehlerbehandlung) erstellt haben, können Sie diese Muster erweitern, um Statusänderungen zu klassifizieren und mit Automatisierung zu reagieren. Bei Statusänderungen, die als wiederherstellbar gelten, können Sie das Wiederholungsverhalten automatisieren. Automatisieren Sie bei Statusänderungen, die als kritisch oder tödlich eingestuft werden, Benachrichtigungen an Benutzer. - **Vermeiden Sie Geräusche**. Wenn Benutzer zu viele Benachrichtigungen erhalten, insbesondere Benachrichtigungen, die keine Maßnahmen erfordern, neigen sie dazu, alle Benachrichtigungen zu deaktivieren oder zu ignorieren. Dieses Szenario untergräbt alle Bemühungen, [hilfreiche](/docs/architect/de-de/well-architected/guide/engaging#hilfreich) Benachrichtigungen zu erstellen. Wenn Sie genauer festlegen möchten, wer Benachrichtigungen erhält, was sie auslöst und wann sie ausgelöst werden, sollten Sie die folgenden Schritte in Erwägung ziehen. - **Erstellen Sie Zuordnungen zu Beteiligten**. Identifizieren und klassifizieren Sie zunächst Ihre Beteiligtengruppen, um sicherzustellen, dass Ihr System die richtigen Benachrichtigungen zur richtigen Zeit an die richtigen Beteiligten sendet. - **Weiterleiten von Nachrichten anhand von Benutzerberechtigungen**. Senden Sie Benachrichtigungen nur an Empfänger, die über die Fähigkeit und Befugnis zum Antworten verfügen. Geschäftsbenutzer können von Benachrichtigungen zu Problemen profitieren, die sie beheben können, indem sie Probleme in Datensätzen korrigieren, auf die sie Zugriff haben. Wenn ein Problem eine komplexere technische Antwort erfordert, sollten Benachrichtigungen an das Supportpersonal gerichtet werden. - **Mach die erwartete Antwort deutlich**. Senden Sie Benachrichtigungen nur in Szenarien, in denen ein menschliches Eingreifen erforderlich ist. Strukturieren Sie Nachrichten so, dass sie die vom Empfänger erwartete Aktion eindeutig angeben. Wenn Sie eine Benachrichtigung zur Sichtbarkeit an einen Beteiligten senden und dieser keine Maßnahmen ergreifen muss, machen Sie dies in der Version der Nachricht deutlich, die er erhält. - **Mach Benachrichtigungen rechtzeitig und relevant**. Warnungen, die als Reaktion auf auf aufgetretene Fehler bereitgestellt werden und noch behoben werden müssen) sind nicht so hilfreich wie Warnungen über einen potenziellen Fehler. Im Idealfall werden Supportmitarbeiter benachrichtigt, sobald problematische Bedingungen im System auftreten, was die Möglichkeit bietet, Probleme [zu testen](/docs/architect/de-de/well-architected/guide/resilient#möglichkeit-zum-triage), bevor sie negative Auswirkungen auf den Geschäftsbetrieb haben können. Die Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/resilient#vorfallsreaktionsmuster-und-anti-muster) zeigt, wie die Architektur für eine effektive Überwachung und Warnung in einer Salesforce-Lösung aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder Bereiche Ihres Systems zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools zur Überwachung und Warnung finden Sie unter [Salesforce-Tools für Resilienz](/docs/architect/de-de/well-architected/guide/resilient#salesforce-tools-für-resilienz). ### Vorfallsreaktionsmuster und Anti-Muster Diese Tabelle zeigt eine Auswahl an Mustern, die in Ihrer Organisation gesucht oder erstellt werden sollen, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Reaktion auf Vorfälle im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/adaptable-incident-response) Anti-Muster.

	Muster	Anti-Muster
Zeit zum Erholen	In Ihrem Unternehmen: - Wiederherstellungsprotokolle werden in regelmäßigen Abständen geübt. - Teams wissen, welche Services in der Produktion sie besitzen und für welche sie verantwortlich sind. - Teams kennen die relevanten Tools zur Unterstützung der Diagnose von Problemen.	In Ihrem Unternehmen: - Wiederherstellungsprotokolle sind nicht vorhanden oder werden nicht in regelmäßigen Abständen praktiziert. - Welche Teams Inhaber und verantwortlich für die verschiedenen Services in der Produktion sind, ist nicht klar. - Teams verfügen nicht über Anleitungen oder Standards für Tools zur Unterstützung der Diagnose von Problemen.
	In Ihrer Dokumentation: - Wiederherstellungstaktiken werden nach Vorfallstyp und Auslöser definiert und klassifiziert. - Beendigungskriterien für Vorfallsantworten sind in SLOs enthalten und klar. - Aktivierungskriterien und Zuweisungslogik für erhöhte Berechtigungen bei Vorfällen sind klar. - Berechtigungssätze und Autorisierungen für Vorfallsantworten sind klar aufgeführt. - Es gibt eine Anleitung zur Fehlerbehebung, die bei der Identifizierung und Diagnose häufiger Probleme hilft.	In Ihrer Dokumentation: - Vorfallsantwort wird ad hoc ausgeführt. - Beendigungskriterien für Vorfallsantworten sind nicht vorhanden. - Erhöhte Berechtigungen werden nicht zugewiesen oder wenn sie es sind, werden sie ad hoc zugewiesen. - Berechtigungssätze und Autorisierungen für Vorfallsantworten sind nicht aufgeführt.
	In Ihrer Organisation: - Sitzungsbasierte Berechtigungssätze für die Reaktion auf Vorfälle sind vorhanden und können während der Wiederherstellung dem Supportpersonal zugewiesen werden. - Setup-Aktivierungsprotokoll zeigt, dass sich angegebene Wiederherstellungstester zum vereinbarten Zeitpunkt bei der Testumgebung angemeldet haben und Wiederherstellungstestskripts befolgt haben.	In Ihrer Organisation: - Sitzungsbasierte Berechtigungssätze sind für die Vorfallsantwort nicht vorhanden. Andernfalls sind die Supportmitarbeiter nicht autorisiert, sie zu verwenden. - Setup-Aktivierungsprotokoll zeigt, dass sich angegebene Wiederherstellungstester nicht bei der Testumgebung angemeldet haben oder Wiederherstellungstestskripts nicht gefolgt sind
	In Ihren Testplänen: - Testskripts für Wiederherstellungstests sind vorhanden und können wiederholt werden. - Umgebungen für Vorfallssimulationen sind übersichtlich aufgeführt.	In Ihren Testplänen: - Testskripts für Wiederherstellungstests sind nicht vorhanden. - Umgebungen für Vorfallssimulationen werden nicht eingerichtet.
Möglichkeit zum Testen	In Ihrem Unternehmen: - KMU oder Beteiligte, die benachrichtigt werden sollten, um komplexe Probleme zu unterstützen, werden identifiziert, bevor ein Vorfall auftritt. - Die Übergabe zwischen Zustellungs- und Supportteams ist Teil des Go-live. - Bei Rücksprache reagieren Salesforce-Architekten schnell und helfen dem Team, sich auf die Wiederherstellung zu konzentrieren.	In Ihrem Unternehmen: - KMU oder Beteiligte, die benachrichtigt werden sollten, werden erst identifiziert, wenn ein Vorfall auftritt. - Die Übergabe zwischen Zustellungsteams und Supportteams ist kein Teil des Versionsprozesses. - Salesforce-Architekten betrachten die Reaktion auf Vorfälle als außerhalb ihres Arbeitsbereichs.
	In Ihrer Dokumentation: - System- und Designmuster, die in einer bestimmten Lösung verwendet werden, sind erkennbar und für Supportmitarbeiter lesbar.	In Ihrer Dokumentation: - System- und Designmuster, die in einer bestimmten Lösung verwendet werden, sind für Supportmitarbeiter nicht ohne Weiteres verfügbar.
	In Ihrer Organisation: - Protokollierung und benutzerdefinierte Fehlermeldungen werden in Ausführungspfade im gesamten System integriert.	In Ihrer Organisation: Protokollierung und benutzerdefinierte Fehlermeldungen werden nicht verwendet.
Überwachung und Warnung	In Ihrer Organisation: - Benachrichtigungen werden nur verwendet, um Benutzer über Szenarien zu informieren, in denen ein menschliches Eingreifen erforderlich ist. Andere Fehler werden protokolliert und gemeldet. - Benachrichtigungen werden an Benutzer gesendet, die in der Lage sind, auf sie zu antworten. - Wenn möglich, werden Warnungen vor einem potenziellen Fehler zugestellt.	In Ihrer Organisation: - Es werden Benachrichtigungen gesendet, wenn eine beliebige Art von Fehler auftritt, unabhängig davon, ob Folgeaktionen erforderlich sind. - Benachrichtigungen zu Problemen, die technische Lösungen erfordern, werden Geschäftsbenutzern bereitgestellt. - Benachrichtigungen werden nur als Reaktion auf bereits aufgetretene Fehler zugestellt.
Überwachung und Warnung	In Ihrer Dokumentation: - Die Eingabekriterien für Benachrichtigungen zur Aufforderungsabstimmung werden auf der Grundlage direkter und indirekter Feedbackkennzahlen für generative AI definiert.	In Ihrer Dokumentation: - Es sind keine Kriterien für das Auslösen von Aufforderungs-Tuning-Benachrichtigungen für generative AI-Anwendungen definiert.

## Kontinuitätsplanung Ein Schlüssel zur Geschäftsresilienz ist die Kontinuitätsplanung, die sich darauf konzentriert, wie Personen und Systeme bei Problemen funktionieren können, die durch ein ungeplantes Ereignis verursacht werden. Business Continuity-Pläne (BCPs) nehmen eine menschenorientierte Sichtweise ein, um Prozesse durch die Krise zu führen. Technische Aspekte der Kontinuitätsplanung sind in den Notfallwiederherstellungsabschnitten eines BCP enthalten. Siehe [Technologiekontinuität](/docs/architect/de-de/well-architected/guide/resilient#technologiekontinuität). Ohne geeignete Kontinuitätspläne weiß Ihre Organisation nun möglicherweise, wie sie bei einem Krisen- oder Systemausfall handeln muss – und daher überhaupt nicht. Eine ineffektive Kontinuitätsplanung kann katastrophale Auswirkungen auf Kunden, Beteiligte und Unternehmen haben. Im Nachgang eines unerwünschten Ereignisses riskiert jeder Moment, der vergeht, ohne wichtige Prozesse aufrechtzuerhalten oder wiederherzustellen, finanzielle Schäden, Ansehensschäden, die Sicherheit der Mitarbeiter und sogar die Einhaltung gesetzlicher Vorschriften. Sie können eine bessere Kontinuitätsplanung in Ihre Systeme integrieren, indem Sie sich auf drei Bereiche konzentrieren: [Definieren der Geschäftskontinuität für Salesforce](/docs/architect/de-de/well-architected/guide/resilient#geschäftskontinuität), [Planen der Technologiekontinuität](/docs/architect/de-de/well-architected/guide/resilient#technologiekontinuität) und [Erstellen von Sicherungs- und Wiederherstellungsfunktionen](/docs/architect/de-de/well-architected/guide/resilient#erstellen-von-sicherungs--und-wiederherstellungsfunktionen). ### Geschäftskontinuität Ihr Unternehmen verfügt möglicherweise bereits über ein BCP. Stellen Sie in diesem Fall sicher, dass Salesforce darin enthalten ist. Wenn Ihr Unternehmen nicht über eine BCP verfügt, erstellen Sie zusammen mit Ihren Beteiligten eine, die Ihre Salesforce-Organisationen abdeckt. Salesforce wird oft als verlässliche Datenquelle für Kundendaten und wichtige Geschäftsprozesse in vielen Geschäftsbereichen angesehen. Daher kann sich die Rolle, die Salesforce in einem BCP spielt, von der Rolle anderer Systeme unterscheiden. Es ist wahrscheinlich, dass Salesforce in vielen Bereichen mit hoher Priorität für die Wiederherstellung tätig sein wird. Erstellen einer relevanten Geschäftskontinuitätsplanung für Salesforce-Systeme: - **Klarstellen von Prioritäten für die Wiederherstellung**. Wie beim allgemeinen Ansatz für die [Vorfallsreaktion](/docs/architect/de-de/well-architected/guide/resilient#vorfallsreaktion) muss auch bei den Systemen in Krisenzeiten die Wiederherstellung an erster Stelle stehen. Viele geschäftskritische Services werden in und mit Salesforce ausgeführt. Sie müssen Beteiligten helfen, die richtige Priorität für die Wiederherstellung verschiedener Geschäftsfunktionen und -funktionen zu ermitteln. Ein allgemeiner Rahmen könnte sein: - Stabilisieren Sie die wichtige Geschäftsinfrastruktur. - Stabilisieren Sie den Kundendienst. - Stabilisieren Sie Mitarbeiter- und Partnerservices. - **Berücksichtigen Sie Ihr Ökosystem in Ihren BCPs**. Salesforce ist nicht das einzige System in Ihrer Landschaft. Stellen Sie sicher, dass Sie Lücken in Ihrem BCP in Bezug auf Systeme identifizieren, die in Salesforce integriert werden, Lösungen, die von AppExchange-Anbietern installiert wurden, und alle anderen Systeme, die eine Verbindung mit Daten oder Prozessen in Salesforce herstellen. Wenn Ihre Bereitstellungsfähigkeit von Anbietern abhängt, fragen Sie diese Anbieter nach ihren Kontinuitätsplänen. Bewerten Sie ihre Funktionen und planen Sie, wie Sie Ihre Systeme verfügbar halten können. - **Integrieren Sie BCP-Anliegen in Ihre Teststrategie.** Erstellen Sie Testpläne für Ihr BCP und führen Sie sie aus. Es ist besonders wichtig, die Bereiche Ihres BCP in Bezug auf Prozesse oder Personen zu testen, die oft übersehen werden. Integrieren Sie relevante Elemente aus Ihrem BCP in Ihre allgemeine ALM-[Teststrategie](/docs/architect/de-de/well-architected/guide/resilient#teststrategie). Erstellen Sie einen Wartungsplan und befolgen Sie ihn, um Tests zu überprüfen und sicherzustellen, dass Ihr Plan auf dem neuesten Stand bleibt. Die [Muster und Anti-Muster für die](/docs/architect/de-de/well-architected/guide/resilient#kontinuitätsplanungsmuster-und-anti-muster) Kontinuitätsplanung zeigen, wie eine ordnungsgemäße und schlechte Kontinuitätsplanung in einer Salesforce-Lösung aussieht. Verwenden Sie sie, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools zum Definieren der Geschäftskontinuität finden Sie unter [Salesforce-Tools für Resilienz](/docs/architect/de-de/well-architected/guide/resilient#salesforce-tools-für-resilienz). ### Technologiekontinuität Das Ziel der Technologiekontinuität besteht darin, sicherzustellen, dass Probleme mit Komponenten in einem System das Unternehmen nicht daran hindern, wichtige Vorgänge aufrechtzuerhalten. Salesforce priorisiert die Aufrechterhaltung unserer Services auf höchster Verfügbarkeitsebene und stellt transparente Informationen zu Problemen bereit. Unter [Trust.salesforce.com](https://trust.salesforce.com/) können Sie Echtzeitinformationen zur Leistung und zu Problemen des Salesforce-Systems einsehen. Als Architekt, der auf Salesforce aufbaut, profitieren Ihre Lösungen von der Zuverlässigkeit, Sicherheit und Leistung der Site, die Salesforce auf der gesamten Plattform bietet. Die Gesamtkontinuität Ihrer Salesforce-Lösungen geht jedoch über die von Salesforce bereitgestellten integrierten Services hinaus. Aus architektonischer Sicht muss die Planung der Technologiekontinuität von Salesforce damit beginnen, Fragen zu stellen und zu beantworten, wie Salesforce in Ihre größere Unternehmenslandschaft passt. Welche Arten von Systemen sind in Salesforce integriert? Wie hängen externe Systeme von Prozessen oder Informationen in Salesforce ab? Welche Prozesse oder Funktionen basieren in Ihren Salesforce-Organisationen auf AppExchange-Lösungen? Greifen Ihre Benutzer über Identitätsdienste oder SSO von Drittanbietern auf Salesforce zu? Bessere Technologiekontinuität in Ihren Salesforce-Systemen: - **Bewerten Sie Ihre Infrastruktur.** Die häufigste Strategie zur Behebung von Technologieausfällen oder Problemen besteht darin, redundante Services oder Systeme zu erstellen, auf die Sie während eines Vorfalls zurückgreifen können. Bei Salesforce verfügen wir über eine absichtlich redundante Architektur, d. h., wir pflegen Kopien der Systeme und Services unserer Kunden an unterschiedlichen physischen Standorten. Es werden verschiedene Notfallwiederherstellungstechniken verwendet, einschließlich des Site-Wechsels, wodurch der Benutzerdatenverkehr bei Bedarf von einem Rechenzentrum zum anderen umgeleitet werden kann. Stellen Sie sich diese Fragen, um zu ermitteln, wo Sie möglicherweise eine absichtliche Redundanz aufbauen müssen. - Was geschieht während einer Serviceunterbrechung für den \[X]-Service? Können wir von diesem Service zu einem anderen wechseln? - Wie lange dauert die Wiederherstellung \[X]? Welche Auswirkungen hat dies auf unsere Kunden? Welche Auswirkungen hat dies auf unsere Partner? Welche Auswirkungen hat dies auf interne Teams? - Was ist mit [Backups](/docs/architect/de-de/well-architected/guide/resilient#erstellen-von-sicherungs--und-wiederherstellungsfunktionen) und ihrer Häufigkeit? Können die Sicherungen die Daten bereitstellen, die zur Unterstützung des Unternehmens erforderlich sind? - Haben wir Abhängigkeiten von Anbietern? Wie sehen ihre BCP-Pläne aus? - **Bieten Sie betriebliche Unterstützung.** Bei der operativen Unterstützung geht es darum, Teams so schnell wie möglich wieder einsatzbereit zu machen. Überlegen Sie, wie Ihr System mit deutlich gestiegenen Kapazitätsanforderungen und Nachfrage aufgrund unerwarteter Änderungen umgehen kann, einschließlich branchenweiter, regionsweiter oder globaler Änderungen. Stellen Sie sicher, dass Ihr BCP die zusätzlichen Ressourcen oder Brillenglasverfahren berücksichtigt, die Site Reliability Engineering (SRE) oder Supportteams möglicherweise benötigen, um effektiv auf Vorfälle zu reagieren. Zu den Fragen zur betrieblichen Unterstützung zählen: - Verfügen unsere technischen Teams bei einem Ausfall über die Tools, die sie benötigen, um ihre Arbeit fortzusetzen? Haben wir einen Ausfall simuliert, um Pläne zu validieren oder Lücken zu identifizieren? - Wenn sich eine Katastrophe in einem bestimmten Gebiet befindet, gibt es dann Abdeckungspläne für dieses Gebiet? - Sind unsere Kunden global? Arbeiten sie rund um die Uhr? - Verfügen wir über eine ordnungsgemäße [Überwachung und Warnung](/docs/architect/de-de/well-architected/guide/resilient#überwachung-und-warnung), um die entsprechenden Personen bei Ausfällen zu benachrichtigen? - **Automatisieren und testen Sie Ihre Wiederherstellungstaktiken.** Identifizieren Sie nach der Behebung eines Problems, wo es aufgetreten ist und wie es behoben wurde. Automatisieren Sie nach Möglichkeit Ihre Wiederherstellungstaktiken und passen Sie alle Prozessprobleme an. Viele Unternehmen planen Vorfallssimulationen für eine Teilmenge von Services, um die Systemresilienz zu testen. Ein Beispiel kann die Simulation eines gesperrten oder kompromittierten Systemadministratoraccounts oder die Simulation eines Ausfalls oder Problems mit einem AppExchange-Anbieter sein. Entsprechende Informationen finden Sie unter [Vorfallsantwort](/docs/architect/de-de/well-architected/guide/resilient#vorfallsreaktion).)Fragen, wie Sie mithilfe von Tests und Automatisierung Services schneller wiederherstellen können: - Wie oft werden Vorfallssimulationen geplant und ausgeführt? - Wissen wir, wie lange es dauert, die Services wieder in einen stabilen Zustand zu versetzen? - Verfügen wir über stabile Lieferprozesse? - Wissen wir, wo wir Failover und Wiederherstellung automatisieren können? Behandeln Sie alle Elemente, die aus Ihren Überprüfungen nach einem Vorfall stammen, wie Ihre anderen Entwicklungselemente. Fügen Sie sie Ihren Planungssystemen hinzu, damit Sie sie priorisieren und bearbeiten können. Die [Muster und Anti-Muster für die](/docs/architect/de-de/well-architected/guide/resilient#kontinuitätsplanungsmuster-und-anti-muster) Kontinuitätsplanung zeigen, wie eine ordnungsgemäße und schlechte Technologiekontinuitätsplanung in einer Salesforce-Lösung aussieht. Verwenden Sie sie, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen. Weitere Informationen zu Salesforce-Tools für die Planung der Technologiekontinuität finden Sie unter [Salesforce Tools for Resilience](/docs/architect/de-de/well-architected/guide/resilient#salesforce-tools-für-resilienz) (Salesforce-Tools für Resilienz). ### Erstellen von Sicherungs- und Wiederherstellungsfunktionen Die Wiederherstellung gesicherter Kopien von Daten oder Metadaten kann dazu beitragen, Ihre Organisation wieder in den letzten bekannten stabilen Zustand zu versetzen. Es kann auch ein Failover-System während eines katastrophalen Systemausfalls oder einer Serviceunterbrechung bereitstellen. Wenn Sie Ihre Daten und Metadaten regelmäßig sichern und Ihre verschlüsselten, gesicherten Kopien an einem sicheren Ort speichern, erhalten Sie eine zusätzliche Resilienzebene für Ihre Architektur. Ohne Sicherungs- und Wiederherstellungsstrategien können Sie keine sauberen Versionen Ihrer Produktionsdaten und Metadaten wiederherstellen, wenn sie böswillig beschädigt wurden, wenn versehentlich Fehler in die Produktion gelangen oder wenn ein Fehler während eines Ladens großer Daten Produktionsdaten beschädigt. Jedes dieser Szenarien kann dazu führen, dass Ihre geschäftskritischen Produktionsdaten beschädigt werden oder sogar dauerhaft verloren gehen. Die Einrichtung von Sicherungs- und Wiederherstellungstechnologien bietet neben der Kontinuitätsplanung eine Reihe von Vorteilen, einschließlich der Unterstützung bei Strategien zur Verringerung großer Datenmengen und der Einhaltung von Compliance-bezogenen Aufbewahrungsrichtlinien. Gewährleisten der Kontinuität mit Sicherungs- und Wiederherstellungsstrategien in Ihren Salesforce-Lösungen: - **Gehe los.** Der erste Schritt zu einer guten Sicherungs- und Wiederherstellungsstrategie besteht darin, zunächst eine Strategie zu haben. Selbst so einfache Vorgänge wie das Erstellen nächtlicher Sicherungen aller Daten und Metadaten Ihrer Organisation können Ihr Unternehmen davor bewahren, während einer Katastrophe wichtige Informationen oder Funktionen zu verlieren. - **Einschränken des Zugriffs auf Sicherungen.** Systemadministratoren sind die einzigen Benutzer, die Zugriff auf gesicherte Kopien Ihrer Daten haben sollten. Durch diese Zugriffseinschränkung wird verhindert, dass ein Geschäftsbenutzer Datensätze in einer Sicherungskopie anzeigen kann, zu deren Anzeige er in Ihrer Organisation nicht berechtigt wäre. - **Testen Sie Ihren Wiederherstellungsprozess regelmäßig.** [Testen](/docs/architect/de-de/well-architected/guide/resilient#teststrategie) Sie Ihren Wiederherstellungsprozess unabhängig von der implementierten Sicherungs- und Wiederherstellungsstrategie regelmäßig in einer Sandbox für vollständige oder teilweise Kopien, um sicherzustellen, dass er bei Bedarf ordnungsgemäß funktioniert. - **Passen Sie Ihre Sicherungs- und Wiederherstellungsstrategie an Ihre Datenarchivierungsstrategie an.** Legen Sie fest, was in Ihren Sicherungen oder Archiven geschehen soll, wenn Datensätze archiviert oder aus Ihrem System bereinigt werden. Siehe [Datenvolumen](/docs/architect/de-de/well-architected/guide/reliable#datenvolumen)). Möglicherweise benötigen Sie eine genauere Sicherungsstrategie, wenn Ihre Datenvolumen so groß sind, dass eine vollständige Sicherung nicht abgeschlossen werden kann, bevor die nächste Sicherung ausgeführt wird. Möglicherweise benötigen Sie auch eine genauere Sicherungsstrategie, wenn sich die Daten Ihrer Organisation so häufig ändern, dass die Aktualisierungen für Ihre Organisation von entscheidender Bedeutung sind. Granularere Sicherungsstrategie: - **Begrenzen Sie Ihre Sicherungen auf bestimmte Objekte**. Bei dieser Strategie werden Datensätze aus verschiedenen Objekten in unterschiedlichen Zeitintervallen gesichert. Beachten Sie, dass untergeordnete Objekte in denselben Intervallen wie ihre übergeordneten Objekte gesichert werden müssen, um die Datenkonsistenz zu gewährleisten. - **Zeitfenster-\*\***Teilsicherungen\*\*. Bei dieser Strategie wird zwischen vollständigen Sicherungen (aller Daten und Metadaten) und Teilsicherungen (nur von Metadaten und Datensätzen, die seit der letzten Sicherung hinzugefügt oder geändert wurden) unterschieden. **\* Beenden Sie niemals die vollständige Sicherung**. Es ist wichtig zu beachten, dass Sie vollständige Sicherungen niemals vollständig entfernen sollten, selbst wenn Datenvolumen zu langen Laufzeiten führen. Planen Sie für große Datenmengen regelmäßige, aber seltene vollständige Sicherungen (z. B. wöchentliche Sicherungen) ein. Planen Sie auch häufigere teilweise oder objektspezifische Sicherungen ein (z. B. nächtliche Sicherungen oder Sicherungen alle X Stunden). Dieser Ansatz bietet Ihnen die Flexibilität, das vollständigste und genaueste Datenset zu rekonstruieren, das in Ihren Wiederherstellungsprozessen verwendet werden soll.\* Die [Muster und Anti-Muster für die](/docs/architect/de-de/well-architected/guide/resilient#kontinuitätsplanungsmuster-und-anti-muster) Kontinuitätsplanung zeigen, wie ordnungsgemäße und schlechte Sicherungs- und Wiederherstellungsfunktionen in einer Salesforce-Lösung aussehen. Verwenden Sie sie, um Ihre Entwürfe vor dem Erstellen zu validieren oder Stellen in Ihrem System zu identifizieren, die neu faktorisiert werden müssen. ### Salesforce Backup and Recover Salesforce Backup and Recover, eine integrierte Salesforce-Lösung, die "Own Recover from the Own Acquisition" (Eigene Wiederherstellung aus eigener Übernahme) enthält, schützt wichtige Daten vor Verlust oder Beschädigung. Unsere hochsichere, einfach einzurichtende und jederzeit verfügbare Lösung gewährleistet Geschäftskontinuität und Datenresilienz und vereinfacht die Einhaltung. Verwenden Sie "Salesforce Backup and Recover" (Salesforce-Sicherung und -Wiederherstellung), um Datenverluste zu verhindern, Datenvorfälle schnell wiederherzustellen und Ihre allgemeine Datenverwaltungsstrategie zu vereinfachen. Sie können Sicherungsrichtlinien für hochwertige und regulierte Daten erstellen und diese Daten mit nur wenigen Klicks wiederherstellen. #### Bereitstellen von automatisierten Sicherungen Automatisierte tägliche Sicherungen schützen alle Ihre wichtigen Organisationsdaten, einschließlich Metadaten, Sandbox-Instanzen, verwalteter Paketdaten, Dateianhänge und mehr. Führen Sie Sicherungen nach Bedarf aus, um Ihre Ziele für das Wiederherstellungspunktziel zu erreichen und Ihre Bereitstellungen zu schützen. Sicherungen sind immer zugänglich und werden sicher und konform gespeichert. Der kontinuierliche Datenschutz ist auch für noch sensiblere oder transaktionale Daten verfügbar und ermöglicht eine schnellere Wiederherstellung sich schnell ändernder wichtiger Informationen. #### Proaktives Überwachen von Daten Erkennen Sie ungewöhnliche Datenaktivitäten, Datenverluste und Beschädigungen mit proaktiven Benachrichtigungen, die direkt an Ihre E-Mail gesendet werden. Erhalten Sie Echtzeitbenachrichtigungen, um statistische Ausreißer zu identifizieren oder Regeln zu erstellen, mit denen Sie über ungewöhnliche Datenaktivitäten benachrichtigt werden, sodass Sie Vorfälle schneller als je zuvor erkennen können. #### Präzise und schnelle Wiederherstellung Salesforce Backup and Recover beschleunigt die Wiederherstellung, indem es detaillierte Einblicke in Änderungen bietet, sodass betroffene Daten schnell identifiziert und wiederhergestellt werden können. Tools wie visuelle Diagramme heben unerwünschte Änderungen hervor, während benutzerfreundliche Wiederherstellungsfunktionen betroffene Objekte, Felder und Datensätze präzise wiederherstellen. #### Erweitern der Verwendung Ihrer Sicherungen Mit unseren Tools können Sie Sicherungen für Analysen, Prüfungen und Compliance verwenden. Sie bieten durchsuchbare Verlaufsdaten, offene Suchfunktionen für die Sichtbarkeit vergangener Daten und Exportfunktionen für externe Analysen oder Lager. Dadurch werden Sicherungen wiederverwendet, ohne dass zusätzliche Salesforce-APIs erforderlich sind. #### Vereinheitlichte Datensicherungsverwaltung Backup and Recover bietet eine einzige Konsole zum Konsolidieren aller Sicherungen, Verwaltung, Vorgänge und Compliance. Mit dieser Konsole können Sie auf Sicherungen für alle Ihre Produktionsorganisationen und Sandbox-Instanzen zugreifen, sie verwalten, anpassen und überwachen. Damit können Sie auch Anforderungen betroffener Personen ausführen, um die Einhaltung von Sicherungsdaten sicherzustellen, und die vollständige Kontrolle über die Anpassung von Sicherungsplänen, Häufigkeit und Aufbewahrungsrichtlinien haben. #### Wichtige Anwendungsfälle für Salesforce Backup and Recover - **Verringern Sie die Auswirkungen von Datenvorfällen**. Salesforce Backup and Recover hilft Ihnen, Datenvorfälle wie Cyberangriffe oder bösartige interne oder externe Aktivitäten zu vermeiden, indem es Benutzern ermöglicht, betroffene Datensätze in den Zustand vor dem Vorfall zurückzuversetzen. Die Exportfunktionen von Backup and Recover garantieren einen kontinuierlichen Zugriff auf und die Benutzerfreundlichkeit der wichtigen Daten. - **Verhindern Sie dauerhaften Datenverlust**. Menschliche Fehler sind nach wie vor die Hauptursache für Datenverluste. Backup and& Recover bietet eine präzise und schnelle Lösung für diese Fehler. - **Erfüllen Sie einfacher die Datenkonformität und die gesetzlichen Anforderungen**. Salesforce Backup and Recover unterstützt das Modell der gemeinsamen Verantwortung und ermöglicht Self-Service-Funktionen für Massenvergessenheiten oder die Datenkorrektur in Ihren Sicherungsdaten. Weitere Informationen zu Salesforce-Tools für die Sicherung und Wiederherstellung finden Sie unter [Salesforce Tools for Resilience](/docs/architect/de-de/well-architected/guide/resilient#salesforce-tools-für-resilienz) (Salesforce-Tools für die Resilienz). ### Kontinuitätsplanungsmuster und Anti-Muster Diese Tabelle zeigt eine Auswahl an Mustern, die in Ihrer Organisation gesucht oder erstellt werden sollen, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Kontinuitätsplanung im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/adaptable-continuity-planning) Anti-Muster.

	Muster	Anti-Muster
Geschäftskontinuität	In Ihrem Unternehmen: - Es wird eine Einstellung vom Typ "Erholung zuerst" angenommen, bei der der Fokus darauf liegt, die Geschäftsfunktionen und -funktionen mit der höchsten Priorität so schnell wie möglich außer Kraft zu setzen. - Es gibt einen Wartungsplan für die Überprüfung von BCP-Testplänen.	In Ihrem Unternehmen: - Eine "Problem beheben"-Mentalität ist der einzige Ansatz für das Vorfallsmanagement. - BCP-Testpläne werden nicht in regelmäßigen Abständen aktualisiert.
	In Ihrer Dokumentation: - Es ist ein BCP vorhanden, das Schritte zum Fortsetzen der Verarbeitung oder Triage von Daten enthält, wenn Salesforce nicht mehr verfügbar ist, eine Liste der Ereignisse, die die Verwendung des BCP auslösen, sowie Schritte und Intervalle für BCP-Tests. - Das BCP umfasst vor- und nachgelagerte Systeme und Abhängigkeiten.	In Ihrer Dokumentation: - Ein BCP ist nicht vorhanden, nicht vollständig oder enthält nur Salesforce.
	In Ihren Testplänen: - Die Bereiche Ihres BCP in Bezug auf Prozesse und Personen werden berücksichtigt.	In Ihren Testplänen: - Die mit Prozessen und Personen verbundenen Bereiche Ihres BCP werden nicht berücksichtigt.
Technologiekontinuität	In Ihrem Unternehmen: - Sie haben ausgewertet, ob Sie beabsichtigte Redundanz- oder Failover-Systeme erstellen müssen - Taktiken zur Vorfallsbehebung werden nach Möglichkeit automatisiert.	In Ihrem Unternehmen: - Sie haben die Notwendigkeit von absichtlichen Redundanz- oder Failover-Systemen nicht bewertet - Die Taktiken zur Vorfallsbehebung sind alle manuell.
Technologiekontinuität	In Ihrer Dokumentation: - Das BCP berücksichtigt zusätzliche Ressourcen oder Brillenglasverfahren, die Teams möglicherweise benötigen, um effektiv auf Vorfälle zu reagieren.	In Ihrer Dokumentation: - Der BCP enthält keine Anforderungen an die betriebliche Unterstützung.
Sichern und Wiederherstellen	In Ihrer Dokumentation: - Es gibt eine Sicherungs- und Wiederherstellungsstrategie für Daten und Metadaten.	In Ihrer Dokumentation: - Eine Sicherungs- und Wiederherstellungsstrategie ist nicht vorhanden oder wenn sie abgeschlossen ist, gilt sie nur für Daten oder nur für Metadaten, nicht für beide.
Sichern und Wiederherstellen	In Ihrem Unternehmen: - Sicherungen werden an einem sicheren Ort gespeichert, auf den nur autorisierte Benutzer zugreifen können. - Testpläne und Testprotokolle zeigen, dass die Datenwiederherstellung in einer Full oder Partial Copy Sandbox mindestens zweimal pro Jahr getestet wird.	In Ihrem Unternehmen: - Sicherungen sind nicht menschenlesbar. - Sicherungen werden an Orten gespeichert, auf die nicht autorisierte Geschäftsbenutzer zugreifen können. - Es gibt keinen Datenwiederherstellungsprozess oder der Datenwiederherstellungsprozess ist nicht getestet.

## Salesforce-Tools für Resilienz

Tool	Beschreibung	Anwendungslebenszyklus-Verwaltung	Vorfallsreaktion	Kontinuitätsplanung
Apex Hammer-Tests	Erfahren Sie mehr über Salesforce Apex Tests in aktuellen und neuen Versionen.	X
Apex Stub API	Erstellen Sie ein simuliertes Framework, um Tests zu optimieren.	X
Sichern und Wiederherstellen	Generieren Sie automatisch Sicherungen, um Datenverluste zu vermeiden.			X
Große Objekte	Speichern und verwalten Sie große Datenmengen auf der Plattform.			X
Feldverlaufsverfolgung	Verfolgen und Anzeigen des Feldverlaufs.		X
Abrufen von Akzeptanz- und Sicherheitsstatistiken für Ihre OrganisationLink in neuem Fenster öffnen	Überwachen Sie die Akzeptanz und Nutzung von Lightning Experience in Ihrer Organisation.		X
Verwalten von Aufträgen zum Laden von Massendaten	Erstellen Sie mit der Bulk-API eine Aktualisierung oder löschen Sie große Datensatzmengen.		X
Ereignisüberwachung in Echtzeit verwalten	Verwalten Sie die Streaming- und Speichereinstellungen für die Ereignisüberwachung.		X
Daten- und Speicherressourcen	Zeigen Sie die Speicherobergrenzen und die Nutzung Ihrer Salesforce-Organisation an.		X
Debug-Protokolle überwachen	Überwachen Sie Protokolle und legen Sie Kennzeichnungen fest, um die Protokollierung auszulösen.		X
Überwachen der Anmeldeaktivität mit der Anmeldeforensik	Identifizieren Sie das Verhalten, das auf Identitätsbetrug hinweisen kann.		X
Überwachen von Setup-Änderungen mit dem Setup-Aktivierungsprotokoll	Verfolgen Sie die zuletzt von Administratoren vorgenommenen Setup-Änderungen.		X
Trainingsverlauf überwachen	Zeigen Sie die Salesforce-Schulungskurse an, die Ihre Benutzer absolviert haben.		X
Überwachen von Hintergrundaufträgen	Überwachen Sie Hintergrundaufträge in Ihrer Organisation.		X
Überwachen geplanter Aufträge	Zeigen Sie Bericht-Snapshots, geplante Apex-Aufträge und Dashboard-Aktualisierungen an.		X
Skalierungstest	Testen Sie die Systemleistung und interpretieren Sie die Ergebnisse.	X
Proaktive Überwachung	Minimieren Sie Unterbrechungen mithilfe von Salesforce-Überwachungsservices.		X
Salesforce Data Mask	Maskieren Sie Daten in einer Sandbox automatisch.	X
Die Systemübersichtsseite	Zeigen Sie Nutzungsdaten und Obergrenzen für Ihre Organisation an.		X
Anwendungskraft:Lightning:lint	Analysieren und validieren Sie Code über die Salesforce CLI.	X

## Für Resilienz relevante Ressourcen

Ressource	Beschreibung	Anwendungslebenszyklus-Verwaltung	Vorfallsreaktion	Kontinuitätsplanung
7 Anti-Patterns bei Leistungs- und Skalierungstests	Vermeiden Sie häufige Anti-Patterns bei Leistungs- und Skalierungstests.	X
Analysieren von Leistungs- und Skalierungs-Hotspots in komplexen Salesforce-Anwendungen	Erfahren Sie mehr über einen Ansatz zur Lösung von Leistungs- und Skalierbarkeitsproblemen in Ihrer Organisation.	X
Erstellen eines Notfallwiederherstellungsplans (Trailhead)	Erstellen Sie einen Notfallwiederherstellungsplan.			X
Geschäftskontinuität ist mehr als Sicherung und Wiederherstellung	Verschaffen Sie sich einen umfassenden Überblick über BCP.			X
Vorlage 'Designstandards'	Erstellen Sie Designstandards für Ihre Organisation.	X
Diagnose- und Überwachungstools in Salesforce	Erfahren Sie, wie Sie die Qualität und Leistung Ihrer Implementierungen verbessern können.		X
Leitsätze für die Geschäftskontinuitätsplanung	Überprüfen Sie die grundlegenden Prinzipien, die effektiven BCP zugrunde liegen.			X
Skalierungstest in Salesforce	Machen Sie sich mit den fünf Phasen des Skalierungstestlebenszyklus vertraut.	X
Einführung in Leistungstests	Erfahren Sie, wie Sie eine Leistungstestmethode entwickeln.	X
Überwachen Ihrer Organisation	Erfahren Sie mehr über die Self-Service-Überwachungsoptionen.		X
Teststrategievorlage	Erstellen und passen Sie Skalierungs- und Leistungstestpläne an.	X
Teststrategievorlage	Stellen Sie sicher, dass Ihre Teststrategie abgeschlossen ist.	X
Grundlegendes zur quellgesteuerten Entwicklung (Trailhead)	Erfahren Sie mehr über die Paketentwicklung und Testorganisationen.	X

## Teilen Sie uns Ihre Meinung mit Helfen Sie uns, Salesforce Well-Architected für Sie relevant zu halten. Nehmen Sie an unserer [Umfrage teil](https://sfdc.co/bxNtvh), um Feedback zu diesen Inhalten zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten. > Lesen Sie [hier](/docs/architect/de-de/well-architected/guide/contributors) unsere Aktualisierungspläne. ## Einführung Ein sicheres System schützt die Beteiligten und Daten einer Organisation. Sichere Architekturen überprüfen die Benutzeridentität, schränken den Datenzugriff auf nur erforderliche Informationen ein und verhindern Datenkompromittierungen. Salesforce priorisiert Customer Trust und Datensicherheit. Die Salesforce Platform gewährleistet Datenschutz und Sicherheit. Informationen zur Systemleistung und -sicherheit in Echtzeit sind bei [Salesforce Trust](https://trust.salesforce.com/) verfügbar. Der Schutz Ihrer Organisation und Ihrer Kundendaten ist die Grundlage für die Entwicklung sicherer Salesforce-Lösungen. Als Salesforce-Architekt sind Sie dafür verantwortlich, Ihre Organisation und Kundendaten zu schützen, indem Sie die integrierten Sicherheitsfunktionen von Salesforce nutzen. Berücksichtigen Sie bei diesen Entscheidungen die geografische Verteilung, die Branche, die Betriebsverfahren des Unternehmens und die Kundendatentypen. Sie können Ihre Lösungen sicherer gestalten, indem Sie sich auf drei Bereiche konzentrieren: Organisationssicherheit, Sitzungssicherheit und Datensicherheit. ## Organisationssicherheit Die Organisationssicherheit schützt Systeme vor unbefugtem Zugriff, indem sichergestellt wird, dass nur validierte autorisierte Benutzer auf ein System zugreifen können und nur die erforderlichen Funktionen und Daten. Zu den Anzeichen für eine problematische Organisationssicherheit zählen: - Ad-hoc-Prozesse zum Aktivieren oder Deaktivieren von Benutzern - Unklare Schritte zum Aktualisieren der Autorisierung für Benutzer- oder Systemrollenänderungen - Vertrauen auf institutionelles Knowledge von Einzelpersonen für korrekte Benutzersicherheitszuweisungen - Nichtübereinstimmung mit bestehenden Sicherheits-Frameworks oder bewährten Vorgehensweisen der Branche - Fehlen eines strukturierten Datenverwaltungs-Frameworks und unterstützende Richtlinien Sie können bessere organisatorische Sicherheitssteuerungen für Ihre Salesforce-Organisationen erstellen, indem Sie sich auf die Authentifizierung und Autorisierung konzentrieren. ### Authentifizierung Die Authentifizierung ist wichtig für die Sicherheit und die Zugriffsverwaltung und überprüft die Identität der Benutzer, die versuchen, auf Ihr System zuzugreifen. Dies gilt sowohl für menschliche Benutzer (Mitarbeiter, Kunden) als auch für automatisierte Benutzer (externe Systeme, Integrationen), wobei für jeden Benutzertyp spezifische Authentifizierungsschemas erforderlich sind. Um den sicheren Zugriff auf alle Salesforce-Eingangspunkte in Ihrer Organisation zu gewährleisten, müssen Sie verschiedene Authentifizierungsmethoden einrichten. Erstellen sicherer Authentifizierungs-Flows in Salesforce: - **Erstellen Sie Salesforce-Benutzer anhand von Einzelpersonen und nicht anhand von Personas**. Die integrierten Überwachungsfunktionen von Salesforce sind am effektivsten, wenn jeder Benutzeraccount einer einzelnen Person entspricht, die auf die Plattform zugreift. Die Verwendung freigegebener Benutzeraccounts beeinträchtigt die Effektivität dieser Prüfungen, führt zu zusätzlichen Sicherheitslücken, eskaliert die potenziellen Auswirkungen von Accountverletzungen und erschwert die Erstellung effektiver Autorisierungsschemas. Dies schließt Benutzeraccounts für Integrationsbenutzer ein. - **Sichere UI-basierte Zugriffsszenarien**. Die meisten menschlichen Benutzer benötigen für eine Salesforce-Organisation eine Art Benutzeroberflächen-basierten Zugriff (oft als Anmeldezugriff bezeichnet). Salesforce bietet verschiedene Schutzebenen für diese Anmeldeszenarien, darunter: - **Kennwortrichtlinien.** Cyberkriminelle zielen häufig auf Benutzernamen und Kennwörter ab, um nicht autorisierten Zugriff auf Anwendungen zu erhalten. Die Konfiguration [von Kennwortrichtlinien](https://help.salesforce.com/s/articleView?id=sf.admin_password.htm&type=5) ist zwar ein grundlegender Schritt zum Schutz des Anmeldezugriffs, es ist jedoch wichtig zu beachten, dass dies allein nicht ausreicht, da Salesforce Überschreibungen dieser Richtlinien pro Benutzer zulässt. - **Multi-Faktor-Authentifizierung (MFA)**. Salesforce [fordert die Multi-Faktor](https://help.salesforce.com/s/articleView?id=000352937&type=1)-Authentifizierung für alle Benutzeranmeldungen auf der Benutzeroberfläche. Die Multi-Faktor-Authentifizierung bietet einen wichtigen Schutz vor Credential Leaks und Brute-Force-Angriffen, indem Benutzer nach erfolgreicher Eingabe ihres Benutzernamens und Kennworts aufgefordert werden, eine zusätzliche Form der Identifikation oder einen zusätzlichen Faktor anzugeben. Dieser zusätzliche Faktor hat in der Regel eine physische Form, beispielsweise ein Mobilgerät, einen Sicherheitsschlüssel oder eine biometrische Markierung. - **Single Sign On (SSO)**. In SSO-Szenarien verwenden Benutzer nur einen Satz von Anmeldeinformationen in den Anwendungen einer Organisation. Der Zugriff auf Systeme wird zentral bereitgestellt und verwaltet, was die Sicherheit erhöht. Salesforce kann in [SSO-Szenarien](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5) als Serviceanbieter oder Identitätsanbieter fungieren. Stellen Sie sicher, dass sich einige oder alle Administratoren direkt bei Salesforce anmelden können, damit sie Ausfälle oder Probleme mit Ihrer SSO-Implementierung beheben können. - **Schritte nach der Anmeldung.** In einigen Anwendungsfällen können Sie verlangen, dass Benutzer zusätzliche Schritte ausführen, bevor sie auf Ihr System zugreifen. Benutzerdefinierte Anmelde-Flows können implementiert werden, um Benutzer durch diese zusätzlichen Prozessschritte zu führen. Beispiele: - Akzeptieren von Nutzungsbedingungen - Arbeiten durch [Anmeldeerkennungs- und](https://help.salesforce.com/s/articleView?id=sf.external_identity_passwordless_login_use_cases.htm&type=5) Anmeldeszenarien ohne Kennwort - Begrenzen der Anzahl gleichzeitiger Salesforce-Sitzungen pro Benutzer, um die Wahrscheinlichkeit sitzungsbasierter Angriffe zu reduzieren (siehe [Sitzungssicherheit](/docs/architect/de-de/well-architected/guide/secure#sitzungssicherheit)). - Herstellen einer Verbindung mit Geofencing-Services - **Sichere API-basierte Zugriffsszenarien**. Jeder Benutzer kann API-basierten Zugriff für eine Salesforce-Organisation anfordern. Salesforce bietet verschiedene Schutzebenen für API-basierte Szenarien, darunter: - **API-Zugriffssteuerung**. Ohne [API-Zugriffssteuerung](https://help.salesforce.com/s/articleView?id=sf.security_api_access_control_about.htm&type=5) kann jeder mit einer gültigen Reihe von Anmeldeinformationen jede beliebige Anwendung nutzen, um eine Verbindung mit Ihrer Organisation herzustellen, selbst wenn die verbundene Anwendung nicht in der Organisation bereitgestellt wird. Datenzugriffssteuerungen werden weiterhin erzwungen, Benutzer können jedoch auf unkontrollierte Weise auf Informationen zugreifen. Beispielsweise kann eine Anwendung verwendet werden, um große Datenmengen herunterzuladen oder sogar beschädigte Informationen hochzuladen, ohne dass ein Systemadministrator dies genehmigt. - **Nur API-Berechtigungen**. Sie können Benutzerberechtigungen vom Typ "Nur API" in Salesforce konfigurieren. Weisen Sie dies als Teil eines Berechtigungssatzes allen automatisierten oder [Integrationsbenutzer-](https://help.salesforce.com/s/articleView?language=en_US&id=sf.integration_user.htm)Personas zu, um den Benutzeroberflächen-basierten Zugriff vollständig zu blockieren. - **Zertifikate und Schlüssel**. Mit [Zertifikaten und Schlüsseln](https://help.salesforce.com/s/articleView?id=sf.security_keys_about.htm&type=5) kann Salesforce überprüfen, ob Anforderungen von autorisierten Unternehmen oder Unternehmen stammen. Wenn Sie [SSO mit Salesforce](https://help.salesforce.com/s/articleView?id=sf.sso_about.htm&type=5) verwenden möchten, müssen Sie Zertifikate und Schlüssel konfigurieren. - **Verbundene Anwendungen**. Durch die Konfiguration [verbundener Anwendungen](https://help.salesforce.com/s/articleView?id=sf.connected_app_overview.htm&type=5) in Salesforce können Sie den Zugriff des externen Systems auf Salesforce steuern, einschließlich der erforderlichen Authentifizierungsprotokolle, des Autorisierungsumfangs und des Sitzungsverhaltens in einer einzigen Definition. - **Anmeldeinformationen mit Namen**. Mit [Anmeldeinformationen mit Namen](https://help.salesforce.com/s/articleView?id=sf.named_credentials_define.htm&type=5) können Sie externe Zugriffspunkte und Authentifizierungsprotokolle in einer einzigen Definition in Salesforce steuern. Verwenden Sie sie, um die Authentifizierung für Callouts aus Apex, externen Services und Salesforce Connect-Datenquellen sicher zu definieren und zu verwalten. - **Authentifizierung für Agentforce Agent-Benutzer**. Agentforce-Agenten verwenden auf Salesforce basierende Agenten-Benutzerobjekte mit verwaltbaren Berechtigungen wie echte Benutzer. Richten Sie beim Einrichten eines Agenten den Zugriff sorgfältig auf die Rolle des Agenten ein und beschränken Sie den Datenzugriff auf das, was für die Bereitstellung der Endbenutzer erforderlich ist. Ebenso wichtig ist, dass Agenten mit öffentlichen und privaten Aktionen konfiguriert werden können. Validieren und authentifizieren Sie Endbenutzer bei privaten Aktionen und ordnen Sie sie dem Agentenkontext zu. Dadurch kann sich der Agent innerhalb der Zugriffssteuerungen des Endbenutzers ausgeben und agieren, wobei Sicherheit und Trust gewahrt bleiben. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/secure#organisationssicherheitsmuster-und-antimuster) zeigt, wie die richtige (und schlechte) Authentifizierungsarchitektur in einer Salesforce-Organisation aussieht. Verwenden Sie diese, um Ihre Designs vor dem Erstellen zu validieren oder Opportunities für weitere Verbesserungen zu identifizieren. Weitere Informationen zu den von Salesforce verfügbaren Authentifizierungstools finden Sie unter [Sicherungsrelevante Tools](/docs/architect/de-de/well-architected/guide/secure#für-die-sicherheit-relevante-tools). ### Autorisierung Die Autorisierung definiert, auf welche Funktionen, Funktionen und Daten ein Benutzer zugreifen kann und welche Aktionen er mit diesen Ressourcen ausführen kann, nachdem er [authentifiziert](/docs/architect/de-de/well-architected/guide/secure#authentifizierung) wurde. Autorisierungssteuerungen sind nicht nur für menschliche Benutzer vorgesehen, sie müssen auch auf Agentforce Agent-Benutzer zugeschnitten sein, insbesondere auf Agenten, die Services für nicht authentifizierte Endbenutzer bereitstellen. Auch wenn es ein entscheidender erster Schritt ist, einzuschränken, wer sich bei Ihrer Organisation authentifizieren kann, ist es ebenso wichtig, die sichere Authentifizierung mit einer robusten Autorisierung zu verbinden. Ohne geeignete Autorisierungssteuerungen könnten Benutzer möglicherweise Datensätze erstellen, bearbeiten und löschen oder auf Systemfunktionen zugreifen, die für Ihr Unternehmen und Ihre Beteiligten schädlich sind. Eine unzureichende Autorisierungskontrolle kann auch die Verwendung von Systemen erschweren. Indem Sie steuern, was Benutzer im System tun können, fördern Sie ein höheres Maß an Trust und schützen so Ihr System und Ihre Benutzer. Erstellen sicherer Autorisierungsschemas für Salesforce: - **Befolgen Sie das Prinzip der geringsten Berechtigung**. Nutzen Sie das Prinzip der geringsten Berechtigung (PoLP), indem Sie Benutzern nur die erforderlichen Berechtigungen für ihre Aufgaben zuweisen. Entwerfen Sie granulare und modulare Berechtigungssätze, um diesem Prinzip zu folgen. Dies ermöglicht komplexe Zugriffssteuerungen über Berechtigungssatzgruppen, die eine präzise Verwaltung von Berechtigungen ermöglichen, einschließlich der Möglichkeit, [stummzuschalten](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_muting.htm&type=5), [Ablaufdatumswerte festzulegen](https://help.salesforce.com/s/articleView?id=release-notes.rn_forcecom_permissions_assn_expiration.htm&type=5&release=238) und mehr. Richten Sie die [Funktionseinheiten](/docs/architect/de-de/well-architected/guide/composable#funktionale-einheiten) Ihrer Systeme auf Geschäftsfunktionen aus, um detaillierte Berechtigungen und effektive Berechtigungssatzgruppen zu definieren. Denken Sie daran, dass Berechtigungen für den _Metadatenzugriff_ in Salesforce gelten. Details zum Konfigurieren von PoLP für den Salesforce-_Datenzugriff_ finden Sie unter [Freigabe und Sichtbarkeit](/docs/architect/de-de/well-architected/guide/secure#freigabe-und-sichtbarkeit). - **Überlegen Sie sich den Benutzerzugriff in Form von Personas und nicht als Einzelpersonen.** Wenn Sie an Autorisierung (oder Sicherheit im Allgemeinen) in Bezug auf einzelne Benutzer denken, wird Ihr System nicht auf Skalierung und Weiterentwicklung eingestellt. Entwerfen und verwalten Sie stattdessen Personas, die Benutzergruppen darstellen. Sichere Salesforce-Lösungen verwenden Einzelpersonen für die Authentifizierung und Personas für die Autorisierung. Durch das Definieren von Sicherheitskonfigurationen für unterschiedliche Personas erhalten Sie eine genaue Kontrolle über den Zugriff und die Berechtigungen in Ihrem Sicherheitsmodell, wodurch die Notwendigkeit von Refaktoren langfristig minimiert wird. Fügen Sie die von Ihnen definierten Sicherheitspersonas in Ihre [Designstandards und Dokumentation](/docs/architect/de-de/well-architected/guide/intentional#lesbarkeit) ein. - **Steuern Sie den Benutzerzugriff auf Metadaten mithilfe von Berechtigungssätzen und Berechtigungssatzgruppen**. Berechtigungssätze und Berechtigungssatzgruppen bestimmen, auf welche Metadaten Benutzer zugreifen und was sie mit diesen Metadaten tun können. Weitere Informationen zu Salesforce-Metadaten finden Sie unter [Metadaten im Vergleich](/docs/architect/de-de/fundamentals/guide/architecture-basics#metadaten-im-vergleich-zu-daten) zu Daten. Konfigurieren Sie Anwendungszuweisungen, Funktionslizenzaktivierungen, Zugriff auf verwaltete Pakete, Systemberechtigungen, [CRUD-](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm)Zugriff und Zugriff auf Feldebene über Berechtigungssätze und Berechtigungssatzgruppen. Fügen Sie diesen Zugriff in Ihre [Designstandards und Dokumentation](/docs/architect/de-de/well-architected/guide/intentional#lesbarkeit) ein. - **Mit organisationsweiten Standardeinstellungen und Freigaben können Sie den Datenzugriff für Benutzer steuern.** [Daten und Metadaten](/docs/architect/de-de/fundamentals/guide/architecture-basics#metadaten-im-vergleich-zu-daten) sind unterschiedliche Einheiten in Salesforce, für die jeweils separate Zugriffssteuerungen erforderlich sind. Verwenden Sie OWDs und integrierte Freigabetools, um den Zugriff für Salesforce-Daten (einzelne Datensätze, Dateien und Dokumente) zu konfigurieren. Weitere Details finden Sie unter [Datensicherheit](/docs/architect/de-de/well-architected/guide/secure#datensicherheit). - **Mit OAuth-Geltungsbereichen können Sie den Zugriff für verbundene Anwendungen steuern.** Beim Konfigurieren einer verbundenen Anwendung definieren Sie den [Geltungsbereich](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US) oder die Zugriffsberechtigungen, über die Anwendungsbenutzer für Salesforce-Ressourcen verfügen. Weitere Informationen zum Verwalten von OAuth-Token finden Sie unter [Sitzungsverwaltung](/docs/architect/de-de/well-architected/guide/secure#sitzungsverwaltung). - **Erstellen Sie für jede Integration einen Salesforce-Benutzer.** Erstellen Sie für jede Integration einen eindeutigen Salesforce-[Integrationsbenutzer](https://help.salesforce.com/s/articleView?id=sf.integration_user.htm), um das Prinzip der geringsten Berechtigung einzuhalten. Dadurch können Sie bestimmten Datenzugriff zuweisen, die Kontrolle über Vorgänge verbessern, die Rückverfolgbarkeit von Transaktionen sicherstellen und die Auswirkungen potenzieller Sicherheitsverletzungen minimieren. - **Implementieren Sie eindeutige Accounts mit dem PoLP für alle Agentenbenutzer**. Jeder Agentforce Agent-Benutzer sollte eindeutig sein und nicht über mehrere Agenten hinweg wiederverwendet werden. Bei Berechtigungen für diese Accounts muss das Prinzip der geringsten Berechtigung unbedingt beachtet werden. Beachten Sie, dass Aktionen, die von einem Agentenbenutzer ausgeführt werden, in einem erhöhten Sicherheitskontext innerhalb von Salesforce oder in externen Systemen ausgeführt werden können, die Salesforce-Zugriffssteuerungen nicht berücksichtigen. Dies kann dazu führen, dass Aktionen auf sensible Informationen zugreifen oder sie Benutzern zugänglich machen. - **Minimieren Sie die Verwendung von Profilen und migrieren Sie alle Zugriffssteuerungen aus Profilen.** Profile bieten die Möglichkeit, den Zugriff auf [die Anmelde-IP-Bereiche](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm&type=5), [Anmeldezeiten](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) und Funktionen zu begrenzen, die für die ältere Salesforce Classic-Benutzeroberfläche (insbesondere Standarddatensatztypen und Seitenlayoutzuweisungen) spezifisch sind. Alle anderen Funktionen, die derzeit in Profilen vorhanden sind, sollten zu entsprechenden Funktionen in [Berechtigungssätzen und Berechtigungssatzgruppen](https://help.salesforce.com/s/articleView?id=sf.perm_set_groups_create_with_perm_sets.htm) migriert werden. Die Funktionen in Ihren Profilen, die an Salesforce Classic-Benutzeroberflächenfunktionen gebunden sind, sollten korrigiert werden. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/secure#organisationssicherheitsmuster-und-antimuster) zeigt, wie ordnungsgemäße (und schlechte) Autorisierungspraktiken in einer Salesforce-Organisation aussehen. Verwenden Sie diese, um Ihre Designs vor dem Erstellen zu validieren oder Opportunities für weitere Verbesserungen zu identifizieren. Weitere Informationen zu den von Salesforce verfügbaren Autorisierungstools finden Sie unter [Sicherungsrelevante Tools](/docs/architect/de-de/well-architected/guide/secure#für-die-sicherheit-relevante-tools). ### Organisationssicherheitsmuster und Antimuster Diese Tabelle zeigt eine Auswahl an Mustern, die in Ihrer Organisation gesucht (oder erstellt) werden sollen, und Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Organisationssicherheit im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/trusted-organizational-security) Anti-Muster.

	Muster	Anti-Muster
Authentifizierung	In Ihren Designstandards und in Ihrer Dokumentation: - Genehmigte Sicherheitspersonas sind klar definiert und aufgeführt - Zuordnung zwischen Sicherheitspersonas und zulässigen Authentifizierungsschemas (UI, API) in einer Sicherheitsmatrix vorhanden	Wenn Designstandards und Dokumentation vorhanden sind, - Schließen Sie keine Sicherheitspersonas ein - Fügen Sie keine Sicherheitsmatrix mit eindeutigen Zuordnungen für Sicherheitspersonas und zulässige Authentifizierungsschemas ein
	In Ihrer Organisation: - Anmeldekonfigurationen werden an die Salesforce-MFA-Überprüfung angepasst - Die Beziehung zwischen Benutzern und Einheiten, die sich bei Salesforce anmelden, beträgt 1:1 (keine freigegebenen Benutzer) - API-Zugriffssteuerung verhindert die Authentifizierung von Benutzern über eine nicht autorisierte verbundene Anwendung - Wenn SSO aktiviert ist, haben genehmigte Administratorbenutzer direkten Anmeldezugriff	In Ihrer Organisation: - Anmeldekonfigurationen stimmen nicht mit der Salesforce-MFA-Überprüfung überein - Die Beziehung zwischen Benutzern und Einheiten, die sich bei Salesforce anmelden, ist nicht 1:1 (es gibt freigegebene Benutzeraccounts) - Wenn Benutzer hinter einer Firewall auf Salesforce zugreifen, verwendet die Firewall hartcodierte IP-Adressen, um die Kommunikation mit/von Salesforce zu schützen - API-Zugriffssteuerung ist nicht aktiviert - Wenn SSO aktiviert ist, haben keine genehmigten Administratorbenutzer direkten Anmeldezugriff
	In LWC, Apex, Aura: - Methoden, die die Authentifizierung ausführen, verwenden Anmeldeinformationen mit Namen zum Verarbeiten von Benutzernamens-/Kennwort-Flows - Keine Benutzernamen oder Kennwörter werden im Code in lesbaren Formaten angezeigt (keine hartcodierten Werte oder Zeichenfolgen) - Wenn benutzerdefinierte Anmelde-Flows vorhanden sind, verwendet der zugehörige benutzerdefinierte Code die entsprechenden `SessionManagement-`Methoden	In LWC, Apex, Aura: - Authentifizierung wird ad hoc verarbeitet - Benutzernamen und Kennwörter werden im Code angezeigt
Autorisierung	In Ihren Designstandards und in Ihrer Dokumentation: - Jeder Benutzer und jedes System mit Zugriff auf Salesforce wird einer oder mehreren Personas in einer Sicherheitsmatrix zugeordnet - Die Sicherheitsmatrix listet Metadatenberechtigungen und zugewiesene Benutzerpersonas übersichtlich auf - Anwendungsfälle für die Gewährung erhöhter Berechtigungen sind klar aufgeführt, einschließlich: -- Berechtigungen "Alle Daten modifizieren" -- Berechtigungen "Alle Daten anzeigen"	Wenn Designstandards und Dokumentation vorhanden sind, - Keine Sicherheitsmatrix einschließen - Berechtigungen nicht eindeutig auflisten - Anwendungsfälle für die Gewährung erhöhter Berechtigungen nicht eindeutig auflisten
	In Ihrer Organisation: - Berechtigungssätze und Berechtigungssatzgruppen werden verwendet, um den Zugriff auf Metadaten zu steuern - Berechtigungssätze und Berechtigungssatzgruppen richten sich nach Geschäftsfunktionen - Berechtigungen, die Benutzern zugewiesen sind, folgen Sicherheitsmatrixdefinitionen - Profile werden nur minimal und nur zum Steuern von IP-Bereichen und Anmeldezeiten für die Anmeldung verwendet - Für jede Integration wird ein eindeutiger API-Integrationsbenutzer konfiguriert	In Ihrer Organisation: - Berechtigungssatzgruppen sind nicht so konfiguriert, dass sie den Zugriff basierend auf Geschäftsfunktionen zulassen - Berechtigungssätze werden ad hoc konfiguriert - Berechtigungssätze sind redundant oder stark dupliziert; es ist schwierig, klare Funktionslogik und Unterschiede zwischen Sätzen zu verstehen - Berechtigungen, die Benutzern zugewiesen sind, befolgen keine Sicherheitsmatrixdefinitionen - Profile enthalten Zugriffssteuerungen für Metadaten - Nur API-Benutzer sind nicht konfiguriert oder werden über mehrere Integrationen hinweg freigegeben
	In Apex: - Datenbankvorgänge führen Zugriffsprüfungen auf Feld- und Objektebene entsprechend aus, einschließlich: -- DML- und Datenbank-DML-Anweisungen deklarieren den Benutzer- oder Systemmodus für Datenvorgänge UND/ODER -- DML- und Datenbank-DML-Anweisungen verwenden `stripInaccessible-`Methoden vor Datenvorgängen -- SOQL- und SOSL-Anweisungen werden `mit USER_MODE` und `mit SYSTEM_MODE-`Stichworten UND/ODER verwendet. -- `stripInaccessible`-Methoden werden zum Filtern von Abfrage- und Unterabfrageergebnissen verwendet -- sObject description-Ergebnismethoden (d. h. `isAccessible`, `isCreateable`, `isUpdateable` und/oder `isDeletable`) werden sparsam verwendet	In Apex: - DML, Datenbankklassen-Methoden, SOQL und SOSL werden im standardmäßigen Systemmodus ausgeführt - Datenbankvorgänge führen Zugriffsprüfungen nicht ordnungsgemäß aus, einschließlich: -- DML- oder Datenbankklassen-Methoden verwenden ausschließlich die Überprüfungen `isAccessible`, `isCreateable`, `isUpdateable` und/oder `isDeletable` für sObject- und Feldebenenzugriff -- SOQL-Abfragen verwenden ausschließlich `MIT SECURITY_ENFORCED-`Stichworten für Zugriffseinschränkungen
	In Flows (Sicherheitsüberlegungen zum Flow-Design): - Flows verwenden den restriktivsten Ausführungskontext, idealerweise Benutzermodus - Sicherheitsrelevanter oder privilegierter Datenzugriff wird durch Subflows ausgeführt, um den Ausführungskontext zu minimieren - In durch einen Datensatz ausgelösten Flows ausgeführte Begrenzungslogik - Flow-Eingaben werden validiert, um sicherzustellen, dass nur zulässige Nutzlasten als Eingabe übergeben werden	In Flows: - Flows werden entweder im Systemmodus oder im Systemmodus ohne Freigabe ausgeführt, unabhängig davon, welche Aktionen der Flow ausführt - Die gesamte Flow-Logik wird in einem einzelnen, großen Flow ausgeführt - Flow-Eingaben werden nicht validiert und ohne Überprüfung an Verbraucher weitergegeben

## Sitzungssicherheit Eine Sitzung ist die Reihe von Anforderungen und Antworten, die einem Benutzer über einen bestimmten Zeitraum zugeordnet sind. Eine Sitzung wird initiiert, wenn sich ein Benutzer erfolgreich bei Salesforce authentifiziert. Bei der [Sitzungssicherheit](https://help.salesforce.com/s/articleView?language=en_US&type=5&id=sf.security_overview_sessions.htm) handelt es sich um die Konfiguration Ihres Systems, um unbefugten Zugriff und Datenschutzverletzungen zu verhindern, indem Sitzungsstörungen oder -hijacking verhindert werden. Alle Benutzeraktivitäten in Ihrem System erfolgen im Kontext einer Sitzung. Daher ist es wichtig, zu berücksichtigen, wie Sitzungen initiiert werden, was während einer Sitzung stattfinden kann, welche Geräte Benutzer verwenden werden (und sollten) und wie verdächtiges oder anormales Sitzungsverhalten erkannt und darauf reagiert werden kann. Sie können die Sitzungssicherheit in Salesforce erstellen, indem Sie sich auf drei Schlüssel konzentrieren: Sitzungsverwaltung, Gerätezugriff und Bedrohungserkennung und -reaktion. ### Sitzungsverwaltung Sitzungen werden initiiert, wenn sich ein Benutzer erfolgreich authentifiziert und Zugriff auf Salesforce erhält. Durch diese Sitzungen kann die Plattform bestimmte Anforderungen und Antworten mit diesem bestimmten Benutzer verknüpfen. HTTPS-Protokoll erleichtert die Kommunikation zwischen einem Front-End-Client und Salesforce Platform. Zu den Kunden können Browser, mobile Anwendungen, lokale Anwendungen usw. gehören. HTTPS ist ein Protokoll ohne Status, d. h., jede Kommunikation ist diskret und nicht mit vorherigen oder zukünftigen Kommunikationen verbunden. Dieser zustandslose Ansatz beschleunigt die Netzwerkkommunikation und beseitigt Fehler, die durch unterbrochene Verbindungen zwischen Paketen verursacht werden. Webanwendungen benötigen jedoch weiterhin eine Möglichkeit, die Identität der einzelnen Benutzer und andere zugehörige Informationen über mehrere Anforderungs- und Antwortinteraktionen hinweg zu verfolgen. Wie die meisten Webanwendungen verwendet Salesforce dazu Sitzungen und [Token](https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_tokens_scopes.htm&type=5). - Mit **Sitzungen** kann Salesforce Anforderungen und Antworten Benutzern zuordnen. Nachdem ein Benutzer authentifiziert wurde, sendet die Plattform eine Sitzungs-ID zurück an die Client-Anwendung, die diese ID mit allen Benutzeranforderungen (z. B. Navigieren, Suchen und Senden von Daten) enthält. - Mit **Token** können Benutzer und verbundene Anwendungen ihre Identität einmal bestätigen und fortan ein eindeutiges Zugriffstoken verwenden. Token haben eine begrenzte Lebensdauer und bieten nur Zugriff auf bestimmte Ressourcen (weitere Informationen zum Konfigurieren von Zugriffsebenen finden Sie unter [Autorisierung](/docs/architect/de-de/well-architected/guide/secure#autorisierung)). Token ermöglichen den Zugriff auf autorisierte Ressourcen, ohne dass sich Benutzer anmelden müssen. Wenn Sitzungen und Token nicht ordnungsgemäß geschützt sind, können fehlerhafte Akteure sie möglicherweise beeinträchtigen und sich als Benutzer ausgeben oder schädlichen Code in Ihrem System ausführen. Erstellen einer sicheren Sitzungsverwaltung für Salesforce: - **Erfahren Sie, wie Salesforce Sitzungstypen klassifiziert**. Identifizieren und ordnen Sie genehmigte [Sitzungstypen](https://help.salesforce.com/s/articleView?id=sf.security_session_types.htm&type=5) Sicherheitsbenutzer-Personas zu und zeichnen Sie sie in Ihrer Dokumentation auf. - **Steuern Sie, wie Sitzungen entstehen und wohin der Sitzungsverkehr gehen kann**. Nachdem Sie die Sitzungstypen identifiziert haben, die von verschiedenen Benutzer-Personas initiiert werden dürfen, konfigurieren Sie Steuerelemente, um Sitzungen zu blockieren, die aus nicht genehmigten Quellen oder Kontexten stammen. Salesforce bietet mehrere Möglichkeiten, den Ursprung und den Datenverkehr von Sitzungen zu steuern, darunter: - **Integrierter Sitzungsschutz**. Salesforce aktiviert automatisch organisationsweite Schutzmaßnahmen für sitzungsbasierte bösartige Aktivitäten, einschließlich Cross-Site-Scripting, Fälschung von Site-übergreifenden Anforderungen, [Inhalts-Sniffing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing), [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking) und mehr. Diese Schutzmaßnahmen sollten niemals deaktiviert werden. Einige können nicht deaktiviert werden. - **Domänen und IP-Bereiche**. In allen Salesforce-Organisationen ist standardmäßig [Meine Domäne](https://help.salesforce.com/s/articleView?id=sf.domain_name_overview.htm&type=5) aktiviert, wodurch eine unternehmensspezifische Unterdomäne für den Salesforce-Zugriff erstellt wird. Sie können den Namen, der einer Organisation zugeordnet ist, über "Meine Domäne" anpassen oder ändern. Darüber hinaus unterstützt Salesforce zusätzliche [Domänenkonfigurationen](https://help.salesforce.com/s/articleView?id=sf.domain_mgmt_overview.htm&type=5) für Experience Cloud-Sites und andere Anwendungsseiten. Hinweis: Wenn Ihre Benutzer hinter einer Unternehmens-Firewall auf Salesforce zugreifen müssen, fügen Sie Ihren Firewall-Zulassungslisten die [erforderlichen Domänen](https://help.salesforce.com/s/articleView?id=sf.setup_domains.htm&type=5) hinzu. Sie können [IP-Bereiche](https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/users_profiles_epui_login_ip_ranges_edit.htm) für die Anmeldung und [vertrauenswürdige IP-Bereiche](https://help.salesforce.com/s/articleView?id=sf.security_networkaccess.htm) einrichten, um eingehende Anmelde- und Sitzungsanforderungen an Salesforce zu steuern. - **Anmeldezeiten**. Wenn bestimmte Benutzer-Personas Arbeitszeiten festgelegt haben, können Sie ihre Zugriffsmöglichkeiten auf Salesforce außerhalb der definierten [Anmeldezeiten](https://help.salesforce.com/s/articleView?id=sf.login_hours.htm&type=5) einschränken. - **Steuern Sie Aktivitäten, für die zusätzliche Sicherheit auf Sitzungsebene erforderlich ist**. Standardmäßig können Sitzungen zwei Arten von [Sicherheitsebenen](https://help.salesforce.com/s/articleView?id=sf.security_overview_sessions.htm&type=5) aufweisen: Standard und hohe Sicherung. Verwenden Sie diese Sicherheitsebenen, um zu steuern, wie Benutzer Aktivitäten wie den Zugriff auf Berichte und Dashboards oder die Verwaltung der Sicherheitskonfigurationen in einer Salesforce-Organisation ausführen können und wie nicht. Sicherheitsrichtlinien auf Sitzungsebene können vorschreiben, dass Benutzer [Sitzungen mit hoher Sicherung](https://help.salesforce.com/s/articleView?id=sf.security_auth_require_ha_session.htm&type=5) einrichten müssen, um Vorgänge auszuführen, oder Benutzer daran hindern, sensible Vorgänge überhaupt auszuführen. - **Steuern Sie Aktivitäten, für die sitzungsbasierte Berechtigungen hinzugefügt werden müssen**. Salesforce unterstützt [sitzungsbasierte Berechtigungsaktivierungen](https://help.salesforce.com/s/articleView?id=sf.perm_sets_session_use.htm&type=5), um Benutzern während einer bestimmten Sitzung vorübergehend eine erhöhte Autorisierung oder Zugriff auf Berechtigungen zu ermöglichen. Sie können sitzungsbasierte Berechtigungen über Flow- oder Salesforce-APIs aktivieren und deaktivieren. - **Verwalten Sie inaktive Benutzersitzungen über Zeitüberschreitungen**. Das Beenden inaktiver Sitzungen ist ein wichtiger Bestandteil der Verwaltung der Sitzungssicherheit. Dadurch wird Ihr System geschützt, wenn ein Benutzer beispielsweise eine Salesforce-Sitzung auf einer Browserregisterkarte geöffnet lässt, jedoch aktiv in einer anderen Anwendung arbeitet oder wenn das Mobilgerät eines Benutzers bei Salesforce angemeldet ist, jedoch nicht besucht wird. Salesforce hat eine standardmäßige Sitzungsinaktivitäts-Zeitüberschreitung von zwei Stunden. Sie können die Zeitüberschreitung bei Sitzungsinaktivität erhöhen oder verringern. Die Erhöhung der Zeitüberschreitungen sollte jedoch nur mit einer überzeugenden und gut dokumentierten Begründung erfolgen. - **Verwalten Sie Sitzungen verbundener Anwendungen über die Tokenkonfiguration.** Wenn Sie eine verbundene Anwendung konfigurieren, definieren Sie auch den Umfang oder die Autorisierungsebene, die Benutzern gewährt werden, die über die verbundene Anwendung auf Salesforce zugreifen. Dieser Umfang wird auf Sitzungsebene über [OAuth-Token](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US) erzwungen, die ausgestellt werden, nachdem sich ein Benutzer einer verbundenen Anwendung erfolgreich authentifiziert hat. Über [Tokenaktualisierungsrichtlinien](https://help.salesforce.com/s/articleView?id=remoteaccess_oauth_tokens_scopes.htm&type=5&language=en_US) können Sie steuern, wie lange ein Token gültig sein soll. Organisationsadministratoren können Token bei Bedarf manuell pro Benutzer und pro Organisation widerrufen. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/secure#sitzungssicherheitsmuster-und-anti-muster) zeigt, wie eine ordnungsgemäße (und schlechte) Sitzungsverwaltung in einer Salesforce-Organisation aussieht. Verwenden Sie diese, um Ihre Designs vor dem Erstellen zu validieren oder Opportunities für weitere Verbesserungen zu identifizieren. Weitere Informationen zu den von Salesforce verfügbaren Sitzungsverwaltungstools finden Sie unter [Sicherungsrelevante Tools](/docs/architect/de-de/well-architected/guide/secure#für-die-sicherheit-relevante-tools). ### Gerätezugriff Im aktuellen Kontext ist ein _Gerät_ jedes elektronische Gerät, das eine Einzelperson für den Zugriff auf Salesforce verwendet, beispielsweise ein Desktop-Arbeitsplatz, ein Laptop, ein Tablet oder ein Mobiltelefon. Tragbare Geräte bieten Benutzern die Flexibilität, von jedem beliebigen Standort aus auf Salesforce zuzugreifen. Diese Bequemlichkeit führt jedoch potenziell zu zusätzlichen Angriffsvektoren für bösartige Akteure. Diese Bedrohungsvektoren reichen von einfachen Taktiken wie Schultersurfen an einem öffentlichen Ort zum Stehlen von Anmeldeinformationen bis hin zu komplexeren Methoden wie der Installation von Malware auf einem Gerät oder der Erstellung eines gefälschten öffentlichen WLAN-Netzwerks zum Abfangen von Datenübertragungen. Aus diesem Grund ist die Sicherung von Geräten – insbesondere tragbaren Geräten – für die allgemeine Systemsicherheit unerlässlich. Schützen des Gerätezugriffs für Salesforce: - **Verwenden Sie die von Salesforce bereitgestellten Lösungen für mobile Anwendungen.** Legen Sie fest, dass Benutzer auf Mobilgeräten, die auf Salesforce zugreifen müssen, die offiziellen [Salesforce-Anwendungen für iOS und Android](https://help.salesforce.com/s/articleView?id=sf.mobile_security.htm&type=5) verwenden können. Wenn geschäftliche Anforderungen eine benutzerdefinierte mobile Lösung erfordern, sollten Sie das [Mobile Salesforce SDK](https://developer.salesforce.com/docs/atlas.en-us.mobile_sdk.meta/mobile_sdk/intro.htm) verwenden, das Methoden zur sicheren Authentifizierung und Autorisierung bereitstellt. - **Entwerfen Sie die Nutzung mobiler Geräte in Ihre Sitzungsverwaltung.** Sitzungssicherheitsebenen, Sitzungs-Timeouts und andere Sitzungskontextsteuerungen sollten jeden erwarteten Zugriff von Benutzern auf Mobilgeräten berücksichtigen. Überlegen Sie, welche Geräte auf Salesforce zugreifen dürfen und welche Benutzertypen auf mobile Sitzungen zugreifen sollen. Fügen Sie mobile Zugriffsstandards in Ihre Sicherheitspersona-Dokumentation ein. Weitere Informationen zu diesem Thema finden Sie unter [Sitzungsverwaltung](/docs/architect/de-de/well-architected/guide/secure#sitzungsverwaltung). - **Ergänzen Sie die Sicherheit auf Geräteebene durch die MDM-Technologie (Mobile Device Management).** Die Salesforce-Anwendungen für iOS und Android sind [kompatibel mit vielen beliebten MDM-Suites](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mdm.htm&type=5). Sie können zusätzliche Zugriffssteuerungen für die Salesforce-Anwendung auf Benutzergeräten über Ihre bevorzugte MDM-Lösung konfigurieren. - **Ergänzen Sie die Sicherheit auf Anwendungsebene durch die MAM-Technologie (Mobile Application Management).** Die MAM-Technologie unterstützt Steuerelemente auf Anwendungsebene auf Mobilgeräten. Salesforce bietet ein kostenpflichtiges [MAM-Add-On](https://help.salesforce.com/s/articleView?id=sf.mobile_security_mam_overview.htm&type=5) für mobile Salesforce-Anwendungen. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/secure#sitzungssicherheitsmuster-und-anti-muster) zeigt, wie eine ordnungsgemäße (und schlechte) Geräteverwaltung in einer Salesforce-Organisation aussieht. Verwenden Sie diese, um Ihre Designs vor dem Erstellen zu validieren oder Opportunities für weitere Verbesserungen zu identifizieren. Weitere Informationen zu den von Salesforce verfügbaren Geräteverwaltungstools finden Sie unter [Sicherungsrelevante Tools](/docs/architect/de-de/well-architected/guide/secure#für-die-sicherheit-relevante-tools). ### Bedrohungserkennung und -reaktion Bei der Bedrohungserkennung handelt es sich um das Identifizieren von Verhaltensmustern in Ihrem System, die auf bösartige Aktivitäten hinweisen können. Dies kann dazu führen, dass Datenvolumen, die überdurchschnittlich groß sind, heruntergeladen werden oder dass ein Benutzer Felder mit sensiblen Daten in mehreren Datensätzen innerhalb eines kürzeren als durchschnittlichen Zeitraums ändert. Zu den Reaktionen auf Bedrohungen können automatisierter Sitzungsablauf, Warnungen und andere Benachrichtigungen gehören. Ziel der Bedrohungserkennung ist es, potenzielle Probleme so schnell wie möglich zu erkennen und darauf zu reagieren. Wenn Sie Maßnahmen auf der Grundlage der Echtzeit-Bedrohungserkennung ergreifen, kann dies dazu führen, dass bösartiges Verhalten in den Verfolgungen gestoppt wird. Salesforce bietet eine [Echtzeit-Ereignisüberwachung](https://help.salesforce.com/s/articleView?id=sf.real_time_event_monitoring_overview.htm&type=5) als Add-On oder als Teil von [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/). Verwenden Sie eine dieser Lösungen, wenn Sie über hochsensible Anwendungen verfügen oder zuverlässige Echtzeit-Bedrohungserkennungs- und -reaktionsfunktionen benötigen. Erstellen einer effektiven Strategie zur Erkennung und Reaktion von Bedrohungen für Ihre Salesforce-Lösungen: - **Verwenden Sie integrierte Überwachungsfunktionen**. Salesforce bietet eine Vielzahl [integrierter Tools](https://help.salesforce.com/s/articleView?id=sf.monitoring_admin.htm&type=5), mit denen Sie Änderungen an Ihrer Organisation verfolgen und überprüfen können. Mit dem [Setup-Aktivierungsprotokoll](https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5) können Sie beispielsweise den Aktivierungsverlauf von Verwaltungsaktionen anzeigen. Salesforce verfolgt Feldebenenänderungen standardmäßig für einen begrenzten Zeitraum. Sie können jedoch [die Feldverlaufsverfolgung](https://help.salesforce.com/s/articleView?id=sf.tracking_field_history.htm&type=5) aktivieren, um Feldänderungen für bis zu 18 Monate auf der Benutzeroberfläche und bis zu 24 Monate über die API anzuzeigen. Außerdem können Sie [das Feld-Aktivierungsprotokoll](https://help.salesforce.com/s/articleView?id=sf.field_audit_trail.htm&type=5) aktivieren, um einen Überprüfungsverlauf für Änderungen auf Feldebene unbegrenzt beizubehalten (bis Sie die Daten manuell löschen). - **Erstellen Sie regelmäßige Überprüfungen**. Die Überprüfung ist wichtig, um anomale Änderungen zu identifizieren, die bei der Echtzeit-Bedrohungserkennung möglicherweise übersehen werden. Stellen Sie sich ein Szenario vor, in dem ein Benutzer mit berechtigtem Zugriff täglich eine kleine Anzahl von Datensätzen über einen längeren Zeitraum hinweg löscht. Da dieser Benutzer über gültige Anmeldeinformationen verfügt, ordnungsgemäß autorisiert ist, Datensätze zu löschen, und nicht eine große Menge an Datensätzen gleichzeitig löscht, ist es unwahrscheinlich, dass die Aktivität als Echtzeitbedrohung erkannt wird. Ein Überprüfungsteam, das Berichte zu Benutzeraktivitäten überprüft, würde diesen Trend der übermäßigen Löschung von Datensätzen durch einen einzelnen Benutzer im Laufe der Zeit jedoch eindeutig identifizieren, wodurch er einfacher angegangen werden könnte. Richten Sie im Rahmen Ihrer [Governance-Richtlinien](/docs/architect/de-de/well-architected/guide/intentional#governance) regelmäßige Intervalle für die Überprüfung des Anmeldeverlaufs, der Benutzersitzungsaktivität und der Nutzung verbundener Anwendungen ein. - **Entwickeln Sie eine Strategie zur Bedrohungsreaktion und fügen Sie sie in Ihre Sicherheitsrichtlinien ein.** Erstellen Sie eine Strategie zur Reaktion auf Bedrohungen, die Folgendes abdeckt: - Definitionen des Bedrohungsantworttyps (z. B. Warnungen und Automatisierungen) und alle Beteiligtengruppen, [die beteiligt sein sollten](/docs/architect/de-de/well-architected/guide/resilient#vorfallsreaktion). Weitere Informationen zum Entwerfen von Nachrichten oder Benachrichtigungen finden Sie unter [Fehler und Benachrichtigungen](/docs/architect/de-de/well-architected/guide/engaging#benachrichtigungen-und-nachrichten). - Spezifische Kategorien für Echtzeitänderungen oder -aktivitäten, die als Bedrohungen betrachtet werden könnten, und der zugehörige Antworttyp für die einzelnen - Übersichtliche Liste aller automatisierten Bedrohungsantworten (z. B. Widerrufen von Token, Beenden von Sitzungen, Deaktivieren von Benutzeraccounts oder Blockieren des Zugriffs auf Ressourcen) und Automatisierungsauslöser Die Ereignisüberwachung stellt die Daten bereit, die zur Durchsetzung dieses Prinzips erforderlich sind, indem sie die Echtzeiterkennung und -reaktion von Bedrohungen aktiviert. Die Transaktionssicherheit wendet die richtliniengesteuerten Aktionen Ihres Unternehmens an und Ereignistypen unterstützen die Überwachung des Benutzer- und Anwendungszugriffs im Laufe der Zeit. Der native Service "Bedrohungserkennung" von Salesforce verwendet statistische Modelle und Modelle für maschinelles Lernen, um verdächtiges Verhalten zu identifizieren. Dieser Service generiert bestimmte Ereignisse, die vor Cyberangriffen und verdächtigem Datenzugriff schützen. Die Transaktionssicherheit geht mit der Sicherheit noch einen Schritt weiter, da sie ein Framework bereitstellt, das wichtige Ereignisse in Ihrer Organisation abfängt und die richtliniengesteuerten Aktionen Ihres Unternehmens anwendet. Dadurch wird die Ereignisüberwachung von einem Protokollierungstool zu einer wichtigen Komponente einer automatisierten Sicherheitsabwehr. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/secure#sitzungssicherheitsmuster-und-anti-muster) zeigt, wie die ordnungsgemäße (und schlechte) Erkennung und Reaktion von Bedrohungen in einer Salesforce-Organisation aussieht. Verwenden Sie diese, um Ihre Designs vor dem Erstellen zu validieren oder Opportunities für weitere Verbesserungen zu identifizieren. Weitere Informationen zu den von Salesforce verfügbaren Tools zur Bedrohungserkennung, -warnung und -reaktionsautomatisierung finden Sie unter [Sicherungsrelevante Tools](/docs/architect/de-de/well-architected/guide/secure#für-die-sicherheit-relevante-tools). ### Sitzungssicherheitsmuster und Anti-Muster Diese Tabelle zeigt eine Auswahl an Mustern, die in Ihrer Organisation gesucht (oder erstellt) werden sollen, und Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Sitzungssicherheit im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/trusted-session-security) Anti-Muster.

	Muster	Anti-Muster
Session Management	In Ihren Designstandards und in Ihrer Dokumentation: - Sicherheitspersonas führen genehmigte Sitzungstypen und Einstellungen für Zeitüberschreitung/Dauer für jede Persona übersichtlich auf - Anmeldezeiten wurden angegeben (oder als nicht erforderlich identifiziert) - Vorgänge, die erhöhte Sicherheit auf Sitzungsebene oder Berechtigungen erfordern, sind klar und auffindbar - Richtlinien für den Umfang und die Tokenverwaltung der verbundenen Anwendung sind klar und auffindbar	In Ihren Designstandards und in Ihrer Dokumentation: - Sicherheitspersonas sind nicht vorhanden oder es fehlen Informationen über Sitzungstypen und Zeitüberschreitungs-/Dauereinstellungen - Sicherheitsrichtlinien enthalten keine Informationen über Umfänge der verbundenen Anwendung oder die Tokenverwaltung
	In Ihrer Organisation: - Sitzungsüberprüfungen zeigen, dass Benutzer nur über erwartete Sitzungstypen auf Salesforce zugreifen - Es gibt einen klaren, aktiven Berechtigungssatz für den Zugriff "Nur API-Benutzer" (mit dem Berechtigungssatz "Nur API" auf TRUE) und alle Integrations- und automatisierten Benutzer werden zugewiesen - Wenn Benutzer hinter einer Firewall auf Salesforce zugreifen, verwendet die Firewall eine Zulassungsliste der erforderlichen Domänen anstelle von IP-Adressen, um die Kommunikation mit/von Salesforce zu schützen - Inaktive Sitzungs-Timeout-Intervalle überschreiten nicht den Standardwert (2 Stunden) - Alle folgenden Einstellungen sind aktiviert: -- Clickjack-Schutz für Setup-Seiten -- Clickjack-Schutz für Salesforce-Seiten ohne Setup -- Cross-Site Request Forgery (CSRF) Schutz -- Cross-Site Scripting (XSS) Schutz -- Aktivieren des Schutzes vor Inhaltsschnüffelung -- Referrer URL protection (Schutz des Referrer-URLs) -- Warnen von Benutzern, bevor sie außerhalb von Salesforce umgeleitet werden	In Ihrer Organisation: - Es gibt keine regelmäßige Sitzungsüberprüfung - Es gibt keine Definitionen, welche Sitzungstypen Benutzer haben sollten - "Nur API"-Berechtigungen sind unklar oder fehlen bei Integration und automatisierten Benutzern - Wenn Benutzer hinter einer Firewall auf Salesforce zugreifen, verwendet die Firewall hartcodierte IP-Adressen, um die Kommunikation mit/von Salesforce zu schützen - Inaktive Sitzungs-Timeout-Intervalle überschreiten den Standardwert (2 Stunden) - Eine der folgenden Einstellungen ist deaktiviert: -- Clickjack-Schutz für Setup-Seiten -- Clickjack-Schutz für Salesforce-Seiten ohne Setup -- Cross-Site Request Forgery (CSRF) Schutz -- Cross-Site Scripting (XSS) Schutz -- Aktivieren des Schutzes vor Inhaltsschnüffelung -- Referrer URL protection (Schutz des Referrer-URLs) -- Warnen von Benutzern, bevor sie außerhalb von Salesforce umgeleitet werden
	In LWC, Apex, Aura: - Wenn benutzerdefinierte Anmelde-Flows vorhanden sind, verwendet der zugehörige benutzerdefinierte Code geeignete `SessionManagement-`Methoden, um die Sicherheit auf Sitzungsebene zuzuweisen	In LWC, Apex, Aura: - Wenn benutzerdefinierte Anmelde-Flows vorhanden sind, gibt es keine Logik zum Zuweisen der Sitzungsebenensicherheit
Gerätezugriff	In Ihren Designstandards und in Ihrer Dokumentation: - Geräterichtlinien sind klar und auffindbar - Sicherheitspersonas sind eindeutig den entsprechenden Gerätenutzungen und -richtlinien zugeordnet	In Ihren Designstandards und in Ihrer Dokumentation: - Sicherheitsrichtlinien sind nicht vorhanden oder enthalten keine Informationen über den Gerätezugriff
Gerätezugriff	In Ihrer Organisation: - Konfiguration der mobilen verbundenen Salesforce-Anwendung erfordert Entsperrung von PIN/Kenncode nach Inaktivität - Wenn Geschäftsanforderungen eine strenge Kontrolle der Benutzer erfordern, die auf Salesforce Mobile zugreifen können, ist die API-Zugriffssteuerung aktiviert und allen Benutzern mobiler Salesforce-Anwendungen werden Berechtigungssätze zugewiesen.	In Ihrer Organisation: - Die mobile verbundene Salesforce-Anwendung ist nicht so konfiguriert, dass die Entsperrung von PIN/Kenncode für Inaktivität erforderlich ist – Geschäftsanforderungen erfordern eine strenge Kontrolle der Benutzer, die auf mobile Salesforce-Anwendungen zugreifen können. Die API-Zugriffssteuerung ist jedoch nicht aktiviert oder Berechtigungssätze werden nicht zum Steuern des Zugriffs auf mobile Salesforce-Anwendungen verwendet.
Bedrohungserkennung und -reaktion	In Ihren Designstandards und in Ihrer Dokumentation: - Sicherheitsrichtlinien enthalten eine Liste der Ereignisse, die eine Antwort zusammen mit dem entsprechenden Antworttyp auslösen sollen - Überwachungsebenen wurden für alle Objekte in Ihrem Datenmodell angegeben - Schritte zum Überprüfen der in Salesforce verfügbaren Protokolle werden dokumentiert - Alle automatisierten Antworten werden übersichtlich dokumentiert	In Ihren Designstandards und in Ihrer Dokumentation: - Sicherheitsrichtlinien sind nicht vorhanden oder enthalten keine Informationen zur Bedrohungserkennung und -warnung - Dokumentation für automatisierte Antworten ist nicht vorhanden oder unklar
	Innerhalb Ihres Unternehmens: - Auditdaten sind in Berichten verfügbar, die Geschäftsbeteiligte verstehen und aufrufen können - Regelmäßige Überprüfung des Überprüfungsverlaufs und der Berichte	Innerhalb Ihres Unternehmens: - Überprüfungsdaten sind nur über Protokolldateien verfügbar, für deren Zugriff und Interpretation Fachkenntnisse erforderlich sind - Es gibt keine Prozesse zum Überprüfen von Überwachungsinformationen
	In Ihrer Organisation: - Automatisierungen sind vorhanden, um auf Bedrohungen zu reagieren, indem Benutzeraccounts deaktiviert oder der Zugriff auf Ressourcen in Echtzeit blockiert wird, wenn eine anormale Nutzung erkannt wird - Benachrichtigungen und Warnungen werden konfiguriert, um die entsprechenden Benutzer über anomale Aktivitäten zu informieren - Die Feldverlaufsverfolgung ist für alle Felder aktiviert, die private oder sensible Daten enthalten	In Ihrer Organisation: - Es gibt keine Automatisierungen, um auf Bedrohungen zu reagieren - Benachrichtigungen und Warnungen sind entweder nicht so konfiguriert, dass sie die entsprechenden Benutzer über anomale Aktivitäten benachrichtigen, oder es sind einige Benachrichtigungen und Warnungen in Bezug auf anomale Aktivitäten vorhanden, sie sind jedoch ad hoc - Die Feldverlaufsverfolgung ist für Felder mit privaten oder sensiblen Daten nicht konsistent aktiviert

## Datensicherheit Bei der Datensicherheit handelt es sich um die Praxis, Ihre Daten vor unbefugtem Zugriff, Beschädigung oder unbeabsichtigter Löschung zu schützen. Zur Datensicherheit gehört der Schutz von Daten bei der Übertragung und im Leerlauf. Die hohe Datensicherheit minimiert die Risiken und potenziellen Schäden durch nicht autorisierten Zugriff auf Ihr System. Unzureichende Datensicherheit macht Systeme anfällig für Datenschutzverletzungen, die Kunden und Ihr Unternehmen stark beeinträchtigen können. Daher ist der Schutz Ihrer Daten für den Aufbau sicherer Architekturen von grundlegender Bedeutung. Die Verbesserung der Datensicherheit beginnt mit einem klaren Verständnis dessen, was in Salesforce als Daten betrachtet wird, sowie mit der Klassifizierung. Die einzelnen Datensätze, Dateien und Dokumente, die in einer Salesforce-Organisation gespeichert sind, sind ihre Daten. Weitere Informationen zur Unterscheidung zwischen Metadaten und Daten finden Sie unter [Salesforce Architecture Basics](/docs/architect/de-de/fundamentals/guide/architecture-basics#metadaten-im-vergleich-zu-daten). Sie können die Datensicherheit in Ihren Salesforce-Lösungen erhöhen, indem Sie sich auf die Freigabe und Sichtbarkeit sowie die Verwendung der Verschlüsselung konzentrieren. > Hinweis: Achten Sie beim Entwerfen auf Datensicherheit auf die [Datenprivatsphäre](/docs/architect/de-de/well-architected/guide/compliant#datenschutz) sowie auf die [Archivierung und Bereinigung](/docs/architect/de-de/well-architected/guide/resilient#kontinuitätsplanung), da sich beide Konzepte auf die Gesamtdatensicherheit Ihrer Lösungen auswirken. ### Datenklassifizierung Identifizieren und klassifizieren Sie alle auf der Salesforce Platform gespeicherten Daten anhand ihrer Sensibilität (z. B. öffentlich, intern, vertraulich, eingeschränkt). Definieren Sie eine klare **Datenklassifizierungsrichtlinie**, in der dargelegt wird, wie die einzelnen Datentypen gehandhabt und geschützt werden sollen. Implementieren Sie geeignete Sicherheitssteuerungen wie Feldebenensicherheit, Verschlüsselung und Datenmaskierung, um die Richtlinie durchzusetzen und sensible Daten vor unbefugtem Zugriff oder Offenlegung zu schützen. Überprüfen und überprüfen Sie diese Klassifizierungen und Kontrollen regelmäßig, um sicherzustellen, dass sie den Geschäfts- und Compliance-Anforderungen entsprechen. ### Freigabe und Sichtbarkeit Die Freigabe und Sichtbarkeit beinhaltet die Konfiguration Ihres Systems, um zu steuern, wie Benutzer auf Daten in Salesforce zugreifen. Es ist wichtig zu beachten, dass die Freigabe und Sichtbarkeit steuern, auf welche einzelnen Datensätze ein Benutzer zugreifen kann. Diese Einstellungen allein steuern jedoch letztlich nicht, was ein Benutzer mit einem bestimmten Datensatz tun kann oder welche spezifischen Felder in diesem Datensatz sichtbar sind. Berechtigungen zum Ausführen von Datenvorgängen (wie [CRUD](https://developer.salesforce.com/docs/atlas.en-us.214.0.lightning.meta/lightning/apex_crud_fls.htm)) werden Benutzern über Steuerelemente für den Metadatenzugriff zugewiesen, die für einen Benutzer auf Objekt- und Feldebene konfiguriert werden können. Weitere Informationen hierzu finden Sie unter [Autorisierung](/docs/architect/de-de/well-architected/guide/secure#autorisierung). Agentforce-Aktionen können Daten sowohl für authentifizierte als auch für anonyme Benutzer bereitstellen, die in der Regel keinen direkten Zugriff haben. Berücksichtigen und dokumentieren Sie beim Erstellen von Agentforce Agents sorgfältig alle dem Agenten zugewiesenen Aktionen. Für jede Aktion müssen Sie Folgendes verstehen: - Auf welche Daten die Aktionen zugreifen können. - In welchem Sicherheitskontext die Aktionen ausgeführt werden. - Gibt an, ob die Aktionen Knowledge Retrieval oder andere Funktionen aufweisen, die sensible oder eingeschränkte Daten in die Agentensitzung integrieren können. Konfigurieren der effektiven Freigabe und Sichtbarkeit in Salesforce: - **Designzugriff auf sinnvolle Auftragsfunktionen**. Erstellen Sie eine Sicherheitsmatrix, die Ihre [Benutzerpersonas](/docs/architect/de-de/well-architected/guide/secure#authentifizierung) Geschäftsfunktionen zuordnet, die sie ausführen sollen. Verwenden Sie diese [Vorlage](/docs/architect/de-de/resources/guide/security-policy-template) als Grundlage für die Gestaltung Ihrer Freigabe und Sichtbarkeit. Weitere Informationen zum Identifizieren sinnvoller Geschäftsfunktionen finden Sie unter [Funktionale Einheiten](/docs/architect/de-de/well-architected/guide/composable#funktionale-einheiten). - **Wählen Sie den einfachsten Weg zur Anwendung des Prinzips der geringsten Berechtigung aus**. Wenn Sie das [Prinzip der geringsten Berechtigung](/docs/architect/de-de/well-architected/guide/secure#autorisierung) beim Entwerfen von Freigabe- und Sichtbarkeitsschemas anwenden, sollten Sie dies auf möglichst einfache Weise tun. Vermeiden Sie übertriebene Dateneinschränkungen und Freigabeschemas, die zu nachgelagerten Problemen bei der Systemwartung, -skalierbarkeit und -anpassungsfähigkeit führen können. Profitieren Sie stattdessen von der [flexiblen, mehrschichtigen Datenfreigabe in Salesforce](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf), um detaillierte Regeln für den Benutzerzugriff auf Datenebene zu konfigurieren. - **Setzen Sie _interne_ organisationsweite Standardeinstellungen (OWDs) auf "Öffentlicher Lesezugriff", es sei denn, Ihr Unternehmen verarbeitet sensible Daten. Verwenden Sie dann "Privat".** OWDs steuern die Ebene der "geringsten" Berechtigungen, die Benutzer auf Datenebene haben. Sie können den Zugriff nicht unter der Ebene Ihres Einmalkennworts einschränken. Während Private OWDs in jedem Anwendungsfall ideal erscheinen, können Benutzer im gesamten Unternehmen häufig versehentlich ein freizügigeres OWD durch komplexe Freigabeschemas replizieren. Zusätzlich können private Einmalkennwörter dazu führen, dass Benutzer doppelte Daten erstellen. Die Freigabeberechnungen (und Neuberechnungen) können je nach Datenvolumen und Schieflage zwischen Über- und Unterordnung oder Inhaberschaft viel Zeit in Anspruch nehmen – private Einmalkennzahlen verschärfen dies. Beachten Sie, dass OWDs keine CRUD-Berechtigungen und keine Sichtbarkeit auf Feldebene steuern. Wählen Sie nur dann die Option "Privat" aus, wenn dies durch Geschäftsanforderungen gerechtfertigt ist. Meistens beziehen sich solche Begründungen auf die [Compliance](/docs/architect/de-de/well-architected/guide/compliant). - **Legen Sie _externe_ organisationsweite Standardeinstellungen auf "Privat" fest, es sei denn, Sie haben einen zwingenden geschäftlichen Grund, einen größeren Zugriff zuzulassen.** [Externe Einmalkennwörter](https://help.salesforce.com/s/articleView?id=sf.security_owd_external.htm&type=5) gelten für Benutzer, die über Experience Cloud-Sites, -Portale usw. auf Salesforce-Daten zugreifen. Dadurch können Sie separate OWD-Grundlagen für interne und externe Benutzer konfigurieren, um unterschiedliche Arten von "niedrigsten" Berechtigungen zu ermöglichen. Legen Sie das Einmalkennwort für externe Benutzer immer auf "Privat" fest. Ausnahmen für eine offenere Ebene müssen durch Geschäftsanforderungen klar begründet werden. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/secure#datensicherheitsmuster-und-antimuster) zeigt, wie eine ordnungsgemäße (und schlechte) Freigabe und Sichtbarkeit in einer Salesforce-Organisation aussieht. Verwenden Sie diese, um Ihre Designs vor dem Erstellen zu validieren oder Opportunities für weitere Verbesserungen zu identifizieren. Weitere Informationen zu Freigabe- und Sichtbarkeitstools von Salesforce finden Sie unter [Sicherungsrelevante Tools](/docs/architect/de-de/well-architected/guide/secure#für-die-sicherheit-relevante-tools). ### Verwendung der Verschlüsselung Die Verschlüsselung konvertiert lesbare Daten in ein nicht entschlüsselbares, verschlüsseltes Format. Verschlüsselte Daten können über einen Schlüssel entschlüsselt oder in ihre ursprüngliche Form zurückübersetzt werden. Folglich zählt die Verschlüsselung zu den effektivsten Methoden zum Schutz von Daten im Leerlauf und während der Übertragung. So wird sichergestellt, dass sie auch dann unlesbar sind, wenn unbefugte Personen auf die Daten zugreifen. Entwerfen für die ordnungsgemäße Verwendung der Verschlüsselung in Ihren Salesforce-Lösungen: - **Verschlüsseln Sie Daten bei der Übertragung immer ausreichend.** Salesforce [setzt Transport Layer Security (TLS)](https://help.salesforce.com/s/articleView?id=sf.security_overview_infrastructure.htm&type=5) für alle Sitzungen ein, die in einem von [Salesforce unterstützten Browser](https://help.salesforce.com/s/articleView?id=sf.getstart_browser_overview.htm&type=5) stattfinden, und erfordert, dass ausgehende Aufrufe über HTTPS bestimmte Sicherheitsstandards erfüllen. Plattform-APIs verwenden standardmäßig auch HTTPS. Außerdem werden Daten, die zwischen einer Salesforce Experience Cloud-Site oder einem Portal und der zugehörigen Salesforce-Organisation gesendet werden, [standardmäßig](https://help.salesforce.com/s/articleView?id=xcloud.security_pe_platform_encryption_faq.htm&type=5) verschlüsselt übertragen. Wenn Sie die [integrierten E-Mail-Services](https://help.salesforce.com/s/articleView?id=sf.emailadmin_send_email_from_salesforce_overview.htm&type=5) von Salesforce verwenden, gibt es Standardebenen für die Transport Layer Security (TLS), die Salesforce zum [Versenden und Versuchen](https://help.salesforce.com/s/articleView?id=sf.emailadmin_deliverability.htm&type=5) der Zustellung von E-Mails verwendet. Sie sollten mindestens sicherstellen, dass die Organisationseinstellungen nicht unter den Standardeinstellungen liegen, es sei denn, Sie haben eine klare geschäftliche Begründung. Je nach Klassifizierung und Vertraulichkeit Ihrer Daten sollten Sie eine private Netzwerkverbindung zu Salesforce über AWS Direct Connect oder Salesforce Private Connect nutzen. Dadurch wird sichergestellt, dass Ihre Daten nicht über das öffentliche Internet traversieren, sondern sicher über eine private Netzwerkverbindung für Benutzerzugriff und Integrationen fließen. - **Wenn das Unternehmen dies erfordert, verschlüsseln Sie Daten im Leerlauf**. Salesforce bietet verschiedene Möglichkeiten zum Verschlüsseln von Daten im Leerlauf. - **Hyperforce**. In Organisationen, die [Hyperforce](/docs/architect/de-de/fundamentals/guide/platform-multitenant-architecture#hyperforce) verwenden, werden Daten im Leerlauf verschlüsselt. Die Verschlüsselung wird für Ihre Organisation von Salesforce verwaltet. Sie können keine eigenen Verschlüsselungsschlüssel erstellen (oder vernichten). - **Salesforce Shield**. Mit [Salesforce Shield](https://www.salesforce.com/products/platform/products/shield/) können Sie Daten im Leerlauf in einer Salesforce-Organisation auf zusätzlichen Ebenen verschlüsseln, einschließlich der Anwendungs- und Datenbankebenen. Mit Shield verfügen Sie über vollständige Verwaltungsfunktionen für die Verschlüsselungsschlüssel Ihres Mandanten, einschließlich der robusten Optionen "Bring Your Own Key" (BYOK). Sie können auch unstrukturierte Daten verschlüsseln (einschließlich Dateien, Anhängen, Suchindizes und Ereignissen). Hyperforce Instanzen bieten die Möglichkeit, einen externen Schlüssel-Manager zu verwenden, wodurch Sie Ihr eigenes AWS KMS mitbringen können. Mit dieser Funktion behalten Sie die volle Kontrolle über die Verschlüsselungsschlüssel in Ihrem KMS, die zum Verschlüsseln und Entschlüsseln der in Salesforce gespeicherten Daten verwendet werden. Dies erhöht die Sicherheit und entspricht den Compliance-Anforderungen Ihrer Organisation. Die folgende Liste der [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/secure#datensicherheitsmuster-und-antimuster) zeigt, wie die ordnungsgemäße (und schlechte) Verwendung der Verschlüsselung in einer Salesforce-Organisation aussieht. Verwenden Sie diese, um Ihre Designs vor dem Erstellen zu validieren oder Opportunities für weitere Verbesserungen zu identifizieren. Weitere Informationen zu den von Salesforce verfügbaren Verschlüsselungstools finden Sie unter [Sicherungsrelevante Tools](/docs/architect/de-de/well-architected/guide/secure#für-die-sicherheit-relevante-tools). ### Datensicherheitsmuster und Antimuster Diese Tabelle zeigt eine Auswahl an Mustern, die in Ihrer Organisation gesucht (oder erstellt) werden sollen, und Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Datensicherheit im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/trusted-data-security) Anti-Muster.

	Muster	Anti-Muster
Freigabe und Sichtbarkeit	In Ihren Designstandards und in Ihrer Dokumentation: - Eine Sicherheitsmatrix umreißt die Daten, auf die jede Benutzerpersona zugreifen kann - Für externe und interne Benutzer werden unterschiedliche Datenzugriffsstandards verwendet, sofern zutreffend	In Ihren Designstandards und in Ihrer Dokumentation: - Designstandards und Dokumentation sind nicht vorhanden oder enthalten keine Sicherheitsmatrix - Wenn eine Sicherheitsmatrix vorhanden ist, wird der Datenzugriff für Benutzer-Personas nicht umrissen
	In Ihrer Organisation: - Organisationsweite Standardeinstellungen für interne Benutzer sind "Öffentlich gelesen" oder "OWDs" für interne Benutzer ist aufgrund von Compliance-Anforderungen "Privat". - OWDs für externe Benutzer ist "Privat" - Generative AI funktioniert nur im Benutzermodus oder ausgewählte Verwendungen für den Systemzugriff haben eine klare geschäftliche Begründung	In Ihrer Organisation: - OWDs für interne Benutzer wird ohne geschäftliche Begründung auf "Privat" oder OWDs für interne Benutzer auf "Öffentlicher Lese-/Schreibzugriff" festgelegt - OWDs für externe Benutzer sind ohne geschäftliche Begründung auf alles andere als "Privat" festgelegt - Generative AI arbeitet im Systemmodus ohne geschäftliche Begründung
	In Apex: - Alle Code-Zugriffsdaten (SOQL/SOSL) oder Datenvorgänge (DML/Datenbankklassen-Methoden) werden `mit Freigabestichwörtern` verwendet	In Apex: - `bei Freigabe` werden Stichwörter inkonsistent verwendet
Verwendung der Verschlüsselung	In Ihren Designstandards und in Ihrer Dokumentation: - Anwendungsfälle für die Datenverschlüsselung im Transit und (bei Bedarf) im Leerlauf sind übersichtlich und auffindbar - Genehmigte Verschlüsselungsprotokolle sind klar aufgeführt - In der Codedokumentation wird eindeutig angegeben, wo die Verschlüsselung verwendet wird und welche Protokolle verwendet werden	In Ihren Designstandards und in Ihrer Dokumentation: - Genehmigte Verschlüsselungsprotokolle sind nicht eindeutig oder nicht aufgeführt - Code wird nicht dokumentiert oder die Dokumentation ist unklar, wo und wie die Verschlüsselung im Code verwendet wird
	In Ihrer Organisation: - Wenn Sicherheitsrisiken identifiziert werden, die einen höheren Datenschutz im Leerlauf erfordern, bieten Hyperforce oder Salesforce Shield Verschlüsselung im Leerlauf	In Ihrer Organisation: - Geschäftsanforderungen erfordern mehr Datenschutz im Leerlauf, aber weder Hyperforce noch Salesforce Shield werden verwendet
	In Apex: - Wenn geschäftliche Anforderungen einen höheren Datenschutz bei der Übertragung erfordern, führt der gesamte an der Integration beteiligte Code eine Logik mit Kryptoklassen-Methoden aus, um Daten vor der Übertragung zu verschlüsseln oder nach Erhalt zu entschlüsseln.	In Apex: - Geschäftsanforderungen erfordern mehr Datenschutz bei der Übertragung, aber Code, der an der Integration beteiligt ist, führt Logik aus, ohne Daten vor der Übertragung oder beim Empfang zu verschlüsseln, oder es werden ad hoc Kryptoklassen-Methoden verwendet.

## Für die Sicherheit relevante Tools

Tool	Beschreibung	Organisationssicherheit	Sitzungssicherheit	Datensicherheit
Apex Krypto-Klasse	Verschlüsseln und Entschlüsseln von Daten in Apex			X
API-Zugriffssteuerung	Verwalten des Zugriffs auf Ihre Salesforce-APIs und verbundenen Anwendungen	X	X	X
API-Anomalieereignis	Verfolgen von Anomalien bei API-Aufrufen durch Benutzer		X
Browsersicherheitseinstellungen	Schützen vertraulicher Daten und Überwachen von SSL-Zertifikaten		X
Zertifikatbasierte Authentifizierung	Authentifizieren von Einzelpersonen mit eindeutigen digitalen Zertifikaten	X	X
Zertifikate und Schlüssel	Überprüfen von Anforderungen an externe Websites über Salesforce		X	X
Code-Scanner	Überprüfen von Apex Code auf Sicherheitslücken		X	X
Verbundene Anwendungen	Integrieren über APIs und Standardprotokolle	X	X
Ereignis zum Füllen von Anmeldeinformationen	Verfolgen versuchter Anmeldungen, die gestohlene Benutzeranmeldeinformationen verwenden		X
Vertrauenswürdige Site gemäß CSP	Verhindern von Code-Injection-Angriffen (d. h. Cross-Site-Scripting)		X
Benutzerdefinierte Anmelde-Flows	Steuern von Anmeldegeschäftsprozessen für Benutzer	X
Kundenidentität	Steuern von Website- und Anwendungsanmeldungen und -überprüfung	X
Data Mask	Automatisches Maskieren vertraulicher Daten in Sandbox-Instanzen			X
Debug-Protokolle	Verfolgen der in Ihrer Organisation auftretenden Ereignisse		X
Delegierte Verwaltung	Zuweisen eingeschränkter Administratorberechtigungen zu Nicht-Administratorbenutzern	X		X
Geräteaktivierung	Überprüfen von Anmeldungen über nicht vertrauenswürdige Browser, Geräte oder IP-Bereiche		X
Erhöhte Transaktionssicherheit	Ereignisse abfangen, Benutzeraktivität überwachen und steuern		X
Feldzugriff	Steuern des Datenzugriffs auf Feldebene			X
Feld-Aktivierungsprotokoll	Definieren einer Richtlinie zum Beibehalten archivierter Feldverlaufsdaten			X
Feldverlaufsverfolgung	Verfolgen und Anzeigen des Feldverlaufs			X
Frontdoor.jsp	Zugriff mit vorhandener Sitzungs-ID und Server-URL zulassen		X
Heroku Connect	Bidirektionale Synchronisierung zwischen Heroku und Salesforce			X
Heroku Shield	Erstellen von HIPAA- oder PCI-kompatiblen Anwendungen			X
Sitzungssicherheit mit hoher Sicherung	Zusätzliche Sicherheit für sensible Vorgänge erforderlich		X
Identity Connect	Zuordnen von Benutzerdatensätzen zu Active Directory-Accounts	X
Verlauf der Identitätsüberprüfung	Überprüfen der Identitätsüberprüfung von Benutzern	X
Integrationsbenutzerlizenz	Gewähren Sie Zugriff auf Daten und Funktionen nur über die API.	X		X
Lightning Login	Verhindern schwacher oder vergessener Kennwörter und gesperrter Accounts	X
Anmeldezugriff	Zulassen, dass sich Supportbenutzer als ein anderer Benutzer anmelden	X
Anmeldeforensik	Identifizieren von Verhaltensweisen, die auf Identitätsbetrug hinweisen können		X
Anmeldeverlauf	Überwachen von Anmeldeversuchen für Organisationen und Experience Cloud-Sites	X
Mobilgeräteverfolgung	Verfolgen und Überwachen des Mobilgerätezugriffs auf Ihre Organisation		X
Mobile SDK	Herstellen einer Verbindung mit Salesforce Platform in eigenständigen mobilen Anwendungen	X	X	X
Überwachen von Benutzerberechtigungen (Shield)	Änderungen an Berechtigungssätzen und Berechtigungssatzgruppen	X		X
Multi-Faktor-Authentifizierung	Zwei oder mehr Überprüfungsmethoden für die Anmeldung erforderlich	X	X
Gegenseitige Authentifizierung	Gegenseitige SSL- oder TLS-Authentifizierung erzwingen
Meine Domäne	Konfigurieren von Anmeldeseiten und -richtlinien, SSO und Anmeldungen bei sozialen Netzwerken	X
Anmeldeinformationen mit Namen	Angeben von Endpunkt-URLs und Authentifizierungsparametern		X
OAuth-Autorisierung	Autorisieren des Client-Anwendungszugriffs über Tokenaustausch	X
Kennwortrichtlinien	Festlegen von Kennwortverlauf, Länge und Komplexität	X
Abläufe der Berechtigungssatzzuweisung	Festlegen von Ablaufzeiten für Berechtigungssatz- und Berechtigungssatzgruppen-Zuweisungen	X		X
Berechtigungssatzereignis	Überwachen von Änderungen an Berechtigungssätzen und Berechtigungssatzgruppen	X		X
Berechtigungssatzgruppen	Bündeln von Berechtigungssätzen zur Unterstützung komplexer Zugriffsanforderungen	X
Berechtigungssätze	Steuern, wie Benutzer auf Metadaten, Funktionen und Anwendungen zugreifen	X
Private Connect	Sichere Integrationen zwischen Salesforce und Amazon Web Services			X
Profile	Steuern von IP-Bereichen und Anmeldezeiten für die Anmeldung	X
Echtzeit-Ereignisüberwachung	Überwachen und Erkennen von Standardereignissen in Salesforce		X
Einstellungen für Remote-Sites	Registrieren externer Sites für Apex- oder JavaScript-Aufrufe		X
Berichtsanomalieereignis	Verfolgen von Anomalien bei der Ausführung oder dem Export von Berichten durch Benutzer		X
Einschränkungsregeln	Verhindern, dass Benutzer auf unnötige Datensätze zugreifen			X
Salesforce-Codeanalyse	Scannen von Code über IDE, CLI oder CI/CD, um sicherzustellen, dass er den bewährten Vorgehensweisen entspricht		X	X
Begrenzungsregeln	Steuern der Standarddatensätze, die Ihren Benutzern angezeigt werden können			X
Sicherheitscenter	Anzeigen von Sicherheitseinstellungen in allen Ihren Organisationen und Konfigurieren von Benachrichtigungen bei Haltungsänderungen	X		X
Sicherheitsintegritätsprüfung	Identifizieren von Schwachstellen in Ihren Sicherheitseinstellungen			X
Sitzungs-Hijacking-Ereignis	Identifizieren von nicht autorisiertem Zugriff über gestohlene Sitzungskennzeichner		X
Sitzungsverwaltungsklasse	Anpassen der Sicherheitseinstellungen für eine aktive Sitzung		X
Sitzungssicherheitseinstellungen	Konfigurieren von Sitzungen zum Schutz vor bösartigen Angriffen		X
Setup-Aktivierungsprotokoll	Verfolgen der zuletzt von Administratoren vorgenommenen Setup-Änderungen			X
Freigabeeinstellungen	Steuern des Datenzugriffs auf Datensatzebene			X
Shield Platform Encryption	Verschlüsseln vertraulicher Daten im Leerlauf und während der Übertragung			X
Single Sign-On	Bereitstellen von Zugriff auf mehrere Anwendungen über eine einzige Anmeldung	X	X
System für Cross-Domain Identity Management (SCIM)	Systemübergreifendes Verwalten von Identitäten über REST-APIs		X
Bedrohungserkennung	Verwenden von Statistiken und maschinellem Lernen zum Erkennen von Bedrohungen		X
Vertrauenswürdige IP-Bereiche	Definieren von IP-Adressen, für die keine zusätzliche Überprüfung erforderlich ist		X
Bericht über Benutzerzugriff	Erhalten einer einheitlichen Ansicht des Objekt-, Datensatz- und Berechtigungszugriffs Ihrer Benutzer	X		X

## Für die Sicherheit relevante Ressourcen

Ressource	Beschreibung	Organisationssicherheit	Sitzungssicherheit	Datensicherheit
Ein Leitfaden zur Freigabearchitektur	Weitere Informationen zu Zugriffstools, Freigabemodellen und Anwendungsfällen			X
Vorlage 'Designstandards'	Erstellen von Designstandards für Ihre Organisation	X	X	X
Erstellen eines Benutzersicherheitsmodells	Besseres Verständnis der Benutzersicherheitsmodelle	X		X
Implementieren des Prinzips der geringsten Berechtigung in Salesforce	Anwenden von PoLP-Datenzugriffssteuerungen in Salesforce	X		X
Benutzersitzungen überwachen	Aktive Sitzungen überprüfen und verdächtige Sitzungen beenden		X
Multi-Faktor-Authentifizierung	Zugreifen auf offizielle MFA-Ressourcen über Salesforce	X
Berechtigungssatzgruppen (Trailhead)	Praktische Nutzung von Berechtigungssatzgruppen	X		X
REST-API-Architektur	Grundlegendes zu REST-API-Begriffen und -Konzepten	X	X	X
Sicherheit und SOAP-API	Grundlegendes zu SOAP-API-Begriffen und -Konzepten	X	X	X
Bewährte Vorgehensweisen zur Sicherheit für API- und interne Systembenutzer	Sicherer Zugriff auf Salesforce durch API-Benutzer und sichere Benutzer des internen Systems	X
Security Implementation Guide (Sicherheitsimplementierungshandbuch)	Umfassender Blick auf Salesforce Security	X	X	X
Sicherheitsrichtlinienvorlage	Festlegen von Sicherheitsrichtlinien für Ihre Organisation	X	X	X
Sitzungstypen	Identifizieren der Sitzungstypen für den Zugriff auf Ihre Organisation		X
Grundlagen der Bedrohungsmodellierung (Trailhead)	Erfahren Sie mehr über Sicherheitsbedrohungen und wie Sie sie verhindern können.		X

Diagram showing Salesforce Well-Architected core capabilities are Trusted, Easy, Adaptable

Das Salesforce Well-Architected Framework zeigt Ihnen, wie die Gesundheit aussieht und wo Sie Ihre Zeit mit der Roadmap-Erstellung und dem Entwerfen von Lösungen mit Salesforce Customer 360 Platform verbringen können. Auf der Grundlage von Knowledge von Produktteams und Implementierungsexperten in Salesforce und in unserem Ökosystem werden präskriptive Anleitungen und Beispiele für Muster und Anti-Muster bereitgestellt, nach denen in Ihrer Landschaft gesucht werden muss. Salesforce Well-Architected ist so organisiert, dass Sie vertrauenswürdige, einfache und anpassungsfähige Lösungen entwickeln können. **Vertrauenswürdige** Lösungen schützen Beteiligte.
**Einfache** Lösungen bieten schnell Mehrwert.
**Anpassbare** Lösungen entwickeln sich mit dem Unternehmen weiter.
Salesforce Well-Architected wurde entwickelt, um Sie bei der Entwicklung gesunder Lösungen auf Customer 360 Platform zu unterstützen. Eine einzigartige Herausforderung für Architekten, die Lösungen mit Salesforce erstellen, ist die grundlegende Flexibilität der Plattform. Eine Lösung könnte eine vordefinierte Lösung erweitern, die von Salesforce angeboten wird (d. h. Sales Cloud, Service Cloud, verschiedene Branchen-Cloud-Vertikale). Eine andere Lösung könnte eine vollständig benutzerdefinierte Anwendung sein. Was Sie mit Salesforce tun können, ist breit und tiefgreifend. Welche Technologieoptionen für Ihre Implementierung am besten geeignet sind, hängt von den Geschäftsanforderungen ab. Es kann enorm schwierig sein zu wissen, was die beste Chance auf langfristige Gesundheit für jede mögliche Salesforce-Lösung schafft. Salesforce Well-Architected bietet Ihnen bei Bedarf Statistiken und Anleitungen von erfahrenen Architekten. Sie können die Meinungen und Empfehlungen verwenden, um Ihr Denken zu validieren (oder herauszufordern) und Einblicke in die für Sie möglicherweise neuen Überlegungen oder Technologien zu erhalten. Es kann auch schwierig sein, zu verstehen, ob es architektonische Benchmarks gibt, die allen gesunden Lösungen gemeinsam sind, da die Implementierungen sehr unterschiedlich sind. Bei Salesforce orientieren wir uns bei allem, was wir als Unternehmen und als Mitarbeiter tun, an unseren Grundwerten. Wir glauben, dass dies auch für die Architektur gelten kann. Daher basiert Salesforce Well-Architected auf einem Kern von Trusted, Easy und Adaptable. Während Sie komplexe architektonische Details und Kompromisse auswerten, können Sie zu diesen Kernfunktionen zurückkehren und sie als Kompasspunkte für Ihre Entscheidungsfindung verwenden. Im Folgenden finden Sie Details zu einzelnen Themen, die Sie in unserem vertrauenswürdigen, einfachen und anpassbaren Framework erkunden können. ## Anordnen von Themen Es werden zwei Ebenen verwendet, um Informationen in Salesforce Well-Architected zu organisieren. Die oberste Ebene ist, was gut konzipierte Lösungen sein sollten: Vertrauenswürdig, einfach und anpassbar. In der zweiten Ebene werden Überlegungen, zu erstellende Muster (oder zu vermeidende Anti-Patterns) und präskriptive Anleitungen zu bestimmten Aspekten von vertrauenswürdigen, einfachen und anpassbaren Lösungen ausführlicher erläutert. Wenn Sie Ihre Designs auf die in diesem Framework bereitgestellten Anleitungen abstimmen, sollten Sie die Qualität Ihrer Salesforce Customer 360-Anwendungen verbessern und für eine längere Lebensdauer sorgen. 💡 Möchten Sie schnell mit Mustern und Anti-Mustern beginnen? Besuchen Sie den [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/patterns) Antimuster. Im Folgenden finden Sie eine Übersicht über die Themenanordnung:

Vertrauenswürdig
Eine vertrauenswürdige Lösung schützt Ihr Unternehmen und Ihre Beteiligten.
Sicher	Konform	Zuverlässig
Organisationssicherheit Sitzungssicherheit Datensicherheit	Rechtliche Einhaltung Ethische Standards Barrierefreiheit	Verfügbarkeit Leistung Skalierbarkeit
Einfach
Eine einfache Lösung bietet schnell einen Geschäftswert.
Absichtlich	Automatisiert	Interagieren
Strategie Wartungsfähigkeit Lesbarkeit	Effizienz Datenintegrität	Streamlined Hilfreich
Anpassbar
Eine anpassungsfähige Lösung entwickelt sich mit Ihrem Unternehmen.
Elastisch		Composable
Anwendungslebenszyklus-Verwaltung Vorfallsreaktion Kontinuitätsplanung		Trennung von Bedenken Interoperabilität Paketierbarkeit

> Lesen Sie [hier](/docs/architect/de-de/well-architected/guide/contributors) unsere Aktualisierungspläne. ## Einführung Eine Salesforce-Lösung, die **vertrauenswürdig** ist, schützt Unternehmen und Beteiligte. Eine Lösung, die für **Trusted** konzipiert ist, ist sicher, konform und zuverlässig. **Sichere** Lösungen steuern den Zugriff und schützen Daten.
**Konforme** Lösungen folgen den gesetzlichen und ethischen Richtlinien.
**Zuverlässige** Lösungen arbeiten effizient und zuverlässig.
Die Erstellung einer **vertrauenswürdigen** Lösung erfordert eine sorgfältige Planung. Sie müssen den Kontext des Unternehmens und/oder der Branche verstehen, für die Ihre Lösung zuständig ist. Wie hoch ist die Gesamtrisikotoleranz des Unternehmens? Welche Art von Daten werden in das System verschoben und aus ihm entfernt? Wird Salesforce als Datensatz- oder Speicherort für Daten mit speziellen Sicherheits-, Compliance- oder ethischen Überlegungen dienen? Welche Vorschriften und Compliance-Standards gelten? Gibt es zusätzliche, unternehmensspezifische Standards? Ist Salesforce ein geschäftskritisches System? Gibt es saisonale oder bedingte Spitzen bei der Datenverkehrs- oder Systemnutzung, die Sie berücksichtigen müssen? Wenn Sie zu einer **vertrauenswürdigen** Lösung gelangen möchten, müssen Sie mit Beteiligten im gesamten Unternehmen zusammenarbeiten. Sie müssen einen klaren Überblick über die Benutzer- und Systemtypen haben, die Zugriff auf Ihre Lösung benötigen, sowie über die Daten und Berechtigungen, die für die Erledigung der Arbeit erforderlich sind. Sie müssen die gesetzlichen und branchenspezifischen Anforderungen sowie die internen Richtlinien und Standards verstehen. Sie müssen mit Entwicklungs- und Wartungsteams zusammenarbeiten, um sicherzustellen, dass die Funktionen zugänglich sind und den Benutzern in gleicher Weise zur Verfügung stehen. Sie müssen die Lösungsverfügbarkeit und -leistung selbst in Zeiten von Unterbrechungen oder schnellem Wachstum planen. Nichts ist für eine gut strukturierte Lösung wichtiger als **Vertrauen**. In den folgenden Abschnitten finden Sie eine ausführlichere Anleitung zu den Kernüberlegungen einer Architektur **vertrauenswürdiger** Lösungen. ## Vertrauenswürdige Übersicht

Sicher
Ein sicheres System schützt Unternehmen, Beteiligte und Daten. Sichere Architekturen stellen sicher, dass nur genehmigte Benutzer Zugriff erhalten können, schränken den Benutzerzugriff auf das Wesentliche ein, um die Arbeit zu erledigen, und schützen Daten im System vor Kompromittierung.
Organisationssicherheit	Sitzungssicherheit	Datensicherheit
Authentifizierung Autorisierung	Sitzungsverwaltung Gerätezugriff Bedrohungserkennung und -reaktion	Freigabe und Sichtbarkeit Verwendung der Verschlüsselung
Konform
Konforme Lösungen folgen den gesetzlichen und ethischen Richtlinien. Konforme Architekturen halten sich an gesetzliche Vorschriften und Branchenstandards, halten ethische Richtlinien ein und dienen allen Benutzern gleichermaßen.
Rechtstreue	Ethische Standards	Barrierefreiheit
Datenschutz Lokalisierung	Unternehmensrichtlinien Künstliche Intelligenz	Dateneingabe Navigation
Zuverlässig
Zuverlässige Lösungen arbeiten unter verschiedenen Bedingungen effizient und zuverlässig. Zuverlässige Architekturen sind verfügbar, wann und wo Benutzer erwarten, konsistent arbeiten und mit dem Unternehmen skalieren.
Verfügbarkeit	Leistung	Skalierbarkeit
Risikomanagement Fehlerbehebung	Durchsatz Latenz	Datenmodellierung Datenvolumen

> Lesen Sie [hier](/docs/architect/de-de/well-architected/guide/contributors) unsere Aktualisierungspläne. ## Einführung Zuverlässige Lösungen arbeiten effektiv und zuverlässig. Sie sind verfügbar, leistungsfähig und skalierbar, um wachsende Unternehmen zu unterstützen. Ein zuverlässiges System ist nicht fehleranfällig, verhält sich erwartungsgemäß und liefert zeitnah Ergebnisse. Umgekehrt ist ein unzuverlässiges System langsam, verhält sich nicht wie erwartet oder schlägt in kritischen Zeiten fehl. Unzuverlässige Systeme liefern ungenaue Informationen, sodass Beteiligte ihnen bei Geschäftsentscheidungen nicht Trust schenken können. Die Systemzuverlässigkeit ist nicht konstant. Ein heute zuverlässiges System kann unzuverlässig werden, wenn es nicht auf Wachstum ausgelegt ist. Ein unzuverlässiges System kann eine kostspielige Wartung, Refaktorisierung oder erneute Implementierung erfordern, wodurch Mittel aus strategischen Projekten abgeleitet werden. Verbessern Sie die Zuverlässigkeit Ihrer Salesforce-Lösungen, indem Sie sich auf drei Prinzipien konzentrieren: [Verfügbarkeit](/docs/architect/de-de/well-architected/guide/reliable#verfügbarkeit), [Leistung](/docs/architect/de-de/well-architected/guide/reliable#leistung) und [Skalierbarkeit](/docs/architect/de-de/well-architected/guide/reliable#skalierbarkeit). [Die Salesforce-Skalierbarkeitsproduktsuite](https://www.salesforce.com/platform/application-scaling-performance-testing/) bietet native Funktionen, mit denen Architekten zuverlässige Implementierungen operationalisieren können. ## Verfügbarkeit Die Verfügbarkeit ist ein Maß für den Prozentsatz der Betriebszeit Ihres Systems. Die Salesforce Platform bearbeitet die meisten Verfügbarkeitsprobleme auf [Infrastrukturebene](https://trust.salesforce.com/). Die Verfügbarkeit der Lösungen, die Sie auf der Plattform erstellen und die Ihre Kunden erleben, liegt jedoch in der gemeinsamen Verantwortung. Es ist wichtig zu verstehen, dass selbst bei [hoher Verfügbarkeit](https://trust.salesforce.com/en/#systemStatus) von Salesforce das Risiko einer Serviceunterbrechung nie null ist. Architekten müssen sich auf Salesforce-Serviceunterbrechungen wie geplante Wartungen oder unvorhergesehene Umstände vorbereiten. Überlegen Sie sich zusätzlich zu Serviceunterbrechungen, wie Sie eine hohe Leistung aufrechterhalten und mit dem Unternehmen wachsen können. Enge architektonische Auswahlmöglichkeiten können zu langfristigen Verfügbarkeitsproblemen führen. Überlegen Sie sich die Verfügbarkeit während der Designphase, _bevor_ Ihre Lösung erstellt wird. Je länger Sie die Planung auf Verfügbarkeit zurückstellen, desto höher sind die tatsächlichen Kosten für Verfügbarkeitsprobleme auf lange Sicht. Verwenden Sie den Salesforce Skalierungstest in Ihrer Testumgebung, um potenzielle Risiken zu minimieren. In dieser Umgebung können Sie vor der Bereitstellung von Code in der Produktion auf Produktionsebene testen. Architekten verwenden die Sprache des Unternehmens, um technische Bedenken für Beteiligte zu formulieren und Verfügbarkeitsarbeiten zu priorisieren.Verwenden Sie Salesforce Skalierungstest in Ihrer Testumgebung, um potenzielle Risiken zu minimieren. In dieser Umgebung können Sie auf Produktionsebene testen, bevor Sie Code in der Produktion bereitstellen. Sie können die höhere Verfügbarkeit Ihrer Salesforce-Lösungen durch [Risikomanagement](/docs/architect/de-de/well-architected/guide/reliable#risikomanagement) und [Fehlerbegrenzung](/docs/architect/de-de/well-architected/guide/reliable#fehlerbehebung) planen. ### Risikomanagement Das Verwalten von Risiken im Kontext der Salesforce-Architektur beinhaltet das Identifizieren potenzieller Gefahren für den Betrieb Ihres Systems, seine Benutzer, einschließlich Mitarbeiter, Partner und Kunden) und Ihre Geschäftsprozesse. Oftmals liegt der formale Prozess der Risikoanalyse in der Verantwortung der Projektmanager. Stellen Sie als Architekt sicher, dass die Risikoanalyse die Belange der Beteiligten aus Technik und Wirtschaft angemessen berücksichtigt. Es liegt auch in Ihrer Verantwortung, die geschäftskritischen Anwendungsfälle zu identifizieren, für die Sie basierend auf Ihren Produktionsspitzen-Hotspots skalieren müssen. Einige der größten Fallstricke im Risikomanagement liegen darin, dass man nicht genügend Zeit und Gedanken darauf verwendet. Teams überspringen häufig die Risikobewertung oder sie verknüpfen Lösungen für die [Sicherung und Wiederherstellung](/docs/architect/de-de/well-architected/guide/resilient#erstellen-von-sicherungs--und-wiederherstellungsfunktionen) – ein wichtiger Teil der Risikominderung für die Datenintegrität – mit einer umfassenden Risikobewertung und -minderung. Verwenden Sie zum Bewerten des Risikos für Ihre Salesforce-Lösungen die folgenden Methoden: - **Verwenden Sie ein Risikobewertungs-Framework**. Einige große Unternehmen verfügen möglicherweise bereits über relevante Risikomatrizen. Wenn dies Ihrer Fall ist, können Sie anhand dieser bestimmen, wie Gefahren klassifiziert werden, welche Arten von Informationen erfasst werden sollen, was Sie zur Behebung einrichten müssen und mehr. Wenn Sie noch nicht über ein Framework zur Risikobewertung verfügen, suchen Sie eines aus einer seriösen Quelle und verwenden Sie es. - **Bewerten Sie den Schweregrad und die Risikokategorien aus der Perspektive Ihrer Kunden.** Proactive Monitoring und das Skalierungscenter bieten konfigurierbare Benachrichtigungen und Dashboards. Sie evaluieren kontinuierlich Leistungs- und Skalierbarkeitsrisiken und reduzieren Ihre Abhängigkeit von manuellen Checklisten. Customer Trust und Kundenwahrnehmung sind der Schlüssel zu jedem Unternehmen. Was die geschäftlichen Auswirkungen angeht, überwiegen die Risiken für Probleme, die Kunden erreichen, in der Regel die Risiken für Probleme, die dies nicht tun. Kunden denken und nehmen Risiken möglicherweise nicht so wahr wie interne Teams. Wenn sich ein Kunde nicht bei seinem Account anmelden kann, ist ihm die Ursache des Problems wahrscheinlich egal. Sie kümmern sich am meisten um ihre eigene, unmittelbare Erfahrung. - **Priorisieren Sie Ihre Risiken**. Idealerweise ist jedes Risiko mit einem soliden Plan zur Eindämmung und Reaktion verknüpft. In Wirklichkeit gibt es Lücken, die Sie im Laufe der Zeit schließen müssen. Es ist wichtig, einen Ansatz zu wählen, bei dem Werte frühzeitig und wiederholt bereitgestellt werden. Sie und Ihre Zustellungs- und Wartungsteams können jeweils nur so viel Arbeit übernehmen. Bei Salesforce lautet der allgemeine Ausdruck "Wenn alles wichtig ist, ist nichts wichtig". Wir verwenden V2MOMs, um die Arbeit im gesamten Unternehmen, teamübergreifend und bis hin zu jedem Einzelnen zu priorisieren und abzustimmen. (Auf Trailhead [erfahren](https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom/msfw_oav2m_writing_a_v2mom) Sie mehr über V2MOMs.) Verwenden Sie Ihre Risikobewertungen, die Ihnen die Möglichkeit geben, mit Ihren Beteiligten zusammen an der Priorisierung und dem Engagement für die wichtigsten Risikomanagementarbeiten zu arbeiten. Verwenden Sie Skalierungstest – Testplanerstellung, um die zu priorisierenden Risiken zu identifizieren und diese Risiken mithilfe von Skalierungstests zu minimieren. Verwenden Sie Proactive Monitoring, um Risiken für die frühzeitige Verfügbarkeit zu erkennen. Sie zeigt Anomalien wie Spitzen bei API-Anforderungsobergrenzen, Fehler bei Zeilensperren oder gleichzeitige Apex-Fehler an und bietet handlungsrelevante Statistiken, bevor Probleme zu Serviceunterbrechungen eskalieren. Die Verfügbarkeitsmuster [und Anti-Muster](/docs/architect/de-de/well-architected/guide/reliable#verfügbarkeitsmuster-und-anti-muster) zeigen ein ordnungsgemäßes und schlechtes Risikomanagement innerhalb einer Salesforce-Lösung an. Verwenden Sie die Muster, um Ihre Entwürfe vor dem Erstellen zu validieren oder Refaktorisierungsbereiche in Ihrem System zu identifizieren. Weitere Informationen zu Salesforce-Tools zum Risikomanagement finden Sie unter [Salesforce Tools For Reliability](/docs/architect/de-de/well-architected/guide/reliable#salesforce-tools-für-zuverlässigkeit) (Salesforce-Tools für Zuverlässigkeit). ### Fehlerbehebung Ein Fehlerpunkt ist eine Schwachstelle, die ein System unzuverlässig macht. Bei einer guten Fehlerbegrenzung geht es nicht darum, jeden potenziellen Fehlerpunkt zu ermitteln. Stattdessen geht es darum, Fehlerpunkte schnell zu klassifizieren und zu priorisieren, damit Wartungs- und Supportteams effektiv reagieren können. Siehe [Vorfallsantwort](/docs/architect/de-de/well-architected/guide/resilient#vorfallsreaktion). Entwickeln besserer Strategien zur Fehlerbegrenzung: - **Klassifizieren Sie Auslöser für Fehlerpunkte in Bezug auf Mitarbeiter, Prozess und Technologie**. Genauso wie Sie Risiken in Bezug auf Mitarbeiter, Prozess und Technologie kategorisieren, wenden Sie dasselbe Denken auf die Auslösung von Fehlerpunkten mit hoher Priorität an. Mit diesem Ansatz können Sie potenzielle Fehlerauslöser identifizieren und Antworten darauf entwickeln und organisieren. Manchmal können Sie scheinbar abweichende Fehlerauslöser mit ähnlichen Ansätzen zur Abhilfe abmildern, je nachdem, wie die Auslöser klassifiziert sind.

Auslöserklassifizierung/-typ	Minderung
Personen	Police
Prozess	Playbooks, Continuity-Pläne
Technologie	Redundanz

- **Ermitteln Sie, wie grundlegende, mittelständische und ausgereifte Abhilfemaßnahmen aussehen**. Es wird einige Zeit dauern, bis Abhilfestrategien entwickelt sind. Definieren Sie die Abhilfemaßnahmen, damit Sie und Ihr Team nachvollziehen können, wo Sie sofort Kontrollen einrichten können und wie Sie Ihre Anstrengungen im Laufe der Zeit konzentrieren können. Halten Sie immer Ausschau nach Opportunities, um die Automatisierung in Ihren Abhilfemaßnahmen zu verwenden – so früh wie möglich. Um zu veranschaulichen, wie dieser Ansatz in der Praxis aussieht, zeigt dieses Beispiel einen menschenorientierten Auslöser und wie die richtlinienbasierte Abhilfe auf grundlegender, mittlerer und ausgereifter Ebene aussieht.

Trigger	Minderung	Einfach	Mittelstufe	Reife
Änderung des Benutzerzugriffs für einen neuen oder ausscheidenden Mitarbeiter	Service Level Agreement (SLA) und Anforderungen für die Bereitstellung oder Aufhebung der Bereitstellung von Benutzern	Stellen Sie Benutzer manuell gemäß SLAs für manuelle Änderungen bereit und heben Sie die Bereitstellung auf.	Verarbeiten Sie Benutzeränderungen über geplante Aufträge gemäß SLAs für geplante Änderungen.	Automatisieren Sie die Bereitstellung und die Aufhebung der Bereitstellung von Benutzern über eine SSO/IDM-Lösung.

Verwenden Sie neben der Verwendung von Architektur-Playbooks und der Kontinuitätsplanung auch Proactive Monitoring. Mit Proactive Monitoring können Sie Echtzeitbenachrichtigungen zu Fehlerauslösern wie Anmeldefehlern, CPU-Timeout-Ausnahmen oder gleichzeitigen API-Anforderungsfehlern einrichten. Dieser Ansatz zur Warnung erhöht die Fehlervermeidung, indem sichergestellt wird, dass sowohl technische als auch geschäftliche Beteiligte rechtzeitig informiert werden, um die Auswirkungen von Fehlern zu reduzieren. Die [Muster und Anti-Muster für die Verfügbarkeit](/docs/architect/de-de/well-architected/guide/reliable#verfügbarkeitsmuster-und-anti-muster) zeigen, wie eine ordnungsgemäße und schlechte Fehlerbehebung in einer Salesforce-Lösung aussieht. Verwenden Sie sie, um Ihre Designs vor dem Erstellen zu validieren oder um zu refaktorierende Stellen in Ihrem System zu identifizieren. Weitere Informationen zu Salesforce-Tools zur Fehlerbehebung finden Sie unter [Zuverlässige Tools](/docs/architect/de-de/well-architected/guide/reliable#salesforce-tools-für-zuverlässigkeit). ### Verfügbarkeitsmuster und Anti-Muster Diese Tabelle zeigt eine Auswahl an Mustern, die in Ihrer Organisation gesucht oder erstellt werden sollen, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster zur Verfügbarkeit im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/trusted-availability) Anti-Muster.

	Muster	Anti-Muster
Risikomanagement	In Ihrem Unternehmen: - Es wird ein etabliertes Framework zur Risikobewertung verwendet. - Risiken werden in Personen-, Prozess- und Technologiebereiche kategorisiert.	In Ihrem Unternehmen: - Das Risikobewertungs-Framework für Salesforce ist ad hoc. - Risiken werden nicht eindeutig identifiziert.
Risikomanagement	In Ihrer Dokumentation: - Der Risikoschweregrad wird kategorisiert und anhand der Kundenauswirkung bewertet. - Risikominderungs- und Reaktionspläne werden priorisiert.	In Ihrer Dokumentation: - Die Kundenperspektive wird bei der Bewertung des Risikoschweregrads oder der Kategorie nicht berücksichtigt. - Risikominderungs- und Reaktionspläne versuchen, jedes erdenkliche Risiko zu erfassen.
Fehlerbehebung	In Ihrer Organisation: - Fehlerpunktauslöser und ihre entsprechenden Abhilfepläne werden nach Personen, Prozess und Technologie kategorisiert. - Die Kontrollmechanismen zur Eindämmung werden sofort eingerichtet, reifen im Laufe der Zeit aus und integrieren die Automatisierung so früh wie möglich. - Um eine optimale Skalierbarkeit zu gewährleisten, werden umfassende Tests und Optimierungen abgeschlossen, bevor Änderungen in der Produktion veröffentlicht werden. - Vor geschäftskritischen Ereignissen werden Skalierungstests und -optimierungen gemäß SLAs durchgeführt.	In Ihrer Organisation: - Fehlerpunktauslöser werden nicht klassifiziert. Ansätze zur Eindämmung sind nicht vorhanden oder werden nur ad hoc verwendet. - Die Kontrollelemente zur Eindämmung werden nicht erneut aufgerufen oder verbessert. - Automatisierung wird nicht zur Abhilfe verwendet.
Überwachung und Beobachtbarkeit	In Ihrer Organisation: - Für Überprüfungen und Anomalieerkennung ist Proactive Monitoring aktiviert. - Für die fortlaufende Sichtbarkeit sind Warnungen für Proactive Monitoring in das Skalierungscenter integriert.	In Ihrer Organisation: - Es werden nur manuelle Integritätsprüfungen durchgeführt und es gibt keine kontinuierliche Überwachung.

## Leistung Die Systemarchitekturleistung ist ein Maß dafür, wie viel ein System verarbeitet (Durchsatz) und wie schnell es antwortet (Latenz). Sie verstehen die Leistung Ihres Systems in der Regel durch Produktionstests und -überwachung. Ein leistungsfähiges System schließt Prozesse auf jeder erwarteten Anforderungsebene zeitnah ab. Eine schlechte Leistung geht mit einer höheren Latenz und einem geringeren Durchsatz einher, was zu einer geringeren Produktivität und einer höheren Frustration der Benutzer führt. Die Behebung von Leistungsproblemen ist dringend erforderlich, da sie zu einem Verlust des Customer Trust und finanziellen Verlusten führen können. Sie können die Leistung Ihrer Lösungen verbessern, indem Sie den Durchsatz und die Latenz optimieren. > Hinweis: Durchsatz- und Latenzoptimierung sind wesentliche Aspekte zur Verbesserung der Systemverarbeitung und Reaktionsfähigkeit. Beachten Sie jedoch, dass die Gesamtleistung des Systems auch davon abhängt, wie gut Sie für die [Skalierung](/docs/architect/de-de/well-architected/guide/reliable#skalierbarkeit) planen. Sie müssen beide Dimensionen in Ihren Entwürfen berücksichtigen. ### Durchsatz Im Kontext der Salesforce-Architektur ist der Durchsatz die Anzahl der gleichzeitigen Anforderungen, die ein System in einem bestimmten Zeitintervall abschließen kann. Die Salesforce-Lösungen von Kunden, die auf Durchsatz ausgelegt und optimiert sind, funktionieren innerhalb der integrierten [Obergrenzen](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) der Salesforce Platform besser. Die Optimierung des Durchsatzes in Salesforce beginnt mit der genauen Berechnung der Arbeitslasten in Ihrem System und der Planung ihres Wachstums. Ohne genaue Prognosen für die Anforderungen, die an das System gestellt werden, können Sie potenzielle Probleme mit den Durchsatzfunktionen Ihres Systems nicht identifizieren. Beachten Sie beim Nachdenken über Arbeitslasten die folgenden drei Dimensionen. - **Die Anzahl der Transaktionen**, die Ihr System in einem bestimmten Zeitraum verarbeiten muss - **Die Anzahl der Benutzer**, die gleichzeitig auf Ihr System zugreifen müssen - **Die Gesamtkomplexität der Transaktionslogik** im System Wenn Sie über die Leistung nachdenken, konzentrieren sich Teams manchmal zu sehr auf die Berechnung und die Einschränkungen der maximalen CPU-Zeit, die zu den Obergrenzen der Plattform gehören. Teams mit einem engen Fokus auf CPU-Zeit übersehen andere Methoden zur Optimierung des Durchsatzes. Wenn Sie Ihren Fokus erweitern und diese Methoden anwenden, verbessern Sie den Gesamtdurchsatz und die Effizienz Ihrer Salesforce-Architektur. Diese Verbesserungen werden wiederum dazu beitragen, die Latenz zu reduzieren und die Gesamtleistung des Systems zu steigern. ApexGuru erkennt proaktiv durchsatzbegrenzende Anti-Patterns wie SOQL in Schleifen, DML in Schleifen, ineffiziente GGD-Aufrufe und teure Methoden. Mithilfe dieser Statistiken können Teams die Risiken von Obergrenzen beseitigen, die den Durchsatz begrenzen. Optimieren des Durchsatzes in Ihrem System: - **Bevorzugte asynchrone Verarbeitung**. Die Salesforce Platform verwendet Transaktionskontexte, um die Datenintegrität zu steuern und Ausreißercode zu begrenzen. Entsprechende Informationen finden Sie [unter Architekturgrundlagen](/docs/architect/de-de/fundamentals/guide/architecture-basics#transaktionen) unter Architekturgrundlagen. Daher kann die Verwendung asynchroner (asynchroner) Verarbeitung nach Möglichkeit dazu beitragen, potenzielle Engpässe in synchronen Ausführungskontexten zu minimieren. Siehe [Datenverarbeitung](/docs/architect/de-de/well-architected/guide/automated#datenverarbeitung). Die Verwendung von asynchronen Berechnungen ist nicht für alle Arten von Leistungsproblemen geeignet und Sie müssen beim Integrieren asynchroner Prozesse die Latenz berücksichtigen. Bestimmte Plattformfunktionen wie warteschlangenfähiges Apex können die Latenz bei Datenverkehrsspitzen erhöhen, da sie dazu führen, dass Nachrichten in einer Warteschlange länger warten. Je nach Anwendungsfall können Sie eine potenzielle Verringerung der Reaktionsfähigkeit tolerieren, um den Durchsatz aufrechtzuerhalten oder zu verbessern. In anderen Fällen können Sie entscheiden, dass eine erhöhte Latenz nicht akzeptabel ist. Mit Skalierungstest können Sie diese Kompromisse validieren, indem Sie Datenverkehrsspitzen in einer Vollständigen Sandbox simulieren. Dort können Sie messen, wie sich die Aufträge auf den Durchsatz und die Latenz auswirken. - **Verwenden Sie immer Massenvorgänge**. Auf einer hohen Ebene bedeutet Massenverarbeitung, dass Vorgänge für Sammlungen ausgeführt werden. Oft konzentrieren sich Teams, die über die Massenverarbeitung für ihre Salesforce-Lösungen diskutieren, darauf, Datenvorgänge anhand von Sammlungen zu optimieren. Siehe [Betriebslogik](/docs/architect/de-de/well-architected/guide/automated#betriebslogik). Die Massenverarbeitung auf Systemebene umfasst jedoch mehr als nur Datenvorgänge. Ziehen Sie auch bestimmte Aufgaben wie Callouts oder komplexe Berechnungen als Kandidaten für die Massenverarbeitung in Betracht. Die richtige Massenverarbeitung reduziert den Overhead. Sie führt mehrere Vorgänge mit einer Anforderung statt einer Anforderung pro Vorgang aus. ApexGuru zeigt Anti-Bulkification-Muster wie [DML oder SOQL](https://help.salesforce.com/s/articleView?language=en_US&id=xcloud.apexguru_antipatterns.htm&type=5) an, die Sie vor der Skalierung in die Produktion korrigieren können. Siehe [Massenvorgänge](/docs/architect/de-de/fundamentals/guide/platform-multitenant-architecture#massenvorgänge). - **Verwenden Sie SOSL für Suchvorgänge und behandeln Sie SOQL wie einen Datenvorgang.** Es scheint offensichtlich, dass die Verwendung von zu komplexen SOQL-Anweisungen die Zeit, die das System zum Abrufen von Datensätzen benötigt, erhöht. SOQL fügt der [zugrunde liegenden relationalen Datenbank](/docs/architect/de-de/fundamentals/guide/platform-multitenant-architecture#die-plattformdatenebene) Overhead hinzu, was die Verarbeitung verlangsamt. Bei Verwendung von Text- oder Platzhalterkriterien ist SOSL leistungsfähiger. SOSL verwendet die Suchmaschine der Plattform, die für die Volltextindizierung und universelle Suchvorgänge optimiert ist. Stellen Sie zum Optimieren von Datensatzabrufmustern sicher, dass Ihre Designstandards angeben, wann SOSL zum Suchen von Daten in Ihrem System verwendet werden soll. Stellen Sie außerdem sicher, dass sie angeben, wie SOQL für effiziente Datenvorgänge verwendet werden soll. Siehe [Betriebslogik](/docs/architect/de-de/well-architected/guide/automated#betriebslogik)). - **Verwenden Sie Plattform-Cache und ApexGuru**. Die [Lightning Platform-Cache](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cache_namespace_overview.htm)-Ebene bietet eine schnellere Leistung und mehr Zuverlässigkeit beim Zwischenspeichern von Salesforce-Sitzungs- und -Organisationsdaten. Der Plattform-Cache verbessert die Leistung, indem der Cache-Speicherplatz so verteilt wird, dass einige Anwendungen oder Vorgänge anderen keine Kapazität stehlen. ApexGuru erkennt verpasste Opportunities zum Zwischenspeichern wiederholter Abfragen (z. B. [Plattform-Cache für SOQL-Ergebnisse](https://help.salesforce.com/s/articleView?id=xcloud.apexguru_antipattern_soql_without_platform_cache.htm&type=5)), was den Durchsatz in Umgebungen mit hohem Umfang verbessert. Die [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/reliable#leistungsmuster-und-anti-muster) für die Leistung zeigen, wie ein ordnungsgemäßer und schlechter Durchsatz in einer Salesforce-Organisation aussieht. Verwenden Sie sie, um Ihre Entwürfe vor dem Erstellen zu validieren oder Opportunities für die weitere Optimierung zu identifizieren. Weitere Informationen zu Salesforce-Tools für die Durchsatzoptimierung finden Sie unter [Salesforce-Tools für Zuverlässigkeit](/docs/architect/de-de/well-architected/guide/reliable#salesforce-tools-für-zuverlässigkeit). ### Latenz Die Latenz ist ein Maß dafür, wie schnell ein System einen Ausführungspfad abschließt. Die Optimierung des Durchsatzes Ihres Systems trägt zur Verbesserung der Latenz bei. Eine weitere Dimension der Latenz ist die wahrgenommene Leistung oder die Reaktionsfähigkeit des Systems für Benutzer. Personen möchten nicht warten, bis Seiten geladen oder Prozesse abgeschlossen sind. Benutzer Ihres Systems sind frustriert, wenn sie häufig lange Ladezeiten haben, wenn sie versuchen, in Listenansichten, Datensatzseiten, Berichten usw. zu navigieren. In diesem Fall entscheiden sich Kunden oder Partner möglicherweise dafür, ihr Geschäft an einen anderen Ort zu verlagern, statt sich mit leistungsschwachen Systemen auseinanderzusetzen. Intern können Mitarbeiter Übergangslösungen erstellen, um zu vermeiden, dass das System wie geplant verwendet wird, was zu nachgelagerten Problemen hinsichtlich Sicherheit und Datenintegrität führen kann. Die wahrgenommene Leistung kann schwierig zu diagnostizieren sein. Wenn ein Benutzer eine langsame Leistung meldet, können Supportteams das Problem möglicherweise nicht reproduzieren. Eine erhöhte Latenz ist oft das Ergebnis einer Kombination kleinerer Probleme, die aufeinander aufbauen, was die genaue Diagnose der Ursache wahrgenommener Leistungsprobleme erschweren kann. Reduzieren der Latenz und Verbessern der Reaktionsfähigkeit in Ihrem Salesforce-System: - **Optimieren Sie Berichte**. Stellen Sie sicher, dass jeder Bericht einen einzelnen, spezifischen Zweck erfüllt. Geben Sie Zielgruppe und Zweck jedes Berichts in Ihrem System eindeutig an. Fügen Sie in Berichte nur die Mindestmenge an Daten ein, die Zielgruppenmitglieder benötigen, um Entscheidungen zu treffen. Wenn Sie Spalten entfernen, die nicht mit dem Zweck eines Berichts übereinstimmen, wird die Berichtsleistung verbessert, da weniger Daten abgerufen und angezeigt werden müssen. - **Optimieren Sie Filter**. Effektive Filter beschleunigen die Leistung von Berichten und Listenansichten, indem sie die Anzahl der Zeilen, die aus der Datenbank abgerufen werden, genau festlegen. In der Regel gilt: Je genauer Sie Ihre Filterlogik festlegen, desto effizienter ist die zugrunde liegende Abfrage für Daten. Zu den Möglichkeiten zum Optimieren von Filtern zählen: - Verwenden von "gleich" und "ungleich" anstelle von "enthält" und "enthält nicht" - Vermeiden der Filterung nach Formelfeldern - **Vereinfachen Sie Ihr Freigabemodell**. Ein zu komplexes Freigabemodell kann eine Vielzahl von Prozessen verlangsamen, da das System das Freigabe- und Sichtbarkeitsmodell überprüfen muss, um festzustellen, ob ein Benutzer Zugriff auf die anzuzeigenden oder zu verarbeitenden Daten hat. Komplexe Freigabeberechnungen können die Latenz bei Berichten, Listenansichten und Automatisierungen erhöhen, die im Kontext des Benutzers ausgeführt werden. Siehe [Freigabe und Sichtbarkeit](/docs/architect/de-de/well-architected/guide/secure#freigabe-und-sichtbarkeit). - **Optimieren Sie benutzerdefinierte Benutzeroberflächenkomponenten**. Benutzerdefinierte Benutzeroberflächenkomponenten können die Latenz erhöhen. Wenn Sie die Leistung in benutzerdefinierten Benutzeroberflächenkomponenten optimieren möchten, sollten Sie die folgenden Schritte in Erwägung ziehen. - **Verwenden Sie Lightning Web Components (LWC)**. Das LWC-Framework ist eng an moderne Webstandards angepasst. In LWC geschriebene benutzerdefinierte Komponenten werden in Webbrowsern effizienter dargestellt und ermöglichen es Entwicklern, leistungsfähigere JavaScript-Methoden zu verwenden. Verwenden Sie immer LWC anstelle von älteren Benutzeroberflächentechnologien wie Aura oder Visualforce. - **Verwenden Sie Lightning Data Service**. Der Lightning Data Service übernimmt die Erstellung und Pflege der sicheren, leistungsfähigen und freigegebenen Zwischenspeicherung zwischen Komponenten. Verwenden Sie sie, um unnötige Umwege zum Server für Daten zu vermeiden und die Reaktionsfähigkeit der Anwendung insgesamt zu erhöhen. - **Verwenden Sie die clientseitige Sortierung und Filterung für Listendaten.** Sowohl für LWC-Komponenten (bevorzugt) als auch für Aura-Komponenten (anderweitig) können Entwickler standardmäßige JavaScript-Array-Funktionen verwenden, um Werte auf Client-Seite zu sortieren, zu filtern und auszuwählen, wodurch die Anzahl der erforderlichen Fahrten zum Server reduziert wird. Die [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/reliable#leistungsmuster-und-anti-muster) zeigen, wie die richtige und schlechte Latenz in einer Salesforce-Organisation aussieht. Verwenden Sie sie, um Ihre Entwürfe vor dem Erstellen zu validieren oder Opportunities für die weitere Optimierung zu identifizieren. Weitere Informationen zu Salesforce-Tools zur Latenzoptimierung finden Sie unter [Salesforce Tools For Reliability](/docs/architect/de-de/well-architected/guide/reliable#salesforce-tools-für-zuverlässigkeit) (Salesforce-Tools für Zuverlässigkeit). ### Leistungsmuster und Anti-Muster Diese Tabelle zeigt eine Auswahl an Mustern, die in Ihrer Organisation gesucht oder erstellt werden sollen, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie mehr Muster für die Leistung im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/trusted-performance) Anti-Muster.

	Muster	Anti-Muster
Durchsatz	In Ihren Designstandards: - Anleitung für die Verwendung des Plattform-Cache entspricht den bewährten Vorgehensweisen für Plattform-Cache	In Ihren Designstandards: - Wenn es Richtlinien für die Nutzung des Plattform-Cache gibt, ist dies nicht eindeutig oder entspricht nicht den bewährten Vorgehensweisen.
Durchsatz	In Ihrer Organisation: - Bulkification wird für Daten- und Systemvorgänge verwendet. - DML- oder Datenbankmethoden funktionieren immer mit Sammlungen in Apex. - Die während der DML für kürzere elapsedTime in der Datenbank verwendeten Felder sind begrenzt. - Alle Platzhalterkriterien werden in SOSL verwendet. - SOQL-Anweisungen sind selektiv.: -- Sie verwenden keine LIKE-Vergleiche oder Teiltextvergleiche. -- Vergleichsoperatoren verwenden positive Logik (d. h. INCLUDES oder IN) als primäre Logik oder einzige Logik. -- = NULL und != NULL werden nur selten verwendet folgt immer einem positiven Vergleichsoperator. – Um die Datenlast zu minimieren und die Leistung zu maximieren, werden nur die in SOQL-Abfragen benötigten Felder abgerufen. -- Es werden keine LIMIT-1-Anweisungen verwendet. -- Das Stichwort ALL ROWS wird nicht verwendet. - Asynchrone Verarbeitung wird nach Möglichkeit bevorzugt. - Plattform-Cache-Partitionen sind konfiguriert.	In Ihrer Organisation: - DML-Anweisungen werden nicht per Massenvorgang ausgeführt. - DML- oder Datenbankmethoden funktionieren für einzelne Datensätze in Apex. - SOSL wird selten oder nicht konsequent für Platzhalterauswahlkriterien verwendet. - SOQL-Anweisungen sind nicht selektiv: -- Sie enthalten LIKE- und Platzhalterfilterkriterien. -- Vergleiche mit den Kriterien !=, NOT oder NOT IN werden als primärer oder einziger Vergleichsoperator verwendet. -- Verwendet die Kriterien = NULL und != NULL als primäre oder einzige Vergleichsoperatoren. -- Es werden LIMIT-1-Anweisungen verwendet. -- Das Stichwort ALL ROWS wird verwendet. - SOQL wird in Schleifen angezeigt. - Synchrone Prozesse werden bevorzugt.
Latenz	In Ihrer Organisation: - Berichte dienen einem einzelnen spezifischen Zweck und enthalten die Mindestanzahl an Zeilen und Spalten, die zum Treffen von Entscheidungen erforderlich sind. - Filter verwenden "gleich" und "nicht gleich". - Filter enthalten keine Formelfelder. - Freigabemodelle werden so weit wie möglich vereinfacht. - Benutzerdefinierte Benutzeroberflächenkomponenten verwenden Lightning Web Components (LWC). - LWC verwendet Lightning Data Service für Datenvorgänge. - Das Sortieren und Filtern von Listendaten wird clientseitig in JavaScript verarbeitet. - Salesforce Edge ist aktiviert.	In Ihrer Organisation: - Berichte dienen mehreren Zwecken oder enthalten zusätzliche Zeilen und Spalten, die für Entscheidungen nicht erforderlich sind. - Filter verwenden "enthält" und "enthält nicht". - Filter enthalten Formelfelder. - Freigabemodelle sind komplex. - Benutzerdefinierte Benutzeroberflächenkomponenten verwenden Frameworks, die zu einem weniger effizienten Rendering als LWC führen können (z.B. Aura oder Visualforce). - LWC verwendet Apex für Datenvorgänge. - Das Sortieren und Filtern von Listendaten erfolgt serverseitig über Apex. - Salesforce Edge ist nicht aktiviert.

## Skalierbarkeit Die Skalierbarkeit ist die Fähigkeit eines Systems, eine konsistente Leistung zu erbringen, während es sich weiterentwickelt und wächst. Ein skalierbares System verarbeitet große Steigerungen des Transaktionsvolumens oder gleichzeitigen Zugriffs ohne grundlegende Änderungen. Die Plattformservices von Salesforce wurden entwickelt, um die Skalierbarkeit von Anwendungen zu unterstützen. Siehe [Interne Plattformverarbeitung](/docs/architect/de-de/fundamentals/guide/platform-multitenant-architecture#interne-plattformverarbeitung). Wenn Ihre Organisation wächst und die Nachfrage nach Ihren Produkten und Services steigt, sind Sie dafür verantwortlich, ein System zu erstellen, das effektiv und erwartungsgemäß funktioniert. Die von Anfang an auf Skalierbarkeit ausgelegte Architektur führt zu einer schnelleren Bereitstellung neuer Funktionen und zu weniger Serviceunterbrechungen bei zunehmendem Benutzerverkehr. Verwenden Sie **Skalierungstest** zu Beginn der Designphase, bevor Sie neue Funktionen in der Produktion bereitstellen, um projizierte Arbeitslasten zu simulieren und zu validieren, dass die Architektur sie unterstützen kann. Systeme, die nicht auf Skalierbarkeit ausgelegt sind, erfordern ständige und kostspielige Fehlerbehebung, Neugestaltung und Refaktorierung. Bei der Skalierbarkeit kommt es im Laufe der Zeit zu Problemen, die die Leistung im gesamten System beeinträchtigen. In einigen Fällen müssen Unternehmen den Großteil der Entwicklungs- und Wartungsressourcen für die Lösung von Skalierbarkeitsproblemen aufwenden, statt für neue Funktionen, die einen Mehrwert schaffen. Manchmal erreicht ein Unternehmen einen kritischen Kipppunkt. Das ursprüngliche Design des Systems kann das Wachstum des Unternehmens nicht unterstützen und unerwartete Ereignisse machen das System instabil. Verwenden Sie Statistiken aus **dem Skalierungscenter**, um Kipppunkte für die Skalierbarkeit frühzeitig zu erkennen. Das Skalierungscenter zeigt Ausnahme-Hotspots, langfristige Transaktionen und Warteschlangenengpässe, die sich im Laufe der Zeit verschlimmern. Sie können die Skalierung besser planen, indem Sie sich auf die Datenmodelloptimierung und die Verwaltung des Datenvolumens konzentrieren. _Hinweis: Auch wenn hier nicht darauf eingegangen wird, ist das Testen auf Skalierbarkeit ein wichtiger Teil der Validierung Ihrer Anwendungsarchitekturen. Eine Anleitung finden Sie unter [Teststrategie](/docs/architect/de-de/well-architected/guide/resilient#teststrategie)._ ### Datenmodellierung Bei der Datenmodellierung werden die Objekte in Ihrer Organisation strukturiert und so miteinander verknüpft, dass Ihre Benutzer und automatisierten Prozesse die benötigten Daten schnellstmöglich abrufen können. Wenn Sie Schritte zur [Verbesserung des Durchsatzes](/docs/architect/de-de/well-architected/guide/reliable#durchsatz) unternehmen, werden viele Leistungsprobleme behoben. Ohne ein optimiertes Datenmodell sind Ihre Bemühungen jedoch nicht so effektiv. Die negativen Auswirkungen eines schlecht konzipierten Datenmodells sind nicht sofort spürbar. Seine Schwächen werden mit zunehmendem Datenvolumen, Prozessen, Benutzern und Integrationen deutlich. Ein gut durchdachtes Datenmodell erleichtert die kontinuierliche Refaktorierung Ihrer Anwendung, wenn Anforderungen hinzugefügt und erweitert werden. **ApexGuru** zeigt Anti-Patterns für den Datenzugriff wie nicht selektive SOQL, nicht verwendete Felder und Schemaineffizienzen, die sich direkt auf die Skalierbarkeit des Datenmodells auswirken. Optimieren Ihres Datenmodells: - **Verwenden Sie die vordefinierten Datenmodelle von Salesforce**. Salesforce bietet vorgefertigte Datenmodelle für den Vertrieb, Service und eine Vielzahl von Branchenbereichen. Durch die Verwendung der von Salesforce bereitgestellten Datenmodelle wird sichergestellt, dass Funktionen in Ihrem System nur einmal definiert werden, wodurch Redundanz und Silos beseitigt werden und eine einzige Datenquelle im gesamten System entsteht. Da Sie für diese einzelne Quelle vordefinierte Salesforce-Datenmodelle verwendet haben, ist es einfacher, Anwendungsdaten mit Analysen zu verstehen und die vordefinierten Services für künstliche Intelligenz von Salesforce zu verwenden. Wenn Sie zudem die Anpassungen reduzieren, die Sie unterstützen müssen, werden die Wartungskosten gesenkt und die technischen Schulden reduziert. - **Wählen Sie die richtigen Datentypen** aus. Machen Sie sich mit den verschiedenen von Salesforce unterstützten Feldtypen und ihren Einschränkungen vertraut. Berücksichtigen Sie Berichterstellungs- und Verschlüsselungsanforderungen, damit Sie künftig keine Daten mehr zwischen Typen konvertieren müssen. - **Wählen Sie die richtigen Beziehungen** aus. Salesforce unterstützt zwei Arten von Beziehungen zwischen Objekten: Master-Detail und Nachschlagevorgang. Master-Detail-Beziehungen bieten zwei primäre Vorteile. Eine davon sind integrierte Rollup-Zusammenfassungsfunktionen, die Details aus untergeordneten Datensätzen zählen und aggregieren. Bei der anderen handelt es sich um eine integrierte Kaskadenlöschfunktion, durch die beim Löschen eines übergeordneten Datensatzes auch dessen untergeordnete Datensätze gelöscht werden. Stellen Sie jedoch sicher, dass Sie sich mit den [Auswirkungen](/docs/architect/de-de/well-architected/guide/reliable#datenvolumen) von Master-Detail-Beziehungen vertraut machen, bevor Sie sie verwenden. - **Denormalisieren Sie die Skalierung.** Bei der Normalisierung handelt es sich um den Prozess der Strukturierung Ihres Datenmodells für eine reduzierte Datenredundanz und eine verbesserte Datenintegrität. Leider führt die Normalisierung manchmal zu Skalierungsproblemen. Denormalisierte Tabellen können skalierbar besser abschneiden. Denken Sie jedoch an Datenintegrität und Redundanz. Die [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/reliable#skalierbarkeitsmuster-und-anti-muster) zeigen, wie eine ordnungsgemäße und schlechte Datenmodelloptimierung in einer Salesforce-Organisation aussieht. Verwenden Sie sie, um Ihre Entwürfe vor dem Erstellen zu validieren oder Opportunities für die weitere Optimierung zu identifizieren. Weitere Informationen zu Salesforce-Tools für die Datenmodelloptimierung finden Sie unter [Salesforce-Tools für Zuverlässigkeit](/docs/architect/de-de/well-architected/guide/reliable#salesforce-tools-für-zuverlässigkeit). ### Datenvolumen Das Datenvolumen ist ein Maß für die Menge der in Ihrem System gespeicherten Daten, basierend auf Datensatzzahlen und -größen. Wenn Ihre Organisation über Zehntausende Benutzer, Zehnmillionen Datensätze oder Hunderte Gigabyte Gesamtdatensatzspeicher verfügt, verfügen Sie über ein großes Datenvolumen. Das Datenvolumen und die Beziehungen zwischen Objekten in Ihrer Organisation wirken sich auf die Skalierbarkeit aus und haben wahrscheinlich größere Auswirkungen auf die Skalierbarkeit als die Anzahl der Datensätze allein. Verbessern der Skalierbarkeit von Organisationen mit großen Datenvolumen: - **Verteilen Sie untergeordnete Datensätze**. Vermeiden Sie Datenverzerrungen zwischen übergeordneten und untergeordneten Elementen, indem Sie sicherstellen, dass kein übergeordnetes Element über eine große Anzahl untergeordneter Datensätze verfügt. Die allgemeine Empfehlung lautet, dass kein übergeordnetes Element über mehr als 10.000 untergeordnete Datensätze verfügen sollte. Bei einer Bereitstellung mit vielen Kontakten, die jedoch keine Accounts verwendet, sollten Sie beispielsweise mehrere Accountdatensätze einrichten und die zugehörigen Kontaktdatensätze darauf verteilen. - **Verteilen Sie die Inhaberschaft von Datensätzen**. Vermeiden Sie Inhaberschaftsverzerrungen, indem Sie sicherstellen, dass kein einzelner Benutzer oder keine einzelne Warteschlange Inhaber von mehr als 10.000 Datensätzen aus demselben Objekt ist oder dass alle Mitglieder einer einzelnen Rolle oder öffentlichen Gruppe Inhaber sind. "Parken" von Daten mit einem "Dummy-Benutzer" ist eine Praxis, die oft zu einer Verzerrung der Inhaberschaft führt. Beachten Sie bei diesem Problem die Auswirkungen, die es auf [Freigabeberechnungen](/docs/architect/de-de/well-architected/guide/reliable#latenz) haben wird. Wenn Sie Datensätze nicht neu verteilen können, um die Verzerrung der Inhaberschaft zu vermeiden, sollten Sie vermeiden, den Benutzer mit Dateninhaberschaft einer Rolle zuzuweisen. Wenn für das Freigabemodell Ihrer Organisation eine Rollenzuweisung erforderlich ist, platzieren Sie den Benutzer, der Inhaber der Daten ist, in einer anderen Rolle ganz oben in der Freigabehierarchie. Lassen Sie keine häufigen oder ungeplanten Änderungen an der Rolle dieses Benutzers zu, da Änderungen erhebliche Auswirkungen auf die Leistung aufgrund von Freigabeneuberechnungen haben. Halten Sie diesen Benutzer aus öffentlichen Gruppen heraus, auf die in Freigaberegeln verwiesen werden könnte. - **Reduzieren Sie die Datensatzdatenmenge in Salesforce.** Salesforce wurde entwickelt, um Unternehmen eine einzelne Ansicht ihrer Kunden zu bieten. Es kann widersprüchlich erscheinen, dass die Einschränkung von Daten in Salesforce eine bewährte Vorgehensweise ist. Die Leistung der einzelnen Ansicht liegt jedoch darin, wie gut Geschäftsbenutzer Kundendaten verstehen und entsprechende Maßnahmen ergreifen können. Wenn das Datenvolumen wächst, führen Daten, die nicht aktuell oder für tägliche Prozesse oder Analysen relevant sind, zu mehreren Problemen. Zu diesen Problemen zählen eine verschlechterte Anwendungsleistung, ein erhöhtes Datensicherheitsrisiko und negative Auswirkungen auf die Suche, Berichte und Analysen. Definieren Sie zum Vermeiden solcher Probleme einen Datenlebenszyklus für jedes Objekt in Ihrem Datenmodell mit Zeitachsen und Klassifizierungen für Daten, wenn sie altern und sofort an Geschäftswert verlieren. Implementieren Sie diese Verfahren entsprechend dem Datenlebenszyklus, um Daten im Laufe der Zeit zu verwalten. - **Datenarchivierung und -bereinigung**: Entfernen Sie Datensätze, die vom Unternehmen nicht benötigt werden, um das Datenvolumen so gering wie möglich zu halten. Verwenden Sie die Funktion zum endgültigen Löschen der Bulk-API 2.0, um große Datenmengen zu löschen. - **Datenaggregation:** Erstellen Sie benutzerdefinierte Aggregationsobjekte, die wichtige historische Trends oder Zusammenfassungsdaten in einem mit Berichten kompatiblen Format zusammenfassen. Füllen Sie die benutzerdefinierten Objekte mit [Batch-Apex](/docs/architect/de-de/well-architected/guide/reliable#durchsatz) aus. Benutzer können dann Berichte auf der Grundlage der aggregierten Objektdatensätze ausführen. - **Datenstufe**. Verwalten Sie große Datensets in einer anderen Anwendung, wenn sie für Salesforce-Berichte oder die tägliche Arbeit nicht benötigt werden. Stellen Sie die Daten nach Bedarf über Mashups, Callouts oder externe Objekte in Salesforce zur Verfügung. In der Praxis können Sie die Ursache eines Skalierbarkeitsproblems möglicherweise nicht immer sofort beheben, wenn Probleme auftreten. Aus diesem Grund bietet Salesforce Optionen, mit denen sofortige Probleme behoben werden können. Es ist wichtig zu wissen, dass das Aktivieren dieser Funktionen in Ihrer Organisation keine tragfähige, langfristige Architekturstrategie für den Umgang mit großen Datenmengen ist. Diese kurzfristigen Übergangslösungen können dazu beitragen, die Latenz in Systemen mit schlechter Datenarchitektur zu reduzieren, aber sie können Ihrer Organisation auch technische Schulden zufügen. Zu den kurzfristigen Übergangslösungen für Skalierungsprobleme zählen: - **Benutzerdefinierte Indizes** werden in einer speziellen internen Tabelle gespeichert, die von der Abfrageoptimierung der Plattform verwendet wird, um den Datenzugriff zu beschleunigen. Siehe [Mandantenindizes](/docs/architect/de-de/fundamentals/guide/platform-multitenant-architecture#indexes)). Die Plattform indiziert standardmäßig bestimmte Feldtypen automatisch. Wenn Sie Abfragen mit schlechter Leistung beschleunigen möchten, können Sie zusätzliche benutzerdefinierte Indizes anfordern, indem Sie sich an den Salesforce-Kundensupport wenden. Verwenden Sie das Abfrageplan-Tool, um festzustellen, ob benutzerdefinierte Indizes die Leistung Ihrer Abfragen verbessern. - **Dünne Tische**. Wenn Sie Abfragen für allgemeine Feldgruppen in Objekten mit mehr als 1 Million Datensätzen weiter optimieren müssen, können dünne Tabellen hilfreich sein. In dünnen Tabellen entfällt die [Verknüpfung im Hintergrund](https://developer.salesforce.com/docs/atlas.en-us.salesforce_large_data_volumes_bp.meta/salesforce_large_data_volumes_bp/ldv_deployments_infrastructure_skinny_tables.htm), die auftritt, wenn benutzerdefinierte und Standardfelder aus demselben Objekt in einem Bericht oder einer Automatisierung verwendet werden. Damit Sie dünne Tabellen verwenden können, muss der Salesforce-Kundensupport sie für Ihre Organisation aktivieren. Die [Muster und Anti-Muster](/docs/architect/de-de/well-architected/guide/reliable#skalierbarkeitsmuster-und-anti-muster) für die Skalierbarkeit zeigen, wie eine ordnungsgemäße und schlechte Verwaltung des Datenvolumens in einer Salesforce-Organisation aussieht. Verwenden Sie sie, um Ihre Entwürfe vor dem Erstellen zu validieren oder Opportunities für die weitere Optimierung zu identifizieren. Weitere Informationen zu Salesforce-Tools zum Verwalten von Datenvolumen finden Sie unter [Salesforce Tools For Reliability](/docs/architect/de-de/well-architected/guide/reliable#salesforce-tools-für-zuverlässigkeit) (Salesforce-Tools für Zuverlässigkeit). ### Skalierbarkeitsmuster und Anti-Muster Dies zeigt eine Auswahl an Mustern, nach denen in Ihrer Organisation gesucht oder die erstellt werden sollen, sowie Anti-Muster, die vermieden oder behoben werden sollen. ✨ Entdecken Sie weitere Muster für die Skalierbarkeit im [Explorer für Muster und](/docs/architect/de-de/well-architected-tools/guide/trusted-scalability) Anti-Muster.

	Muster	Anti-Muster
Datenmodellierung	In Ihren Designstandards: - Standards und Anleitungen, für die Geschäftsberechtigungen ein benutzerdefiniertes Objekt rechtfertigen.	In Ihren Designstandards: - Es gibt keine Standards zum Erstellen von benutzerdefinierten Objekten.
	In Ihrem Datenmodell: - Standardobjekte werden nach Möglichkeit verwendet. - ApexGuru-Überprüfungen auf Anti-Patterns bestätigen, dass SOQL-Abfragen selektiv sind und eine ineffiziente Schemanutzung vermeiden. - Tabellen werden für die Skalierung denormalisiert.	In Ihrem Datenmodell: - Sie haben Standardobjekte repliziert. - Tabellen werden normalisiert, um Redundanz zu vermeiden.
	Innerhalb Ihres Unternehmens: - Low-Code-Generatoren kennen die verschiedenen von Salesforce unterstützten Feldtypen und werten die Berichterstellungs- und Verschlüsselungsanforderungen aus, bevor sie Felddatentypen auswählen. - Bevor Sie sich entscheiden, eine Master-Detail-Beziehung zwischen Objekten herzustellen, werten Sie die Auswirkungen dieser Beziehung auf die Freigabe und die Datenverzerrung aus.	Innerhalb Ihres Unternehmens: - Low-Code-Generatoren wählen Datentypen aus, ohne nachgelagerte Berichterstellungs- und Verschlüsselungsanforderungen auszuwerten. - Bevor Sie sich entscheiden, Master-Detail-Beziehungen zwischen Objekten einzurichten, werten Sie die Auswirkungen dieser Beziehung auf die Freigabe und die Datenverzerrung nicht aus.
Datenvolumen	In Ihren Daten: - Keine übergeordneten Datensätze haben mehr als 10.000 untergeordnete Datensätze. - Es werden keine Benutzer mehr als 10.000 Datensätzen desselben Objekttyps zugewiesen. - Keine Instanzen enthalten mehr als 10.000 Datensätze, deren Nachschlagefelder auf denselben Datensatz verweisen. - Massendatenladungen werden in Batches nach ParentId-Feldwerten sortiert. - Um sicherzustellen, dass Batch-Strategien nicht gleichzeitig funktionieren, wird Skalierungstest verwendet, um Massenlademuster im Produktionsmaßstab zu validieren. - Massendaten werden während der Hauptgeschäftszeiten nicht in die Produktion geladen. - Massendatenladungen enthalten nur die Mindestdaten, die für Geschäftsentscheidungen erforderlich sind.	In Ihren Daten: - Es sind Datensätze mit mehr als 10.000 untergeordneten Datensätzen vorhanden. - Benutzer werden mehr als 10.000 Datensätzen desselben Typs zugewiesen. - Es gibt Instanzen, in denen mehr als 10.000 Datensätze Nachschlagefelder aufweisen, die auf denselben Datensatz verweisen. - Massendatenladungen werden nicht nach ParentId-Feldwerten in Batches sortiert. - Massendaten werden während der Hauptgeschäftszeiten in die Produktion geladen. - Massendatenladungen sind nicht auf die für Geschäftsentscheidungen erforderlichen Mindestdaten beschränkt.
	In Flow und Apex: - Logik ist vorhanden, um die Anzahl der untergeordneten Datensätze auf mehrere übergeordnete Datensätze in Szenarien zu verteilen, in denen Datenverzerrungen problematisch sind. - Beim Importieren oder Abgleichen von Datensätzen über die Integration weist die Logik sie den entsprechenden menschlichen Benutzern zu. - Für Apex-Sammlungen wie Listen und Sätze ist eine Logik vorhanden, um mehrere Datensätze zu verarbeiten, um Abfragen zu minimieren und die Datenverarbeitung zu optimieren. - Effizienter Apex Code, der den Standards und bewährten Vorgehensweisen für skalierbaren Code folgt, wird geschrieben und bereitgestellt.	In Flow und Apex: - Untergeordnete Datensätze werden willkürlich übergeordneten Datensätzen zugewiesen, unabhängig von der Anzahl der bereits zugewiesenen untergeordneten Datensätze. - Über Datenladevorgänge oder Integrationen erstellte Datensätze werden einem generischen "Integrationsbenutzer" zugewiesen. - Mehrere rekursive SOQL-Abfragen aus demselben Objekt befinden sich in synchronen Transaktionen, was zu einer hohen Heap-Nutzung führt. - Wenn Entwickler Apex Code schreiben, führen sie zu Ineffizienzen und leistungsgefährdenden Mustern.
	Innerhalb Ihres Unternehmens: - Sie haben eine Datenarchivierungs- und Bereinigungsstrategie dokumentiert und implementiert	Innerhalb Ihres Unternehmens: - Sie verfügen nicht über eine Strategie zur Datenarchivierung und -bereinigung oder Ihre Strategie wurde dokumentiert, aber nicht implementiert

## Salesforce-Tools für Zuverlässigkeit

Tool	Beschreibung	Leistung	Skalierbarkeit
Große Objekte	Speichern und verwalten Sie große Datenmengen auf der Plattform.		X
Code-Scanner	Scannen Sie Apex Code auf Leistungsprobleme.	X
Benutzerdefinierte Indizes	Verbessern Sie die Abfrageleistung mit benutzerdefinierten Indizes.		X
Löschen von Daten	Entfernen Sie nicht benötigte Daten, um die Leistung zu verbessern.	X	X
Unterteilungen	Partitionsdaten zum Begrenzen der Datensatzanzahl in Abfragen und Berichten.		X
Skalierungstest	Testen Sie die Systemleistung und interpretieren Sie die Ergebnisse. Bevor Sie die Bereitstellung in der Produktion vornehmen, sollten Sie zum Validieren der Skalierbarkeit und Leistung umfangreiche Benutzeroberflächen- und API-Arbeitslasten mit Playwright- oder JMeter-Skripts imulieren.	X	X
Skalierungscenter	Erhalten Sie Self-Service-Statistiken und Echtzeit-Statistiken zur Systemleistung. Finden Sie langfristige Transaktionen, Ausnahme-Hotspots und Durchsatzengpässe. Diagnostizieren Sie Skalierungsprobleme an einem früheren Punkt in Ihrem Entwicklungszyklus.	X	X
ApexGuru	Verwenden Sie diese GenAI-basierte Funktion im Skalierungscenter, um Anti-Patterns für Apex, SOQL und Testklassen zur Laufzeit zu erkennen. Durch die Integration von ApexGuru in Salesforce Code Analyzer erhalten Sie AI-gestützte Empfehlungen und Inline-Korrekturen im Entwicklungs-Workflow. Verwenden Sie diese Empfehlungen und Korrekturen, um Hotspots zu beheben und die Abfrageselektivität, die Massenverarbeitung, die Cache-Nutzung und die Testqualität zu verbessern.	X	X
Salesforce-Codeanalyse	Scannen Sie Code mit IDE, CLI oder CI/CD, um sicherzustellen, dass er den bewährten Vorgehensweisen entspricht. Über die Integration von Salesforce Code Analyzer in ApexGuru erhalten Sie direkt im Entwickler-Workflow Statistiken zu Leistungs-Anti-Patterns.	X
Salesforce Edge Network	Verbessern Sie die Download-Zeiten und die Benutzererfahrung, indem Sie Ihre Meine Domäne über das Salesforce Edge-Netzwerk weiterleiten.	X
Skinny Tables	Vermeiden Sie Verknüpfungen in Tabellen, die häufig verwendete Felder aufweisen.		X
Proaktive Überwachung	Überwachen Sie kontinuierlich Anomalien beim Datensatzwachstum, Inhaberschaftsverzerrungen und Leistungsrückgänge. Benachrichtigen Sie Sie über Skalierungsprobleme, bevor sie kritisch werden.	X	X

## Salesforce-Ressourcen für Zuverlässigkeit

Ressource	Beschreibung	Verfügbarkeit	Leistung	Skalierbarkeit
Skalierungsherausforderungen kosten Millionen – So sind Sie zukunftssicher	Erfahren Sie, wie die Implementierung der Skalierbarkeit zu nachhaltigem Wachstum und langfristigem Erfolg führt.		X	X
Erstellen und Bereitstellen skalierbarer Anwendungen mithilfe des Skalierungscenters	Erfahren Sie, wie Sie Leistungsprobleme in Ihren Salesforce-Implementierungen proaktiv bewerten und beheben können.
Analysieren von Leistungs- und Skalierungs-Hotspots in komplexen Salesforce-Anwendungen	Beheben Sie Leistungs- und Skalierbarkeitsprobleme in Ihrer Organisation.		X	X
Ihre Anwendung sollte im Berufsverkehr nicht in Panik geraten – So bereiten Sie sich vor	Erfahren Sie mehr über die vier wichtigsten Schritte für erfolgreiche Skalierungstests.
Erläutertes ApexGuru-AI-Modul	Erfahren Sie, wie ApexGuru benutzerdefinierte trainierte Modelle, reale Organisationstelemetrie und intelligente Filter verwendet, um präzise, kontextbezogene und handlungsrelevante Statistiken bereitzustellen.		X	X
Optimieren von Apex für Anwendungen und Agentforce mit ApexGuru	Erfahren Sie, wie ApexGuru Entwicklern hilft, Leistungs-Anti-Patterns zu erkennen und zu beheben, einschließlich SOQL, DML, Debugging und Testineffizienzen. Verwenden Sie ApexGuru als AI-gestützten Coach für die skalierbare Entwicklung Ihrer Anwendungen und Ihre Implementierung von Agentforce.		X	X
ApexGuru Antipatterns	Erfahren Sie mehr über die offizielle Bibliothek der ApexGuru-erkannten Anti-Patterns, die für jede Salesforce-Hauptversion aktualisiert wird.		X	X
Bewährte Vorgehensweisen für Bereitstellungen mit großen Datenvolumen	Machen Sie sich mit den Prozessauswirkungen großer Datenmengen vertraut.			X
Überlegungen zum Salesforce Edge-Netzwerk	Erfahren Sie, wie Sie Ihre Organisation auf die Verwendung des Salesforce Edge-Netzwerks vorbereiten.		X
Vorlage 'Designstandards'	Erstellen Sie Designstandards für Ihre Organisation.	X	X	X
Überlegungen zum Datenmodelldesign	Optimieren Sie Datenmodelle für Skalierung und Wartung.		X	X
Designing Record Access for Enterprise Scale (Entwerfen des Datensatzzugriffs für die Enterprise-Skala)	Optimieren Sie die Leistung der Zugriffssteuerung durch Konfiguration.			X
Infrastruktur für Systeme mit großen Datenmengen	Erfahren Sie mehr über Funktionen, die die Systemleistung für Bereitstellungen mit großen Datenvolumen unterstützen.			X
Lernressourcen für die Batch-Verwaltung	Erfahren Sie mehr über die Batch-Verwaltung.		X	X
Leistungsoptimierung Lightning Experience	Verbessern Sie Lightning Experience in Ihrer Organisation, damit Ihre Benutzer schneller arbeiten können.		X
Verwalten von Nachschlageverzerrungen in Salesforce zum Vermeiden von Ausnahmen bei Datensatzsperren	Erfahren Sie, wie Sie die Auswirkungen von Nachschlageverzerrungen minimieren können.		X	X
Bewährte Vorgehensweisen für SOQL und SOSL	Befolgen Sie die bewährten Vorgehensweisen für SOQL und SOSL für Bereitstellungen mit großen Datenvolumen.		X	X
Tools für großflächige Neuausrichtungen	Planen und führen Sie Neuausrichtungen effektiv aus.			X
Verwenden von Mashups	Verwalten Sie große Datensets in einer anderen Anwendung.		X	X