Salesforce weckt immer wieder den Erfinder in einem. Dieses Mal: Wir beweisen, dass Teams für benutzerdefinierte Objekte doch möglich sind.
Account-, Opportunity- und Case-Teams sind eine gute Möglichkeit bei einem eher restriktiven Sharing Model, um Zugriff auf Datensätze dieser Objekte sehr granular zu ermöglichen. Mithilfe von Teams ist es erlaubt auf Benutzerebene zu definieren, wer den Datensatz nur sehen oder auch bearbeiten darf. Daher ist es nicht verwunderlich, dass alt eingesessene Systemadministratoren und Salesforce Berater, wie Sie und ich, Teams auch für andere Objekte - vor allem benutzerdefinierte Objekte - herbeisehnen.
Es gibt dafür auch schon eine Idee in der Community. Doch wenn man hier auf den Status schaut, möchte man gleich den Glauben verlieren. Doch verzweifeln Sie nicht zu sehr. Ich werde Ihnen jetzt eine Lösung vorstellen, bei der man weder nach Classic wechseln noch darauf warten muss, dass es sich Salesforce-Macher noch einmal anders überlegen.
Hintergrund
Wie in jedem Beratungsunternehmen arbeiten wir in Teams an Projekten. Daher ist es auch nicht weiter verwunderlich, dass wir in unserer Salesforce Organisation ein Objekt mit dem Namen "Project" haben. Das war bislang eine einfache Sache, aber nach Einführung der neuen Datenschutzgrundverordnung sollte nicht mehr jeder alle Projekte und damit verknüpfte Datensätze sehen, sondern nur noch die einzelnen Teammitglieder sollten ihre eigenen Projekte sehen können. Schon allein an der Formulierung der Problemstellung können Sie sich vorstellen, in welchem Dilemma ich steckte.
Ein etwas technischer Hintergrund
Nachdem die Recherche nach einer Lösung mich fast an den Rand der Verzweiflung gebracht hatte, widmete ich mich noch einmal dem Studium des umfassenden Objektkatalogs der Salesforce Plattform. Schon oft hatte mich der schon gerettet. Hier fielen mir zu vielen Standardobjekten "Share"-Objekte wie "AccountShare", "CaseShare" oder "OpportunityShare" auf. In der einführenden Beschreibung heißt es "Represents a sharing entry". Ich fühlte mich schon auf dem richtigen Weg. Wenn es mir also möglich wäre eine Art "ProjectShare"-Datensatz zu erstellen, dann wären Teams nicht mehr weit.
Ich vertraute mich also wie immer in Notsituationen meinem besten Freund dem Flow an und fühlte mich zunächst enttäuscht als ich ein solches Objekt nicht unter den Auswahlmöglichkeiten in der "Record Create"-Komponente fand. Nach mehreren gedanklichen Einbahnstraßen wagte ich es schließlich in meiner Sandbox das Objekt "Project" unter den Sharing Settings auf "Private" umzustellen. Jetzt war auch das Objekt "Project__Share" im Flow zur Erstellung zu finden.
Zum "Share"-Objekt waren mir jetzt also zwei Dinge klar:
(1) Benutzerdefinierte Objekte müssen in den Sharing Settings auf "Private" umgestellt werden.
(2) Ob von Standard oder Benutzerdefiniert auf "Share"-Objekten sind stets die gleichen Felder zu finden:
- Access Level - was entweder auf "Read" oder "Edit" festgelegt werden kann.
- Objekt Id - die natürlich festlegt, welcher Datensatz geteilt werden soll
- Row Cause - das anzeigt durch welche Aktion das Objekt geteilt wurde, sei es weil man Inhaber ist, durch eine Child-Beziehung oder manuell.
- User oder Group Id - wodurch der Datensatz mit einem einzelnen Nutzer oder einer Öffentliche Gruppe geteilt werden kann
Und plötzlich gibt es Project Teams...
... mit echten Project Team Members.
Mein bester Freund hatte mich nicht im Stich gelassen. Jetzt erstellte ich also ein eigenes Objekt "Project Team Members". Es besitzt im Moment nur ein Look-Up-Feld zum Benutzer. Im nächsten Schritt baute ich einen Prozess.
Es reicht ein Project Team Member zu einem Projekt hinzuzufügen, um den Prozess auszulösen, der wiederum einen Flow anstößt. Dessen einzige Aufgabe ist es, einen Datensatz des "Project__Share"-Objektes zu erstellen. Im Moment ist im Flow noch festgeschrieben, dass jedes neue Teammitglied nur Lesezugriff auf das Projekt bekommt. Doch theoretisch ist es vorstellbar, sogar den Benutzer darüber entscheiden zu lassen, ob nur Lese- oder auch Schreibzugriff gewährt werden soll. Ein wenig schwieriger könnte es werden, wenn auch die Möglichkeit zum Hinzufügen einer Gruppe als Teammitglied möglich sein soll. Hier kann der Weg über ein eigenes Auswahllistenfeld, das die Namen der Public Groups zur Auswahl stellt, empfohlen werden.
Zum Schluss bleibt also festzuhalten, dass Salesforce den Erfindungsreichtum seiner Anhänger immer wieder herausfordert. Mit Erfolg!
