Obwohl Dynamic Forms als Funktion schon seit einiger Zeit verfügbar ist, wird sie häufig nicht eingesetzt. Doch warum? In diesem Beitrag tauchen wir tiefer in die Materie ein, diskutieren Vor- und Nachteile und zeigen, dass es sich lohnt, sich damit zu beschäftigen.
Salesforce-Optionen bei der Definition des User Interface
Es gibt unzählige Möglichkeiten zu definieren, was Benutzer sehen und was nicht - OWD (Organization-wide Sharing Defaults), Rollenhierarchie, Sharing Rules, Field-Level Security, Profileinstellungen. Aber was macht ein Administrator, wenn er von einem Kunden den Auftrag erhält, dass bestimmte Datensätze verschiedene Felder, Schaltflächen, Aktionen, Abschnitte haben soll? Bislang kam einem das Einrichten des Seitenlayouts in den Sinn.
Um auf diese Art und Weise eine passende Unterscheidung über das Seitenlayout vornehmen zu können, war es bislang nötig, entweder zusätzliche Datensatztypen oder Profile anzulegen.
Beispiel: Nehmen wir an, wir haben einen Vertrag vom Typ Rot und einen Vertrag vom Typ Blau. Was tun wir (bislang)? Wir erstellen zwei Datensatztypen: Rot und Blau, dann zwei Seitenlayouts, die wir Rot und Blau entsprechend zuweisen.
Die Erstellung von neuen Datensatztypen erhöht die technische Komplexität enorm, wodurch eine einfache Diversität des User Interface bezogen auf bestimmte Kriterien mit der technischen Tiefe stets abgewogen werden musste und oft den kürzeren zog.
Die Rettung naht durch zusätzliche Salesforce Lightning Pages Features. Durch die Erweiterungen lässt sich stärker beeinflussen, was Nutzer sehen, ohne die technische Tiefe unnötig zu vergrößern.
Möglichkeiten der Dynamic Forms
Freie Feldplatzierung
Die Felder können frei auf der Lightning Page platziert werden, ohne dass sie im Seitenlayout und der daraus entstehenden “Record Details” festgelegt werden müssen.
Dies ist wahrscheinlich der offensichtlichste und wichtigste Vorteil, den dynamische Formulare bieten. Während früher die gewünschten Felder ausschließlich auf dem Seitenlayout platziert werden konnten und starr in der “Record Detail” Komponente verankert waren, können nun die gewünschten Felder auf der Lightning-Datensatzseite an frei, unabhängig von der “Record Detail” und Seitenlayout Definition, platziert werden.
Nehmen wir an, wir wollen den Details-Bereich in zwei Teile unterteilen, wie auf dem Screenshot zu sehen, und einen Teil über dem Banner platzieren. Mit Dynamic Forms ist das möglich. Früher, als wir noch die üblichen Seitenlayouts verwendet haben, konnte der Detailbereich nicht unterteilt werden.
Wichtiger Zusatz: Felder können nur innerhalb eines Feldabschnitts platziert werden. Zuerst wird der Abschnitt abgelegt, dann benannt - und dann werden die Felder darin platziert.
Unser Favorit! Wenn sich z. B. Verträge nur in einem Feld oder Abschnitt voneinander unterscheiden, müssen kein neues Seitenlayout und kein Datensatztyp erstellt werden. Mit Dynamic Forms hat man die Möglichkeit, jedes einzelne Feld zu steuern. Man nimmt z. B. die Felder A und B und definiert die Sichtbarkeitsfilter für diese Felder, indem man dem System befiehlt, sagt: Zeige das Feld A und blende das Feld B aus, wenn der Vertrag z. B. das Kriterium “rot” erfüllt. Und wenn der Vertrag das Kriterium“blau” erfüllt, zeige das Feld B und blende das Feld A aus.
Man kann auch die Sichtbarkeit oder sogar die Bearbeitbarkeit des Feldes definieren, abhängig von
- einem anderen Feld
- einem Feldwert von einem verwandten Datensatz
- dem Benutzer
- den Berechtigungen des Benutzers
Das bietet absolute Flexibilität!
Das Ende verschiedener Seitenlayouts
Dieser Punkt ergibt sich aus dem vorhergehenden. Da bei Dynamic Forms sowohl Komponenten als auch Felder definiert werden können, müssen nicht für jeden Fall verschiedene Seitenlayouts erstellt werden. Man verwendet Lightning Pages, oder Dynamic Forms, und passt es an die weiteren Bedürfnisse des Kunden an.
Verbesserung der Seitenladezeiten
Lightning Pages bietet die Seitenanalyse an. Dieses Tool hilft bei der Überprüfung der Leistung der Seite, die von Feldern, Komponenten und einer Reihe anderer Metriken, die sich auf ihr befinden, beeinflusst wird. Sie gibt einen detaillierten Überblick darüber, was die Leistung am meisten beeinflusst und wie diese verbessert werden kann.
Überlegungen zur Verwendung von Dynamic Forms
So großartig die Dynamic Forms auch sein mögen, die Funktion ist noch relativ neu und weist noch Einschränkungen und Faktoren auf, die berücksichtigt werden müssen. Die offensichtlichsten sind:
- Dynamic Forms werden nur auf Datensatzseiten für benutzerdefinierte Objekte, Accounts (einschließlich personalisierte Accounts), Kontakte und Opportunities unterstützt.
- Bei der Migration einer Seite zu Dynamic Forms werden nur Felder und Abschnitte, die Felder enthalten, berücksichtigt. Andere Elemente im Seitenlayout, wie z. B. benutzerdefinierte Links und Leerräume, werden nicht berücksichtigt.
- Die Komponenten „Field Section" und „Fields” werden auf mobilen Geräten nicht unterstützt. Bei allen migrierten Seiten wird automatisch eine neue Komponente „Record Detail – Mobile" hinzugefügt. Wenn man die Seite ganz von vorne baut, muss die Komponente manuell hinzugefügt werden. So oder so ist die Komponente nicht dynamisch.
- Weitere Details finden sich auf den Seiten Dynamic Forms Limitations und Dynamic Forms Known Issues.
Fazit
Lohnt es sich also, Dynamic Forms zu verwenden? Ja, auf jeden Fall! Durch den Einsatz der Dynamic Forms lässt sich die User Experience ungemein verbessern, ohne die technische Tiefe zu stark und unnötig zu vergrößern. Dynamic Forms ist definitiv die Funktion, die in Zukunft, sofern es die Einschränkungen und der Use Case es zulässt, eingerichtet und gepflegt werden sollte.
Wenn Sie mehr zu dem Thema erfahren möchten, kontaktieren Sie uns gerne!
Photo by Silas Baisch on Unsplash
