Tipps & Tricks für Salesforce Administratoren: Die Top 5 Links, die mich bei meiner Arbeit mit dem Visual Flow richtig weitergebracht haben.
Ich mag den Visual Workflow. Er ist vielseitig, kommt mit jedem Benutzer gut klar und hat in meiner Karriere als Sales Cloud Beraterin schon oft einen Apex-Entwickler ersetzt. Oft werde ich vor Aufgaben gestellt, bei denen ich mich frage: "Hey, geht das nicht mit einem Flow?" In solchen Situationen beginne ich im Internet zu recherchieren und finde dort Blogs, Antworten und Lösungsideen von Leuten, die genauso in den Flow vernarrt zu sein scheinen wie ich.
In diesem Beitrag möchte ich Ihnen meine Favoriten vorstellen.
Link 1: Benutzer vom Schreiben von Prosa abhalten
Anwendungsfall
Bei einem aktuellen Kunden habe ich die Erstellung von Besuchsberichten als einen eigenen Datensatztyp des Objektes "Task" mithilfe eines Flows umgesetzt.
"Wieso Flow?", werden Sie sich jetzt fragen. "Eine Quick Action hätte doch auch gereicht." Ja, das hätte sie bei anderen Kunden. Doch dieser Kunde wollte neben der Erstellung des Besuchsberichts noch die Möglichkeit Follow-Up-Aufgaben gleich mit zu erstellen. Also musste ein Visual Flow her.
Hier bekommen die Benutzer u. a. in einem Freitextfeld die Möglichkeit zu beschreiben wie der Besuch war oder welche Punkte besprochen wurden. Der Text wird dann in das Standardfeld "Beschreibung" auf dem Task geschrieben.
Als erfahrener Salesforce Administrator kennen Sie es sicher: Benutzer schreiben gern ganze Prosa in ein Freitextfeld wenn sie einmal Gelegenheit dazu bekommen. Leider ist die Zeichenanzahl von Standardfeldern begrenzt. Oft scheitert der Flow dann beim Erstellen des Datensatzes weil für die Ausführungen zur Lieblings-Kaffeesorte des CEOs und ihrer Herkunft kein Platz mehr ist.
Link zur Lösung
Um dieses Problem zu lösen hat mir der Salesforce Dude sehr geholfen. In seinem Blog Post "Validating Flow Input: An Ounce of Prevention" beschreibt er nicht nur, wie man den Benutzer dazu zwingt nur wirklich wichtige Sachen aufzuschreiben, sondern es gibt auch Vorlagen zur Validierung von E-Mail-Adressen, Webseiten oder Postleitzahlen.
Link 2: Flow vs. Multi-Select Picklists
Anwendungsfall
Fehler passieren nun einmal. Und so passiert es auch manchmal, dass ein Kunde eine Multi-Select Picklist einsetzt. Nun war folgende Problemstellung zu lösen:
Auf dem Account gab es nun diese schreckliche Pickliste. Die ausgewählten Werte bestimmten bisher nur Benutzer. Nun sollte ein Automatismus eingeführt werden, der je nach dem welcher Code in einem anderen Freitextfeld geschrieben war, Werte zur aktuellen Auswahl hinzufügt oder die ersten Werte überhaupt auswählt.
Doch das war noch nicht das Schwierigste: Waren schon Werte in der Pickliste vorhanden und unter ihnen auch noch welche, die vom eingetragenen Code abhängig waren, so sollten diese kein zweites Mal eingetragen werden.
"Puh, eine ziemlich harte Nuss...", dachte ich mir. Doch auch hier verschaffte das Internet Abhilfe.
Link zum Ziel
Nicht nur, dass ich bei dieser Aufgabe zum ersten Mal Custom Settings in einem Flow benutzt habe, ich lernte auch wie man Werte aus einer Multi-Select Picklist in einer Collection Variabel speichert.
Der Blogpost "Parsing An Object's Multi-Select Picklist Selection To Use In Visual Flow" war mein Schlüssel zum Ziel.
In einem ersten Schritt speicherte ich nun schon vorhandene Werte also in einer Variabel.
Im zweiten Schritt suchte ich das richtige Custom Setting heraus, das mir für den eingetragenen Code die richtigen Picklistenwerte lieferte.
Danach im letzten Schritt verwendete ich einen Loop und überprüfte ob Picklistenwerte aus dem Custom Setting schon in der Multi-Select Pickliste vorhanden waren.
Link 3: Picklist Choices sind immer verpflichtend!
... Nein nicht immer. Nicht, wenn man den kleinen Trick kennt, den ein anderer eifriger Salesforce Administrator gefunden hat.
Der Blogpost "Non mandatory dropdown field in Flow" war Grundstein für viele Lösungen bei Kunden, aber auch in unserer eigenen Salesforce-Umgebung. Hier hatte ich eine sehr wichtige Sache mit einem Flow umgesetzt: die Beantragung von Urlaub.
Da Flows auch auf Startseite und Datensatzseiten eingebaut werden können, war das die perfekte Lösung. Ich eckte bei der Erstellung dieses Flows natürlich mit dem Screenelement "Picklist Choice" an, die - aus einem jenseits meiner Vorstellungskraft liegenden Grund - immer verpflichtend ist. Ich benutzte dieses Element, um die Auswahl eines Benutzers möglich zu machen, der dazu ersonnen war einen selbst zu vertreten.
Doch was war nun wenn man einfach unersetzlich ist? Nun, jetzt ist es für mich jedenfalls möglich, keinen meiner Arbeitskollegen zuzumuten in meine riesigen Fußstapfen zu treten. Eine andere Anwendungsmöglichkeit fand ich bei der Erstellung des im ersten Kapitel angesprochenen Besuchsberichts. Werden Follow-Up-Aufgaben innerhalb dieses Flows erstellt, so ist als Ausgangswert immer der aktuelle Benutzer ausgewählt.
Link 4: Buttons können auch "Günther" heißen
Anwendungsfall
Ein Kunde wollte seinen Benutzern ermöglichen eine Einkaufssperre über bestimmte Accounts zu verhängen. Gesagt, getan. Ich erstellte also einen Flow mit einer Sicherheitsabfrage und bettete ihn in eine Visualforce Page ein.
Warum Visualforce Page und Flow? Das ist eine berechtigte Frage, die Sie sich da stellen. Die Antwort: Der Kunde wollte mit derselben Funktion auch Accounts wieder entsperren und einer Quick Action kann man schlecht sagen, dass sie "Entsperren" heißen soll, wenn der Account gesperrt ist und umgedreht.
Nun blieb also nur noch ein Problem: der Button "Next". Auf der Willkommen-Seite meines Flows stand "Bitte klicken Sie auf 'Next' um den Account zu sperren.". Hier lag das Problem. Für den Benutzer ist es nicht intuitiv wenn er zum Sperren auf "Weiter" klicken muss. Die Tester fanden "Das muss anders sein!" und ich stand vor einer riesigen Herausforderung.
Link zum Glück
Die Herausforderung wurde kleiner als ich herausfand, dass sich jemand anderes genau dieselbe Frage stellte und prompt eine Antwort bekam.
Die Antwort auf die Frage "Change Flow button label from 'Next' to 'Finish' in VisualForce page" brachte auch die Lösung für mein Problem. Und so heißt der "Next" Button je nach Situation "Sperren" oder "Entsperren". Damit sind der Fantasie keine Grenzen mehr gesetzt. Wie wäre es zum Beispiel mit einem Button namens "Günther".
Link 5: Alles neu nach dem Flow
Anwendungsfall
Der Anwendungsfall bleibt der gleiche wie bei "Link 4" beschrieben. Diese dort beschriebene Einkaufssperre versperrte auch mir so manchen Weg.
Mein Problem dieses Mal: Der Flow aktualisierte den Datensatztyp des Accounts, nur wurde das nicht gleich sichtbar. Die Seite wurde nicht aktualisiert nachdem der Flow beendet war.
Link zur Lösung
Nach stundenlanger Suche stieß ich schließlich auf die Lösung meines Problems. In Bob Buzzard's Blogpost "Refreshing Record Detail from Embedded Visualforce Page" ist beschrieben wie ein Update auf einer Visualforce Seite die ganze Seite neu laden kann.
Dann sah ich es deutlich vor mir. Das Stückchen Code, wonach ich seit vier Stunden suchte. Ich erstellte also eine neue Visualforce Seite, fügte das "outputPanel"-Element ein und legte diese Visualforce Seite als "Finish Location" für den Flow fest. Und schon wurde die Seite aktualisiert ohne dass ich auch nur eine Zeile APEX Code geschrieben habe.
Fazit
Ich kann es nur wiederholen, ich mag den Flow. Ob ich nun mit den schrecklichsten Multi-Select Picklisten oder wahren Poeten unter meinen Benutzern konfrontiert war, ich konnte mich jederzeit auf einen Freund verlassen. Mit diesen hilfreichen Links wird er hoffentlich auch zu Ihrem besten Freund.