Erstellen von Formularen

Es gibt mehrere Optionen zum Erstellen von Formularen auf der Agentforce 360 Platform und sie umfassen ein Kontinuum von Low-Code- bis hin zu Pro-Code-Ansätzen. An einem Ende des Kontinuums können dynamische Formulare im Lightning-Anwendungsgenerator und Bildschirm-Flows in Flow Builder für Low-Code-Lösungen verwendet werden. Zum anderen wird für Pro-Code-Lösungen das Lightning Web Component Framework (LWC) verwendet. Innerhalb des Kontinuums können Tools auf verschiedene Weise mit Bildschirm-Flows gemischt werden, die um LWCs und kundenorientierte Formulare erweitert werden, die mit OmniStudio erstellt wurden.

In diesem Leitfaden werden ein Entscheidungs-Framework und Anleitungen zum Erstellen von Formularen für Benutzeroberflächenlösungen vorgestellt. Insbesondere werden ein Dutzend Laufzeiten und nicht funktionale Entscheidungspunkte verwendet, um die beste Technologie für einen bestimmten Anwendungsfall auszuwählen.

• Verwenden Sie beim Erstellen von Layouts zum Erstellen/Bearbeiten/Anzeigen von Lightning-Seiten dynamische Formulare. Künftig wird empfohlen, dynamische Formulare im Lightning App Builder zu verwenden, um Datensatz-Detailseiten zu konfigurieren.

• Wenn Sie ein Formular für ein Objekt erstellen, erstellen oder bearbeiten müssen, verwenden Sie Lightning Pages und Dynamische Formulare. Dies ist die einfachste Möglichkeit, Formulare auf der Agentforce 360 Platform zu erstellen. Sie bietet auch zusätzliche Funktionen (z. B. Kontrolle der Feldsichtbarkeit).

• Wenn Sie ein mehrseitiges Formular oder einen Assistenten erstellen und keine strengen UX- oder Branding-Anforderungen haben, verwenden Sie einen Bildschirm-Flow. Bildschirm-Flows bieten ein lineares Navigations-Framework für die Orchestrierung mehrerer Formulare. Sie können LWCs verwenden, um Ihr eigenes Framework für die Navigation zwischen Formularen zu erstellen. Es wird jedoch empfohlen, Flow die Arbeit zu überlassen, damit Sie sich auf die Formulare selbst konzentrieren können, statt sich auf den Formularstatus zu konzentrieren.

• Wenn Sie zusätzliche Logik oder Aktionen zur Unterstützung des Formulars benötigen, verwenden Sie einen Bildschirm-Flow, OmniStudio oder LWCs. Jedes dieser Tools bietet unterschiedliche Möglichkeiten, Ihre Lösung zu verbessern, indem sie über das Erstellen oder Bearbeiten eines einzelnen Datensatzes hinaus erweitert wird. In diesem Fall kann sich der Begriff eher auf erweiterte Logik (z. B. Verzweigung oder Iteration) oder auf Aktionen wie die Integration in externe Systeme, das Senden von E-Mails oder das Übertragen von Benachrichtigungen an die mobile Anwendung eines Benutzers beziehen.

• Wenn Sie über komplexe UX-Anforderungen verfügen oder mehr als die Benutzeroberflächensichtbarkeit dynamisch verwalten müssen, verwenden Sie LWC oder OmniScript. Für Anforderungen, die durch die Verwendung von Themen und spaltenbasierten Layouts erfüllt werden können, können Sie Ihre Formulare direkt in einem Low-Code-Generator erstellen. Die genaue Kontrolle über den Stil Ihres Formulars erfordert jedoch die Flexibilität von LWC. Wenn Sie ein Branchenkunde sind und ein perfektes Branding benötigen oder über komplexe hierarchische Daten verfügen, verwenden Sie OmniStudio, mit dem Sie Formulare auf Verbraucherebene erstellen können, die komplexe Geschäftslogik und Datentransformationen verarbeiten können.

• Wenn Sie die Testautomatisierung bereitstellen müssen, verwenden Sie LWC. Sie können Einheitentests für jede LWC schreiben, unabhängig davon, wo Sie sie einbetten. Dadurch können Sie eine zuverlässigere Teststrategie erstellen, die Massentests mit mehreren Datensätzen sowie negative Tests umfassen kann.

• Sie sind nicht an “entweder/oder”-Entscheidungen gebunden. Sie können mehrere Optionen kombinieren, um die beste Lösung für Ihre Anwendungsfälle zu finden (wenn Sie beispielsweise das integrierte Navigationssystem von Flow und die volle Flexibilität bei der Gestaltung von LWC benötigen, können Sie sie zusammen verwenden).

Die folgenden Tools werden häufig zum Implementieren und Erweitern von Formularerfahrungen verwendet.

In dieser Tabelle werden die Tools beschrieben, die zum Erstellen von Formularen über Salesforce verfügbar sind, sowie die erforderlichen Fertigkeiten und Lizenzüberlegungen.

Hinweis: In einem späteren Abschnitt werden die spezifischen Funktionen, die für jedes Tool unterstützt werden, genauer erläutert, wie Sie zwischen klickbasierten Tools und codebasierten Tools auswählen und wann sie kombiniert werden.

Beim Treffen von Produkt- und Werkzeugauswahlen sind eine Reihe von Entscheidungspunkten zu beachten. In dieser Tabelle werden verschiedene Entscheidungspunkte beschrieben und allgemeine Anleitungen bereitgestellt.

Hinweis: In nachfolgenden Entscheidungsvergleichstabellen gibt es eine Handvoll Werte, die einem beliebigen Werkzeug-Funktionspaar zugeordnet sind:

• Verfügbar: Das Tool/die Funktion funktioniert mit grundlegenden Überlegungen.

• Nicht verfügbar: Es ist nicht geplant, innerhalb der nächsten zwölf Monate Support hinzuzufügen.

• Nicht ideal: Dieses Tool/diese Funktion kann funktionieren, ist jedoch nicht das optimale Tool.

• Nicht zutreffend: Das Tool gilt nicht für den jeweiligen Anwendungsfall.

Verwenden Sie diese Szenarien, um Tooling-Auswahlen anhand von Umfang, Umfang und betrieblichen Anforderungen zu vergleichen.

Wenn Sie alle Ihre Benutzereingaben über ein Formular mit einem einzigen Bildschirm abrufen können, beginnen Sie mit “Dynamische Formulare”. Beachten Sie, dass dynamische Formulare auf Datensatzseiten die Funktion “Pfad” verwenden können, um mehrstufige Geschäftsprozesse zu unterstützen.

• 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 beim Ausfüllen Ihres Formulars visuell angezeigt wird, wie weit sie im Prozess 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 von einigen zusätzlichen Fragen ab:

• Ist es in Ordnung, unten in Ihrem Formular eine Navigationsleiste anzuzeigen? Wenn die Bildschirm-Flow- und OmniScript-Navigationserfahrung eine unerwünschte Benutzeroberfläche bereitstellt, neigen Sie zu LWC.

• Was muss hinter dem Formular auftreten? Wenn das Verhalten von einem Administrator konfiguriert werden muss, verwenden Sie einen Flow. Verwenden Sie für komplexe Beziehungen mit mehreren Objekten OmniScript oder LWC.

Wenn Sie Flow oder OmniStudio auswählen, müssen Sie möglicherweise auch 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 diese Komponente in einen Flow eingebettet werden muss.

Navigation im Assistentenstil

Wenn Ihre Lösung jedoch 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.

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

Unabhängig davon, ob Sie Formulare mit einem oder mehreren Bildschirmen erstellen, ist es wichtig, sicherzustellen, 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. Dynamische Formulare sind derzeit jedoch nur auf dem Desktop verfügbar. Wenn Sie 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 aktivieren, 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 Datensatzkontext erforderlich ist, wird die Funktion “Dynamische Formulare” nur auf Lightning-Datensatzseiten unterstützt. Dynamische Formulare werden jedoch auf Experience Cloud-Seiten nicht unterstützt.

Sie können Flows erstellen, die einen Datensatzkontext erfordern, oder Flows, die global funktionieren. Anders ausgedrückt: Sie können Flows an einer Vielzahl von Stellen einbetten. Bei Flows im Datensatzkontext können Standorte Folgendes umfassen: Lightning-Datensatzseiten, Experience Cloud-Datensatzseiten, objektspezifische Aktionen oder Bereitstellungen von Aktionen und Empfehlungen. Bei globalen Flows können Standorte Folgendes umfassen: Dienstprogrammleiste, andere Lightning- oder Erfahrungsgenerator-Seiten, Snap oder externe Anwendungen. Derzeit werden Flows nicht als globale Aktionen unterstützt. Sie können Flows jedoch als Übergangslösung in eine _Aura-_Komponente einschließen.

Mit OmniStudio können Sie zusammengesetzte FlexCards und OmniScripts erstellen, die Sie fast überall platzieren können, wo Sie einen Flow platzieren können. Sie können jedoch nicht in Pakete aufgenommen werden.

LWC bietet ein hohes Maß an Wiederverwendbarkeit für die Erstellung von Komponenten, die über Metadaten in Salesforce-, Communities- und Open-Source-Projekten Zielen zugeordnet werden können. Mit Lightning Out 2.0 können LWC-Komponenten auch in Ihre eigene Website eingebettet werden.

LWC-Komponenten können Flows auch mit der Komponente Lightning-Flow starten.

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

Derzeit wird keine der in diesem Handbuch behandelten Formulartechnologien offiziell in Mobile SDK-Vorlagen unterstützt. Wenn das Mobile SDK für Ihren Anwendungsfall wichtig ist, empfiehlt es sich, Ihr Formular nativ in Ihrer mobilen Anwendung zu erstellen oder eine Visualforce-Seite zu erstellen, wobei der Formfaktor zu berücksichtigen ist.

Dynamische Formulare sind perfekt, wenn Sie die Werte in Ihrem Formular verwenden müssen, um einen Datensatz zu erstellen oder zu aktualisieren. Sie müssen Flow, OmniStudio oder LWC für Funktionen nutzen, die außerhalb dieses Geltungsbereichs liegen. Dazu zählen das Erstellen von Entscheidungs- oder Iterationsebenen oder das Generieren von Slack-Posts oder -E-Mails mithilfe der Eingaben aus dem Formular.

• Welche Aktionen oder Logiken müssen im Hintergrund ausgeführt werden?

• Müssen Sie Werte aus einem verwandten Datensatz verwenden?

• 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 zum Posten in Slack, Senden von E-Mails und Interagieren mit Quip-Dokumenten. Für diese Vorgänge müssen Sie keinen Code schreiben. LWC bietet umfangreiche Interaktionen mit einzelnen Datensätzen und verwandten Objekten über Wire-Adapter, die mit der Benutzeroberflächen-API interagieren. LWC kann auch mit mehreren Datensätzen interagieren, indem der Wire für getListInfoByName verwendet wird.

OmniStudio verwendet Integrationsverfahren und die Datenzuordnung, um Daten (externe und interne Daten von Salesforce) abzurufen und umzuwandeln. Dank zahlreicher codefreier Funktionen können Datensets mit verschiedenen Beziehungsebenen vereinfacht und erweitert werden.

Flow, OmniStudio und LWC können alle in Apex integriert werden. Auf diese Weise können Sie ohne Weiteres Lücken in der von Ihnen ausgewählten Lösung schließen. Wenn Sie beispielsweise Datensätze aus einem LWC filtern möchten, können Sie den Wire-Adapter für Apex verwenden, um komplexe SOQL-Abfragen zu erstellen. Wenn Sie von klickbasierten Artikeln beeinflusst werden, sollten Sie Flow oder OmniStudio als praktikable Alternative zu einem Apex-Steuerfeld für Ihre serverseitigen Anforderungen verwenden.

Sie sollten auch überlegen, ob Sie Aktionen sofort übernehmen oder auf einen bestimmten Teil Ihres Formulars zurückstellen möchten. Dies ist besonders relevant, wenn Sie ein mehrseitiges Formular verwenden. Mit Flow können Eingaben aus mehreren Formularen (Flow-Bildschirmen) ganz einfach kombiniert und später im Assistenten (Flow) verwendet werden, um bestimmte Vorgänge auszuführen. Genau so wird das Entwerfen von Flows empfohlen. Führen Sie am Ende Aktionen aus (falls Benutzer zwischen Bildschirmen hin- und herwechseln, um ihre Antworten zu ändern).

Transaktionen und Obergrenzen sind integraler Bestandteil der Agentforce 360 Platform. Wenn Ihr Anwendungsfall ziemlich einfach ist, ist es möglicherweise nicht so wichtig, die Transaktion zu steuern, bei der ein bestimmter Vorgang auftritt. 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.

Hier einige Beispiele:

• Rollback: Angenommen, Ihr Formular erstellt mehrere Datensätze im Hintergrund. Wenn die Erstellung eines dritten Datensatzes fehlschlägt, sollten die ersten beiden Datensätze zurückgesetzt werden? Wenn jede Ihrer Aktionen unabhängig voneinander ist, können Sie sie als separate Transaktionen ausführen. Wenn sie jedoch voneinander abhängig sind – und Sie möchten, dass die anderen durch das Fehlschlagen einer Transaktion ebenfalls wiederhergestellt werden –, sollten Sie sie als einzelne Transaktion implementieren. Wenn sich Ihr Formular im Flow befindet, können Sie das Element “Rückmeldung” im Pfad “Fehler” verwenden, um Ihre Transaktion zurückzusetzen und die Datenintegrität sicherzustellen.

• Nachgelagerte Auswirkungen auf die Obergrenzen für Gouverneure: Wenn Ihr Formular einen Datensatz erstellt oder aktualisiert, ist es wichtig, die nachgelagerten Auswirkungen dieses Vorgangs zu berücksichtigen:

  • Welche Prozesse, Workflow-Regeln, Flow-Auslöser, Apex-Auslöser oder anderen Elemente innerhalb des Speicherauftrags können basierend auf den vorgeschlagenen Datensatzänderungen ausgelöst werden?

  • Wie wirken sich diese kollektiven Änderungen auf die Obergrenzen aus, die innerhalb dieser Transaktion verbraucht werden?

  • Wenn eine bestimmte Datensatzänderung zu vielen nachgelagerten Änderungen führen kann, die sich auf Ihre Obergrenzen auswirken, sollten Sie diese Datensatzänderung möglicherweise innerhalb ihrer eigenen Transaktion isolieren.

• Batchverarbeitung: Möglicherweise müssen Sie mehrere Aktualisierungen zusammen als Batch ausführen (auch innerhalb eines Benutzeroberflächenkontexts). 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 erfasst 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 nur einen Vorgang aus und dieser Vorgang ist immer der Start einer neuen Nettotransaktion.

Wenn Sie einen Bildschirm-Flow erstellen, haben Sie erhebliche Kontrolle darüber, was in einer bestimmten Transaktion vorkommt. Bildschirme und lokale Aktionen fungieren als Grenzen zwischen Transaktionen. Im Folgenden finden Sie eine allgemeine Zusammenfassung der Verwaltung von Transaktionen innerhalb der Bildschirm-Flow-Architektur.

1. Der Endbenutzer interagiert mit einem Bildschirm und klickt dann auf Weiter.

2. Der Client postet eine Eingabeanforderung an die API.

3. Die API empfängt die Anforderung und öffnet eine Transaktions- und Datenbankverbindung. Anschließend ruft die API 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 auf einen Bildschirm oder einen lokalen Aktionsknoten gelangt. Anschließend gibt das Modul 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 (gemäß der 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, mit dem der Benutzer interagiert.

7. Beginnen Sie mit Schritt 1 und wiederholen Sie den Vorgang.

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 beginnt. Beachten Sie, dass die spezifischen Designelemente (die Vorgänge, die Sie in eine bestimmte Transaktion gruppieren) Ihnen überlassen sind.

Hier einige Beispiele:

• Zu Beginn wird ein Flow angezeigt, der Eingaben über mehrere Bildschirme hinweg erfasst und dann mehrere Aktionen innerhalb einer Transaktion ausführt.
• Der nächste Flow führt jeden Vorgang in einer separaten Transaktion aus.
• Flows können auch “Datensätze zurücksetzen” verwenden, um eine gesamte Transaktion zurückzusetzen, wenn ein einzelner Vorgang innerhalb einer Reihe von Datenbankvorgängen fehlschlägt. Angenommen, Sie verfügen über einen Flow, der Datensätze erstellt, aktualisiert und dann zusätzliche Datensätze erstellt (im nächsten Flow dargestellt).

Wenn in diesem Szenario die ersten beiden Elemente erfolgreich sind und das letzte fehlschlägt, werden die entsprechenden Datensätze weiterhin durch die ersten beiden DML-Vorgänge erstellt und aktualisiert, das dritte jedoch nicht. Mithilfe des Elements “Datensätze zurücksetzen” können Sie sicherstellen, dass die gesamte Transaktion zurückgesetzt wird, wenn alle drei Vorgänge zusammen ausgeführt werden müssen (wie im endgültigen Flow dargestellt).

Hinweis: Weitere Details finden Sie unter Flows in Transaktionen und Flow-Massenverarbeitung in Transaktionen.

Ihre Fähigkeit, die Transaktion über eine LWC zu steuern, basiert auf den zugrunde liegenden Services, die die LWC zum Ausführen ihrer Vorgänge verwendet. Wenn Sie die Lightning-Datensatz-Basiskomponente verwenden, erfolgt der zugrunde liegende Vorgang (Erstellen oder Aktualisieren des Datensatzes) beim Senden des Formulars innerhalb einer eigenständigen Transaktion.

Im Allgemeinen gelten die folgenden Regeln:

• Jeder Benutzeroberflächen-API-Aufruf ist innerhalb einer eigenen 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). Beachten Sie, dass die regulären Transaktionsregeln für diese Technologie weiterhin gelten.

Flow, OmniStudio und LWC unterstützen Plattformereignisse (für ereignisgesteuerte Architektur) und API-Integrationen. Zusätzlich zu benutzerdefiniertem Apex Code verfügen Flow und OmniStudio über deklarative Supportmechanismen, die auch in APIs integriert werden können.

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

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

Verwenden Sie für alle anderen Instanzen die Funktion “HTTP-Callout” (mit Unterstützung externer Services) in Flow oder die HTTP-Aktion in OmniStudio.

OmniStudio verfügt über eine Vielzahl von Integrationsfunktionen, die externe Systeme mithilfe von Integrationsverfahren aufrufen können, um Daten über die Datenzuordnung umzuwandeln.

Unabhängig davon, ob Sie benutzerdefinierten Apex Code oder einen externen Service für die Implementierung verwenden, ist ein Callout weiterhin ein Callout.

Folgendes müssen Sie wissen.

• Die Verarbeitung eines Callouts kann viel Zeit in Anspruch nehmen.

• Wenn ein Callout synchron ausgeführt wird, wird er ausgeführt, während eine Datenbanktransaktion geöffnet ist.

• Salesforce erlaubt es Ihnen nicht, eine Datenbanktransaktion offen zu halten, wenn Datenbankvorgänge ausstehen.

Beachten Sie, dass die Haupteinschränkung die Gefahr besteht, dass Daten in einem inkonsistenten Zustand verbleiben, was auftritt, wenn Sie einen Erstellungs-, Aktualisierungs- oder Löschvorgang ausführen und dann einen Callout innerhalb derselben Transaktion ausführen. Dieses Muster ist aufgrund der dritten oben genannten Überlegung, die aufgrund der ersten beiden Überlegungen vorhanden ist, nicht zulässig.

In Flow können Sie diese Einschränkung umgehen, indem Sie die Transaktion unterbrechen. Zur Erinnerung: Bildschirme und lokale Aktionen führen den Browserkontext wieder ein. Wenn Sie mit externen Callouts arbeiten, können Sie zwar Bildschirme und lokale Aktionen verwenden, es wird jedoch empfohlen, die Transaktionssteuerung in den aufrufbaren erweiterten Einstellungen zu aktivieren. Mit der Transaktionssteuerung können Sie die Transaktion automatisch beenden, bevor ein Callout erfolgt. Wählen Sie zum Aktivieren der Transaktionssteuerung im Abschnitt “Erweitert” der aufgerufenen Aktion die Option “Immer eine neue Transaktion starten” aus. LWC vereinfacht die Auswirkungen von Callouts auf die Transaktion. Führen Sie Ihre Datenvorgänge mit dem Lightning Data Service (LDS) aus und verwenden Sie dann ein Apex-Steuerfeld, um den externen Callout vorzunehmen. Da der LDS-Aufruf innerhalb seiner eigenen Transaktion (separat vom Apex-Callout) isoliert ist, schützen Sie sich vor daraus resultierenden Dateninkonsistenzen.

Dynamische Formulare unterstützen die Wiederverwendung nicht. Jede 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 beim Schreiben von Bibliotheken, Dienstprogrammen und Komponenten, die über mehrere Komponenten hinweg verwendet werden können, können Sie auch beim Erstellen von Flows ähnliche Designmuster anwenden, indem Sie die Leistungsfähigkeit von Subflows nutzen. Speichern Sie dazu Ihre Flows in kleineren, modularen Buckets und rufen Sie sie dann über andere Flows mit dem Element “Subflow” auf. Wenn Ihr Design dies erfordert, können Sie einen Flow erstellen, der alleine und als Subflow nützlich ist.

OmniStudio ist von Natur aus auf Modularität ausgelegt. Datenzuordnungen, OmniScripts, FlexCards und Integrationsverfahren werden unabhängig voneinander erstellt, können jedoch auch austauschbar verwendet werden. FlexCards können auch 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 zusammengesetzt werden können, profitieren Sie auch von Anpassungsfähigkeit und Stabilität.

Alle Technologien, die zum Erstellen oder Aktualisieren von Datensätzen verwendet werden, müssen sich an die Validierung auf Systemebene halten, unabhängig davon, ob es sich um klassische Validierungsregeln oder benutzerdefinierte Validierungen handelt, die in einen Apex Auslöser integriert sind. Unabhängig davon, welche Technologie Sie zum Ausführen von Datensatzänderungen verwenden, muss jede Änderung den Speicherauftrag durchlaufen. Das bedeutet, dass Datensatzänderungen zusätzlich zu Validierungsregeln auch durch eine Reihe von Flows vor oder nach dem Speichern, Vor- oder Nachauslösern, Eskalationsregeln, Zuweisungsregeln usw. verarbeitet werden.

Hinweis: Wenn Sie dies noch nicht getan haben, überprüfen Sie die Apex-Ausführungsreihenfolge und markieren Sie sie mit einem Lesezeichen.

• Verfügt Ihr Formular über zusätzliche Anforderungen, die über die Validierung auf Systemebene hinausgehen?

• Müssen Sie Pflichtfelder oder schreibgeschützte Felder dynamisch im Formular festlegen?

In der Regel sind Eingaben in einem Flow-Bildschirm oder OmniScript-Schritt nicht gebunden, sodass das Formular selbst nicht nativ an die Validierung auf Systemebene gebunden ist, die einem bestimmten Objekt zugeordnet ist. Die Werte, die Sie zum Erstellen oder Aktualisieren von Datensätzen verwenden, werden jedoch in der Speicherreihenfolge verarbeitet, d. h., sie durchlaufen die Validierung auf Systemebene des Objekts.

Hinweis: Nicht alle Bildschirm-Flow-Komponenten unterstützen die Eingabevalidierung.

Ähnlich wie bei Seitenlayouts können Sie mit dynamischen Formularen die Erforderlichkeit und den schreibgeschützten Status auf Seitenebene festlegen. Beachten Sie, dass Sie Einstellungen auf Systemebene nicht überschreiben können.

Flow bietet Flexibilität beim Anpassen der Formulareingabevalidierung. Mehrere Überprüfungen werden auf Client-Ebene durchgeführt (z. B. Kennzeichnen fehlender Pflichtfelder und Datentypüberprüfungen sowie kompatible Formeln innerhalb von Eingabevalidierungsregeln). Als zusätzliche Sicherheitsebene wird die Eingabevalidierung auch auf dem Server ausgewertet. Wenn ein Benutzer auf Weiter klickt, sendet Flow die Eingaben erneut zur Validierung an den Server. Wenn ungültige Eingaben zurückgegeben werden, wird die Navigation blockiert und der entsprechende Fehler wird angezeigt.

Der Server validiert die Eingaben, indem er Folgendes überprüft:

• Die Erforderlichkeitseinstellung der Eingabe oder ob der eingegebene Wert mit dem zugrunde liegenden Datentyp kompatibel ist.

• Die benutzerdefinierte Validierung der Eingabe. Sie müssen einen booleschen Formelausdruck und eine Fehlermeldung angeben, die angezeigt werden soll, wenn der Formelausdruck nicht erfüllt ist.

• Die benutzerdefinierte Validierung der zugrunde liegenden Komponente. Wenn Sie eine benutzerdefinierte LWC für einen Flow erstellen, müssen Sie der Methode validate() Ihren eigenen Validierungscode hinzufügen.

Sie können Benutzer auch über die Komponente “Nachricht” in Bildschirm-Flows benachrichtigen, was jedoch nicht verhindert, dass ein Benutzer zu anderen Seiten navigiert oder zum nächsten Schritt in einem geführten Flow übergeht. Der Fehlerstatus in der Komponente “Meldung” wird am besten auf speziellen Fehlerbildschirmen verwendet, die über einen Fehlerpfad ausgelöst werden, wenn die Navigation deaktiviert ist.

OmniStudio bietet eine zuverlässige Fehler- und Validierungsverarbeitung über die Aktion “Fehler festlegen” in Kombination mit Bedingten Ansichten und der Komponente “Messaging”.

Bei LWC führen die meisten Basiskomponenten ihre eigenen clientseitigen Validierungen aus (beispielsweise berücksichtigt Lightning-Datensatzform die System-, nicht jedoch die Seitenebenenanforderungen). Für Ihre benutzerdefinierten Komponenten können Sie Build Your Own Validierungsmechanismen erstellen.

Beachten Sie, dass Felder, für die Benutzer Daten eingeben müssen, am Anfang Ihrer Formulare angezeigt werden sollten. Validieren Sie Benutzereingaben auf Client-Seite, bevor Formulare gesendet werden (sofern möglich).

Statische Formulare sind veraltet. Heute liegt der Fokus auf der dynamischen Aktualisierung von Formularen mit den richtigen Eigenschaften und Werten für einen bestimmten Benutzer zu einer bestimmten Zeit an einem bestimmten Ort. Sehen wir uns einmal genauer an, was über Salesforce-Tools zum Erstellen von Formularen 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 (im Hintergrund) ausführen, während Ihr Formular ausgefüllt wird?

• Müssen Sie Felder als sichtbar, erforderlich, schreibgeschützt oder deaktiviert festlegen oder die Formatierung anhand von Formulareingaben ändern?

Auf reaktiven Bildschirmen wird die Bildschirm-Flow-Interaktivität aktiviert. Durch die Reaktivität können einzelne Komponenten auf einem Flow-Bildschirm miteinander kommunizieren, was Bildschirm-Flows leistungsfähiger macht.

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. Sie können automatisch gestartete Flow-Ergebnisse demselben Bildschirm zuordnen, wodurch Benutzer nicht mehr zu einem anderen Bildschirm navigieren müssen.

LWC bietet eine vollständige Reihe von Wire-Adaptern, die Zugriff auf Salesforce-Daten bieten, um Daten in Formularkomponenten dynamisch auszufüllen, wodurch Entwickler Datensätze über Apex-Steuerfelder aktualisieren, löschen und erstellen können.

Sichtbarkeit

Die Sichtbarkeit kann in allen Formularerstellungstools dynamisch gesteuert werden. Dynamische Formulare, Flow Builder und OmniStudio beheben dies mithilfe von Komponentensichtbarkeitsfunktionen. Sie können Felder deklarativ ein- oder ausblenden, die auf anderen Werten im Formular basieren oder darauf, ob der Benutzer das Formular auf einem Mobilgerät ausfüllt.

• Dynamische Formulare steuern die Sichtbarkeit anhand von Datensatzfeldwerten, Nachschlagefeldern und Formfaktoren.

• Mit Flow können Sie eine Sichtbarkeitsregel auf anderen Bildschirmeingaben sowie anderen Ressourcen basieren, die zuvor im Flow ausgefüllt wurden (z. B. Formeln oder Werte aus anderen Datensätzen).

  • Gerätebasierte Regeln: Dies ist möglicherweise nicht von Anfang an offensichtlich. Sie können jedoch eine Formel verwenden, um ein bestimmtes Feld ein- 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, füllt der Benutzer das Formular mithilfe der mobilen Salesforce-Anwendung aus.

  • Andere Ressourcen auswerten: Manuelle Variablen- und Formelverweise werden nur auf dem Server ausgewertet. Das bedeutet, dass der Wert, den diese Ressource beim ersten Rendern des Bildschirms aufweist, dem Wert entspricht, den sie aufweist, bis Sie zu einem anderen Bildschirm navigieren. Während der Navigation sendet die Flow-Laufzeit eine Anforderung an das Flow-Modul (den Server) und gibt die neuesten manuellen Variablen- und Formelwerte zurück. Wenn Sie erwarten, dass Ihre Sichtbarkeitsregel aktualisiert wird, während der Benutzer einen einzelnen Bildschirm durchläuft (z. B. onblur), müssen Sie sicherstellen, dass Sie nur auf Werte aus den anderen Komponenten auf dem Bildschirm verweisen.

• Mit OmniStudio können Sie Komponenten bedingt ein- oder ausblenden, indem Sie die Eigenschaft “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 (z. B. ob ein Feld erforderlich, deaktiviert oder schreibgeschützt ist), gibt es einige Optionen. LWC bietet vollständige, reaktive Kontrolle über Ihren Eingabestatus. Mit reaktiven Bildschirm-Flow-Komponenten können Sie Komponentenattribute (z. B. 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 (z. B. ob ein Feld erforderlich oder schreibgeschützt ist), verwenden Sie LWC kurzfristig, da Sie die vollständige 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 Lightning-Webkomponenten erstellen, die auf andere Komponenten in einem Bildschirm-Flow reagieren und sie ändern können, lesen Sie den Leitfaden zu den bewährten Lightning-Webpraktiken für Bildschirm-Flows, um sicherzustellen, dass Ihre Komponenten in das Flow-Laufzeitmodul integriert werden und wie vorgesehen funktionieren.

Bei benutzerdefinierten Ereignissen ist LWC die einzige Option, wenn einige Ihrer Eingaben (oder das gesamte Formular) mit einem anderen Element auf der Seite kommunizieren müssen.

• Verwenden Sie die Benutzeroberfläche CustomEvent, um innerhalb derselben DOM-Struktur zu kommunizieren.

• Verwenden Sie zum DOM-übergreifenden Kommunizieren den Lightning Messaging Service.

• Wenn Lightning Messaging Service für Ihren Ziel-Container nicht unterstützt wird, verwenden Sie das Modul “Pub/Sub”.

• Detailliertere Informationen finden Sie im Lightning Web Components Dev Guide unter Communicate with Events and Communicate Across the DOM (Mit Ereignissen kommunizieren).

• Informationen zu OmniStudio finden Sie unter Mit OmniScript über eine Lightning Webkomponente kommunizieren.

Um die beste Benutzererfahrung zu bieten, müssen Sie sicherstellen, dass Ihr Formularstil mit dem Rest der Anwendung oder Site, auf der er eingebettet wird, konsistent ist. Dies kann die Verwendung von Standardvorlagen bedeuten, die von Salesforce bereitgestellt werden, oder die Erstellung eines benutzerdefinierten CSS, das jedes Pixel im Design verwendet, um ein schärferes Erscheinungsbild zu bieten.

Administratoren können einen begrenzten Satz an Bildschirm- und Komponentenstilüberschreibungen (z. B. Farben, Rahmen und Schaltflächenerscheinungen) für den Bildschirmcontainer oder für einzelne Komponenten konfigurieren. Diese Überschreibungen werden nach Themen und Branding angewendet, wodurch Generatoren gezielte visuelle Anpassungen vornehmen können, ohne dass sich dies auf den Rest der Anwendung auswirkt.

Gestaltungsüberschreibungen sind für lokalisierte visuelle Ausnahmen vorgesehen (z. B. Hervorhebung eines Bestätigungsbildschirms oder Hervorhebung einer bestimmten Handlungsaufforderung). Sie sind kein vollständiges Gestaltungssystem. Sie bieten keine Kontrolle auf CSS-Ebene und sind nicht für die Wiederverwendung auf Bildschirmen oder Flows vorgesehen.

Aus architektonischer Sicht sollte der Stil der folgenden Präzedenzreihenfolge folgen:

1. Themen und Branding: Lightning-Themen, Erfahrungsgenerator-Brandingsätze oder LWR-Site-Themen

2. Überschreibungen des Flow-Stils: Gezielte Bildschirm- oder Komponentenanpassungen

3. Benutzerdefinierte Komponenten (LWC): wenn pixelgenaue Steuerung oder wiederverwendbare Designmuster erforderlich sind

Die Verwendung von Themen und Designsystemen trägt dazu bei, sicherzustellen, dass der Stil im Laufe der Zeit konsistent, skalierbar und einfach zu pflegen bleibt.

• Wie anspruchsvoll ist Ihr gewünschter Stil und CSS?

• Sie benötigen einen benutzerdefinierten, pixelgenauen Stil oder Standardthemen?

FlexCards ist das einzige Produkt in diesem Handbuch, mit dem Sie den Stil und das Layout der Benutzeroberfläche, die Sie im Tool erstellen, deklarativ steuern können (z. B. Ränder und Innenabstände, Typografie, Farben usw.).

Dynamische Formulare und Flows berücksichtigen deklarative Themenfunktionen. Wenn Sie zusätzliche Kontrolle benötigen (über die Unterstützung von Salesforce-Themen, Erfahrungsgenerator-Brandingsätzen oder LWR Experience Cloud-Sites hinaus), sollten Sie eine programmgesteuerte Lösung in Betracht ziehen.

Teams, die mit CSS vertraut sind, haben mehrere Optionen:

• Flows und Lightning-Webkomponenten übernehmen Standarddesigntoken.

• OmniScripts und FlexCards enthalten die anpassbare Unterstützung des Designsystems über Newport.

• Mit LWC können Sie Ihre eigenen Komponenten schreiben und deren HTML und CSS vollständig steuern.

Wenn möglich, sollten Sie Themen und Designsysteme verwenden, um ein einheitliches Erscheinungsbild für alle Ihre Inhalte zu gewährleisten.

Hinweis: Lightning-Komponenten können in Flows eingebettet werden. Wenn Sie das Erscheinungsbild Ihres Formulars pixelgenau steuern möchten, aber auch die anderen Vorteile von Flows (z. B. das Navigationsmodell) nutzen möchten, können Sie das Beste aus beiden Welten herausholen. 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.

• Wie können Sie Formularlayouts strukturieren, um die Benutzererfahrung zu optimieren?

• Wie können Sie Benutzern vorhandene Daten so präsentieren, dass sie leichter neue Daten in Ihre Formulare eingeben können?

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

Flows können auch mithilfe der Komponente “Abschnitt” dargestellt werden. Sie können bis zu vier Spalten und eine unbegrenzte Anzahl von Abschnitten auf dem Flow-Bildschirm hinzufügen. Die Komponente “Abschnitte” reagiert auch auf die Bildschirmbreite und funktioniert daher auch auf kleineren Bildschirmen. Sie bietet Ihnen die Möglichkeit, die bedingte Sichtbarkeit auf den gesamten Abschnitt anzuwenden, 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 und CSS. Die Komponente Lightning-Datensatzform berücksichtigt die Abschnittskonfiguration im zugeordneten Seitenlayout (wenn ein Abschnitt beispielsweise im Seitenlayout zweispaltig ist, ist er auch in der Komponente zweispaltig).

Wenn Benutzer in verschiedenen Regionen oder Sprachen auf Ihr Formular zugreifen können müssen, müssen Sie sicherstellen, dass das Tool, das Sie zum Erstellen verwenden, Ihre Lokalisierungsanforderungen erfüllt.

Hinweis: 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 benutzerdefinierte Felder lokalisieren, berücksichtigen dynamische Formulare die übersetzten Bezeichnungen. Dynamische Formulare berücksichtigen auch alle benutzerdefinierten Bezeichnungen, die Komponentenbezeichnungen und Attributen im Lightning-Anwendungsgenerator zugewiesen sind.

Der Flow unterstützt die Übersetzung von benutzerdefinierten Bezeichnungen für alle standardmäßigen und benutzerdefinierten Bildschirmkomponenten über die Übersetzungsworkbench.

Sie können Bezeichnungen, Hilfetext und Fehlermeldungen für die folgenden Bildschirmkomponenten lokalisieren:

• Text
• Langer Textbereich
• Nummer
• Währung
• Kontrollkästchen
• Optionsfelder
• Auswahlliste
• Mehrfachauswahlliste
• Kontrollkästchen Gruppenkennwort
• Datum
• Datum/Uhrzeit

Für vorkonfigurierte Aktionen (z. B. “E-Mail senden” oder “Bei Chatter posten”) gibt es keine integrierte Übersetzungsunterstützung. Es gibt jedoch eine Übergangslösung. Wenn Sie eine benutzerdefinierte Bezeichnung zum Definieren der übersetzten Bezeichnungen verwenden, können Sie bei der Konfiguration in Flow Builder in der Aktion oder Komponente auf diese benutzerdefinierte Bezeichnung verweisen. Dazu müssen Sie eine Flow-Formel erstellen, die auf die benutzerdefinierte Bezeichnung verweist, und dann an den entsprechenden Stellen in Ihrem Flow auf diese Formel verweisen.

OmniScripts verwenden benutzerdefinierte Bezeichnungen für Übersetzungen. Weitere Informationen finden Sie in diesem Hilfedokument, um sicherzustellen, dass Ihre OmniScripts mehrsprachig sind.

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

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

In diesem Abschnitt können Sie Sicherheits-, Qualitäts- und Betriebseinschränkungen vor der Implementierung bewerten.

Sicherheit ist ein komplexes Thema. Beim Erstellen von Formularen gibt es einige Überlegungen, die möglicherweise nicht offensichtlich sind. Auf der grundlegenden Ebene müssen 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 auch zusätzliche Maßnahmen ergreifen, um potenziell bösartigen Code oder URLs aus Rich-Text-Feldern zu entfernen, bestimmte Benutzer am Zugriff auf das Formular zu hindern oder Einschränkungen hinsichtlich der Standorttypen festzulegen, an denen Administratoren das Formular in Zukunft potenziell einbetten können.

Dokumentieren Sie Ihre Sicherheitsanforderungen sorgfältig, bevor Sie ein Tool auswählen. Weitere Anleitungen zu diesem Dokumentationstyp finden Sie in der Salesforce Well-Architected Security Policy Template.

• 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 ein Programm 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 (beispielsweise können Benutzer nur dann ein Formular zur Kundenvorgangsaktualisierung ausführen, wenn sie Kundenvorgänge aktualisieren können, die entsprechende Feldebenensicherheit und Zugriff auf den betreffenden Datensatz haben).

Was geschieht, 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!

Mit dem Systemkontext können Sie die Berechtigungen eines Benutzers für die Dauer der Sitzung erhöhen (beispielsweise muss der Benutzer den Zugriff auf das Kundenvorgangsobjekt nicht aktualisieren, um das 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.

Systemkontext sollte nur verwendet werden, wenn dies unbedingt erforderlich ist. Wenn ein Formular im Systemkontext ausgeführt wird, umgeht jeder CRUD-Vorgang die Sicherheits- und Freigabekomponenten auf Objekt- und Feldebene. Außerdem hat der Systemkontext keine Auswirkungen darauf, wer von Salesforce als Akteur betrachtet wird (der Name, der im Feld “Zuletzt geändert von” angezeigt wird). Für jeden Vorgang, den Ihr Formular ausführt (z. B. eine Kundenvorgangsaktualisierung), ist der Akteur der aktuelle Benutzer (auch wenn das Formular in einem anderen Kontext ausgeführt wird).

Hinweis: 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 entscheiden, ob der Flow Zugriff auf alle Daten erteilen oder den Zugriff auf Datensatzebene erzwingen soll.

• 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, verwenden Sie den Flow, um diese Vorgänge auszuführen und die entsprechenden Daten an die Lightning-Komponente weiterzugeben. Einige vorkonfigurierte Komponenten (z. B. “Nachschlagen”) können nicht im Systemkontext verwendet werden.

• Wenn Ihr Flow Apex-Aktionen aufruft, sind andere Nuancen beteiligt.

  • Wenn die Apex-Klasse auf “Freigabe übernommen” festgelegt ist, wird sie im Systemkontext mit Freigabe ausgeführt, unabhängig davon, wie der Flow festgelegt ist.

  • Wenn die Klasse keine explizite Freigabedeklaration aufweist, wird sie im Systemkontext ohne Freigabe ausgeführt, unabhängig davon, wie der Flow festgelegt ist.

  • Wenn die Klasse mit oder ohne Freigabe 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 wenn er nicht authentifiziert ist), speichern Sie nur bestimmte Felder in Ihren Elementen vom Typ “Datensätze abrufen”. 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, werden möglicherweise alle Felder aus diesem Objekt von den Entwicklertools des Browsers überprüft. Trotz Ihrer Absichten werden Experience Cloud-Benutzern dadurch möglicherweise Felder zur Verfügung gestellt. Geben Sie diese spezifischen Felder in den Elementen vom Typ “Datensätze abrufen” an, um sicherzustellen, dass bei aktiviertem Systemkontext nur die richtigen Felder angezeigt werden.

Hinweis: Die OmniScript-Logik wird clientseitig ausgeführt. Dadurch können Angreifer die erwartete Ausführung eines OmniScripts ändern und Antworten auf Aufrufe von Integrationsverfahren, Datenzuordnungen und Apex-Methoden über die Entwicklertools des Browsers anzeigen. Wenn Sie OmniScript verwenden, ist es wichtig, Geschäftslogik serverseitig auszuführen (sofern möglich) und Eingabevalidierungsregeln für alle Apex-Methoden zu implementieren, die über die Anmerkung @InvocableMethod verfügbar gemacht werden.

Sanitäreingaben

Verwenden Sie die Eingabebereinigung, um Ihre Organisation vor schlechten Akteuren zu schützen. Angenommen, Sie verfügen über eine Eingabe in einem öffentlich zugänglichen Formular, das einem Rich-Text-Feld in Ihrer Organisation zugeordnet werden kann. Möglicherweise sollten Sie die Automatisierung aktivieren, die HTML entfernt, die schädliche URLs ausblenden kann.

Es ist nicht ideal, die Bereinigung auf Formularebene zu implementieren, da Sie möglicherweise über eine beliebige Anzahl von Quellen verfügen, die in diese Felder schreiben. Erstellen Sie einen Flow für die schnelle Feldaktualisierung (Vor dem Speichern) oder verwenden Sie einen vorhandenen Apex-Auslöser, um mögliche HTML-Elemente, die in das Formular eingegeben werden können, zu entfernen oder zu ändern.

• Lassen Sie zu, dass Flows in ihrem Standardkontext ausgeführt werden (es sei denn, Sie müssen den Zugriff des aktuellen Benutzers für einen bestimmten Vorgang erhöhen).

• Vermeiden Sie die Ausführung von Flows im Systemkontext für Gastbenutzer. Erstellen Sie Berechtigungssätze mit eingeschränktem Feldzugriff und weisen Sie sie dem Profil des Experience Cloud-Gastbenutzers zu.

• Wenn Sie Datensätze in Systemkontextausführungs-Flows auf Experience Cloud-Sites abfragen, speichern Sie nur die Felder, die Sie im Element “Datensätze abrufen” oder “Aufrufbare Aktionen” benötigen.

• Wenn ein Flow eine Vielzahl von Vorgängen ausführt, für die kein erhöhter Zugriff erforderlich ist, verwenden Sie Subflows, um die Vorgänge zu isolieren, die im Systemkontext ausgeführt werden sollten.

• Wenn Sie ein Formular in eine externe Webseite einbetten, muss es möglicherweise Rich-Text-Feldern zugeordnet werden, um potenzielle Phishing-Angriffe zu verhindern. Bereinigen Sie dazu Benutzereingaben, um HTML mithilfe eines Flows für schnelle Feldaktualisierungen oder Apex Triggers zu entfernen.

• OmniScripts, FlexCards und LWCs werden standardmäßig im Benutzerkontext ausgeführt.

• LWCs werden standardmäßig im Benutzerkontext ausgeführt.

• Flows werden im Benutzerkontext ausgeführt. Sie können sie jedoch mithilfe eines Apex-Steuerfelds überschreiben.

• Vorgänge, die innerhalb der Benutzeroberflächen-API ausgeführt werden, werden im Benutzerkontext ausgeführt.

• Vorgänge, die mit einem Apex Steuerfeld ausgeführt werden, hängen von der jeweiligen Klasse ab. Um diese Vorgänge im Systemmodus auszuführen, legen Sie die Apex-Klasse mit oder ohne Freigabe fest.

Wenn Sie steuern möchten, wer auf ein Formular zugreifen kann, überprüfen Sie den Container, in den das Formular eingebettet ist (beispielsweise können Sie Lightning-Seiten zuweisen, damit sie für bestimmte Anwendungen, Datensatztypen oder Profile verfügbar sind). Wenn bestimmte Eingaben vertraulich sind, können Sie mithilfe von Sichtbarkeitsregeln weiter 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 Apex-Klassen- oder Visualforce-Seiten). Flows sind standardmäßig uneingeschränkt. Das bedeutet, dass jeder Benutzer mit der Benutzerberechtigung “Flows ausführen” darauf zugreifen kann.

Wenn Sie OmniStudio verwenden, können Sie eine Berechtigungsprüfung für Apex-Klassen konfigurieren, bei der Benutzer expliziten Zugriff auf die Apex-Klasse benötigen, die Remote-Aktionen über OmniScript-, FlexCard-, Classic Card- oder REST-APIs verwaltet.

Hinweis: Berechtigungsprüfungen für Apex-Klassen gelten nur für Apex-Klassen. Es empfiehlt sich auch, Berechtigungen auf Profilebene für Integrationsverfahren und Datenzuordnungen festzulegen.

• Wenn Sie Gastbenutzern einen Flow zur Verfügung stellen, sollten Sie nur Gastbenutzerprofilzugriff auf die Flows gewähren, die sie unbedingt benötigen. Es ist möglich, Gastbenutzerprofilen “Flows ausführen” hinzuzufügen. Diese Vorgehensweise kann jedoch riskant sein.

• Gehen Sie beim Arbeiten mit Flows, die im Systemkontext ausgeführt werden, mit Bedacht vor. Sie sollten diese Flows auf einen bestimmten Satz von Benutzern 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 mit Freigabe aufgeführt ist.

• Weisen Sie für Gastbenutzerprofile nur die Apex-Klassen zu, die Gastbenutzer aufrufen können sollen. Durch diese Vorgehensweise wird verhindert, 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. Sie können Salesforce-Berechtigungen direkt in JavaScript aus den @salesforce/userPermission- und @salesforce/customPermission importieren. Sie können auch Apex verwenden, um Berechtigungen zu überprüfen.

LWCs sind nur an einem bestimmten Ort verfügbar, nachdem 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. Flow Builder unterstützt mehrere Typen von Flows mit Bildschirmen. Der prominenteste 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). Dies ähnelt 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 ist. Flows sind an allen Standorten verfügbar, an denen dieser bestimmte Flow-Typ unterstützt wird.

Wenn Sie Salesforce-Branchen verwenden, gibt es in Bezug auf OmniScript einige Einschränkungen.Es ist nicht möglich, ein Ziel für ein OmniScript anzugeben. Sie können jedoch ein Ziel für die FlexCards angeben, die Sie einbetten möchten.

Bei Salesforce gibt es mehrere durchgängige Testautomatisierungstools (beispielsweise Salesforce UTAM), mit denen Sie simulieren können, wie ein Benutzer mit Ihren Formularen interagiert. Sie können Tests für jede standardmäßige oder benutzerdefinierte Benutzeroberfläche schreiben, einschließlich Lightning-Seiten und Bildschirm-Flows.

Hinweis: Diese Testtypen können die Ausgaben für die ausgeführten Methoden nicht überprüfen. Beachten Sie dies beim Konfigurieren Ihrer Anforderungen an die Benutzeroberflächentestautomatisierung.

• Benötigen Sie automatisierte Tests für Ihre Formulare?

• Welche Arten von Tests planen Sie durchzuführen?

• Welche Granularität ist für Testautomatisierungen erforderlich?

Berücksichtigen der Anforderungen an die Testautomatisierung auf der Benutzeroberfläche

Einheitentests bieten eine detaillierte Automatisierung und Validierung, die mit den CI/CD-Standardsystemen und -Tools der Branche in Einklang steht, die die Geschäftslogik, JavaScript-Steuerelemente und -Ausgaben bestimmter Komponenten testen. Wenn Sie sich für einen Low-Code-Ansatz entscheiden, können Sie keine Tests selbst erstellen. Salesforce testet jedoch alle durchgängigen Angebote sorgfältig.

Wenn die Methoden Ihrer Komponente komplex sind, können Sie sie einzeln per SMS senden, indem Sie die Methoden in dedizierte JavaScript-Dateien einfügen. Dadurch können Sie sie in eine LWC importieren und dann in einen Jest-Test (beispielsweise importieren Sie { sort } aus ‘c/utils’;).

Sie können eine No-Code-Lösung aus einem ISV verwenden, eine benutzerdefinierte Testautomatisierungslösung erstellen oder ein Open-Source-Test-Framework (z. B. Selenium WebDriver oder WebdriverIO) für die durchgängige Automatisierung verwenden. Diese Lösungen sind für alle Interaktionen auf der Salesforce-Benutzeroberfläche gültig (beispielsweise ein dynamisches Formular auf einer Lightning-Seite, ein Bildschirm-Flow auf einer Dienstprogrammleiste oder eine Lightning-Webkomponente in einem Schnellaktions-Flow).

Nachdem Sie Ihr Formular in einer Produktionsumgebung bereitgestellt haben, müssen Sie sicherstellen, dass es effektiv verwendet wird. Je nach Anwendungsfall kann dies bedeuten, dass Sie verfolgen können, wie oft Ihr Formular ausgefüllt wurde, bis der durchschnittliche Benutzer das Formular ausfüllt, bevor er seine Informationen sendet. Es ist wichtig, dass Sie Ihre nachverfolgbaren KPIs identifizieren, bevor Sie ein Tool auswählen.

• Müssen Sie die Formularnutzung verfolgen?

• Welche KPIs können bestimmen, ob das Formular effektiv verwendet wird?

Verwenden Sie Low-Code-Tools, um die Nutzung und Akzeptanz von Formularen insgesamt zu verfolgen. Dynamische Formulare und Bildschirm-Flows können über vorkonfigurierte benutzerdefinierte Berichte verfolgt werden. Berichte zur Bildschirm-Flow-Verfolgung bieten jedoch zusätzliche Granularität. Wenn Sie die LWC-Nutzung verfolgen müssen, hängt die vorkonfigurierte Verfügbarkeit davon ab, wo Sie die LWC verwenden. Wenn sie sich auf einer Lightning-Seite befindet, gelten alle verfügbaren Elemente zur Verfolgung der Nutzung von Lightning-Seiten auch für Ihre Lightning-Seiten. Dies gilt auch für LWCs, die in Flows eingebettet sind.

Dynamische Formulare können nicht vorkonfiguriert verfolgt werden. Sie können jedoch die Nutzung der übergeordneten Lightning Seite über Lightning Nutzungsobjekte verfolgen. Verwenden Sie zum Verfolgen von Lightning Standardseiten den benutzerdefinierten Bericht “Kennzahlen für Lightning-Nutzung nach Seite”. Verwenden Sie für benutzerdefinierte Lightning-Seiten den benutzerdefinierten Bericht Users with Lightning Usage by FlexiPage Metrics.

Mit Flows können Sie die Akzeptanz für bestimmte Formulare verfolgen. Verwenden des Beispiel-Flow-Berichts: Bildschirm-Flows zum Beantworten der folgenden Fragentypen:

• Wie hoch ist die Abschlussrate für dieses Formular? Ist es derzeit gut angenommen?

• Wie lange dauert das Ausfüllen dieses Formulars?

• Auf welchem Bildschirm verbringen Benutzer die meiste Zeit?

• Wie oft navigieren Benutzer zu vorherigen Bildschirmen?

• Wie oft treten Fehler auf?

Wenn der Standardbericht Ihre Anforderungen nicht erfüllt, können Sie ihn duplizieren und Änderungen vornehmen oder mit dem Bericht “Bildschirm-Flows” einen neuen Bericht Build Your Own erstellen.

Wenn Sie die paketbasierte OmniScript-Laufzeit verwenden, können Sie auch den Service OmniStudio für die Vlocity-Verfolgung verwenden. Dieser Service verfolgt alle Arten von Ereignissen (beispielsweise können Sie die Zeit verfolgen, die zum Abschließen der Schritte erforderlich ist, in einem OmniScript, wodurch Prozessverbesserungen identifiziert werden können).

Hinweis: Es gibt keine vorkonfigurierte Option zum Verfolgen einer LWC, die nicht in einen Bildschirm-Flow, ein OmniScript oder eine Lightning-Seite eingebettet ist. Sie können jedoch mithilfe von Apex eine benutzerdefinierte Lösung erstellen.

Möglicherweise sind Sie mit der Verwendung von Änderungssets oder dem DevOps Center vertraut, um Ihre Lösung in Testumgebungen oder in der Produktion bereitzustellen. Diese Bereitstellungsoptionen unterstützen dynamische Formulare, Flows und LWCs vollständig. OmniStudio benötigt jedoch ein separates Tool, die IDX Workbench.

• Wie möchten Sie das Formular bereitstellen?

• Muss das Formular an mehrere Salesforce-Organisationen verteilt werden?

Wenn Sie ein ISV oder Partner sind und planen, Ihre Lösung für die Verteilung auf AppExchange zu bündeln, sollten Sie sich Dynamische Formulare, Flows und LWCs ansehen. Beachten Sie, dass OmniStudio die Paketerstellung nicht unterstützt.

Dieser Leitfaden soll Ihnen zeigen, welche Funktionen und Anpassungsebenen über dynamische Formulare, Bildschirm-Flows, OmniStudio und LWC verfügbar sind. Hier finden Sie eine allgemeine Übersicht.

• Wenn es um das Erstellen von Formularen geht, ist LWC die robusteste und anpassbarste Option, verfügt jedoch über die wenigsten vorhandenen Leitplanken. Daher ist es wichtig, dass Sie Ihre Komponenten unter Berücksichtigung von Sicherheit und Skalierbarkeit erstellen.

• Dynamische Formulare sind die am wenigsten flexible Option, es gibt jedoch viel weniger Möglichkeiten für Fehltritte.

• Flow und OmniStudio liegen leicht in der Mitte. Sie sind leistungsfähiger als dynamische Formulare, aber sie sind nicht ganz auf der LWC-Ebene. Sie verfügen jedoch über weniger Leitplanken als dynamische Formulare und sind schwerer zu knacken als benutzerdefinierter Code.

Sie werden feststellen, dass mehrere Tools Ihren Anforderungen entsprechen. Wenn ja, hängt die Entscheidung letztlich davon ab, welches Tool für Ihr Team am besten geeignet ist. Weitere Informationen zu zusätzlichen Aspekten finden Sie in den folgenden Entscheidungsleitfäden für Architekten.

• Wenn Sie Tools vergleichen, ist es wichtig, zu bewerten, wie viel Fachwissen Ihr Team in Bezug auf die einzelnen Tools hat?
• Wie viele Ihrer Entwickler sind mit LWC oder JavaScript vertraut?
• Gibt es Entwickler in Ihrem Team, die Experten für Flow Builder sind oder Interesse an weiteren Informationen bekundet haben?

Obwohl wir nicht auf spezifische Details eingehen, finden Sie hier ein paar weitere Informationen dazu, wie diese speziellen Tools mit den Bewertungen, die wir bisher behandelt haben, in Beziehung stehen.

Zustellungsdelegation

Beachten Sie, dass selbst wenn einige Ihrer Anforderungen LWC erfordern, nicht die gesamte Lösung mit LWC erstellt werden muss. Es ist wichtig zu bestimmen, wie Sie Ihre Lösung modular erstellen können. Dazu müssen Sie angeben, welche Teile eine codierte LWC erfordern und welche nicht. Die Teile, für die kein LWC erforderlich ist, sollten mit einer Low-Code-Lösung erstellt werden.

Bei Flow und LWC gibt es verschiedene Komponenten (z. B. reaktive Bildschirmkomponenten und Bildschirm-Flow), die auf demselben Bildschirm miteinander synchronisiert werden können, um neue Tools für Architekten, Administratoren und Entwickler freizugeben. Entwickler können nun zielgerichtete, modulare Komponenten erstellen, die in der gesamten Organisation wiederverwendet werden können, was zur Steigerung der Teamproduktivität beiträgt. Dadurch können Entwickler Zeit sparen, indem sie eine Kombination aus standardmäßigen und benutzerdefinierten Flow-Komponenten verwenden, um eine Formdynamik zu erreichen, wodurch sie sich mehr auf die Lösung neuer Herausforderungen konzentrieren können. Mit der Einführung von reaktiven Komponenten in Flow gab es nie einen günstigeren Zeitpunkt, um Flow und LWC beim Erstellen von Formularen zu kombinieren.

Langfristige Inhaberschaft und Wartungsfähigkeit

Wenn Sie ein Formular mit mehreren Schritten erstellen, beginnen Sie mit Flow oder einer Kombination aus Flow und LWC. Wenn es sich bei dem Team, das das Formular verwaltet, um ein Low-Code-Team handelt, stellen Sie sicher, dass die Lösung für Ihre vorgesehene Zielgruppe so konfigurierbar und erweiterbar wie möglich ist. Unabhängig vom gewählten Tool ist es wichtig, Ihre Lösung in zusammensetzbare Einheiten zu organisieren, um die Stabilität und Wartungsfähigkeit zu verbessern.

Leistungsüberlegungen zu dynamischen Formularen, Bildschirm-Flows, OmniStudio oder LWC basieren auf dem Framework, in dem sich die Technologien befinden. Technologien, die auf LWC basieren, übertreffen in der Regel die auf Aura basierenden Technologien. Aufgrund mehrerer Kernfunktionen, die nativ in Web-Engines (und nicht über Framework-Abstraktionen in JavaScript) implementiert sind, bietet die LWC verbesserte Leistungsvorteile.

Wie können wir diese Leistungsvorteile für unsere Formulartechnologien bei Salesforce nutzen? Sehen wir uns das genauer an.

• Dynamische Formulare (in Lightning-Seiten-Metadaten integriert) basieren auf einer LWC-Stapel-Grundlage, die es uns ermöglicht, mehrere lang erwartete Funktionen zu implementieren. Dynamische Formulare verwenden ein progressives Rendering, das die Ladezeit für Seiten mit einer großen Anzahl von Feldern verbessert.

• Bildschirm-Flows basieren auf LWC. Die meisten der einzelnen vorkonfigurierten Komponenten wurden nun mit Ausnahme der Komponenten “Datei hochladen” und “Bild” in LWC konvertiert. 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. Beachten Sie, dass Salesforce in Bildschirm-Flows nur LWC-Komponenten im Framework für reaktive Komponenten unterstützt. Weitere Informationen finden Sie im Trailhead Modul Lightning Web Components for Aura Developer. Wenn Sie eine benutzerdefinierte Komponente für einen Bildschirm-Flow (oder einen anderen Container) erstellen möchten, wählen Sie LWC!

• Es sind verschiedene Versionen von OmniStudio verfügbar. Als langjähriger Kunde verwenden Sie möglicherweise Angular. Alle Neukunden sollten LWC-basierte OmniScripts und FlexCards verwenden. Es wird auch empfohlen, bestehende Kunden von Angular zu migrieren.

• LWC basiert auf LWC.