Winter 22 - das Ende von Process Builder und Workflow Rules angekündigt

Winter 22 - das Ende von Process Builder und Workflow Rules angekündigt

Einen Trauermarsch, bitte

Frühestens zu Winter 23 - nur schon mal zur Einstimmung: Workflow Rules und Process Builder sollen zu Grabe getragen werden,  was nur so viel heißt wie: Ich kann keine neuen mehr erstellen. Flow gehört die Zukunft, Tools sollen den Umstieg vereinfachen. Details bei Jennifer W. Lee im Salesforce Admin Blog, Zitat:

We plan to begin blocking the ability to create new processes and workflows in Winter ’23, pending successful migrations and community input.

Außerdem trifft es diesmal ein sObject, ein Produkt und eine ganze Cloud:

Gibt’s jetzt auch in Lightning aber nicht im Standard

Erinnert sich jemand noch an Classic? Da konnte man in Standard Dashboards Visualforce Pages einbauen und somit seine eigene Visualisierung für Salesforce Daten in Dashboards einbauen. Mit Winter 22 gibt es die Möglichkeit, in einer Beta LWCs in Tableau CRM Dashboards einzubauen (API hier).

Das ist ein alter Wunsch in der Community. Älter noch als der Link zur Idea vermuten lassen mag. Meinem Email Verlauf zufolge war die ursprüngliche Idee auf dem IdeaExchange nämlich Components in Standard Dashboards zu haben, nicht in Tableau CRM. Irgendwie ist sie zu einer “Tableau CRM only” Idee geworden. Was in Konsequenz bedeutet, daß das ehemals kostenlose VF-In-Standard-Dashboard zu LWC-In-Tableau-CRM-Dashboard wurde und dieses CRM ist ein zusätzlicher Kostenfaktor.

LWCs: Dynamic Interactions, Lightning Web Runtime und Lightning Security Beta

Dynamic Interactions und Component AppExchange

Eine Record Page besteht aus mehreren Bausteinen, die eine Administratorin nach den Bedürfnissen des Unternehmens zusammenstellen kann. Problem: Die Bausteine sprechen nicht miteinander ohne daß eine Entwicklerin ihnen das beibringt. Noch dazu muß sich die Entwicklerin für einen von verschiedenen Wegen entscheiden, wie genau die Bausteine miteinander sprechen sollen.

Mit Dynamic Interactions (DI) kann die Administratorin (mit)entscheiden und konfigurieren, welcher Baustein auf welchen hört und braucht die Entwicklerin gar nicht. Natürlich nur, sofern die Entwicklerin Dynamic Interactions mitbedacht und eingebaut hat. Darin liegt die erste Hürde: Der Baustein muß dafür konzipiert sein. Ich denke, in einer ersten Phase werden hauptsächlich Devs sich den Weg mit Message Service oder Aura Wrapper sparen.

Die zweite Phase und die nächste Hürde liegt in der steigenden Komplexität, wenn man das Konzept Dynamic Interactions mit dem - immer noch im Wachkoma liegenden - Component AppExchange verbindet.  Angenommen alle Components sind für DI ausgestattet, dann muß ich als Admin einen Überblick behalten, wer mit wem warum spricht. Da ich als Admin kein Entwickler bin, stehe ich schnell im tiefen Wald, wenn ich irgendwo einen Fehler in der Konfiguration gemacht habe.

Salesforce Developer Website Relaunch mit Lightning Web Runtime

Salesforce hat die Developer Seite neu gebaut - mit Lightning Web Runtime (LWR) - das ist LWC OSS mit schnellerem Unterbau in der Experience Cloud oder selbst gehostet. Ich kann mir gut vorstellen, daß LWR bauen rasch von der Hand geht und die Ergebnisse flotter sind als zum Beispiel die Standard Templates - die für bestimmte Use Cases gemünzt sind. Einen Blog auf Experience Cloud mit LWR zu bauen, scheint sinnvoller als ein Template umzubiegen.

Lightning Web Security

In das LWR/LWC Paket gehört Lightning Web Security (Beta), das Locker Service für LWCs beerbt. Die neue Security Engine macht (u.a.) zwei Sachen möglich:

  • Einen Shadow-DOM-Light Modus, so daß man eben doch an anderen Components im DOM fummeln darf - gedacht ist das für die Experience Cloud. Strenggenommen ist das ein LWC Feature.
  • Cross-Namespace Component Use: Die Möglichkeit Components außerhalb des eigenen und des Standard Namespaces zu nutzen.

Multi Factor Authentication

MFA hat viele Fragen aufgeworfen, eine davon ist geklärt: Wenn mein Identity Provider schon SSO mit MFA für mich macht, muß ich in Salesforce nichts mehr tun. Man gibt sich redlich Mühe, allerhand Materialien und Ressourcen für den Rollout bereitzustellen. Zur Erinnerung: MFA wird im Februar 2022 “enforced” und ist bereits Teil des Vertragswerks mit Salesforce.
In der Beta ist aktuell ferner, mehr Tools zur Authentifizierung (z.B. Windows Hello) nutzen zu können.

Flows und Screen Components rechts, OmniStudio links

Es ist schon so, daß OmniStudio und das Konzept der FlexCards im Moment nur Industry Kunden erfreuen. Anders als noch vor kurzer Zeit, gibt es jetzt aber eine OmniStudio Dev Org mit der man sich Flows rechts und FlexCards links anschauen kann.

Die Sprachregel aktuell lautet in etwa: FlexCards sind fürs Front End, Flows eher fürs das Backend. Stimmt auch, wären da nicht Flow Screen Components und die große Community mit dem Ziel, daß Admins praktische UIs für Anwenderinnen bauen (eher: basteln) können. Die Zukunft wird spannend, weil FlexCards technisch, konzeptionell und in der Handhabe - meiner Meinung nach - um einiges weiter sind als Flows und Components. Allerdings sind sie weiter weg von Visual Development.

Breaking Changes

Lieblingsfeatures

sObject Trigger
Show API Names in Flow Debugger
  • Wesentlich mehr Begeisterung habe ich übrig dafür, daß ISVs mit Flow Templates wenig anfangen konnten. Admins können paketierte Flows, sofern erlaubt, direkt editieren/überschreiben - großartig.
  • Leider erst in Developer Preview - habe seit Feed Based Layouts schon Vorfreude: Invocable Actions aus Apex. Fernes Szenario: Admin stellt eine Record Action zur Verfügung, die im Hintergrund einen Flow nutzt. Diese Action kann ich nun aus Apex aufrufen. Naheliegender: Es gibt eine Standard Action für Chatter Posts. Die ist wesentlich weniger Aufwand als die ConnectAPI.
  • Entwicklerinnen können in VS Code für Apex Klassen, LWCs und viele anderen Metadaten eigene Templates verwenden.
  • Einstein Data Detect gehört zu Salesforce Shield und ist ein (bezahltes?) Managed Package, das nach DSVGO relevanten Datenmustern suchen und diese flaggen kann.
    Die Frage, wie man lose Dahingeschriebenes wie volle Namen oder Kreditkartennummern loskriegt, wird noch zu selten gestellt - war aber eigentlich auch schon zu Chatters besten Zeiten hoch relevant.
Einstein Data Detect

Developer

View LWC Dependencies

Admins

The Named Credential event type is free to all customers. Customers who purchased Salesforce Shield or Salesforce Event Monitoring add-on subscriptions can use the EventLogFile object to monitor events.
  • In eine ähnliche Kerbe schlägt der CORS Event Type (meine Hervorhebung). Das zugehörige Release Update ist hier.
It’s available for free for two releases because it’s intended to help you prepare for the enforcement of the Enforce CORS Allowlist for Lightning Apps release update.
Column Layout

Für Nutzer

  • Tabellen im Case Email Composer. Aufmerksame Beobachter der Salesforce Trust Seite werden sich jetzt ein Lächeln erlauben, denn das Feature verändert den Rechtsklick im Composer. Das hat so viele Nutzer verwirrt, daß Salesforce einen Alert ausgeben mußte.
Table Button
Table with right-click menu shown
  • Trailhead in Slack - finde ich praktisch, weil ich dann besonders bei neuen Teammitgliedern nicht alles erst in Google suchen und dann nach Slack kopieren muß, wenn es um ein Trailhead Modul geht. Außerdem: Trailhead Profile in Slack ansehen, auch das spart einen Gang.
  • Quip Data Mentions unterstützen jetzt Multipicklist und Dependent Picklists.
  • In High Velocity Sales herausfinden, welche Templates am besten bei den Empfängern ankommen
Performance of Templates

Manchmal purzeln Features, von denen wußte ich gar nicht, daß sie fehlen: Die Activity View nach Fälligkeitsdatum sortieren

Sort by Upcoming Date
  • Noch mehr Felder in Berichten bearbeitbar. In der Beta vom Expanded Inline Editing gibt es neue Felder, darunter die wichtigen Lookups. Empfehlung: Anschalten und auf Performance achten. Folgendes geht nicht:
    • Task and event object fields
    • Owner fields
    • System fields, such as Record ID and Created Date
    • Compound fields, including name and address fields
    • Encrypted text fields
    • Formula fields
    • Standard fields of type auto number, rollup summary, record type, master-detail, long text area, rich text, and hierarchy
    • Fields where editing isn’t permitted due to restrictions in the page layout
    • Fields in a Salesforce object that doesn’t have a record type