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:

• “IoT Cloud has been discontinued.”
• Salesforce Anywhere Beta - das war die komische Mischung aus Quip und App Builder auf dem mobilen Endgerät.
• MetricsUsageObject  gibt es nicht mehr und wurde schon lang von App Analytics beerbt. Vermißt kein Mensch/ISV, weil es nie gut funktioniert hat.

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

• Obacht, ListViews und Record Pages können kaputt wirken: Neue Permission nötig für developerName. Knowledge Article hier.
• “Users can no longer log in to Salesforce by using a username and password as URL query string parameters to the login URL.” Wie, das war noch möglich?
• Auch Product2 erhält Sharing ab Spring 22. Wie üblich, besonders auf Guest User aufpassen.
• Nochmal Guest User: Im Sommer 22 wird die “Run Flows” Permission abgedreht. Das bedeutet, daß man dem Guest User expliziten Zugriff auf individuelle Flows geben muß. Das könnte in Arbeit ausarten.
• Custom Events in LWCs prüfen, die mit ihrem Parent sprechen wollen. Die Events müssen zwingend composed: true sein, bubbles: true allein reicht nicht mehr.

Lieblingsfeatures

• Die Batch Size für Platform Events wurde von 2000 auf die für die Platform üblichen 200 reduziert. Sehr gut finde ich das.
• And the winner among paid stuff is: FieldService (Augmented Reality!), dicht gefolgt von Salesforce Industries. Gewonnen haben sie in der Kategorie “Kluge Features”. Im Vergleich: Salesforce Revenue Cloud hat fast keine Innovation zu bieten in diesem Release.
• Überfällig. Bei dem Hype um Record Triggered Flows will ich auf den ersten Blick sehen, welcher Flow zu welchem sObject gehört. Ebenso überfällig: Subflows aus Record Triggered Flows aufrufen und Rollback Optionen.

• Semi-Begeisterung: Wenn ihr einen Flow aus einem managed Package benutzt, werden nicht mehr alle Fehlerdetails angezeigt, dafür kann ich mir API Namen im Flow Debugger anzeigen lassen und andere Verbesserungen wie zum Beispiel Scheduled Flows debuggen und hilfreiche Shortcuts.

• 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.

• Auch lang drauf gewartet: Prompts und Guidance an eine bestimmte Record Page Component kleben und Prompts, die mit RecordTypes kompatibel sind.

Developer

• Functions sind GA, dazu passend Apex Mocks für Functions. Preispunkt: 2000€ / Org / Monat mit 10 Millionen Aufrufen inklusive. Mit diesen Angaben läßt sich nun entscheiden, ob ElasticCompute über die Platform sinnvoll ist. Im übrigen liegen alle Daten in den Vereinigten Staaten.
• Es gibt einen Development Guide für Salesforce Scheduler
• Eine Release Update, das CORS nicht nur browser- sondern auch serverseitig erzwingt. Soll Spring 22 kommen, bitte eingehend unter die Lupe nehmen.
• Recommendation Builder ist in Managed Packages jetzt möglich
• Erst im Pilot, aber eine Component, die von Eurer Experience direkt mit Eurer Marketing Cloud sprechen kann.
• Für Selbst-Registrierung in Experiences zum Beispiel kann endlich die Endnutzersprache festgelegt werden
• Das sObject TaskRelation unterstützt PK Chunking
• Die Lightning Web Runtime bringt einige Verbesserungen für Experience Cloud Developer, darunter Apex Continuation und @salesforce/site. Zu letzterem gibt’s noch keine Informationen, weil die Developer Dokumentation noch Summer 21 anzeigt.
• Mich deucht, wir hatten hasPackageLicense(packageId) schon in der Form UserInfo.isCurrentUserLicensed(namespace). Die Neue Methode ist für Second Generation Packages gedacht, weil sich da viele Pakete denselben Namespace teilen können.
• Change Data Capture ist etwas bekömmlicher für ISVs geworden. Die Installation bricht nicht mehr ab, wenn die Org schon zu viele CDC Events definiert hat.
• Nochmal ISVs: Rezepte, wie man App Analytics Data in Tableau CRM konsumiert samt Ideen für KPIs.
• Fehlt ja fast nur noch CodeBuilder, um LWCs in Org zu editiern. Immerhin sehen wir sie jetzt samt ihrer Abhängigkeiten:

• Etwas weniger Arbeit zwischen Strings und Enums mit Enum.valueOf()

Admins

• Cool: Auch Browser Extensions über CORS Einstellungen freischalten können
• Wer sich bisher vor MyDomain erfolgreich gedrückt konnte, wird mit diesem Release fällig - im Zweifel wird aus der OrgId eine URL generiert. Außerdem läßt sich abschalten, daß man via SOAP API via login.salesforce.comauf die Org kommt. Ich kann mir vorstellen, daß man viele Dritt-Anbieter sofort abgedreht bekommt mit dieser Option - daher Obacht.
• Scoping Rules (Beta) haben keinen Einfluß auf Sharing. Sie sollen dabei helfen, Nutzer effizienter zu machen. Wenn im operativen Geschäft, keine Opportunities und deren Aufgaben älter als 3 Monate relevant sind, müssen die in einer Suche auch nicht auftauchen (wohl aber im Report übers letzte halbe Jahr).
• Eine Org-Weite No-Reply Email Adresse einrichten (Release Update)
• OmniChannel Flows und OmniChannel Flow Templates sind GA. Einfacher Omni Channel aufsetzen und anpassen. Gute Sache, war Gefrickel. Das mäandert durch die ganze Sevice Cloud, zum Beispiel auch bei/mit Voice, da aber noch Beta.
• User Email Adressen Domains erzwingen, z.B. alle User Emails müssen auf @company.com enden.
• Nutzern temporär Berechtigungen zuweisen.
• Bei Schedule-Triggered Flows den Default Workflow User angeben (dazu muß der Flow auf API Verison 53.0/Winter 22) sein. Ferner werden pausierte Flows mit einem Release Update im selben User Context wieder aufgenommen und ein anderes Updates soll dafür sorgen, CPU Time korrekt bei Flows und Process Builder messen zu können.
• Salesforce schenkt uns (wenige) Surveys in der Service Cloud samt Setup.
• Bin nicht ganz sicher, was hinter Incident Management steckt, aber es ist jetzt für neue Service Cloud Orgs da: “All new Service Cloud orgs can access Incident Management right out of the box.” Muß vom Laster gefallen sein in der Corona Zeit.
• Mit dem neuen “Named Credential Event Type” mithören, wer oder welche Pakete eben diese Credentials nutzen.

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.

• Enhanced Domains kommen im Sommer 22, bitte rechtzeitig kontrollieren - insbesondere auch jene, die Links von Hand geschrieben irgendwo eingebaut haben.
• Wenn man mal mehr zu sagen hat: Betreffzeile in Lightning Email Templates mit bis zu 1000 Zeichen statt bisher 230 (was für Classic auch so bleibt), dazu passend: Zeilen und Spalten (aka Column Layout) in Email Templates sind nun auch neu

• Templates und besseres Setup für Bots.
• Mit 20 statt bisher 50 Beispielen pro Einstein Intent Datenmodell wird das Rumspielen ganz erschwinglich. Einstein Vision reduziert mehr im Verhältnis: 50 statt 200 Beispiele.
• Ein PushCount Feld auf Opportunity. Wie oft wurde das CloseDate verschoben?
• Tableau CRM trifft CDP (Beta)

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.

• 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

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

• 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