Möchten Sie Formulare auf der Salesforce Platform erstellen? Sie haben mehrere Optionen, die das gesamte Low-Code- bis Pro-Code-Kontinuum umfassen. Dynamische Formulare im Lightning-Anwendungsgenerator und Bildschirm-Flows in Flow Builder stehen für Low-Code. In der Mitte des Kontinuums können Sie Bildschirm-Flows mit LWCs erweitern und kundenorientierte Formulare mit OmniStudio erstellen. Und Pro-Code ist das LWC-Framework und seine ständig wachsende Bibliothek an Basiskomponenten.

Optionen sind großartig, aber wie bestimmen Sie, welche (oder welche Kombination) die richtige Option ist? Hier kommt dieser Leitfaden ins Spiel.

• Takeaway #1: Verwenden Sie beim Erstellen von Layouts zum Erstellen/Bearbeiten/Anzeigen von Lightning-Seiten dynamische Formulare. Möglicherweise stellen Sie fest, dass Seitenlayouts in den Vergleichstabellen in dieser Anleitung fehlen. Künftig sollten Sie dynamische Formulare im Lightning-Anwendungsgenerator verwenden, um Datensatz-Detailseiten zu konfigurieren. Im Abschnitt "Seitenlayouts" finden Sie weitere Informationen dazu, warum sie nicht weiter verbessert werden sollen.
• Takeaway #2: Wenn Sie ein Formular zum Erstellen oder Bearbeiten für genau ein Objekt erstellen müssen, beginnen Sie mit Lightning-Seiten und dynamischen Formularen. Dies ist die einfachste Möglichkeit, Formulare auf der Salesforce Platform zu erstellen. Sie bietet auch einige zusätzliche Funktionen, beispielsweise die Möglichkeit, die Feldsichtbarkeit zu steuern. Wenn Ihre Anforderungen weiter fortgeschritten sind, lesen Sie weiter. Bildschirm-Flow, OmniStudio oder Lightning Web Components (LWC) sind möglicherweise besser geeignet.
• Takeaway #3: Wenn Sie ein mehrseitiges Formular oder einen Assistenten erstellen und keine strengen Anforderungen an Benutzeroberfläche oder Branding haben, beginnen Sie mit einem Bildschirm-Flow. Bildschirm-Flows bieten ein lineares Navigations-Framework für die Orchestrierung mehrerer Formulare zusammen. Sie können LWC verwenden, um Ihr eigenes Framework für die Navigation zwischen Formularen zu erstellen. Es wird jedoch empfohlen, Flow die harte Arbeit für Sie zu überlassen, damit Sie sich auf die Formulare selbst konzentrieren können, statt sich um den Formularstatus zu kümmern.
• Takeaway #4: Wenn Sie zusätzliche Logik oder Aktionen hinter dem Formular benötigen, verwenden Sie einen Bildschirm-Flow, OmniStudio oder LWC. Alle drei Tools bieten Möglichkeiten, mit denen Ihre Lösung mehr erledigen kann, als einen einzelnen Datensatz zu erstellen oder zu bearbeiten. Diese "Mehr" kann erweiterte Logik sein, beispielsweise Verzweigung oder Iteration, oder es können mehr Aktionen wie die Integration in externe Systeme, das Senden von E-Mails oder das Übertragen von Benachrichtigungen an die mobile Anwendung eines Benutzers sein.
• Takeaway #5: Sie haben komplexe UX-Anforderungen? Sie müssen mehr als nur die Sichtbarkeit dynamisch verarbeiten? Verwenden Sie LWC oder OmniScript. Wenn Ihre Anforderungen mit einfachen Themen und spaltenbasierten Layouts erreicht werden können, können Sie Ihre Formulare direkt in einem Low-Code-Generator erstellen. Für eine genauere Kontrolle über den Stil Ihres Formulars benötigen Sie die ultimative Flexibilität von LWC. Wenn Sie ein Branchenkunde sind und ein pixelgenaues Branding benötigen oder über komplexe hierarchische Daten verfügen, verwenden Sie OmniStudio, mit dem Sie Formulare für Verbraucher erstellen können, die komplexe Geschäftslogik und Datentransformationen verarbeiten können.
• Takeaway #6: Wenn Sie eine Testautomatisierung benötigen, beginnen Sie mit Lightning Web Components. Sie können Einheitentests für jede LWC schreiben, unabhängig davon, wo Sie sie einbetten möchten. Dadurch können Sie eine zuverlässigere Teststrategie erstellen, die Massentests mit mehreren Datensätzen und negative Tests umfassen kann. Unter Salesforce Well-Architected – Test Strategy finden Sie weitere Informationen zum Erstellen von Tests, mit denen Sie nachvollziehen können, wie gut Ihre Formulare Ihren funktionalen und nicht funktionalen Anforderungen entsprechen.

Beachten Sie, dass Sie nicht zwischen einem Entweder-Oder wählen müssen – Sie können die Leistung mehrerer Optionen kombinieren. Wenn Sie beispielsweise das integrierte Navigationssystem von Flow und die volle Flexibilität bei der Gestaltung von LWC benötigen, verwenden Sie sie zusammen.

In der folgenden Tabelle sind die Tools zum Erstellen von Formularen mit Salesforce sowie die erforderlichen Fertigkeiten und Lizenzüberlegungen aufgeführt. Später werden die spezifischen Funktionen, die für die einzelnen Tools unterstützt werden, genauer erläutert. Außerdem erfahren Sie, wie Sie zwischen klickbasierten Tools und codebasierten Tools auswählen (und wann sie kombiniert werden):

Die folgende Tabelle enthält eine Übersicht über die Entscheidungspunkte, die bei der Auswahl Ihrer Produkte berücksichtigt werden sollten, sowie Fragen, die Sie sich zu den einzelnen Produkten stellen sollten. Im weiteren Verlauf dieses Leitfadens werden wir jedes dieser Themen genauer untersuchen.

Im Folgenden finden Sie die Begriffe, die in den Vergleichstabellen zusammen mit ihren Definitionen verwendet werden:

• Verfügbar: Funktioniert gut mit grundlegenden Überlegungen.
• Nicht ideal: Kann funktionieren, ist aber nicht das optimale Tool.
• Roadmap: Geschätzte Unterstützung innerhalb der nächsten zwölf Monate (Juni 2025).
• Zukunft: Voraussichtliche Unterstützung über die nächsten zwölf Monate hinaus.
• Nicht verfügbar: Es ist nicht geplant, diese Funktion in den nächsten zwölf Monaten zu unterstützen.

Wie versprochen, beginnen wir mit einer Vielzahl von Vergleichspunkten und Funktionsunterschieden zwischen dynamischen Formularen, Bildschirm-Flows, OmniStudio, Bildschirm-Flows mit eingebetteten LWCs und dem LWC-Framework selbst.

Wenn Ihr Formular für ein einzelnes Salesforce-Objekt verwendet wird, funktionieren alle Tools, die verglichen werden. Bei objektübergreifenden oder objektunabhängigen Formularen wird es etwas komplizierter. Unter objektunabhängig verstehen wir Eingaben, die keinem Salesforce-Objekt zugeordnet sind. Möglicherweise stellt Ihr Formular eine Datenstruktur dar, die Sie an einen externen Service wie Stripe oder DocuSign senden. Oder Sie verwenden mehrere Eingaben in Ihrem Formular, um einen Wert zu berechnen, und übernehmen diesen Wert dann in die Datenbank.

• Für welche Objekte wird das Formular verwendet?
• Ist es nur ein Objekt oder gibt es mehrere Objekte?
• Arbeiten Sie mit bestimmten Objekten (z. B. Account, Kontakt, Opportunity, Lead und Kundenvorgang) oder muss Ihr Formular auch mit anderen Objekten funktionieren?

Bei objektübergreifenden und objektunabhängigen Formularen sind Flow und OmniStudio solide Optionen. Die in Flow-Bildschirmen verfügbaren Komponenten sind von Natur aus agnostisch. Sie können also auswählen, was mit diesen Daten im Hintergrund geschehen soll. Verwenden Sie beispielsweise die in einem Formular eingegebenen Daten, um mehrere Datensätze im Hintergrund zu erstellen, oder verwenden Sie die Daten, um andere Aktionen auszuführen, beispielsweise Chatter-Posts zu generieren, Slack-Nachrichten zu senden, E-Mails zu senden oder eine Verbindung mit externen Services herzustellen.

In einfachen Fällen kann die Verwendung vorhandener LWC-Komponenten wie Lightning-Datensatzform eine einfache Möglichkeit sein, den Code zu reduzieren, der für eine zuverlässige Lösung erforderlich ist. In Szenarien, in denen mehrere Objekte beteiligt sind, bietet Flow jedoch umfassende Kontrolle über alle Objekte und macht es Entwicklern nicht mehr erforderlich, komplexe Beziehungen und Abhängigkeiten zu durchlaufen.

OmniStudio geht noch einen Schritt weiter und ist vollständig objektunabhängig: Es trennt die Form, die einem Benutzer angezeigt wird, vom zugrunde liegenden Datenmodell. Stattdessen bearbeitet OmniStudio die zugrunde liegende JSON, die dann Salesforce-Objekten (oder externen Daten) mit Tools wie der Datenzuordnung und Integrationsverfahren zugeordnet wird. "Datenzuordnung" und "Integrationsverfahren" sind zwei wichtige Komponenten für die Verbindung Ihrer OmniStudio-Formulare mit internen und externen Salesforce-Daten. Mithilfe von Ziehen-und-Ablegen-Elementen können Sie mit komplexen hierarchischen Daten in einem externen System arbeiten und die Daten dann entsprechend Ihren Anforderungen umwandeln, je nachdem, wohin die Daten gelangen sollen. Sie ermöglichen es Ihnen auch, Formeln zu verwenden, um Mathematik und Logik für Arrays oder Datenlisten auszuführen, ähnlich wie Apex.

OmniStudio Integrations

Wenn Sie alle Ihre Benutzereingaben über ein Formular mit einem einzigen Bildschirm abrufen können, beginnen Sie mit "Dynamische Formulare". Dynamische Formulare auf Datensatzseiten können zwar die Funktion "Pfad" verwenden, um die verschiedenen Phasen Ihres Geschäftsprozesses locker darzustellen, passen jedoch möglicherweise nicht in die meisten Ihrer Anwendungsfälle.

• Benötigen Sie einen einzelnen Bildschirm oder muss der Benutzer zwischen mehreren Bildschirmen navigieren, um eine Aufgabe zu erledigen?
• Möchten Sie, dass Ihren Benutzern eine visuelle Darstellung angezeigt wird, wie weit sie beim Ausfüllen Ihres Formulars sind?
• Müssen Ihre Benutzer die Informationen auf jedem Bildschirm in einer bestimmten Reihenfolge ausfüllen oder sollten sie nach Bedarf zwischen den Bildschirmen wechseln können?

Wenn Sie mehr Funktionen benötigen, als dynamische Formulare bieten, hängt die Auswahl zwischen Flow, OmniStudio und LWC auch von einigen anderen Fragen ab:

• Welche Fertigkeiten hat Ihr Team? Für eine administratorlastigere Organisation sollten Sie mit Flow beginnen. Wenn Sie über Branchenlösungen verfügen, Ihr Team bereits mit OmniStudio vertraut ist und Ihr Projekt strenge UX-Anforderungen hat, beginnen Sie mit OmniStudio.
• Ist es in Ordnung, unten in Ihrem Formular eine Navigationsleiste anzuzeigen? Wenn der Bildschirm-Flow und die OmniScript-Navigationserfahrung unerwünscht sind, neigen Sie zu LWC.
• Was muss hinter dem Formular geschehen? Wenn das Verhalten von einem Administrator konfiguriert werden muss, erstellen Sie einen Flow oder – bei grundlegenden Änderungen wie dem Ändern von Feldbezeichnungen – ein OmniScript. Erstellen Sie andernfalls für komplexe Beziehungen mit mehreren Objekten ein OmniScript oder eine LWC.
• Wenn Sie Flow oder OmniStudio auswählen, müssen Sie möglicherweise ohnehin eine LWC erstellen, um die richtige Benutzeroberfläche zu erreichen. Wenn Sie bereits eine Lightning-Webkomponente erstellen, um den Stil Ihres Formulars richtig festzulegen, sollten Sie überlegen, ob das Einbetten dieser Komponente in einen Flow übertrieben ist.

Wenn Ihre Lösung hingegen wie ein Assistent aussieht, bei dem der Benutzer zwischen mehreren Bildschirmen navigiert, sollten Sie Flow oder OmniStudio in Betracht ziehen. Flows und OmniStudio verfügen über ein integriertes Navigationsmodell, sodass Sie keine aneinandergereihten LWCs erstellen und verwalten müssen. Die Navigation erfolgt linear mit vorwärts beweglichen Aktionen, rückwärts beweglichen Aktionen und einem Mechanismus zum Speichern des Formulars für später. Sie können auch ein Formular mit nichtlinearer Navigation erstellen, wenn es Ihren Zwecken entspricht. Ein großartiges Beispiel dafür, wie Sie Bildschirm-Flows verwenden, finden Sie im Paket "Digital Store Audit" von Salesforce Labs.

OmniStudio bietet einen wichtigen Navigationsvorteil, da Fortschrittsindikatoren aus der Standardnavigation bereitgestellt werden, die "Schritte" im Formular anzeigen. In dieser Schrittansicht wird automatisch angezeigt, wo sich ein Benutzer in einem bestimmten Formular mit mehreren Schritten befindet. Im Gegensatz zu Flow können Benutzer durch Klicken auf verschiedene Schritte des Formulars zwischen Bildschirmen springen.

Unabhängig davon, ob Sie Formulare mit einem einzelnen Bildschirm oder Formulare mit mehreren Bildschirmen erstellen, stellen Sie sicher, dass Ihre Formulare optimiert sind, damit Ihre Benutzer einfach darin navigieren können.

Wenn Sie ein Formular in eine Lightning Standard-Datensatzseite einbetten, funktionieren alle Tools, die verglichen werden, mit dem Vorbehalt, dass dynamische Formulare derzeit nur auf dem Desktop verfügbar sind. Wenn Sie jedoch eine Erfahrung bereitstellen möchten, die es Benutzern ermöglicht, von anderen Standorten aus auf Formulare zuzugreifen, sollten Sie möglicherweise alternative Optionen in Betracht ziehen.

• Benötigen Benutzer Zugriff auf das Formular über Desktops, Mobilgeräte oder beides?
• Sollten Benutzer von überall in Ihrer Anwendung aus über eine Dienstprogrammleiste auf das Formular zugreifen können?
• Möchten Sie Schnellaktionen verwenden, damit Benutzer Ihr Formular ausfüllen können, ohne die Seite verlassen zu müssen, auf der sie sich gerade befinden?
• Muss Ihr Formular auf einer externen Website verfügbar sein?

Da sie Datensatzkontext erfordern, werden dynamische Formulare nur auf Lightning-Datensatzseiten unterstützt. Dynamische Formulare werden jedoch auf Experience Cloud-Seiten nicht unterstützt. Diese Einschränkung gilt, da Experience Cloud das zugrunde liegende Framework nicht verwendet, von dem dynamische Formulare abhängen: Lightning-Seiten. Dies wird anhand von Anforderungen für dynamische Formulare in Experience Cloud ausgewertet.

Sie können Flows erstellen, die einen Datensatzkontext erfordern, oder Flows, die global funktionieren. Daher können Sie Flows an einer Vielzahl von Orten einbetten. Bei Flows mit Datensatzkontext kann es sich um eine Lightning-Datensatzseite, eine Experience Cloud-Datensatzseite, eine objektspezifische Aktion oder eine Bereitstellung von Aktionen und Empfehlungen handeln. Für den globalen Flow kann dies die Dienstprogrammleiste, andere Lightning- oder Erfahrungsgenerator-Seiten, ein Snap oder eine externe Anwendung sein. Flows werden derzeit nicht als globale Aktionen unterstützt. Als Übergangslösung können Sie den Flow jedoch in eine Aura-Komponente einschließen.

Mit OmniStudio können Sie zusammengesetzte FlexCards und OmniScripts erstellen, die Sie fast überall dort platzieren können, wo Sie einen Flow platzieren können. Sie können jedoch nicht als Paket erstellt werden.

LWC unterstützt ein hohes Maß an Wiederverwendbarkeit, da Sie Komponenten erstellen, die über Metadaten in Salesforce, Communities und sogar in Open-Source-Projekten Zielen zugeordnet werden können. Über Lightning Out können LWC-Komponenten auch in die eigene Website eingebettet werden.

Lightning Out auf externen Sites

Lightning-Webkomponenten werden derzeit nicht als Schnellaktionen (objektspezifisch oder global) unterstützt. Als Übergangslösung können Sie jedoch eine Lightning-Webkomponente in eine Aura-Komponente einschließen (ähnlich wie bei Flows). LWC-Komponenten können auch Flows mit der Lightning-Flow-Komponente starten.

OmniStudio zeichnet sich durch die Bereitstellung von Inhalten auf externen Sites durch die OmniOut-Funktion aus. Mit OmniStudio und OmniOut können Sie Ihre OmniScript-Formulare und FlexCard-Komponenten zu Standardkomponenten kompilieren und sie außerhalb der Plattform auf Sites oder in Anwendungen von Drittanbietern ausführen.

Keine der in diesem Handbuch behandelten Formulartechnologien wird heute offiziell in Mobile SDK-Vorlagen unterstützt. Wenn das Mobile SDK für Ihren Anwendungsfall wichtig ist, sollten Sie Ihr Formular besser nativ in Ihrer mobilen Anwendung erstellen oder eine Visualforce-Seite erstellen, wobei die Salesforce Well-Architected Formfaktor-Anleitung zu berücksichtigen ist.

Fahrplanhinweis: Das Mobile SDK-Team arbeitet aktiv an der Unterstützung von LWCs auf Visualforce-Seiten.

Dynamische Formulare sind perfekt, wenn Sie die Werte in Ihrem Formular verwenden müssen, um einen Datensatz zu erstellen oder zu aktualisieren. Für alle darüber hinausgehenden Funktionen müssen Sie Flow, OmniStudio oder LWC verwenden. Diese Funktionen können eine Entscheidungsebene oder eine Iterationsebene umfassen oder die Generierung von Slack-Posts oder -E-Mails mithilfe der Eingaben aus dem Formular.

• Welche Aktionen oder Logiken möchten Sie im Hintergrund ausführen?
• Enthält Ihr Datenmodell hierarchische Daten?
• Muss Ihr Formular seine Vorgänge innerhalb einer einzelnen Transaktion oder transaktionsübergreifend abschließen?
• Müssen Sie in externe Systeme integriert werden?
• Welche Anforderungen stellen Sie an Wiederverwendbarkeit und Modularität?

Der Flow bietet Standardaktionen für das Posten in Slack, das Senden von E-Mails und die Interaktion mit Quip-Dokumenten, sodass Sie für diese Vorgänge keinen Code schreiben müssen. LWC bietet umfassende Interaktionen mit einzelnen Datensätzen und verwandten Objekten durch die Verwendung von Wire-Adaptern, die mit der Benutzeroberflächen-API interagieren. LWC kann auch mit mehreren Datensätzen interagieren, wenn der Wire für getListInfoByName verwendet wird.

Lightning Web Components

Wie oben erwähnt, verwendet OmniStudio Integrationsverfahren und Datenzuordnung, um Daten extern und intern in Salesforce einfach abzurufen und umzuwandeln. Dank zahlreicher codefreier Funktionen, die Sie verwenden können, können Sie Datensets mit verschiedenen Beziehungsebenen vereinfachen und erweitern.

Fahrplanhinweis: Flow wird bald die Möglichkeit zum Aktualisieren und Einfügen von Sammlungen von Datensätzen sowie zum Verwalten hierarchischer Daten unterstützen.

Flow, OmniStudio und LWC können alle in Apex integriert werden, sodass Sie Lücken in der von Ihnen ausgewählten Lösung ganz einfach schließen können. Wenn Sie beispielsweise Datensätze aus einem LWC filtern müssen, können Sie jederzeit den Wire-Adapter für Apex verwenden, um komplexe SOQL-Abfragen zu erstellen. Wenn Sie von dem klickbasierten Artikel überzeugt sind, sollten Sie Flow oder OmniStudio als brauchbare Alternativen zu einem Apex-Steuerfeld für Ihre serverseitigen Anforderungen in Betracht ziehen.

Eine sekundäre Frage hier ist, ob Sie Aktionen sofort übernehmen oder auf einen bestimmten Teil Ihres Formulars zurückstellen möchten. Dies ist besonders relevant, wenn Sie sich in einem mehrseitigen Formular befinden. Mit Flow können Eingaben aus mehreren Formularen (Flow-Bildschirmen) ganz einfach kombiniert und viel später im Assistenten (Flow) verwendet werden, um einige Vorgänge auszuführen. Es wird sogar empfohlen, Flows genau auf diese Weise zu entwerfen – also Aktionen am Ende auszuführen –, falls der Benutzer zwischen Bildschirmen hin- und herwechselt und seine Antworten ändert.

Transaktionen und Obergrenzen sind eine Lebenseinstellung auf Salesforce Platform. Wenn Ihr Anwendungsfall ziemlich einfach ist, ist es möglicherweise nicht so wichtig, zu steuern, in welcher Transaktion ein bestimmter Vorgang vorkommt. Es gibt jedoch einige Anwendungsfälle, in denen Sie mehrere Vorgänge in einer einzelnen Transaktion kombinieren möchten, statt sie transaktionsübergreifend auszuführen. Einige Beispiele:

• Zurücksetzen oder nicht zurücksetzen: Das ist die Frage. Angenommen, Ihr Formular erstellt mehrere Datensätze im Hintergrund. Wenn der dritte Datensatz nicht erstellt werden kann, sollten die ersten beiden Datensätze zurückgesetzt werden? Wenn jede Ihrer Aktionen unabhängig voneinander ist, können Sie sie in separaten Transaktionen ausführen. Wenn sie jedoch abhängig sind und Sie möchten, dass die anderen nicht ebenfalls zurückgesetzt werden, implementieren Sie sie in einer einzelnen Transaktion. Wenn sich Ihr Formular im Flow befindet, können Sie das Element "Rückmeldung" in einem Fehlerpfad verwenden, um Ihre Transaktion zurückzusetzen und die Datenintegrität sicherzustellen.
• Nachgelagerte Auswirkungen auf die Obergrenzen: Insbesondere wenn Ihr Formular einen Datensatz erstellt oder aktualisiert, sollten Sie die nachgelagerten Auswirkungen dieses Vorgangs berücksichtigen. Welche Prozesse, Workflow-Regeln, Flow-Auslöser, Apex-Auslöser oder anderen Elemente in der Speicherreihenfolge werden basierend auf dieser Datensatzänderung ausgelöst? Und wie wirken sich diese kollektiven Änderungen auf die Obergrenzen aus, die in dieser Transaktion verbraucht werden? Wenn eine bestimmte Datensatzänderung zu vielen nachgelagerten Änderungen führt, die sich auf Ihre Obergrenzen auswirken, sollten Sie diese Datensatzänderung in eine eigene Transaktion aufnehmen.
• Batchverarbeitung: Selbst in einem Benutzeroberflächenkontext müssen Sie möglicherweise mehrere Aktualisierungen zusammen als Batch vornehmen. Angenommen, Ihr Formular mit mehreren Bildschirmen durchläuft eine große Gruppe von Datensätzen. Statt nach jedem Bildschirm eine Datensatzaktualisierung zu übernehmen, warten Sie, bis Sie die Aktualisierungen für alle Datensätze gesammelt haben, und senden Sie dann eine Anforderung zur Aktualisierung aller Datensätze.

Wenn Sie dynamische Formulare zum Erstellen oder Bearbeiten eines Datensatzes verwenden, führen Sie immer nur einen Vorgang aus und dieser Vorgang ist immer der Start einer neuen Nettotransaktion.

Beim Erstellen eines Bildschirm-Flows haben Sie erhebliche Kontrolle darüber, was in einer bestimmten Transaktion passiert. Bildschirme und lokale Aktionen fungieren als Grenzen zwischen Transaktionen. Im Folgenden finden Sie eine allgemeine Zusammenfassung der Verwaltung von Transaktionen in der Bildschirm-Flow-Architektur.

1. Der Endbenutzer interagiert mit einem Bildschirm und klickt dann auf Weiter.
2. Der Client postet eine Anforderung mit den Eingaben an die API.
3. Die API empfängt die Anforderung und eine Transaktion und eine Datenbankverbindung werden geöffnet. Die API ruft dann das Flow-Modul auf, um die Anforderung aufzurufen.
4. Das Flow-Modul übernimmt die Funktion und folgt dem entsprechenden Pfad in der Flow-Definition, bis es einen Bildschirmknoten oder einen Knoten vom Typ "Lokale Aktion" erreicht. Das Modul gibt dann Informationen zu diesem Knoten an die API zurück.
5. Die API erstellt ein Antwortobjekt, das die Details des nächsten Bildschirms enthält, der dargestellt werden soll, und gibt dieses Objekt an den Client zurück. Zu diesem Zeitpunkt werden Datenbankänderungen übernommen (Hinweis auf die Ausführung des Speicherauftrags) und die Datenbankverbindung und die Transaktion werden geschlossen.
6. Der Client verwendet die API-Antwort, um den nächsten Bildschirm darzustellen, auf dem der Benutzer interagieren kann.
7. Wiederholen Sie den Vorgang ab Schritt 1.

Anders ausgedrückt: Bildschirme brechen Transaktionen ab. In diesem Fall werden alle ausstehenden Aktionen oder DML übernommen, die vorherige Transaktion wird geschlossen und eine neue Transaktion wird gestartet.

Das richtige Design – welche Vorgänge Sie zu einer bestimmten Transaktion gruppieren – ist Ihr Anruf. Sehen wir uns einige Beispiele an.

Links sehen Sie einen Flow, der Eingaben über mehrere Bildschirme hinweg erfasst und dann mehrere Aktionen in einer Transaktion ausführt.

Der Flow auf der rechten Seite führt jeden Vorgang in einer separaten Transaktion aus.

Angenommen, Sie verfügen über einen Flow, der Datensätze erstellt, Datensätze aktualisiert und dann weitere Datensätze erstellt, wie im nächsten Flow auf der rechten Seite dargestellt.

Wenn in diesem Szenario die ersten beiden Elemente erfolgreich sind und das letzte fehlschlägt, werden diese Datensätze weiterhin durch die ersten beiden DML-Vorgänge erstellt und aktualisiert, während das dritte nicht der Fall ist.

Mithilfe des Elements "Datensätze zurücksetzen" können Sie sicherstellen, dass die gesamte Transaktion zurückgesetzt wird, wenn alle drei Vorgänge gleichzeitig ausgeführt werden müssen – wie im letzten Flow auf der linken Seite zu sehen.

Weitere Details finden Sie unter Flows in Transaktionen und Flow-Massenverarbeitung in Transaktionen. Im Abschnitt "Automatisiert" von Salesforce Well-Architected wird dies auch unter "Datenverarbeitung" ausführlicher erläutert.

Ihre Fähigkeit, die Transaktion über eine LWC zu steuern, hängt von den zugrunde liegenden Services ab, die LWC zum Ausführen seiner Vorgänge verwendet. Wenn Sie die Basiskomponente "Lightning-Datensatzform" verwenden, wird der zugrunde liegende Vorgang (Erstellen oder Aktualisieren des Datensatzes) in einer eigenständigen Transaktion ausgeführt, sobald das Formular gesendet wird.

Im Allgemeinen gelten die folgenden Regeln:

• Jeder Benutzeroberflächen-API-Aufruf wird in eine eigene Transaktion isoliert.
• Wenn Sie mehrere Vorgänge innerhalb einer einzelnen Transaktion ausführen müssen, senden Sie die Eingaben an eine serverseitige Technologie, beispielsweise ein Apex-Steuerfeld oder einen Flow. Es gelten die regulären Transaktionsregeln für diese Technologie.

Flow, OmniStudio und LWC unterstützen Plattformereignisse (für ereignisgesteuerte Architektur) und API-Integrationen. Neben benutzerdefiniertem Apex Code unterstützen Flow und OmniStudio deklarative Mechanismen zum Integrieren einer API.

Wenn Sie eine Verbindung mit einer MuleSoft-API oder einem RPA-Bot herstellen müssen, verwenden Sie MuleSoft-Services. Dadurch wird ein externer Service generiert.

-APIs und RPA-Bots

Wenn die API über ein OpenAPI-Schema verfügt, erstellen Sie einen externen Service.

-Externe Integrationen in APIs mit OpenAPI-Schemas

Verwenden Sie andernfalls die HTTP-Callout-Funktion in Flow oder HTTP-Aktion in OmniStudio. Der HTTP-Callout von Flow wird von externen Services unterstützt.

Externe Integrationen über HTTP

OmniStudio verfügt über einen umfangreichen Satz an Integrationsfunktionen, die externe Systeme mit Integrationsverfahren aufrufen und die Daten mit der Datenzuordnung umwandeln können. (Weitere Informationen finden Sie unter Objektauswirkung)

Unabhängig davon, ob Sie ihn mit benutzerdefiniertem Apex oder einem externen Service implementieren, ist ein Callout ein Callout. Folgendes müssen Sie wissen.

1. Ein Callout kann lange dauern.
2. Wenn ein Callout synchron ausgeführt wird, wird er ausgeführt, während eine Datenbanktransaktion geöffnet ist.
3. Salesforce lässt Sie eine Datenbanktransaktion nicht offen, wenn Datenbankvorgänge ausstehen.

Die Haupteinschränkung, die Sie beachten sollten, besteht in der Gefahr sogenannter schmutziger Transaktionen, bei denen Sie einen Erstellungs-, Aktualisierungs- oder Löschvorgang ausführen und dann in derselben Transaktion einen Callout ausführen. Dieses Muster ist aufgrund von Überlegung Nr. 3 oben nicht zulässig, was natürlich aufgrund von Überlegung Nr. 1 und 2 vorhanden ist.

In Flow können Sie diese Einschränkung umgehen, indem Sie die Transaktion unterbrechen. Denken Sie daran, dass Bildschirme und lokale Aktionen den Browserkontext wieder einführen, wodurch die Transaktion unterbrochen wird. Obwohl Sie beim Arbeiten mit externen Callouts Bildschirme und lokale Aktionen verwenden könnten, wird empfohlen, die Transaktionssteuerung in den aufrufbaren erweiterten Einstellungen zu aktivieren. Die Transaktionssteuerung ist eine Funktion aufrufbarer Aktionen, mit der Sie die Transaktion automatisch beenden können, bevor ein Callout erfolgt. Sie können die Transaktionssteuerung aktivieren, indem Sie im Abschnitt "Erweitert" einer aufgerufenen Aktion Immer eine neue Transaktion starten auswählen.

Ausführlichere Anleitungen zu Apex Callouts, externen Services und Datenintegrationsfunktionen im Allgemeinen finden Sie im Architektenhandbuch zur Datenintegration mit Salesforce.

Dynamische Formulare unterstützen die Wiederverwendung nicht. Jedes dynamische Formular ist mit einer bestimmten Lightning-Datensatzseite für ein bestimmtes Objekt verknüpft (Sie können diese Lightning-Datensatzseite jedoch mehreren Anwendungen, Profilen usw. zuweisen).

Ähnlich wie Sie Bibliotheken, Dienstprogramme und Komponenten schreiben können, die für die Verwendung in mehreren anderen Komponenten vorgesehen sind, können Sie beim Erstellen von Flows mit der Leistungsfähigkeit von Subflows ähnliche Designmuster anwenden. Speichern Sie Ihre Flows in kleineren, modulareren Buckets und rufen Sie sie dann mithilfe des Subflow-Elements aus anderen Flows auf. Wenn Ihr Design dies erfordert, können Sie einen Flow erstellen, der für sich steht und als Subflow eines anderen nützlich ist.

OmniStudio ist von Natur aus auf Modularität ausgelegt. Datenzuordnungen, OmniScripts, FlexCards und Integrationsverfahren werden unabhängig voneinander erstellt und können austauschbar verwendet werden. Darüber hinaus können FlexCards als LWC-Komponenten erstellt werden, die in andere LWCs, OmniScripts, Datensatzseiten und Experience Cloud-Sites eingebettet werden können.

Bildschirm-Flows, OmniScripts und Lightning-Webkomponenten können für die Wiederverwendung erstellt und an verschiedenen Orten eingebettet werden, einschließlich externer Sites und Lightning Out-Anwendungen. Wenn Sie Ihre Lösungen so gestalten, dass sie komposibel sind, erhalten Sie zusätzliche Vorteile wie Anpassungsfähigkeit und Stabilität.

Alle Technologien, die zum Erstellen oder Aktualisieren eines Datensatzes verwendet werden, halten sich an die Validierung auf Systemebene – unabhängig davon, ob es sich um klassische Validierungsregeln oder eine in einen Apex-Auslöser integrierte benutzerdefinierte Validierung handelt. Unabhängig davon, welche Technologie Sie zum Ausführen einer Datensatzänderung verwenden, wird jede Änderung durch den Speicherauftrag ausgeführt. Das bedeutet, dass die Datensatzänderung zusätzlich zu Validierungsregeln durch eine beliebige Anzahl von Flows vor oder nach dem Speichern, vor oder nach Auslösern, Eskalationsregeln, Zuweisungsregeln usw. verarbeitet wird. Falls Sie dies noch nicht getan haben, stellen Sie sicher, dass Sie ein Lesezeichen setzen und sich mit der Apex-Ausführungsreihenfolge vertraut machen.

• Verfügt Ihr Formular über zusätzliche Anforderungen, die über die Validierung auf Systemebene hinausgehen?
• Müssen Sie festlegen, dass Felder im Formular dynamisch als Pflichtfelder oder schreibgeschützt festgelegt werden?

Eingaben in einem Flow-Bildschirm oder OmniScript-Schritt sind naturgemäß nicht gebunden, sodass das Formular selbst nicht nativ an die Validierung auf Systemebene gebunden ist, die einem bestimmten Objekt zugeordnet ist. Unabhängig davon, welche Werte Sie zum Erstellen oder Aktualisieren von Datensätzen verwenden, werden sie jedoch durch die Speicherreihenfolge verarbeitet, d. h., sie durchlaufen die Validierung auf Systemebene des Objekts. Beachten Sie jedoch, dass nicht alle Bildschirm-Flow-Komponenten die Eingabevalidierung unterstützen. Ab der Version Summer '24 sind die verbleibenden Bildschirmkomponenten, die die Eingabevalidierung nicht unterstützen, Optionsfelder, Auswahlliste, Mehrfachauswahlliste, Kontrollkästchengruppe und Auswahlsuche.

Genau wie Seitenlayouts können Sie mit dynamischen Formularen die Erforderlichkeit und den schreibgeschützten Status auf Seitenebene festlegen. Einstellungen auf Systemebene können jedoch nicht überschrieben werden.

Flow bietet Flexibilität bei der Anpassung der Validierung für die Eingaben eines Formulars. Während einige Überprüfungen im Client durchgeführt werden (beispielsweise das Kennzeichnen fehlender Pflichtfelder oder inkompatibler Werte), verhindert keine der clientseitigen Validierungen, dass der Benutzer versucht, zu navigieren. Die eigentliche Validierung erfolgt auf dem Server. Wenn ein Benutzer auf Weiter klickt, sendet Flow die Eingaben zur Validierung an den Server. Wenn Eingaben als ungültig zurückgegeben werden, wird die Navigation blockiert und der entsprechende Fehler wird angezeigt. Der Server validiert die Eingaben, indem er Folgendes überprüft:

1. Die Anforderungseinstellung der Eingabe oder ob der eingegebene Wert mit dem zugrunde liegenden Datentyp kompatibel ist.
2. Benutzerdefinierte Validierung für diese Eingabe: Verschiedene Standardkomponenten (Kontrollkästchen, Währung, Datum, Datum/Uhrzeit, langer Textbereich, Zahl, Kennwort und Text) unterstützen die benutzerdefinierte Validierung pro Bildschirm. Geben Sie einen booleschen Formelausdruck und eine Fehlermeldung an, die angezeigt werden sollen, wenn der Formelausdruck nicht erfüllt ist.
3. Benutzerdefinierte Validierung für die zugrunde liegende Komponente: Wenn Sie eine benutzerdefinierte LWC für einen Flow erstellen, fügen Sie der Methode validate() Ihren eigenen Validierungscode hinzu.

OmniStudio bietet umfangreiche Fehler- und Validierungsverarbeitung über die Aktion "Fehler festlegen" in Kombination mit "Bedingte Ansichten" und der Komponente "Messaging".

Auf der LWC-Seite führen die meisten Basiskomponenten ihre eigenen clientseitigen Validierungen durch. Beispielsweise berücksichtigt Lightning-Datensatzform die Systemebene, nicht jedoch die Seitenebene. Für Ihre benutzerdefinierten Komponenten können Sie Build Your Own Validierungsmechanismen erstellen.

Felder, für die Benutzer Daten eingeben müssen, sollten frühzeitig in Ihren Formularen angezeigt werden. Validieren Sie Benutzereingaben nach Möglichkeit auf Client-Seite, bevor Formulare gesendet werden. Weitere bewährte Vorgehensweisen zur Optimierung Ihrer Formulare finden Sie in der Formularanleitung unter Salesforce Well-Architected – Engaging.

Sicherheit ist im Allgemeinen ein komplexes Thema. Beim Erstellen von Formularen gibt es eine Reihe von Überlegungen, über die Sie möglicherweise noch nicht einmal nachgedacht haben. Auf der grundlegenden Ebene sollten Sie sicherstellen, dass das Formular im richtigen Kontext ausgeführt wird und dass die Benutzer über die Berechtigungen verfügen, die sie für die Arbeit mit den zugrunde liegenden Daten benötigen. Darüber hinaus können Sie jedoch auch zusätzliche Maßnahmen ergreifen, um potenziell bösartigen Code oder URLs aus Rich-Text-Feldern zu entfernen, zu verhindern, dass bestimmte Benutzer überhaupt auf das Formular zugreifen können, oder Einschränkungen hinsichtlich der Arten von Stellen festzulegen, an denen Administratoren das Formular in Zukunft potenziell einbetten können. Dokumentieren Sie Ihre Sicherheitsanforderungen sorgfältig, bevor Sie ein Tool auswählen. Die Salesforce Well-Architected Security Policy Template enthält Richtlinien für diese Art von Dokumentation.

• Soll das Formular den Zugriff des Benutzers überprüfen, bevor bestimmte Vorgänge ausgeführt werden?
• Sollten Sie Benutzereingaben bereinigen?
• Möchten Sie steuern, wer auf das Formular zugreifen kann?
• Möchten Sie steuern, wo das Formular eingebettet werden kann?

Wenn etwas im Benutzerkontext ausgeführt wird, erzwingt Salesforce eine Reihe von Zugriffsprüfungen, einschließlich der Überprüfung der Feldebenensicherheit, der CRUD-Berechtigungen und des Datensatzzugriffs auf der Grundlage der Freigaberegeln Ihrer Organisation. Benutzer können also beispielsweise nur dann ein Formular zur Kundenvorgangsaktualisierung ausführen, wenn sie über die Möglichkeit zum Aktualisieren von Kundenvorgängen, die entsprechende Feldebenensicherheit und Zugriff auf den betreffenden Datensatz verfügen. Was geschieht jedoch, wenn Benutzer einen bestimmten Vorgang ausführen können sollen, wenn sie Ihr Formular verwenden, jedoch nicht über ein anderes Formular oder eine andere Interaktion? Hier kommt der Systemkontext ins Spiel.

Der Systemkontext ist eine Möglichkeit, die Berechtigungen des aktuellen Benutzers für die Dauer der Sitzung zu erhöhen, sodass der Benutzer beispielsweise den Zugriff "Aktualisieren" auf das Kundenvorgangsobjekt nicht benötigt, um Ihr Formular zur Kundenvorgangsaktualisierung erfolgreich auszufüllen. Dies ist besonders für nicht authentifizierte Communities nützlich. Statt Gastbenutzern potenziell gefährliche Funktionen zu gewähren, legen Sie fest, dass Ihr Formular im Systemkontext ausgeführt wird.

Natürlich ist der Systemkontext ein zweischneidiges Schwert und Sie sollten es nur bei Bedarf verwenden. Wenn ein Formular im Systemkontext ausgeführt wird, umgeht jeder einzelne CRUD-Vorgang die Objekt- und Feldebenensicherheit und -freigabe und nicht nur den spezifischen Vorgang, der Ihnen wichtig ist. Beachten Sie auch, dass der Systemkontext keine Auswirkungen darauf hat, wer Salesforce als Akteur betrachtet – der Name, der im Feld "Zuletzt geändert von" angezeigt wird. Für jeden Vorgang, den Ihr Formular ausführt, beispielsweise die Kundenvorgangsaktualisierung, ist der Akteur der aktuelle Benutzer, selbst wenn das Formular in einem anderen Kontext ausgeführt wird.

Dynamische Formulare, OmniScripts und Lightning-Webkomponenten werden immer im Benutzerkontext ausgeführt und es gibt keine Möglichkeit, dieses Verhalten zu überschreiben.

Bildschirm-Flows werden standardmäßig im Benutzerkontext ausgeführt. Sie können sie jedoch so festlegen, dass sie im Systemkontext ausgeführt werden. Sie können auswählen, ob der Flow Zugriff auf alle Daten erteilen soll oder ob er weiterhin Zugriff auf Datensatzebene wie die Freigabe erzwingt.

• Wenn Sie eine Lightning-Komponente in einen Flow einbetten, der im Systemkontext ausgeführt wird, überschreibt der Flow den Kontext der Komponente nicht. Wenn Sie Benutzerzugriffsprüfungen umgehen müssen, sollten Sie den Flow verwenden, um diese Vorgänge auszuführen und die entsprechenden Daten in die Lightning-Komponente oder aus ihr heraus zu übergeben. Einige vorkonfigurierte Komponenten (z. B. "Nachschlagen") können nicht im Systemkontext verwendet werden.
• Wenn Ihr Flow Apex-Aktionen aufruft, gibt es noch einige weitere Nuancen zu verstehen. Wenn die Apex-Klasse auf "übernommene Freigabe" festgelegt ist, wird sie im Systemkontext mit "Freigabe" ausgeführt, unabhängig davon, auf welche Einstellung der Flow festgelegt ist. Wenn die Klasse keine explizite Freigabedeklaration aufweist, wird sie im Systemkontext ohne Freigabe ausgeführt, unabhängig davon, auf welche Einstellung der Flow festgelegt ist. Wenn die Klasse auf with sharing oder without sharing festgelegt ist, wird der Kontext des Flows überschrieben.

Abfragen von Datensätzen im Systemkontext mit Experience Cloud-Sites:

Wenn Sie einen Flow im Systemkontext auf einer Experience Cloud-Site ausführen, insbesondere nicht authentifiziert, sollten Sie nur bestimmte Felder in Ihren Elementen vom Typ "Datensätze abrufen" speichern. Wenn Sie mit Flow arbeiten und die Ergebnisse eines Elements vom Typ "Datensätze abrufen" an einen Subflow, eine aufrufbare Aktion oder eine Lightning-Komponente übergeben, können alle Felder aus diesem Objekt über die Entwicklertools des Browsers überprüft werden. Dadurch werden möglicherweise Felder für Benutzer Ihrer Experience Cloud-Site verfügbar, die Sie möglicherweise nicht beabsichtigen. Durch die Angabe spezifischer Felder in Ihren Elementen vom Typ "Datensätze abrufen" können Sie sicherstellen, dass auch bei aktiviertem Systemkontext nur die richtigen Felder angezeigt werden.

Beachten Sie, dass die OmniScript-Logik clientseitig ausgeführt wird. Dadurch können Angreifer die erwartete Ausführung eines OmniScripts ändern und Antworten auf Aufrufe von Integrationsverfahren, Datenzuordnungen und Apex-Methoden mit den Entwicklertools des Browsers anzeigen. Wenn Sie OmniScript verwenden, sollten Sie nach Möglichkeit Geschäftslogik serverseitig ausführen und Eingabevalidierungsregeln für alle Apex-Methoden implementieren, die über die Anmerkung @InvocableMethod verfügbar gemacht werden.

Desinfektionseingaben:

Wenn Sie Ihre Organisation vor schlechten Akteuren schützen möchten, sollten Sie auch die Eingabebereinigung in Betracht ziehen. Angenommen, Sie verfügen über eine Eingabe in einem öffentlich zugänglichen Formular, die einem Rich-Text-Feld in Ihrer Organisation zugeordnet werden könnte. Möglicherweise sollten Sie eine Automatisierung in Betracht ziehen, die HTML entfernt, die schädliche URLs verbergen könnte. Im Allgemeinen ist es nicht ideal, diese Bereinigung auf Formularebene zu implementieren, da Sie eine beliebige Anzahl von Quellen in diese Felder schreiben lassen könnten. Es wird empfohlen, einen Flow zur schnellen Feldaktualisierung (Vor dem Speichern) zu erstellen oder einen vorhandenen Apex-Auslöser für das Objekt zu verwenden, um potenzielle HTML-Elemente, die in das Formular eingegeben werden, zu entfernen oder zu ändern.

Bewährte Vorgehensweisen:

• Lassen Sie Flows im Standardkontext ausgeführt werden, es sei denn, Sie müssen den Zugriff des aktuellen Benutzers für einen bestimmten Vorgang erhöhen.
• Vermeiden Sie das Ausführen von Flows im Systemkontext für Gastbenutzer aus Sicherheitsgründen. Erstellen Sie stattdessen Berechtigungssätze mit eingeschränktem Feldzugriff, die dem Gastbenutzerprofil der Experience Cloud-Site zugewiesen sind.
• Wenn Sie Datensätze in vom Systemkontext ausgeführten Flows auf Experience Cloud-Sites abfragen, speichern Sie nur die Felder, die Sie in Ihrem Element "Datensätze abrufen" oder "Aufrufbare Aktionen" benötigen.
• Wenn ein Flow eine Vielzahl von Vorgängen ausführt und nicht alle einen erhöhten Zugriff erfordern, verwenden Sie Subflows, um die Vorgänge zu isolieren, die im Systemkontext ausgeführt werden sollten.
• Wenn Sie planen, ein Formular in eine externe Webseite einzubetten, sollten Sie ggf. Benutzereingaben bereinigen, um HTML mithilfe eines Flows für schnelle Feldaktualisierungen oder Apex Triggers zu entfernen, wenn sie schließlich Rich Text-Feldern zugeordnet werden, um potenzielle Phishing-Angriffe durch schlechte Akteure zu verhindern.

• OmniScripts, FlexCards und LWCs werden standardmäßig im Benutzerkontext ausgeführt.
• LWCs werden standardmäßig im Benutzerkontext ausgeführt und Flows werden im Benutzerkontext ausgeführt. Sie können dies jedoch in einem Apex-Steuerfeld überschreiben.
• Über die Benutzeroberflächen-API ausgeführte Vorgänge werden im Benutzerkontext ausgeführt.
• Über ein Apex-Steuerfeld ausgeführte Vorgänge hängen von dieser Klasse ab. Wenn Sie diese Vorgänge im Systemmodus ausführen möchten, legen Sie die Apex-Klasse mit oder ohne Freigabe fest.

Wenn Sie steuern müssen, wer auf Ihr Formular zugreifen kann, können Sie oft den Container anzeigen, in den das Formular eingebettet ist. Beispielsweise können Sie Lightning-Seiten zuweisen, die für bestimmte Anwendungen, Datensatztypen oder Profile verfügbar sind. Wenn bestimmte Eingaben in Ihrem Formular vertraulich sind, verwenden Sie Sichtbarkeitsregeln, um weiter zu steuern, was wem angezeigt wird. Diese Funktion gilt für dynamische Formulare und Bildschirm-Flows.

Sie können einen Flow einschränken auf bestimmte Profile oder Berechtigungssätze, ähnlich wie eine Apex Klasse oder Visualforce Seite. Flows sind standardmäßig uneingeschränkt. Das bedeutet, dass jeder Benutzer mit der Benutzerberechtigung "Flows ausführen" sie ausführen kann.

Wenn Sie OmniStudio verwenden, können Sie eine Berechtigungsprüfung für Apex-Klassen konfigurieren, um sicherzustellen, dass Benutzer expliziten Zugriff auf die Apex-Klasse benötigen, die die über eine OmniScript-, FlexCard-, Classic Card- oder REST-API aufgerufene Remote-Aktion verwaltet.

• Hinweis: Berechtigungsprüfungen für Apex-Klassen sind für neu erstellte Skripts standardmäßig aktiviert. Sie müssen jedoch für vorhandene Skripts manuell aktiviert werden.
• Beachten Sie außerdem, dass die Apex-Klassenberechtigungsprüfungen nur für Apex-Klassen gelten. Es wird empfohlen, Berechtigungen auf Profilebene auch für Integrationsverfahren und Datenzuordnungen festzulegen.

Weitere Details und bewährte Vorgehensweisen zu Gastbenutzerberechtigungen finden Sie unter:

• Bewährte Vorgehensweisen für den Gastbenutzerzugriff auf Datensätze
• Entwickeln sicherer Sites: Authentifizierte Benutzer und Gastbenutzer

Bewährte Vorgehensweisen:

• Wenn Sie Gastbenutzern einen Flow bereitstellen, erteilen Sie dem Gastbenutzerprofil nur Zugriff auf die benötigten Flows. Obwohl es möglich ist, dem Gastbenutzerprofil "Flows ausführen" hinzuzufügen, wird dies als riskante Vorgehensweise erachtet.
• Seien Sie besonders vorsichtig bei Flows, die im Systemkontext funktionieren. Es wird dringend empfohlen, diese Flows auf eine bestimmte Gruppe von Benutzern zu beschränken, da sie weniger Überprüfungen und Abwägungen zum Schutz Ihrer Daten aufweisen.
• Stellen Sie sicher, dass jedes OmniScript, das Apex in einer Gastbenutzer-Community ausführt, in der Apex Klassendefinition "with sharing" aufweist.
• _ Weisen Sie in Ihrem Gastbenutzerprofil nur die Apex-Klassen zu, die Gastbenutzer aufrufen können sollen. Andernfalls besteht die Gefahr, dass Gastbenutzern versehentlich zusätzliche Geschäftslogik angezeigt wird._

Bei LWCs können Sie die Berechtigungszuweisungen des aktuellen Benutzers überprüfen, um zu überprüfen, ob er über eine bestimmte Standard- oder benutzerdefinierte Berechtigung verfügt. Direkt aus JavaScript können Sie Salesforce-Berechtigungen aus den Umfangsmodulen @salesforce/userPermission und @salesforce/customPermission importieren. Alternativ können Sie Apex verwenden, um dasselbe zu überprüfen.

Lightning-Webkomponenten sind an einem bestimmten Ort nur verfügbar, wenn sie als gültiges Ziel hinzugefügt wurden. Beispielsweise können Sie eine Komponente auf Datensatzseiten und nicht als Dienstprogrammleistenelement verfügbar machen.

Sobald ein Bildschirm-Flow aktiviert ist, ist er an allen Orten verfügbar, an denen Bildschirm-Flows unterstützt werden, unabhängig davon, ob er überall verfügbar sein soll oder nicht. Flow Builder unterstützt jedoch mehrere Flow-Typen mit Bildschirmen. Der Brot-und-Butter-Typ ist "Bildschirm-Flow", es gibt jedoch einige andere spezialisierte Typen, die auf bestimmte Standorte beschränkt sind. Beispielsweise unterstützt die Field Service Mobile-Anwendung nur Field Service Mobile-Flows – Sie haben es erraten. Dasselbe gilt für Kontaktanforderungs-Flows, die nur in Experience Cloud unterstützt werden.

Unabhängig vom Flow-Typ hat die Person, die den Flow erstellt, keine Kontrolle darüber, wo der Flow eingebettet werden kann. Der Flow ist an allen für diesen Flow-Typ unterstützten Standorten verfügbar.

Wenn Sie Salesforce-Branchen verwenden, gibt es in Bezug auf OmniScript einen kleinen Vorbehalt: Obwohl Sie kein Ziel für ein OmniScript selbst angeben können, können Sie eines für die FlexCards angeben, die Sie möglicherweise darin einbetten möchten.

Statische Formen gehören der Vergangenheit an. Heute geht es darum, das Formular mit den richtigen Eigenschaften und Werten für diesen Benutzer dynamisch zu aktualisieren, diesmal an diesem Ort. Lassen Sie uns darüber sprechen, was in diesem Sinne für die Formularerstellungstools von Salesforce möglich ist.

• Welche Arten von Interaktionen oder Bedingungen sollten dynamische Antworten in Ihrem Formular auslösen?
• Müssen Sie Vorgänge außerhalb des Bildschirms während des Ausfüllens Ihres Formulars im Hintergrund ausführen?
• Müssen Sie Felder als sichtbar, erforderlich, schreibgeschützt oder deaktiviert festlegen oder die Formatierung anhand von Formulareingaben ändern?

Dank reaktiver Bildschirme ist die Bildschirm-Flow-Interaktivität nun Realität. Durch die Reaktivität können einzelne Komponenten auf einem Flow-Bildschirm miteinander kommunizieren, wodurch Bildschirm-Flows unendlich leistungsfähiger werden.

Ausführen von Off-Screen-Datenvorgängen: Bildschirm-Flows bieten einen deklarativen Ansatz zum Abrufen von Daten auf demselben Bildschirm über Bildschirmaktionen. Mit Bildschirmaktionen können Sie automatisch gestartete Flows bei jeder Änderung auf dem Bildschirm oder wenn ein Benutzer auf eine Komponente vom Typ "Aktionsschaltfläche" klickt, auslösen. Anschließend können Sie die Ergebnisse dieser automatisch gestarteten Flows demselben Bildschirm zuordnen, sodass Benutzer nicht mehr zu einem anderen Bildschirm navigieren müssen.

LWC bietet eine umfassende Palette von Wire-Adaptern, mit denen Sie auf Salesforce-Daten zugreifen können, um Daten in den Komponenten Ihres Formulars dynamisch auszufüllen, und ermöglicht es Entwicklern, Datensätze über Apex-Steuerfelder zu aktualisieren, zu löschen und zu erstellen.

Datenvorgänge für Lightning-Webkomponenten außerhalb des Bildschirms

Sichtbarkeit: Die Sichtbarkeit kann in allen Formularerstellungstools dynamisch gesteuert werden. Dynamische Formulare, Flow Builder und OmniStudio beheben dies mit Komponentensichtbarkeitsfunktionen. Damit können Sie Felder deklarativ anhand anderer Werte im Formular anzeigen oder ausblenden oder festlegen, ob sich der Benutzer auf einem Mobilgerät befindet.

• Mit dynamischen Formularen kann die Sichtbarkeit anhand von Datensatzfeldwerten, über Nachschlagefelder zugeordneten Datensätzen und Formfaktoren gesteuert werden.
• Mit Flow können Sie eine Sichtbarkeitsregel auf anderen Eingaben auf dem Bildschirm sowie anderen Ressourcen basieren, die zuvor im Flow ausgefüllt wurden, beispielsweise Formeln oder Werte aus anderen Datensätzen.
  • Gerätebasierte Regeln: Es ist nicht von Anfang an offensichtlich. Sie können jedoch eine Formel verwenden, um ein bestimmtes Feld anzuzeigen oder auszublenden, wenn sich der Benutzer auf einem Mobilgerät befindet. Schreiben Sie eine Flow-Formel, die den Wert der globalen Variablen $User.UIThemeDisplayed überprüft. Wenn der Wert Theme4t lautet, befindet sich der Benutzer in der mobilen Salesforce-Anwendung.
  • Auswerten anderer Ressourcen: Manuelle Variablen- und Formelverweise werden nur auf dem Server ausgewertet. Welchen Wert diese Ressource also beim ersten Rendern des Bildschirms hat, ist der Wert, den sie hat, bis Sie zu einem anderen Bildschirm navigieren. Bei der Navigation sendet die Flow-Laufzeit eine Anforderung an das Flow-Modul (den Server) und erhält die neuesten Werte der manuellen Variablen und Formeln zurück. Wenn Sie erwarten, dass Ihre Sichtbarkeitsregel aktualisiert wird, während der Benutzer einen einzelnen Bildschirm durchläuft (z. B. onblur), stellen Sie sicher, dass Sie nur auf Werte aus den anderen Komponenten auf dem Bildschirm verweisen.
• Mit OmniStudio können Sie Komponenten bedingt anzeigen oder ausblenden, indem Sie eine Eigenschaft für bedingte Ansicht einrichten. Sie können jedoch nicht mehr als eine Eigenschaft vom Typ "Bedingte Ansicht" für eine Eingabe hinzufügen.

Bedingte Eingabezustände: Wenn Sie andere Eigenschaften dynamisch steuern müssen, beispielsweise ob ein Feld erforderlich, deaktiviert oder schreibgeschützt ist, haben Sie einige Möglichkeiten. Erwartungsgemäß können Sie mit LWC Ihren Eingabestatus vollständig und reaktiv steuern. Mit reaktiven Bildschirm-Flow-Komponenten können Sie Komponentenattribute wie "Schreibgeschützt", "Deaktiviert" und "Erforderlich" für Standardkomponenten, die sie unterstützen, dynamisch steuern, während OmniStudio das gesamte Spektrum komponentenspezifischer Attribute unterstützt. Wenn Sie aufgrund Ihrer Anforderungen Flow benötigen und die Komponente einen bestimmten Attributstatus nicht unterstützt, können Sie eine einbettbare LWC erstellen, um einen dynamischen Eingabestatus zu erreichen.

Wenn Sie andere Eigenschaften dynamisch steuern müssen, beispielsweise ob ein Feld erforderlich oder schreibgeschützt ist, sollten Sie kurzfristig am besten LWC verwenden, wo Sie die volle Kontrolle haben. Dies gilt insbesondere, wenn Sie maßgeschneiderte Anforderungen für die Handhabung von onblur oder onclick haben.

Reaktive LWCs in Bildschirm-Flows: Wenn Sie LWCs erstellen, die auf andere Komponenten in einem Bildschirm-Flow reagieren und sie ändern können, lesen Sie diesen Leitfaden zu bewährten Vorgehensweisen für Bildschirm-Flows, um sicherzustellen, dass Ihre Komponenten gut in das Flow-Laufzeitmodul integriert werden und wie erwartet in der Zukunft funktionieren.

Nun für benutzerdefinierte Ereignisse. Wenn einige Ihrer Eingaben oder das gesamte Formular mit etwas anderem auf der Seite kommunizieren müssen, ist LWC die einzige Option.

• Verwenden Sie die Benutzeroberfläche CustomEvent, um innerhalb derselben DOM-Struktur zu kommunizieren.
• Verwenden Sie zum DOM-übergreifenden Kommunizieren Lightning Messaging Service.
• Wenn Lightning Messaging Service für Ihren Ziel-Container nicht unterstützt wird, verwenden Sie das Pub/Sub-Modul.

• Weitere Details finden Sie im Lightning Web Components Dev Guide unter Communicate with Events and Communicate Across the DOM (Mit Ereignissen kommunizieren).
• Konsultieren Sie für OmniStudio "Mit OmniScript kommunizieren" aus einer Lightning-Webkomponente.

Um die beste Benutzererfahrung zu bieten, müssen Sie sicherstellen, dass der Stil Ihres Formulars mit dem Rest der Anwendung oder Site, auf der es eingebettet ist, konsistent ist. Dies kann alles bedeuten, von der Verwendung der von Salesforce bereitgestellten Standardvorlagen bis hin zur Erstellung von benutzerdefiniertem CSS, das jedes Pixel im Design vollständig nutzt, um ein schärferes Erscheinungsbild zu bieten.

• Wie anspruchsvoll ist Ihr gewünschter Stil und CSS?
• Benötigen Sie einen benutzerdefinierten, pixelgenauen Stil oder sind Sie mit Standardthemen einverstanden?

FlexCards ist das einzige in diesem Handbuch behandelte Produkt, mit dem Sie den Stil und das Layout der Benutzeroberfläche, die Sie im Tool erstellen, direkt deklarativ steuern können – unabhängig davon, ob es sich dabei um Ränder und Innenabstände, Typografie, Farben usw. handelt.

Dynamische Formulare und Flows berücksichtigen deklarative Themenfunktionen. Wenn Sie mehr Kontrolle darüber benötigen, was Salesforce-Themen, Erfahrungsgenerator-Brandingsätze oder LWR Experience Cloud-Sites unterstützen, sollten Sie eine programmgesteuerte Lösung in Betracht ziehen.

Für Teams, die mit CSS vertraut sind, haben Sie mehrere Möglichkeiten:

• Flows und Lightning-Webkomponenten übernehmen Standarddesigntoken.
• OmniScripts und FlexCards unterstützen ein anpassbares Designsystem: Newport.
• Mit LWC können Sie Ihre eigenen Komponenten schreiben und HTML und CSS vollständig steuern.

Es wird empfohlen, nach Möglichkeit Themen und Designsysteme zu verwenden, damit Ihr Erscheinungsbild einheitlich auf alle Ihre Inhalte angewendet wird.

Erinnerung: Lightning-Komponenten können in Flows eingebettet werden. Wenn Sie also das Erscheinungsbild Ihres Formulars pixelgenau steuern möchten, aber die anderen Vorteile von Flows wie das Navigationsmodell nutzen möchten, können Sie beides optimal nutzen. Das gleiche Prinzip gilt für OmniScripts und FlexCards.

Die Auswahl eines guten Layouts ist entscheidend für das Entwerfen optimierter Formulare, die eine schnelle und effiziente Dateneingabe ermöglichen und die Datenintegrität erhöhen. Weitere Informationen zu diesem Thema finden Sie unter Salesforce Well-Architected – Forms.

• Wie können Sie das Layout Ihres Formulars verwenden, um die Benutzererfahrung zu optimieren?
• Wie können Sie Ihren Benutzern vorhandene Daten so präsentieren, dass sie leichter neue Daten in Ihre Formulare eingeben können?

Dynamische Formulare unterstützen zweispaltige Layouts und können in einzelne Abschnitte mit Feldern unterteilt werden. Diese Abschnitte können in Komponenten wie Registerkarten und Akkordeons platziert werden, um benutzerfreundliche und organisierte Layouts zu erstellen.

Flows können optional mithilfe der Komponente "Abschnitt" dargestellt werden. Mit Abschnitten können Sie bis zu vier Spalten und beliebig viele Abschnitte auf dem Flow-Bildschirm hinzufügen. Die Komponente reagiert auch auf die Bildschirmbreite, sodass sie auf kleineren Bildschirmen verwendet werden kann. Schließlich können Sie damit die bedingte Sichtbarkeit auf den gesamten Abschnitt anwenden, was die Massenanwendung der Sichtbarkeit auf mehrere Felder innerhalb des Abschnitts vereinfacht. Flow-Abschnitte unterstützen auch Spaltenüberschriften und bieten eine Akkordeon-ähnliche Erfahrung, bei der Benutzer den gesamten Abschnitt durch Klicken auf die Bezeichnung ausblenden können.

OmniScripts verfügen über eine Vielzahl von Layoutoptionen zum Anzeigen von Feldern und Daten. Sie können Datenabschnitte mit bis zu 12 Spalten erstellen, einschließlich bedingt ausblendbarer Akkordeons.

Mit LWC können Sie Lightning-record-[edit|view]-form und das unterstützende Lightning[input|output]-Feld verwenden, um das Layout zu steuern. Die einzigen Layouteinschränkungen stammen aus HTML/CSS. Lightning-record-form berücksichtigt die Abschnittskonfiguration im zugeordneten Seitenlayout. Wenn ein Abschnitt beispielsweise im Seitenlayout zweispaltig ist, ist er in dieser Komponente zweispaltig.

Wenn Benutzer in unterschiedlichen Regionen oder Sprachen auf Ihr Formular zugreifen können, müssen Sie sicherstellen, dass das Tool, das Sie zum Erstellen verwenden, Ihre Lokalisierungsanforderungen erfüllt. Weitere Anleitungen und Empfehlungen finden Sie unter Salesforce Well-Architected – Localization. Insbesondere bei Formularen beinhalten Lokalisierungsanforderungen in der Regel die Übersetzung von Textelementen in andere Sprachen.

• Wird Ihr Formular in mehreren Ländern oder Regionen verwendet?
• Muss der Text in Ihrem Formular in andere Sprachen übersetzt werden?

Wenn Sie Ihre benutzerdefinierten Felder lokalisiert haben, werden diese übersetzten Bezeichnungen in dynamischen Formularen berücksichtigt. Dynamische Formulare berücksichtigen auch benutzerdefinierte Bezeichnungen, die Sie Komponentenbezeichnungen und Attributen im Lightning-Anwendungsgenerator zugewiesen haben.

Mit der leistungsstarken Übersetzungsworkbench unterstützt Flow die Übersetzung von benutzerdefinierten Bezeichnungen für alle standardmäßigen und benutzerdefinierten Bildschirmkomponenten. Sie können die Bezeichnung, den Hilfetext und die Fehlermeldung der folgenden Bildschirmkomponenten lokalisieren: Text, langer Textbereich, Zahl, Währung, Kontrollkästchen, Optionsfelder, Auswahlliste, Mehrfachauswahlliste, Kontrollkästchengruppe, Kennwort, Datum/Uhrzeit.

Für vorkonfigurierte Aktionen wie "E-Mail senden" oder "Bei Chatter posten" gibt es keine integrierte Übersetzungsunterstützung. Es gibt jedoch eine Übergangslösung! Wenn Sie die übersetzten Bezeichnungen mit einer benutzerdefinierten Bezeichnung definieren, können Sie bei der Konfiguration in Flow Builder in der Aktion oder Komponente auf diese benutzerdefinierte Bezeichnung verweisen. Erstellen Sie eine Flow-Formel, die auf die benutzerdefinierte Bezeichnung verweist, und verweisen Sie an den entsprechenden Stellen in Ihrem Flow auf diese Formel.

OmniScripts verwenden benutzerdefinierte Bezeichnungen für Übersetzungen. Lesen Sie diese Hilfedokumentation, um Ihre mehrsprachigen OmniScripts vorzubereiten.

Nun zu LWC. Bestimmte Basiskomponenten übernehmen automatisch Übersetzungen der Felder, Hilfetexte und Validierungsmeldungen des zugeordneten Objekts, wenn sie in der Übersetzungsworkbench konfiguriert wurden (z. B. Lightning-Datensatzform).

Wenn Sie neue übersetzbare Bezeichnungen in Ihren Code einfügen müssen, sind benutzerdefinierte Bezeichnungen immer noch der unbesungene Held. Deklarieren Sie die benötigte benutzerdefinierte Bezeichnung und importieren Sie sie dann aus dem Umfangsmodul @salesforce/label in Ihre Komponente.

Es sind mehrere durchgängige Testautomatisierungstools verfügbar (z. B. Selenium), mit denen Sie simulieren können, wie der Benutzer mit Ihrem Formular interagiert. Sie können diese Tests für jede standardmäßige oder benutzerdefinierte Benutzeroberfläche schreiben, einschließlich Lightning-Seiten und Bildschirm-Flows. Beachten Sie jedoch, dass diese Testtypen die Ausgaben der einzelnen ausgeführten Methoden nicht überprüfen können. Beachten Sie dies, wenn Sie Ihre Anforderungen an die Automatisierung von Benutzeroberflächentests durchdenken.

• Benötigen Sie automatisierte Tests für Ihr Formular?
• Welche Arten von Tests müssen durchgeführt werden?
• Welche Granularitätsstufe benötigen Sie bei Ihren Testautomatisierungen?

Beachten Sie Ihre Anforderungen an die Automatisierung von Benutzeroberflächentests.

Einheitentests ermöglichen eine detailliertere Automatisierung und Validierung, die mit CI/CD-Standardsystemen und -Tools der Branche funktioniert. Dadurch können die Geschäftslogik der Komponenten, ihr JavaScript-Steuerfeld und ihre Ausgaben getestet werden. Wenn Sie ausschließlich Low-Code verwenden, können Sie keine Selbstautorisierungstests durchführen. Salesforce testet jedoch unsere durchgängigen Angebote sorgfältig.

Wenn die Methoden Ihrer Komponente so komplex sind, dass sie einzeln getestet werden sollen, legen Sie die Methoden in dedizierte JavaScript-Dateien fest. Auf diese Weise können Sie sie in eine LWC und in einen Jest-Test mit etwas wie import { sort } from 'c/utils'; importieren.

Unter Benutzeroberflächentestautomatisierung in Salesforce finden Sie einen Vergleich der verschiedenen Optionen zum Erstellen einer durchgängigen Automatisierung in Salesforce. Es werden Überlegungen dazu angestellt, wann Sie eine No-Code-Lösung aus einem ISV verwenden, Build Your Own Custom Test Automation-Lösung erstellen oder ein Open-Source-Test-Framework wie Selenium WebDriver oder WebdriverIO verwenden sollten. Diese Lösungen sind für jede Benutzeroberflächeninteraktion in Salesforce gültig, unabhängig davon, ob es sich um ein dynamisches Formular auf einer Lightning-Seite, einen Bildschirm-Flow auf einer Dienstprogrammleiste oder eine LWC in einem Flow in einer Schnellaktion handelt.

Nachdem Sie Ihr Formular in einer Produktionsumgebung bereitgestellt haben, sollten Sie sicherstellen, dass es effektiv verwendet wird. Abhängig von Ihrem Anwendungsfall kann dies alles bedeuten – von der einfachen Verfolgung der Häufigkeit des Ausfüllens bis hin zur Zeit, die Benutzer damit verbringen, sie auszufüllen, bevor sie ihre Informationen senden. Geben Sie vor der Auswahl eines Tools die KPIs an, die verfolgt werden sollen.

• Müssen Sie die Nutzung Ihres Formulars verfolgen?
• Welche KPIs bestimmen, ob Ihr Formular effektiv verwendet wird?

Wenn Sie die Gesamtnutzung und Akzeptanz Ihres Formulars verfolgen müssen, beginnen Sie mit den Low-Code-Tools. Dynamische Formulare und Bildschirm-Flows können mit vorkonfigurierten benutzerdefinierten Berichtstypen verfolgt werden. Die Berichte zur Bildschirm-Flow-Verfolgung sind jedoch genauer. Wenn Sie die Nutzung einer LWC verfolgen müssen, hängt die vorkonfigurierte Verfügbarkeit davon ab, wo Sie diese LWC verwenden. Wenn sie sich auf einer Lightning-Seite befindet, gilt für Ihre Lightning-Seitennutzung alles, was zum Verfolgen der Lightning-Seitennutzung verfügbar ist. Dasselbe gilt für LWCs, die in Flows eingebettet sind.

Dynamische Formulare selbst können nicht vorkonfiguriert verfolgt werden. Sie können jedoch die Nutzung der übergeordneten Lightning Seite über Lightning Nutzungsobjekte verfolgen. Verwenden Sie zum Verfolgen der Lightning-Standardseiten den benutzerdefinierten Berichtstyp "Benutzer mit Lightning-Nutzungskennzahlen nach Seite". Verwenden Sie für dieselben auf benutzerdefinierten Lightning-Seiten den benutzerdefinierten Berichtstyp "Benutzer mit Lightning-Nutzung nach FlexiPage-Kennzahlen".

Mit Flow können Sie die Akzeptanz Ihres spezifischen Formulars verfolgen (nicht nur die Seite, auf der es sich befindet). Verwenden Sie den Beispiel-Flow-Bericht: Bildschirm-Flows“ zum Beantworten von Fragen wie:

• Wie hoch ist die Abschlussrate für dieses Formular? Wird es gut angenommen?
• Wie lange dauert das Ausfüllen dieses Formulars?
• Auf welchem Bildschirm verbringen Benutzer die meiste Zeit?
• Wie oft navigieren Benutzer rückwärts?
• Wie oft treten Fehler auf?

Wenn der Standardbericht Ihre Anforderungen nicht erfüllt, duplizieren Sie ihn, um Ihre eigenen Änderungen vorzunehmen, oder erstellen Sie Build Your Own von Grund auf neu, indem Sie den Berichtstyp "Bildschirm-Flows" verwenden.

Wenn Sie die paketbasierte OmniScript-Laufzeit verwenden, können Sie den Service "OmniStudio for Vlocity Tracking" verwenden. Dieser Service verfolgt alle Arten von Ereignissen. Beispielsweise können Sie die Zeit verfolgen, die zum Abschließen der Schritte in einem OmniScript benötigt wird, um Prozessverbesserungen zu identifizieren. Sie befindet sich auf der Roadmap des OmniStudio-Teams, um diesen Service in Standard-OmniStudio zu unterstützen.

Wenn Sie dasselbe für eine LWC verfolgen möchten, die nicht in einen Bildschirm-Flow, ein OmniScript oder eine Lightning-Seite eingebettet ist, gibt es keine vorkonfigurierte Option. Mit Apex können Sie eine benutzerdefinierte Lösung erstellen.

Wenn Sie Ihre Lösung in höheren Umgebungen zum Testen oder Bereitstellen in der Produktion bereitstellen müssen, sind Sie möglicherweise daran gewöhnt, dafür Änderungssets oder DevOps Center zu verwenden. Dynamische Formulare, Flows und LWCs werden in diesen Bereitstellungsoptionen vollständig unterstützt. Für OmniStudio ist ein separates Tool erforderlich: IDX Workbench.

• Wie möchten Sie Ihr Formular bereitstellen?
• Wird Ihr Formular an mehrere Salesforce-Organisationen verteilt?

Wenn Sie ein ISV oder Partner sind und planen, ein Paket mit Ihrer Lösung für die Verteilung auf AppExchange zu erstellen, sollten Sie sich zunächst Dynamische Formulare, Flows und LWCs ansehen. OmniStudio unterstützt keine Paketerstellung.

Dieser Leitfaden soll Ihnen helfen, zu verstehen, welche Funktionen und Anpassungsebenen mit dynamischen Formularen, Bildschirm-Flows, OmniStudio und LWC möglich sind. Auf hohem Niveau:

• LWC ist die anpassbarste und robusteste Option zum Erstellen eines Formulars, verfügt jedoch über die wenigsten vorhandenen Leitplanken. Es liegt an Ihnen, eine Komponente so zu erstellen, dass Sicherheit und Skalierbarkeit gewährleistet sind.
• Dynamische Formulare sind am wenigsten flexibel, es gibt jedoch viel weniger Möglichkeiten für Fehltritte.
• Flow und OmniStudio befinden sich irgendwo in der Mitte – leistungsfähiger als dynamische Formulare, aber nicht ganz auf LWC-Ebene. Sie verfügen über weniger Leitplanken als dynamische Formulare, sind jedoch schwerer zu knacken als benutzerdefinierter Code.

Wenn mehrere Tools in die Rechnung passen, wird entschieden, welches Tool für Ihr Team das richtige ist. Andere Architektenentscheidungsleitfäden enthalten zusätzliche Aspekte, die bei dieser Entscheidung berücksichtigt werden sollten.

Auf die Details dieser Aspekte wird hier nicht eingegangen, aber wir werden sie für die spezifischen Tools interpretieren, die dieses Dokument bewertet.

Spezielle Fertigkeiten: Wie viel Fachwissen hat Ihr Team in Bezug auf die Tools, die Sie vergleichen? Wie viele Macher sind mit LWC oder JavaScript vertraut? Wie sieht es mit Machern aus, die Flow Builder-Experten sind oder Interesse daran bekundet haben? Generell sind dynamische Formulare und Flow-Fertigkeiten für eine breitere Population von Personen, die Formulare erstellen, besser erreichbar. Dynamische Formulare sind das deklarativste Tool zum Erstellen von Formularen und werden immer einfacher zu erlernen sein als Flow. Das Flow-Team ist bestrebt, diese Messlatte so niedrig wie möglich zu halten. In Bezug auf die Komplexität befindet sich OmniStudio irgendwo zwischen Flow und LWC und bietet erhebliche Superkräfte beim Erstellen von Formularen.

Zustellungsdelegation: Nur weil einige Ihrer Anforderungen LWC erfordern, bedeutet das nicht, dass Ihre gesamte Lösung mit LWC erstellt werden muss. Überlegen Sie, wie Sie Ihre Lösung modular erstellen können, sodass die Teile, für die LWC erforderlich ist, und die Teile, für die keine LWC erforderlich ist, in einer Low-Code-Lösung erstellt werden. Dadurch wird die Effizienz eines vielfältigen Teams maximiert und sichergestellt, dass jeder Einzelne Probleme löst, die seiner Spezialisierung entsprechen.

Nun zu Flow und LWC. Mit reaktiven Bildschirmkomponenten können Bildschirm-Flow-Komponenten nun auf demselben Bildschirm miteinander kommunizieren und so eine völlig neue Werkzeugkiste für Architekten, Administratoren und Entwickler freischalten. Entwickler können nun zielgerichtete, modulare Komponenten erstellen, die in der gesamten Organisation wiederverwendet werden können, was die Produktivität für alle im Team steigert. Entwickler können sich auf die Lösung neuer Herausforderungen konzentrieren und Zeit sparen, indem sie eine Kombination aus standardmäßigen und benutzerdefinierten Flow-Komponenten verwenden, um eine Formdynamik zu erreichen. Mit reaktiven Komponenten in Flow gab es nie einen günstigeren Zeitpunkt, um Flow und LWC beim Erstellen Ihrer Formulare zu kombinieren.

Wartbarkeit und langfristige Inhaberschaft: Wenn Sie über ein Formular mit mehreren Schritten verfügen, sollten Sie mit Flow oder einer Kombination aus Flow und LWC beginnen. Wenn Sie über ein Low-Code-Team verfügen, das die Lösung verwaltet, sollten Sie überlegen, wie Sie die Lösung für diese Zielgruppe so konfigurierbar und erweiterbar wie möglich gestalten können. Unabhängig davon, welches Tool Sie auswählen, organisieren Sie Ihre Lösung in zusammensetzbare Einheiten, um die Wartungsfähigkeit und Stabilität zu verbessern.

Dynamische Formulare im Lightning-Anwendungsgenerator mit Lightning-Seiten werden künftig empfohlen, um Datensatz-Detailseiten zu konfigurieren. Es ist lange her, dass wir erweiterte Seitenlayouts haben, und dieser Trend wird sich fortsetzen. Folgender Grund:

• Dynamische Formulare sind flexibler. Sie können Felder und Abschnitte direkt im Lightning-Anwendungsgenerator an beliebiger Stelle platzieren, wo Sie Abschnitte, Registerkarten und Akkordeons nutzen können. Wie bei Komponenten auf der Lightning-Seite können Sie die Sichtbarkeit Ihrer Felder und Abschnitte steuern, ohne mehrere Seitenlayouts oder Datensatztypen definieren zu müssen.
• Mit den Komponenten "Akkordeon" und "Registerkarte" können Sie die Anzahl der anfänglich angezeigten Felder einschränken. Raten Sie, was das bedeutet? Schnellere Seitenladezeiten.
• Die Layoutverwaltung mit Lightning-Seiten ist einfacher, da Sie alles über Ihre Seiten im Lightning-Anwendungsgenerator verwalten können – unabhängig davon, ob es sich um den Inhalt der Seite handelt oder welche Benutzer Zugriff auf die Seite haben. Es ist nicht mehr erforderlich, Aktualisierungen an Ihrem Seitenlayout vorzunehmen, um Änderungen an Ihrer Lightning-Seite vorzunehmen. Ganz zu schweigen davon, dass Sie dank der leistungsstarken Sichtbarkeitsregeln nicht mehr mehrere Seiten (oder Seitenlayouts) erstellen müssen, um zu steuern, wer wann welche Felder sieht. Das bedeutet auch, dass Sie Benutzern nur eine Lightning-Seite zuweisen müssen, statt sowohl eine Lightning-Seite als auch ein Seitenlayout zuzuweisen.

Es wird empfohlen, nach Möglichkeit dynamische Formulare zu verwenden und nur bei Bedarf auf Seitenlayouts zurückzugreifen. Wie immer freuen wir uns über Feedback im Ideenaustausch zu den Verbesserungen, die für Ihre Organisation am effektivsten wären.

Alle Überlegungen zur Leistung in Bezug auf dynamische Formulare, Bildschirm-Flows, OmniStudio und LWC konzentrieren sich auf das Framework, auf dem diese Technologien selbst basieren. Die auf LWC basierenden (neben natürlich einer LWC) werden die auf Aura basierenden übertreffen. Das LWC-Framework bietet eine bessere Leistung, da die Kernfunktionen nativ in Webmodulen und nicht in JavaScript über Framework-Abstraktionen implementiert werden. Wenn Sie nicht vertraut sind, lesen Sie diesen Blogpost.

Bereits 2019 haben wir eine Kundenvorgangsstudie durchgeführt, in der die Leistung der gleichen Funktionen in Aura mit der in LWC verglichen wurde. Durch die Konvertierung von DreamHouse von Aura in LWC wurde nicht nur die Entwicklungserfahrung viel besser an die aktuellen Web-Front-End-Entwicklungsstandards und -muster angepasst, sondern auch die Leistungssteigerungen waren erheblich. Labormessungen ergaben Gewinne im Bereich von 2,4 Prozent bis 24,7 Prozent für Cold-Cache und Gewinne im Bereich von 31,83 Prozent bis 63,32 Prozent für Warm-Cache auf denselben beiden Seiten.

Welches Framework verwenden unsere Formulartechnologien? Anders ausgedrückt: Welche Formtechnologien profitieren von dieser überlegenen Leistung?

• Dynamische Formulare, die in die Metadaten von Lightning-Seiten integriert sind, basieren auf einer Grundlage, die den LWC-Stapel verwendet, wodurch einige lang angeforderte Funktionen implementiert werden können. Dynamische Formulare verwenden ein progressives Rendering, was zu einer verbesserten Seitenladezeit für Seiten mit einer großen Anzahl von Feldern führt.
• Bildschirm-Flows basieren auf LWC, wobei die meisten der einzelnen vorkonfigurierten Komponenten nun in LWC konvertiert wurden, mit Ausnahme von zwei vorkonfigurierten Komponenten: Datei hochladen und Bild. Während das Flow-Team den Flow-Laufzeit-Client und die meisten seiner Komponenten in LWC konvertiert hat, müssen Kunden ihre Aura-Bildschirmkomponenten weiterhin in LWC konvertieren. Darüber hinaus unterstützt Salesforce nur LWC-Komponenten im neuen Framework für reaktive Komponenten in Bildschirm-Flows. Es gibt ein ausgezeichnetes Trailhead Modul, in dem erläutert wird, wie dies funktioniert: Lightning Web Components für Aura-Entwickler. Es versteht sich von selbst: Wenn Sie darüber nachdenken, eine benutzerdefinierte Komponente für einen Bildschirm-Flow oder einen anderen Container zu erstellen, sollten Sie immer LWC verwenden.
• Es sind einige Versionen von OmniStudio verfügbar. Wenn Sie ein langjähriger Kunde sind, verwenden Sie möglicherweise Angular. Wir empfehlen allen Neukunden, mit LWC-basierten OmniScripts und FlexCards zu beginnen und bestehende Kunden von Angular zu migrieren.
• LWC basiert auf ... Natürlich LWC. Das ist ein Freebie. 🤓

Als Architekt ist es wichtig, dass Sie alle Optionen, die Ihnen zur Verfügung stehen, genau kennen und wissen, wie Sie sie in Ihrem speziellen Anwendungsfall anwenden können. Beim Erstellen von Formularen in Salesforce reichen die Optionen von Low-Code (mit dynamischen Formularen im Lightning-Anwendungsgenerator, Bildschirm-Flows in Flow Builder und OmniScripts in OmniStudio) bis hin zu Pro-Code (mit dem LWC-Framework) mit einer Kombination aus Bildschirm-Flows oder OmniScripts und LWC in der Mitte. Beachten Sie diese Anleitung und verwenden Sie sie als Referenz, wenn Sie Formulare in Salesforce erstellen oder neu entwerfen möchten. Wenn Sie nach Anleitungen zum Entwerfen optimierter und hilfreicher Formulare suchen, lesen Sie Salesforce Well-Architected: Engagierend.

Helfen Sie uns, sicherzustellen, dass wir das veröffentlichen, was für Sie am relevantesten ist: Nehmen Sie an unserer Umfrage teil, um Feedback zu diesen Inhalten zu geben und uns mitzuteilen, was Sie als Nächstes sehen möchten.