Operational Excellence – Automatisierungsmuster
Weitere Informationen zu Well-Architected Operational Excellence → Automation and Efficiency (Automatisierung und Effizienz)
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Dashboards | ✅ Alle Kennzahlen zu KPIs sind in mindestens einem Dashboard enthalten |
| Plattform | Dokumentation | ✅ Ausgaben für jede Automatisierung sind messbar und zeitgebunden |
| Plattform | Dokumentation | ✅ Verantwortliche Beteiligte werden für jeden KPI aufgeführt |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Dashboards | ⚠️ KPI-Berichte sind nicht vorhanden oder in Dashboards fehlen Kennzahlen zu einigen KPIs. |
| Plattform | Dokumentation | ⚠️ KPIs sind ohne verantwortliche Beteiligte vorhanden |
| Plattform | Dokumentation | ⚠️ KPIs sind für Automatisierungen nicht vorhanden oder weisen unklare Zeitrahmen für Messungen auf |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Flow | ✅ Flow Builder wird für die durch einen Datensatz ausgelöste Automatisierung verwendet (ersetzt den Prozessgenerator und Workflow-Regeln) |
| Plattform | Flow | ✅ Durch einen Datensatz ausgelöste Flows mit Ausführung vor dem Speichern werden für die Feldauffüllung vor der Datensatzerstellung verwendet |
| Plattform | Flow | ✅ Flows verarbeiten Entscheidungslogik, Schleifen, API-Callouts, DML-Vorgänge und komplexe Orchestrierung in mehreren Schritten |
| Plattform | Flow | ✅ Die Flow-Transaktionssteuerung wird verwendet, um bei Bedarf Zwischenänderungen zu übernehmen |
| Plattform | Flow | ✅ Die Fehlerbehandlung wurde für die Fehlerbehebung in Flows implementiert. |
| Plattform | Flow | ✅ Reaktive Bildschirm-Flows bieten dynamische Benutzererfahrungen |
| Plattform | Flow | ✅ Deklarative Automatisierung wird ausgewählt, wenn Geschäftsbenutzer oder Administratoren Logik ohne Entwicklerbeteiligung ändern müssen |
| Plattform | Flow | ✅ Variablen beziehen sich nicht auf hartcodierte Werte (für Datensatztypen, Benutzer usw.) |
| Plattform | Flow | ✅ Flows übergeben Logik in Kontexten mit großem Datenvolumen an Apex |
| Plattform | Flow | ✅ Subflows werden für Abschnitte von Prozessen verwendet, die im gesamten Unternehmen wiederverwendet werden müssen |
| Plattform | Flow | ✅ Alle automatisch gestarteten Flows verwenden Entscheidungs- und/oder Pausenelemente, um Eingabekriterien auszuwerten und Endlosschleifen oder Ausführungen bei großen Datenmengen zu verhindern |
| Plattform | Flow | ✅ Benutzer werden nur aufgefordert, Daten anzugeben, wenn vorhandene Systemdaten nicht verwendet werden können |
| Plattform | Flow | ✅ Flows sind in einer hierarchischen Struktur organisiert, die aus einem Haupt-Flow und unterstützenden Subflows besteht |
| Plattform | Flow | ✅ Alle Benutzereingaben haben einen klaren Zweck innerhalb des Flows |
| Plattform | Flow | ✅ Jeder Flow dient einem einzelnen, spezifischen Zweck |
| Plattform | Flow | ✅ Jeder Schritt führt eine bestimmte, detaillierte Aufgabe aus |
| Plattform | Flow | ✅ Alle in abstrakten Systemkontexttransaktionen des Benutzerkontexts gestarteten Flows in Subflows, die konsistent nach dem Pausenelement platziert werden, um eine neue Transaktion zu erstellen |
| Plattform | Flow | ✅ Bei allen durch einen Datensatz ausgelösten Flows werden Auslöserreihenfolgenwerte ausgefüllt |
| Plattform | Flow | ✅ Flows, die externe System-Callouts oder langfristige Prozesse beinhalten, verwenden asynchrone Pfade |
| Plattform | Flow | ✅ Komplexe Sequenzen zugehöriger Datenvorgänge werden mit Orchestrator erstellt (anstatt mehrere Subflows innerhalb des monolithischen Flows aufzurufen) |
| Plattform | Validierung | ✅ Die Datenintegrität wird auf Plattformebene mithilfe von Validierungsregeln, Duplikatsregeln und Pflichtfeldern erzwungen |
| Plattform | Validierung | ✅ Validierungsregeln verhindern ungültige Dateneingaben vor dem Speichern (effizienter als die Auslöservalidierung) |
| Plattform | Genehmigungsprozesse | ✅ Die mehrstufige Genehmigungsweiterleitung verarbeitet parallele und sequenzielle Genehmigungspfade mit delegierten Genehmigern |
| Plattform | Genehmigungsprozesse | ✅ Genehmigungsarchitektur berücksichtigt Ausnahmeszenarien (alle Genehmiger im Urlaub, dringende Geschäftsanforderung unter Umgehung der normalen Genehmigung) |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Flow | ⚠️ Prozessgenerator und Workflow-Regeln für die neue Automatisierung (Flow Builder ist die strategische Richtung) |
| Plattform | Flow | ⚠️ Programmgesteuerte Automatisierung, die verwendet wird, wenn Geschäftsbenutzer oder Administratoren Logik ohne Entwicklerbeteiligung ändern müssen |
| Plattform | Flow | ⚠️ Bei Flows fehlt die Fehlerbehandlung, was zu einer schlechten Fehlerbehebung führt |
| Plattform | Flow | ⚠️ Variablen haben hartcodierte Werte |
| Plattform | Flow | ⚠️ Flows müssen vor dem Laden von Massendaten manuell deaktiviert werden |
| Plattform | Flow | ⚠️ Teile eines Flows werden Flow-übergreifend wiederholt, statt Subflows zu verwenden |
| Plattform | Flow | ⚠️ Flows lösen Hinweise zu “nicht verarbeiteten Ausnahmen” aus |
| Plattform | Flow | ⚠️ Selbst einfache Flows führen regelmäßig zu Fehlern in Bezug auf Obergrenzen. |
| Plattform | Flow | ⚠️ Flows erfordern zusätzliche Eingaben, um Kontext bereitzustellen |
| Plattform | Flow | ⚠️ Flows dienen mehreren Zwecken |
| Plattform | Flow | ⚠️ Gruppen verwandter Schritte enthalten Funktionen, die sich mit Gruppen von Schritten in anderen Flows überschneiden |
| Plattform | Flow | ⚠️ Flows fragen nach Benutzereingaben, wenn gespeicherte Daten stattdessen verwendet werden können |
| Plattform | Flow | ⚠️ Für Flows sind Eingaben erforderlich, deren Daten nicht verwendet werden |
| Plattform | Flow | ⚠️ Ausführen von DML mithilfe einer Sammlung, die über die Bildschirmkomponente ausgegeben wird (mit der Einstellung “IDs und alle Feldwerte aus einem Datensatz oder einer Datensatzsammlung verwenden” für das Element zum Erstellen, Aktualisieren oder Löschen, wenn die Sammlung über die Bildschirmkomponente ausgegeben wird) |
| Plattform | Flow | ⚠️ Durch einen Datensatz ausgelöste Flows verwenden überhaupt keine Attribute für die Auslöserreihenfolge oder keine durchgängigen Werte für die Auslöserreihenfolge |
| Plattform | Flow | ⚠️ Asynchrone Pfade werden nicht einheitlich oder überhaupt verwendet |
| Plattform | Flow | ⚠️ Große monolithische Flows versuchen, komplexe Sequenzen von zugehörigen Datenvorgängen (mit oder ohne Subflows) zu koordinieren |
| Plattform | Genehmigungsprozesse | ⚠️ Genehmigungsarchitektur berücksichtigt keine Ausnahmeszenarien (alle Genehmiger im Urlaub, dringende Geschäftsanforderungen) |
| Plattform | Validierung | ⚠️ Datenintegrität wird nur in Auslösern anstelle von Validierungsregeln erzwungen (Auslöservalidierung weniger effizient und komplexer) |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Apex | ✅ Das Auslöser-Handler-Framework erzwingt Einzelauslöser pro Objekt, Massenverarbeitung, Trennung von Bedenken und rekursive Ausführungsverhinderung |
| Plattform | Apex | ✅ Auslöser-Handler delegieren an Serviceklassen für Geschäftslogik und behalten dabei eine klare Trennung der Bedenken bei |
| Plattform | Apex | ✅ Auslöser verwenden Rekursionsschutz mithilfe statischer Kennzeichnungen oder einer speziellen Rekursionskontrollklasse |
| Plattform | Apex | ✅ Future Apex wird sparsam für Callouts oder Systemobjekt-DML verwendet |
| Plattform | Apex | ✅ Asynchrone Apex Aufrufe verwenden Warteschlange, um komplexe DML transaktionsübergreifend zu verketten |
| Plattform | Apex | ✅ Batch Apex wird für große Datenmengen verwendet (verarbeitet große Datenmengen mit speziellen Obergrenzen pro Block) |
| Plattform | Apex | ✅ Batchaufträge weisen eine Fehlerbehandlung auf, die fehlgeschlagene Datensätze protokolliert, ohne die gesamte Batchausführung anzuhalten |
| Plattform | Apex | ✅ Die Bulk-API wird nur verwendet, wenn große Datenmengen verarbeitet werden müssen (native SOAP- und REST-APIs werden für kleinere Datenmengen verwendet) |
| Plattform | Apex | ✅ Warteschlangenfähiger Apex wird für komplexe Workflow-Orchestrierungen, externe Callouts mit Wiederholungslogik und Verarbeitungen mit asynchronen Obergrenzen verwendet |
| Plattform | Apex | ✅ Geplantes Apex führt die Verarbeitung nach festen Zeitplänen für die nächtliche Wartung, tägliche Berichte, regelmäßige Integrationssynchronisierung und zeitbasierte Geschäftsregeln aus |
| Plattform | Designstandards | ✅ Anwendungsfälle für synchrone und asynchrone Vorgänge innerhalb von Automatisierungen sind als Teil von Designstandards klar umrissen |
| Plattform | Dokumentation | ✅ Geplante und potenzielle Ausführungspfade für Automatisierungen sind klar umrissen |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Apex | ⚠️ Mehrere Auslöser für ein Objekt mit nicht vorhersehbarer Ausführungsreihenfolge und sich überschneidender Logik |
| Plattform | Apex | ⚠️ Geschäftslogik, die direkt in Auslöserdateien eingebettet ist und Tests erschwert |
| Plattform | Apex | ⚠️ Kein Auslöser-Handler-Framework oder inkonsistente Auslösermuster über Objekte hinweg |
| Plattform | Apex | ⚠️ Batch-Apex-Aufträge haben eine sehr geringe Umfangsgröße (z. B. Umfangsgröße = 1) |
| Plattform | Apex | ⚠️ Für externe Callouts verwendeter Batch-Apex (große Mengen an Salesforce-Daten, die mit Batch-Apex an externe Systeme übertragen werden) |
| Plattform | Apex | ⚠️ Beliebig verwendete asynchrone Apex Funktionen (Zukünftige Methoden und warteschlangenfähiger Apex werden inkonsistent oder austauschbar verwendet) |
| Plattform | Apex | ⚠️ Asynchrones Apex wird selten verwendet |
| Plattform | Apex | ⚠️ Datenbankvorgänge verfügen nicht über eine klare, konsistente Logik, um die Ausführung bei Bedarf an Batch Apex weiterzugeben |
| Plattform | Designstandards | ⚠️ Anwendungsfälle für synchrone und asynchrone Vorgänge werden nicht behandelt |
| Plattform | Dokumentation | ⚠️ Der Automatisierungsaufruf wird nicht dokumentiert |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Plattformereignisse | ✅ Plattformereignisse werden für die ereignisgesteuerte Automatisierung verwendet, die Publisher von Abonnenten entkoppelt |
| Plattform | Plattformereignisse | ✅ Publisher sind sich der Abonnenten nicht bewusst und veröffentlichen “fire-and-forget” |
| Plattform | Plattformereignisse | ✅ Mehrere Abonnenten reagieren unabhängig auf Ereignisse über durch Plattformereignisse ausgelöste Flows, Apex-Auslöser oder externe Integrationen |
| Plattform | Plattformereignisse | ✅ IDs für die erneute Wiedergabe werden verwendet, um verpasste Ereignisse an einem beliebigen Punkt im 72-Stunden-Aufbewahrungsfenster erneut wiederzugeben |
| Plattform | Plattformereignisse | ✅ Plattformereignisse ermöglichen organisationsübergreifende Kommunikation, Benachrichtigung über externe Systeme und interne Workflow-Orchestrierung |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Plattformereignisse | ⚠️ Direkte Kopplung zwischen Publishern und Abonnenten verhindert die zusammengesetzte Automatisierung |
| Plattform | Plattformereignisse | ⚠️ Das Accountstufen-Upgrade ruft die Opportunity-Aktualisierung, die Benachrichtigung des Accountteams und die Data Warehouse-Synchronisierung direkt in einer Transaktion auf (eine enge Kopplung erfordert Änderungen an der Accountlogik, sobald eine neue nachgelagerte Verarbeitung erforderlich ist) |
| Plattform | Apex | ⚠️ Unmittelbar veröffentlichen Plattformereignisse, die adhoc verwendet werden (Echtzeitereignisse, die anstelle von “Nach Commit veröffentlichen” verwendet werden, unabhängig von Veröffentlichungsauftragsanforderungen oder Datensatzsperrrisiken) |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Apex | ✅ SOQL-Anweisungen verwenden positive Logikvergleichsoperatoren (INCLUDES, IN) als primäre oder einzige Logik |
| Plattform | Apex | ✅ SOQL vermeidet = NULL, != NULL oder verwendet sie sparsam nach positiven Vergleichsoperatoren |
| Plattform | Apex | ✅ SOQL verwendet keine LIMIT 1-Anweisungen |
| Plattform | Apex | ✅ SOQL verwendet kein Stichwort ALL ROWS |
| Plattform | Apex | ✅ SOQL wird nicht in Schleifen angezeigt |
| Plattform | Apex | ✅ Platzhalterkriterien werden in SOSL (nicht SOQL) angezeigt |
| Plattform | Apex | ✅ SOQL-Anweisungen vermeiden LIKE oder Teiltextvergleiche |
| Plattform | Apex | ✅ SOQL wird in try-catch-Blöcken eingeschlossen |
| Plattform | Apex | ✅ Variablen beziehen sich nicht auf hartcodierte Werte (für Datensatztypen, Benutzer usw.) |
| Plattform | Apex | ✅ Jede Klasse dient einem einzelnen, spezifischen Zweck |
| Plattform | Apex | ✅ Jede Methode führt eine bestimmte, detaillierte Aufgabe aus |
| Plattform | Apex | ✅ Alle Eingabevariablen haben einen klaren Zweck innerhalb der Klasse |
| Plattform | Apex | ✅ Codeausführung erfordert eine minimale Anzahl an Ressourcen |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Apex | ⚠️ SOQL-Anweisungen verwenden NOT, NOT IN als primären oder einzigen Vergleichsoperator (nicht selektiv) |
| Plattform | Apex | ⚠️ SOQL-Anweisungen verwenden das Stichwort ALL ROWS (nicht selektiv) |
| Plattform | Apex | ⚠️ SOQL-Anweisungen verwenden = NULL, != NULL als primären oder einzigen Vergleichsoperator (nicht selektiv) |
| Plattform | Apex | ⚠️ Variablen haben hartcodierte Werte |
| Plattform | Apex | ⚠️ SOQL wird in Schleifen angezeigt |
| Plattform | Apex | ⚠️ SOQL-Anweisungen verwenden häufig LIKE- und Platzhalterfilterkriterien (nicht selektiv) |
| Plattform | Apex | ⚠️ SOQL nicht in try-catch eingeschlossen |
| Plattform | Apex | ⚠️ SOQL-Anweisungen verwenden LIMIT 1 (nicht selektiv) |
| Plattform | Apex | ⚠️ SOSL wird selten oder nicht einheitlich für Platzhalterauswahlkriterien verwendet |
| Plattform | Apex | ⚠️ Klassen dienen mehreren Zwecken |
| Plattform | Apex | ⚠️ 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 |
| Plattform | Apex | ⚠️ Eingabevariablen werden in Methoden nicht verwendet |
| Plattform | Apex | ⚠️ Methoden rufen unnötig Daten aus der Datenbank oder aus externen Systemen ab |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Apex | ✅ Benutzerdefinierte Ausnahmen werden zum Erstellen von erweiterten Fehlermeldungen und Logik verwendet |
| Plattform | Apex | ✅ Code umschließt alle DML-, SOQL-, Callout- und anderen wichtigen Prozessschritte in try-catch |
| Plattform | Apex | ✅ Datenbankklassenmethoden können ausschließlich für alle Datenvorgänge (anstelle von DML) verwendet werden |
| Plattform | Apex | ✅ In asynchronen und Massenkontexten werden Datenbankklassenmethoden anstelle von DML verwendet |
| Plattform | Aura | ✅ JavaScript umschließt alle Datenvorgänge und wichtigen Prozessschritte in try-catch |
| Plattform | Aura | ✅ In try-catch-Blöcken wird native JavaScript-Error in throw-Anweisungen verwendet (keine Verwendung von $A.error()) |
| Plattform | Aura | ✅ Alle behebbaren Fehlerlogiken werden in catch-Anweisungen angezeigt und bieten klare Benutzermeldungen |
| Plattform | Flow | ✅ Flows mit Datenvorgängen, Callouts und anderen wichtigen Verarbeitungslogiken weisen Fehlerpfade für alle wichtigen Aktionen auf |
| Plattform | Flow | ✅ Bildschirm-Flows verwenden konsistent Fehler-Konnektoren, um Benutzern Fehler anzuzeigen |
| Plattform | Flow | ✅ Benutzerdefinierte Fehlermeldungen werden für Fehler konfiguriert, die auf dem Bildschirm angezeigt werden |
| Plattform | Lightning Web Components (LWC) | ✅ JavaScript umschließt alle Datenvorgänge und wichtigen Prozessschritte in if ()/else if ()-Blöcke |
| Plattform | Lightning Web Components (LWC) | ✅ Alle @wire verwenden die von der API bereitgestellten data- und error. |
| Plattform | Lightning Web Components (LWC) | ✅ Alle if (error)/else if (error)-Anweisungen enthalten Logik zum Verarbeiten von Fehlern und Bereitstellen informativer Meldungen |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Apex | ⚠️ DML, SOQL, Callouts oder andere wichtige Prozessschritte, die nicht durchgängig in Try-Catch-Blöcken eingeschlossen sind |
| Plattform | Apex | ⚠️ Es werden keine Datenbankklassenmethoden verwendet |
| Plattform | Apex | ⚠️ Datenvorgänge, die ausschließlich mit DML ausgeführt werden |
| Plattform | Apex | ⚠️ System.debug werden im Produktionscode angezeigt (und nicht auskommentiert) |
| Plattform | Aura | JavaScript umschließt Datenvorgänge und wichtige Prozessschritte nicht konsistent in try-catch |
| Plattform | Aura | ⚠️ Komponenten verwenden $A.error() |
| Plattform | Aura | ⚠️ Fehlerbehebungslogik wird in catch-Anweisungen nicht einheitlich angezeigt und Fehlermeldungen an Benutzer sind nicht eindeutig |
| Plattform | Flow | ⚠️ Flows verwenden Fehlerpfade nicht einheitlich oder überhaupt |
| Plattform | Flow | ⚠️ Benutzerdefinierte Fehlermeldungen werden nicht verwendet, sodass Benutzern die Standardmeldung “In diesem Flow ist ein nicht bearbeiteter Fehler aufgetreten” angezeigt wird |
| Plattform | Lightning Web Components (LWC) | ⚠️ @wire-Funktionen verwenden die von der API bereitgestellten data- und error-Eigenschaften nicht (oder nicht einheitlich) |
| Plattform | Lightning Web Components (LWC) | ⚠️ Wenn überhaupt verwendet, enthalten if (error)/else if (error)-Anweisungen keine Logik zum Verarbeiten von Fehlern und bieten nützliche Fehlermeldungen |
| Plattform | Lightning Web Components (LWC) | JavaScript verwendet if ()/ else if ()-Blöcke nicht konsistent mit Datenvorgängen oder wichtigen Prozessschritten |