Feature Update

Es wurden einige Funktionen von Talentpool geändert. Abgesehen von dem neuen Namen wurde es auch um Funktionen erweitert. Der Matching-Prozess wird durch Status unterstützt, man kann Schritte und Aktionen mit Hilfe von Flows selbst definieren und Statusübergänge werden protokolliert.

Talentpool wurde in Matchlist umbenannt und Talentpoolmitglieder sind jetzt Matches. Mit der Namensänderung werden die Funktionen besser widerspiegelt. Auf der Matchlist vom Typ Jobeinführung werden Kandidaten abgeglichen/gematcht und auf der vom Typ Kandidateneinführung werden die Ansprechpartner der Unternehmen abgeglichen/gematcht. Ausgehend von diesen Listen aus kann man dann Aktionen anstoßen (per E-Mail kontaktieren oder eben nicht) und einen Status entsprechend dem Fortschritt jedes Abgleichs/Matches verwenden. Zu diesem Zweck wurde der Matchstatus eingeführt, bei der es die Werte „Match/Übereinstimmung“, „Qualifiziert“, „Abgelehnt“ und „Engere Wahl“ gibt. Natürlich können diese bei Bedarf modifiziert und erweitert werden, sodass sie zu den Abläufen in Ihrem Unternehmen passen. Der vorhandene Status wurde in Kommunikationsstatus umbenannt, damit die beiden Statusfelder besser unterschieden werden können.

Um Aktionen beim Matching-Vorgang einzurichten, kann man Matching-Schritte selbst definieren. Die vorhandenen Aktionsschaltflächen von Talentpool wurden bereits konvertiert. Man kann neue Aktionen hinzufügen, die man über Bildschirm-Flows ausführt. Diese Aktionen kann man je nach aktuellem Matching-Status, Kommunikationsstatus und Datensatztyp sichtbar machen.

Um einen besseren Überblick über Aktionen und Bearbeitungszeiten zu erhalten, wird jede über die Matchlist ausführte Aktion protokolliert. Man sieht von welchem Matching-Status, zu welchem Matching-Status, das Statusdatum sowie die zugehörigen Daten wie Account, Team, Teamgruppe und Business Label. Außerdem wird die Matchliste mit der Bewerbung verknüpft, wenn diese ausgehend von Matchlist erstellt wird.

Setup
Um diese Funktion nutzen zu können, müssen Sie einige Schritte durchführen. Lesen Sie dieses Dokument mit den Anweisungen.

Konfiguration Aktionen „Personen suchen“

Neben dem neuen Konfigurationsschritt für Matchlisten und dem vorhandenen Konfigurationsschritt für den Bewerbungsprozess kann man nun auch Aktionen für „Personen suchen“ definieren. Auch hier haben wir die Standardaktionen bereits konvertiert. Man kann auch eigene Aktionen ausgehend von einem Bildschirm-Flow definieren. Hier kann eine Abhängigkeit zum Datensatztyp und zum Kandidatenstatus hergestellt werden. Dabei ist auf die Einstellung „Verfügbar für alle Status“ in Kombination mit „Mehrfachauswahl erlaubt“ zu achten. Mit einer selbst definierten Aktion kann man die Salesforce-Limits beim Ausführen von Workflows überschreiten. Daher kann man die Mehrfachauswahl nur dann anwenden, wenn man ein Limit für den Datensatztyp und/oder den Kandidatenstatus einstellt. 

Neue Konfigurationsmöglichkeiten bei allen Schritten

In den Einstellungen der „Matchlist“-Schritte, „Personen suchen“-Aktionen und „Bewerbung“ kann man die Aktionen jetzt in verschiedenen Bildschirmen einheitlich einrichten und pflegen. Folgendes ist jetzt möglich:

• Standardschritte werden jetzt über einem benutzerdefiniertes Label übersetzt. Alle vorhandenen (vordefinierten) Schritte werden mit einem Label versehen, sofern sie nicht bereits vom Benutzer geändert wurden. Es ist technisch noch nicht möglich, benutzerdefinierte Label für die Beschreibung von Bildschirm-Flows zu verwenden.
• Symbol-Farbe. Man kann nun seine eigene Farbe für die Farben definieren. Dies sollte ein Hex-Wert der entsprechenden Farbe sein. 
• Man kann jetzt die Bildschirmbreite für Bildschirm-Flows einstellen. Einige Komponenten benötigen mehr Platz. Man hat die Wahl zwischen Klein, Mittel und Groß. Wird nichts davon gewählt, wird standardmäßig der Wert „Mittel“ verwendet.

Setup
Um diese Funktion nutzen zu können, müssen Sie einige Schritte durchführen. Lesen Sie dieses Dokument mit den Anweisungen.

Es war bisher schon möglich, mehrere Dokumente aus der Platzierung heraus unterzeichnen zu lassen, aber das ist jetzt auch in anderen Bereichen der Anwendung (z.B. Kontakt, Arbeitsvertrag, Bewerbung) möglich. Mit dieser Funktion können mehrere Dokumente ausgewählt und in einer großen Übersicht zur Unterzeichnung vorgelegt werden. Der Unterzeichner muss dann nicht mehrere einzelne Dokumente öffnen und genehmigen oder unterzeichnen.

Es wurde auch ein zusätzlicher Filter implementiert, der von den vordefinierten Unterzeichnern des Dokumenttyps ausgeht. Dieser Filter verhindert, dass Dokumente, die für Kontakte bestimmt sind, z.B. Kandidaten vorgelegt werden. 

Anzeige kandidaten- und accountbezogener Dokumente und digitale Signatur des Status
Verwandte Dokumente zu Kandidaten und Konten können jetzt direkt aus verschiedenen Objekten heraus angezeigt werden. Um z. B. verwandte Dokumente aus dem Arbeitsvertrag anzuzeigen, können Sie jetzt das Kontrollkästchen "Verwandte Dokumente" verwenden. Wenn Sie dieses Kontrollkästchen aktivieren, werden alle Dokumente des Bewerbers und des Accounts (sofern vorhanden) angezeigt. Wenn Sie z. B. mehrere Dokumente des Bewerbers prüfen möchten und den Arbeitsvertrag geöffnet haben, müssen Sie nicht erneut suchen, sondern finden alles an der gleichen Stelle. Dies kann auch nützlich sein, wenn mehrere Dokumente digital signiert werden müssen und mit verschiedenen Objekten verknüpft sind, Sie diese aber trotzdem prüfen oder anpassen möchten.
 
Fortschritt der Signatur
Sie können nun auch den Fortschritt der Signatur in der Akte verfolgen. Wenn mehrere Unterzeichner ein Dokument genehmigen müssen, können Sie nun in der Akte unter Genehmigende sehen, wer zu welchem Zeitpunkt unterschrieben hat.

In diesem Feature haben wir die Möglichkeit geschaffen, neben Kursen auch Veranstaltungen im MSR zu erfassen, Veranstaltungen im Kandidatenportal zu veröffentlichen und Kandidaten über das Portal zu einer Veranstaltung anzumelden. Außerdem haben wir die Funktion vorhandener Kurs optimiert, die auch direkt für Veranstaltungen zur Verfügung stehen.

Was kann man jetzt mit Kursen und Veranstaltungen machen?

1. Zuweisen von Kursen an Kandidaten. Auf diese Weise können Kandidaten auch mehrere Kurse belegen. Im Portal sieht der Kandidat dann nur die für ihn relevanten Kurse.
2. Zuweisen von Kursen/Veranstaltungen an ein bestimmtes Business Label. Damit kann man Kurse/Veranstaltungen auf separaten Portalen anzeigen. Kandidaten, die mit dem entsprechenden Business Label verknüpft sind, sehen dann nur relevante Kurse/Veranstaltungen. Das Business Label ist eine bereits vorhandene Funktion.
3. Erfassen einer Datei zu einem Kurs/einer Veranstaltung im MSR, damit sie für den Kandidaten im Portal zu sehen ist. Dieses Dokument kann zusätzliche Informationen über den Kurs/die Veranstaltung enthalten.
4. Erfassen von einer Art Banner (HTML-Format) zu einem Kurs/einer Veranstaltung, sodass dieses für den Kandidaten auf dem Portal für den entsprechenden Kurs sichtbar ist.

Durch die Auswahl eines Wertes im Feld Kurskategorie-Filter wird festgelegt, welche Kurse aus welchen Kategorien der Kandidat sehen darf. Dieser sollte dann mit dem Wert des Feldes Kategorie im Objekt Kurs übereinstimmen. Außerdem haben wir das gleiche Feld auf dem Portal Controller erstellt, sodass man pro Controller (d.h. pro Kachel im Portal) festlegen kann, welche Kategorien und zugehörigen Kurse angezeigt werden dürfen.

Ein Beispiel für einige Einstellungsmöglichkeiten und das daraus resultierende Verhalten im Portal:

Durch die Eingabe des Feldes Label beim Objekt Kontakt verknüpft man das Business Label. Dieses Label bestimmt zusammen mit dem Wert im Feld Label und dem Objekt Kurs oder Veranstaltung die Zuordnung von Kursen zu einem bestimmten Label. Kandidaten mit einem Standardlabel A sehen dann im Portal die Kurse oder Veranstaltungen des Labels A. Das Objekt Business Label gibt auch an, welches Portal Domain für dieses Label verwendet wird. Über den Menüpunkt Portal Domain kann man den gleichen oder einen bestimmten Controller dafür einrichten.

In MSR kann jetzt eine Datei zu einem Kurs oder einer Veranstaltung hochgeladen werden. Es können auch mehrere Dateien hochgeladen werden, wobei jedoch nur die neueste Datei im Portal angezeigt wird.

Im Feld „Beschreibung“ kann nun auch Text mit Formatierung erfassen, der im Portal mit Formatierung angezeigt wird. Dieser wird immer oben angezeigt, unabhängig von seiner Position in den Portal Controller-Feldern.

Setup
Um diese Funktion nutzen zu können, müssen Sie einige Schritte durchführen. Lesen Sie dieses Dokument mit den Anweisungen.

Im letzten Release haben wir es den Kandidaten ermöglicht, sich mit größeren Lebenslaufdateien zu bewerben. Es ist jetzt auch möglich, größere Lebenslaufdateien in Salesforce zu verarbeiten, sowohl über die Lebenslauf-Dropzone auf der Hauptseite als auch über den Lebenslaufdatei-Upload beim Kandidaten.

Da die Verarbeitung größerer Dateien über einen anderen Weg erfolgt, werden die Benutzer benachrichtigt, wenn es sich um eine größere Lebenslaufdatei handelt:

Die Verarbeitung größerer Dokumente dauert länger als die einer kleineren Lebenslaufdatei. Außerdem ist es in vielen Fällen nicht möglich, das Foto des Kandidaten direkt aus dem Lebenslauf zu parsen. In diesem Fall muss man das Foto manuell hinzufügen.

Der Lebenslauf darf jetzt eine maximale Größe von 20 MB haben. Wenn man dies ändern möchte, kann man über Setup, Benutzerdefinierte Einstellungen, Textkernel-Einstellungen einen anderen Wert im Feld „Maximum Document Upload Size (MB)“ eingeben. Wenn dieses leer gelassen wird, wird die maximale Größe von 20 verwendet.

Wir haben eine Erweiterung für die Checklistenkomponente erstellt und auch deren Layout verändert.

Zunächst haben wir eine Schaltfläche hinzugefügt, um deutlich zu machen, dass man ein Dokument direkt hochladen kann. Dabei wird auf die Definition des Items Checkliste geachtet. Wenn eine einzige Dokumentenart mit dem Item verknüpft ist, wird diese automatisch verknüpft und man muss nur die Pflichtfelder ausfüllen. Wenn mehrere Dokumentarten möglich sind, wird eine Auswahl angeboten. Auch wenn ein Dokument generiert werden muss, muss man die richtige Dokumentenart selbst auswählen.

Wir haben auch Informationen hinzugefügt, wenn ein Dokument genehmigt oder abgelehnt wird. Der Grund für die Ablehnung ist sofort ersichtlich, und man kann sehen, wer dies veranlasst hat. Außerdem wird das Datum jetzt im deutschen Datumsformat angezeigt.

Wir haben mehrere Komponenten zum Einbinden in Flows und der Experience Cloud zur Verfügung gestellt

Skill Board

Diese Komponente kann man in Bildschirm-Flows verwenden, indem man die Komponente „Skill Board Matrix“ in einen Bildschirm einfügt. Diese Komponente erwartet eine Record Id. Dabei kann es sich um eine Record Id eines Kandidaten oder eines Jobangebots handeln.

Schritt Lohn im Platzierungsassistenten

Im Platzierungsassistenten gibt es einen Schritt, bei dem man den Lohn eingeben und die Einordnung in die Tarifgruppe vornehmen kann. In diesem Release bieten wir diesen Schritt für Bildschirm-Flows an, sodass man den Platzierungsassistenten selbst in Flows einbauen kann. Diese Komponente nennt sich „Placement Wizard Wages“. Das von dieser Komponente erwartete Input ist:

• CAO Code – Der Code des betreffenden Tarifvertrags
• Person Id – Die Id des Kandidaten
• Start Date – Das Startdatum des Platzierung

Diese Komponente liefert einen Output, der einige Variablen/Outputs enthält:

• functionObject – Funktion
• wageTable – Lohntabelle
• scale – Skala
• Step – Schritt
• wageDeterminiation – Lohnbestimmung
• wageApply – Angewandter Lohn
• wageRaise – Lohnzuschuss

Account-Hierarchie

Get Collection of Accounts. Diese APEX-Komponente steht zur Verfügung, um die Account-Hierarchie für ein bestimmtes Account abzurufen und diese in eine Sammlung von Variablen zu stellen. Zwei Parameter sind hier obligatorisch: „Account Id“ und „Only current and Child Accounts“. Mit dem Wert „True“ werden nur die Accounts und zugrunde liegenden Account abgerufen, mit „False“ die gesamte Struktur, einschließlich übergeordneter Accounts mit eventuell weiter verzweigten Subaccounts.

Checkliste

Man kann die Checkliste jetzt auch in einem Bildschirm-Flow anzeigen, um Dokumente einfach aus einem automatisierten Vorgang hinzuzufügen. Man zieht dazu die Komponente Checklist per Drag & Drop auf einen Bildschirm. Über den Parameter Record Id kann man die ID eines Kontakts, einer Platzierung, eines Arbeitsvertrags oder einer Bewerbung weiterleiten, um damit die vorhandene Checkliste abzurufen und neue Dokumente zur Checkliste hinzuzufügen.

Unterstützung von Phasen in Bildschirm-Flows

Seit kurzem ist es möglich, in Salesforce innerhalb eines Bildschirm-Flows mehrere Phasenvariablen einzurichten. Mit Hilfe dieser Variablen kann man den Fortschritt verschiedener Phasen oder Schritte auf aufeinanderfolgenden Bildschirmen in einem Bildschirm-Flow anzeigen. Das Ergebnis ist, dass man als Benutzer durch die verschiedenen Bildschirme geführt wird und genau sieht, wo man sich im Prozess befindet. Wir haben nun die Bildschirmkomponente „Flow Progress Bar“ mit folgenden Parametern hinzugefügt:

• Current stage: Mit einer Zuweisung legt man fest, welche der Phasenvariablen die aktuelle Phase ist.
• Active stages: Die Sammlung der Phasen.
• Type: Das Layout des Fortschrittsbalkens. Man kann hier zwischen „base“ (Brotkrümel) und „path“ (Pfad-Darstellung) wählen.

Zum erstellten Datensatz navigieren

Wenn ein Record/Datensatz in einem Bildschirm-Flow erstellt wird, kann man eine Komponente einfügen, um direkt zu diesem erstellten Datensatz zu navigieren. Jede Record-erstellen-Komponente weist automatisch eine recordId-Variable zu, die man bei Bedarf auch selbst einstellen kann. Dann platziert man die Komponente „NavigateToRecord“ auf den „Cavase“ und gibt folgende Parameter an:

• Action Target: Wert _self (im aktuellen Bildschirm öffnen) oder _blank (in neuer Registerkarte öffnen). Die Standardeinstellung ist _self, wenn dieser Parameter leer bleibt
• Record Id: die ID-Zuweisung der Aktion „Record erstellen“.

Experience Cloud

Wir haben auch die Komponente für Platzierungsdetails für die Experience Cloud-Portale hinzugefügt. Diese Komponente nennt sich „Placement Payment Info“ und erwartet die Id der Platzierungsdetails. Man kann diese also zu einem Platzierungsdetail hinzufügen. Schließlich ist es nun auch möglich, die Checkliste beim Kontakt in einem Experience Cloud-Portal zur Verfügung zu stellen. Dazu zieht man die Komponente „Checklist community“ per Drag & Drop auf das Portal. Dabei ist sicherzustellen, dass die Portalbenutzer Zugriff auf die APEX-Klasse msf.ChecklistCommunityController haben.

In diesem Release wurde der Metadatentyp Portal Document Controller, den wir zum Anzeigen und Hochladen von Kandidatendokumenten im Portal verwenden, in ein Portal Controller-Objekt umgewandelt. Dies dient der Verbesserung der Benutzerfreundlichkeit für Administratoren und um auf diese Weise allen Controllern einen einheitlichen Platz in MSR zu geben. Dadurch wurde es auch möglich, Spalten einzurichten, die bei Bedarf angezeigt werden können. Bisher wurden nämlich Standardspalten verwendet, die nicht konfigurierbar waren.

Die vorhandenen Portal Document Controller wurden automatisch konvertiert und können sofort verwendet werden. Es ist jedoch notwendig, das Seitenlayout und die Rechte der Administratoren zu definieren, um bei Konfigurationsänderungen darauf zugreifen zu können.

Neben der Konvertierung von Kandidaten Document Controller wurde auch der vorhandene Customer Document Controller-Typ in den neuen generischen Document Controller konvertiert. Auch hier erfolgt die Konvertierung automatisch.

Ebenfalls neu in diesem Release ist auch die Möglichkeit, größere Dateien im Portal zu verarbeiten. Im letzten Release war das Hochladen von Dateien über das Kandidaten- und Kundenportal auf 6 MB pro Dokument beschränkt. Ab sofort können Dateien bis zu 20 MB hochgeladen werden. Im letzten Release wurde die Einstellung „Maximum document upload size“ zu den Typen der benutzerdefinierten Metadaten „Portal Domain“ hinzugefügt, mit dem man die maximale Dateigröße angeben kann. Man kann hier einen Wert zwischen 1 und 20 MB eingeben. Wenn man nichts eingibt, wird die maximale Dateigröße von 20 MB angenommen.

Um den Benutzer darauf hinzuweisen, dass die Datei das festgelegte Limit überschreitet, kann man die Standardbenachrichtigung überschreiben. Man geht dazu über den App-Starter und übersetzt den Schlüssel DocumentsLargerThanNotAllowed. Den Teil „{0}“ kann man stehen lassen:

In diesem Release haben wir eine Integration mit Nétive Connect implementiert. Durch diese Integration kann man Jobangebote von MSP oder Endkunden erhalten, die Nétive nutzen und bei denen man ein Abonnement hat. Um diese Funktion nutzen zu können, muss man sich an seinen Customer Success Manager wenden. Der kann Sie über die Kosten und den Implementierungsvorgang informieren.

Ab diesem Release ist es nicht mehr möglich, E-Mails über Sendgrid zu versenden. Diese Option war auch verfügbar, wenn kein Flowmailer-Konto eingerichtet war. Dies ist insbesondere der Fall, wenn eine neue Sandbox erstellt wird. Bitte an den Support wenden, um Flowmailer auch für die neue Sandbox zu konfigurieren.

Abhängig von den Eigenschaften, die in der Job Status-Einstellung bei Typen für benutzerdefinierte Metadaten definiert wurden, kann man angeben, ob ein bestimmter Status einen erfolgreichen oder nicht erfolgreichen Abschluss des Prozesses garantiert. Bis zu diesem Release wurden auch die Optionen „Auf der Website anzeigen“, „Auf der Website seit“, „Auf der Website bis“ und „Job-Alert generieren“ deaktiviert.

In diesem Release haben wir dies geändert, sodass nur die Optionen „Auf der Website anzeigen“, „Intern anzeigen“ und „Job-Alert generieren“ deaktiviert werden. So kann man jederzeit nachsehen, in welchem Zeitraum das Jobangebot zur internen und externen Veröffentlichung zur Verfügung stand.

In der Gruppe GDPR-Einwilligung kann man eine E-Mail-Vorlage konfigurieren, die dem Kandidaten bestätigt, dass er seine GDPR-Datenschutzeinstellungen über das Portal aktualisiert hat. Ab diesem Release werden diese Vorlagen auch verwendet, um die getroffene Auswahl zu bestätigen, wenn der Kandidat seine Zustimmung direkt über den Link in der E-Mail verlängert oder widerruft.

Um dies einzurichten, geht man über den App-Starter oben links zu den GDPR-Einwilligungsgruppen. Hier kann man für jede Gruppe eine Lightning-E-Mail-Vorlage in den Feldern „E-Mail-Vorlage Bestätigung akzeptiert“ und „E-Mail-Vorlage Bestätigung Löschung“ festlegen.

Beim Erstellen oder Hochladen von Dokumenten werden ab diesem Release auch die Felder Team und Label ausgefüllt. So kann man über die Salesforce-Einstellung „Einstellungen zum Teilen“ bestimmte Dokumente je Team und/oder je Label autorisieren.

Jedes Mal, wenn man ein E-Mail-Fenster öffnet, rufen wir jetzt automatisch Ihre E-Mail-Signatur ab. Man muss diese also nicht mehr selbst manuell eingeben oder über eine E-Mail-Vorlage einfügen. Dies funktioniert überall dort, wo man manuell ein E-Mail-Popup-Fenster mit unserer E-Mail-Schaltfläche öffnet und der Inhalt normalerweise leer wäre.

Bei Aktionen, bei denen eine E-Mail-Vorlage automatisch angenommen wird (z.B. über benutzerdefinierte Metadaten oder einem Flow), geschieht dies nicht. Auch wenn man im E-Mail-Popup-Fenster manuell eine E-Mail-Vorlage auswählt, ersetzt deren Inhalt die Signatur. In diesen Fällen gehen wir davon aus, dass die Signatur Teil der gewählten E-Mail-Vorlage ist.

Man kann seine persönliche E-Mail-Signatur in seinen persönlichen Einstellungen (oben rechts) festlegen. Im Bereich E-Mail findet man die „Meine E-Mail-Einstellungen“.

Für deutsche Textkernel Search & Match-Kunden ist es möglich, Kandidaten für deutsche Jobfeed-Jobangebote zu finden. Möchten Sie diese Funktion nutzen? Dann wenden Sie sich bitte an Ihren Customer Success Manager, um diese Option in Ihrem Vertrag aufzunehmen.

Wir haben eine Änderung an der Ausführung der allgemeinen Lightning-Aktion “Einen Vorgang starten“ vorgenommen. Man kann jede Aktion nun einzeln zum allgemeinen Herausgeber-Layout hinzufügen und so pro Funktionsprofil festlegen, welche Benutzer eine bestimmte allgemeine Aktion ausführen dürfen. Beispiele dafür sind der Start und das Ausführen des GDPR-Bereinigungsvorgangs, den Versand von Datenschutz-E-Mails oder Checklisten-Erinnerungen usw.

Über Setup, Herausgeber-Layouts fügt man nun die einzelnen Aktionen hinzu. Layout unter einem anderen Namen speichern und mit einem Profil verknüpfen. Vergessen Sie nicht, die Verknüpfung des bestehenden „Einen Vorgang starten“ für diese Benutzergruppe aufzuheben.

Diese neue Funktion ermöglicht es dem Kundenportal, bei der Ablehnung eines Kandidaten einen Grund und eine Erklärung für die Ablehnung im Controller „Kunde Jobangebot“ einzufügen. In Salesforce war dies bereits für den Personaldisponenten möglich. Jetzt können Kunden dies auch selbst in ihrem Portal erledigen.

Im Typ benutzerdefinierte Metadaten „Rejection reason“ gab es bereits die Möglichkeit, Ablehnungsgründe und etwaige Standard-Erklärungstexte aufzunehmen. Wir haben ein Häkchen bei „Show On Customer Portal“ gesetzt, das standardmäßig aktiviert ist. Das bedeutet also, dass ein Ablehnungsgrund immer im Portal sichtbar ist und dass man davon abweichen kann, indem man dieses Häkchen deaktiviert. Ob ein Ablehnungsgrund angegeben werden muss, stellt man ein in Typen benutzerdefinierte Metadaten „Job Application Status Settings“. Dort kann man bei einem Status einstellen, dass diesem ein obligatorischer Ablehnungsgrund zugeordnet werden muss. Wenn dies der Fall ist und der Kontakt den entsprechenden Status im Portal wählt, muss man ab sofort auch einen Ablehnungsgrund angeben. Nach dem Ausfüllen des Ablehnungsgrundes und des Ablehnungstextes werden beide Angaben in der Bewerbung gespeichert. Der Ablehnungsgrund wird im bestehenden Feld „Ablehnungsgrund“ und der Ablehnungstext im neuen Feld „Kunde Ablehnungstext“ gespeichert. Es wird folgende Logik angewandt:

• Wenn im Portal kein Ablehnungsgrund angegeben ist und in den Metadaten „Rejection reason“ ein Standardablehnungsgrund eingestellt ist, wird dieser in das Feld „Ablehnungstext“ übernommen.
• Ist im Portal ein Ablehnungsgrund angegeben, wird der Standardablehnungstext aus den Metadaten nicht in das vorhandene Feld „Ablehnungstext“ übernommen.

Um diese Funktion nutzen zu können, muss man die Berechtigungen für das Objekt „Bewerbung“ um die Berechtigungen für dieses neue Feld erweitern und dieses Feld in die entsprechenden Seitenlayouts aufnehmen.

Wir haben sowohl die Anonymisierung als auch die Löschung von Kandidaten im Rahmen der GDPR erweitert.

Künftig werden bei der Anonymisierung der Kandidaten folgende verknüpfte Daten entfernt:

1. Veranstaltungsanmeldung.
   
2. Fragebogen-Einladungen.
   
3. Fragebogen-Antworten.
   
4. Terminanfragen.
   
5. Portalinteraktionen (sowohl für den Benutzer als auch für den Kandidaten)

Beim Entfernen der anonymisierten Kandidaten werden diese verknüpften Daten dann gelöscht:

1. Kursanmeldung.
   
2. Website-Besuche.
   

Ab diesem Release ist es möglich, selbst einen Bewerbungsstatus für über ein Formular erstellte Bewerbungen einzustellen. Im Moment wird dieser automatisch mit dem Status „Application“ versehen.

Um diesen Status hinzuzufügen, muss man beim Objekt Portal Controller Berechtigungen für das Feld „Job application status“ definieren, muss man dieses Feld im Seitenlayout SFJobApplicationController platzieren und es mit dem gewünschten Status versehen. Dieser Status wird dann bei „Apply“ im Kandidatenportal verwendet.

Wenn dieses Feld nicht eingestellt wurde, wird automatisch „Application“ verwendet. Wenn ein Bewerbungsstatus von der API (/apexrest/msf/api/job/Apply) in den Controller aufgenommen wird, hat dieser Vorrang vor dem im Portal Controller festgelegten Standardstatus.

Wie im letzten Release-Update angekündigt, ist es ab sofort nicht mehr möglich, Classic E-Mail-Vorlagen in den MSR-E-Mail-Komponenten zu verwenden. Verwenden Sie bereits eine Classic E-Mail-Vorlage in der Salesforce-Standardfunktion (E-Mail-Benachrichtigung, Prozess, Flow)? Dann die funktioniert auch weiterhin.

Mit dieser Funktion hat man im Kundenportal die Möglichkeit, einen Kandidaten mit einem Ablehnungsgrund und einer Begründung abzulehnen. In Salesforce selbst ist dies bereits für Recruiter möglich und jetzt kann der Kunde dies auch selbst im Portal erledigen.

Im Typ benutzerdefinierte Metadaten für „rejection reason“ kann man einen Standard-Begründungstext für die verschiedenen Ablehnungsgründe eingeben. Wir haben ein Häkchen bei „Show On Customer Portal“ gesetzt, das standardmäßig aktiviert ist. Das bedeutet, dass immer ein Ablehnungsgrund im Portal sichtbar ist und dass man dies durch Entfernen des Häkchens ändern kann. Der Ablehnungsgrund wird über die „Job Application Status Settings“ gesteuert, die ebenfalls in den Metadaten zu finden sind. Dort kann man bei einem Status einstellen, dass diesem ein obligatorischer Ablehnungsgrund zugeordnet werden muss. Wenn dies der Fall ist und man im Portal den entsprechenden Status auswählt, muss man von nun an auch einen Ablehnungsgrund angeben.

Nach dem Ausfüllen des Ablehnungsgrundes und des Ablehnungstextes werden beide Angaben in der Bewerbung gespeichert. Der Ablehnungsgrund wird im vorhandenen Feld „Ablehnungsgrund“ und der Ablehnungstext im neuen Feld „Kunde Ablehnungstext“ gespeichert. Es wird folgende Logik angewandt:

• Wenn im Portal kein Ablehnungstext eingegeben ist und in den Metadaten Ablehnungsgrund ein Standardablehnungstext definiert ist, wird dieser auch im MSR im Feld „Ablehnungstext“ übernommen.
• Wenn im Portal jedoch ein Ablehnungstext eingegeben wurde, wird diese Begründung im MSR in das Feld „Kunde Ablehnungstext“ übernommen. Das Feld „Ablehnungstext“ bleibt dann leer.

Um diese Funktion zu nutzen, muss man die Berechtigungen für das Objekt Bewerbung anpassen und das Feld Kunde Ablehnungstext zum Seitenlayout hinzufügen. Wenn man bestimmte Ablehnungsgründe nicht im Portal anzeigen möchte, kann man diese in den Typen benutzerdefinierte Metadaten „Rejection reason“ deaktivieren.

Auf den verschiedenen Bewerbungsseiten, wie z.B. Workflow, Registerkarte Bewerbungen oder im Bildschirm Bewerbungsprozess, kann man den Kandidaten mit Hilfe der Bewertungsfunktion bewerten.

Wenn alle Beteiligten ihre Bewertung abgegeben haben, kann man sich die Liste der Bewertungen über die Schaltfläche „Bewertungen anzeigen“ anzeigen lassen:

Wenn man den Mauszeiger über eine Spalte in der Titelleiste bewegt, sieht man eine Sortierungsmöglichkeit. Wenn man auf den Pfeil klickt, wird die entsprechende Sortierung bei dieser Liste angewendet. So lässt sich leichter erkennen, welche Kandidaten die höchste Durchschnittsbewertung erhalten haben.

Wir haben eine Änderung bei der automatischen Verarbeitung von Lebensläufen vorgenommen, die über die API der Website (/apexrest/msf/api/document/parse/) aktiviert wird. Bei diesem Vorgang werden nur die Felder, die vom Kandidaten noch nicht ausgefüllt wurden, aber aus dem Lebenslauf hervorgehen, automatisch in die Kandidatenkarte eingegeben. Vorhandene Kontaktfelder werden dabei niemals überschrieben. Mit dieser Änderung wird das Vorsatzwort eines Namens nie wieder ausgefüllt, wenn dieses nicht bereits beim Kandidaten angegeben wurde. Damit werden unerwünschte Namenszusätze verhindert, wenn das Vorsatzwort bereits im Feld Nachname aufgenommen wurde.

Diese Funktion ist nur für Unternehmen relevant, die über eine eigene Stellenangebotswebsite oder ein Kandidatenportal verfügen und die Daten im MSR über die Parse-API verarbeiten.

Es war schon immer möglich, mit der Komponente „Candidate Resume Previewer“ eine Registerkarte auf der Personenkarte zu erstellen, um den Lebenslauf anzuzeigen. Wir haben jetzt eine generische Komponente hinzugefügt, sodass man selbst entscheiden kann, welches Dokument man anzeigen möchte. Dazu verwendet man die Komponente „Candidate Document Previewer“. Rechts oben kann man die Seite ändern, indem man eine neue Registerkarte erstellt und die Komponente „Candidate Document Previewer“ anhand von Drag & Drop auf den Bildschirm zieht. Man kann dann einen Dokumenttyp angeben, um diesen anzuzeigen.

Es wird immer das letzte Dokument des eingestellten Dokumenttyps angezeigt. Handelt es sich dabei um eine doc- oder docx-Datei, wird diese automatisch in ein PDF-Dokument umgewandelt.

Laden Sie sich hier die neuesten Fixed Features als PDF herunter >

In Mysolution Recruitment hat man die Möglichkeit, seine eigenen flexiblen Fragebogen zu erstellen und diesen an Kandidaten und/oder Kontaktpersonen zu versenden. Auf diese Weise kann man z.B. Informationen für das Screening, das Onboarding oder zum Ermitteln des Interesses anfordern.

Dabei wird ein Experience Cloud-Portal genutzt, das für die Verwendung auf mobilen Geräten optimiert ist.

Fragebögen lassen sich flexibel gestalten, wobei es folgende Optionen gibt:

• Fragen nur dann stellen, wenn eine Person eine bestimmte Antwort auf eine Multiple-Choice-Frage gibt.
• Fragen erneut zu stellen, wobei man die Möglichkeit hat, die Frage bei bereits bekannten Antworten zu überspringen, die zuvor gegebene Antwort anzuzeigen oder die Frage noch einmal zu stellen.
  

Bei der betreffenden Person kann man dann sehen, welche Antworten wann gegeben wurden.

Um diese Funktion nutzen zu können, ist eine ausführliche Konfiguration erforderlich. In diesem Release wollen wir diese neue Funktion mit einer Reihe von Kunden testen. Sind Sie daran interessiert, dieses Angebot zu nutzen? Dann kontaktieren Sie Mysolution über ft@mysolution.nl, um die Möglichkeiten zu besprechen.

Es besteht die Möglichkeit, Dokumente zur digitalen Signatur anzubieten. Dem Unterzeichner wird dafür ein begrenzter Zeitraum eingeräumt, oftmals 30 Tage. Es ist nun möglich, Dokumente, die zur Signatur verschickt wurden, zurückzuziehen, sodass der Empfänger sie nicht mehr einsehen und unterzeichnen kann. Es kann nämlich sein, dass sich ein Fehler im Dokument befindet, der korrigiert werden muss. Außerdem ist es ab jetzt möglich, abgelaufene Dokumente erneut anzubieten.

Wenn ein angebotenes Dokument zurückgezogen werden soll, geht man auf der entsprechenden Seite zur Komponente „Dokumente“ und klickt auf den Text „Zurückziehen“, der sich hinter dem Text „Zur Signatur angeboten“ befindet. Sobald dies gemacht wurde, ändert sich der Status in „Signaturanfrage zurückgezogen - erneut anbieten“. Hier kann man auf den Link „Erneut anbieten“ klicken, um das Dokument erneut zu versenden.

 Set-up

Um die digitale Signatur nutzen zu können, benötigt man ein zusätzliches CM Sign-Abonnement, das Sie bei uns erwerben können.

Für diese Funktion muss man den neuen Auswahlliste-Wertesatz im Objekt msrDocument aktivieren. Dazu geht man zu Setup, Objektverwaltung, msrDocument, Felder und Kontakte. Das Feld „Genehmigungsstatus“ selektieren und einen neuen Wert mit dem API-Namen „Withdrawn for Approval“ hinzufügen.

Bislang war die maximale Dateigröße eines Lebenslaufs und eines Anschreibens im Bewerbungsformular begrenzt. Wir haben in diesem Release eine andere Art des Hochladens und für das Lebenslauf-Parsing (CV-Parsing) im Portal implementiert. So können die Kandidaten größere Dateien mit dem Lebenslauf und Anschreiben hochladen.

Dateianhänge dürfen jetzt eine Gesamtgröße von 20 MB nicht überschreiten. Dies kann man anpassen, wenn man die Dateigröße begrenzen möchte. Dazu geht man zu „Typen für benutzerdefinierte Metadaten“. Seitenlayout der Portal Domain bearbeiten und das Feld „Maximum Document Upload Size (MB)“ auf der Seite einfügen. Jetzt können Sie einen Wert von bis zu 20 MB in ein Kandidatenportal eingeben. Wenn Sie die Einstellung leer lassen, beträgt das Maximum 20 MB.

Die Kandidaten erhalten nun eine Meldung im Portal, wenn die Datei zu groß ist:

Man kann diese Meldung über den App-Starter „Übersetzungen“ selbst, bearbeiten. Sie sollten dann zunächst die neuen Übersetzungsbedingungen des Portals im MSR einlesen. Dann können Sie die Übersetzung DocumentsLargerThanNotAllowed anpassen. Man kann den aktuellen Wert „Dokumente mit mehr als {0} MB sind nicht erlaubt“ ändern, wobei {0} der eingestellte Wert ist.

Anhand dieser Änderung kann man auch einen nicht lesbaren PDF-Lebenslauf in MSR speichern. Ein solcher PDF-Lebenslauf wird als Bild und nicht als Text gespeichert und kann daher nicht ausgewertet werden. Früher führte dies zu einer sofortigen Fehlermeldung, aber wir speichern jetzt immer ein Lebenslaufdokument. In einem solchen Fall werden auf der Kandidatenkarte nur die Angaben von dem Bewerbungsformular übernommen.

Diese Anpassungen gelten auch, wenn eine Bewerbung direkt anhand der API über /apexrest/msf/api/job/Apply erstellt wird. Von nun an können Sie auf zwei Arten einen Lebenslauf oder ein Motivationsschreiben zur Bewerbung hinzufügen:

1. Bei der derzeitigen Methode geben Sie in der Nachricht ein Dokument an mit einem „Value“ (einem base64-Wert des Dokuments) und einem fileName. Dies sieht folgendermaßen aus:

„LEBENSLAUF“: {

     „value“: „VGhlIHNlY3JldCBtZXNzYWdlLg==“,

     „fileName“: „Lebenslauf Zoef de Haas.docx“

2. Die neue Methode umfasst zwei Schritte:
3. Zunächst wird über eine standardmäßige Salesforce-API eine ContentVersionId über /data/v52.0/sobjects/ContentVersion erstellt, die das Dokument in einem base64-Format bereitstellt. Dies sieht folgendermaßen aus:

{„Title“: „Lebenslauf“,

   „PathOnClient“: „Lebenslauf Zoef de Haas.docx“,

   „ContentLocation“: „S“,

   „OwnerId“: „<<ID des API-Benutzers>>“,

   „VersionData“: „VGhlIHNlY3JldCBtZXNzYWdlLg==“}

2. Das Ergebnis ist eine contentVersionId. Sie fügen diese dann in die Nachricht /apexrest/msf/api/job/Apply ein:

„Lebenslauf“ : {

       „fileName“ : „Lebenslauf Zoef de Haas.docx“,

       „contentVersionId“:“068AW000001H4ppYAC“

   },

Wenn Sie nicht lesbare Lebenslaufdokumente analysieren wollen, sollten Sie dies immer mit Methode 2 ausführen. Die vorhandenen API calls /apexrest/msf/api/job/ParseCv und /apexrest​/msf​/api​/document​/parse​/{contactId} sind in diesem Release noch nicht aktualisiert worden. Im MSR selbst kann man noch kein größeres Lebenslaufdokument über die CV Dropzone oder die Dokumentenliste der Kandidaten analysieren. Dies wird im nächsten Release (2023-05) aktualisiert werden.

Dieses Feature erfordert auch eine neue Version des Portals (Version 22.01). Sie wird ab dem 24. August in Testumgebungen eingeführt. Vom 12. bis 29. September wird diese Version in der Produktion eingeführt.

Ab diesem Release ist die Multifaktor-Authentifizierung (MFA) auf den Portalen aktiviert.

Hintergrund

Die Authentifizierung (oder Überprüfung der Anmeldedaten) erfolgt durch einen oder mehrere Faktoren. Ein Faktor ist eine Möglichkeit, die Identität beim Anmelden zu bestätigen. Dies ist notwendig, um die Daten eines Benutzers zu schützen. Der Benutzername und das Passwort sind ein Faktor, den wir bereits verwenden. Wir haben den Faktor der Authentifizierung über eine Identifizierungsdaten-App hinzugefügt. Dies ermöglicht die 2-Faktor-Authentifizierung, auch bekannt als 2FA oder MFA (Multi-Faktor-Authentifizierung).

Was ist neu?

Wir haben den Authentifizierungsablauf in „Typen für benutzerdefinierte Metadaten, Portal Domain“ um die Option „Passwort mit MFA“ erweitert:

Sobald Sie diese Option aktivieren, müssen sich die Benutzer des Portals mit einem Passwort und einem Anmeldecode von einer Authentifizierungs-App anmelden. Die Benutzer können ihre eigene App wählen, z.B. Google Authenticator oder Microsoft Authenticator. Wenn sich ein Benutzer nach Aktivierung der Option zum ersten Mal anmeldet, erhält er nach einem erfolgreichen Anmeldeversuch eine Meldung, dass ein zweiter Faktor festgelegt werden muss:

Nach einem Klick auf „Erweiterte Sicherheitsoptionen“ gelangt der Benutzer auf den Bildschirm zum Einrichten der MFA. Man gelangt dann zu einem Bildschirm mit einem QR-Code. Der Benutzer kann diesen Code mit der Authenticator-App auf seinem Smartphone oder Tablet scannen. Wenn das Scannen des QR-Codes nicht möglich ist, kann der Schlüssel auch kopiert werden, um sich darüber zu authentifizieren:

Sobald dies erfolgreich war, erhält der Benutzer einen Verifizierungscode. Dieser sollte im Anmeldefenster des Portals eingegeben werden. Nach erfolgreicher Verifizierung ist MFA für den Benutzer aktiviert und er wird bei der Anmeldung immer zur Eingabe von Benutzername/Passwort und Verifizierungscode aufgefordert:

Rücksetzen der MFA-Anmeldemethode für Portalbenutzer

Sollte sich der Benutzer nicht mehr mit MFA anmelden können, kann er sich an seine Kontaktperson wenden. Es ist empfehlenswert, die Identität des Portalbenutzers zu überprüfen, um sicherzustellen, dass es sich um denselben Benutzer handelt. Innerhalb von MSR kann die MFA für diesen Portalbenutzer durch Hinzufügen einer Aktionsschaltfläche „MFA entfernen“ auf der Layoutseite zurückgesetzt werden. Wenn man darauf klickt, wird die MFA für diesen Portalbenutzer entfernt. Nach dem Löschen sollte der Portalbenutzer die MFA erneut einrichten, wie in den vorherigen Schritten beschrieben.

MFA-Änderung durch Portalbenutzer

Der Portalbenutzer kann die MFA auch selbst im Portal löschen. Dies kann nützlich sein, wenn sie z.B. eine neue Authentifizierungs-App oder ein anderes Gerät verwenden möchten. Über „Mein Konto“, „Erweiterte Sicherheitsoptionen“, kann MFA entfernt werden:

Nach dem Löschen muss sich der Portalbenutzer ab- und wieder anmelden. Anschließend kann er die MFA wie in den vorherigen Schritten beschrieben zurücksetzen.

Passwort vergessen

Nachdem der Portalbenutzer MFA eingerichtet hat und z.B. sein Passwort vergessen hat, kann er sein Passwort nach der Authentifizierung über die App direkt im Portal zurücksetzen. Zu diesem Zweck wird dann keine E-Mail vom Portal aus versandt. Das funktioniert folgendermaßen: Der Benutzer klickt auf „Passwort vergessen“ und gibt seinen Benutzernamen ein. Der Benutzer authentifiziert sich dann mit der Authentifizierungs-App:

Danach kann er sein Passwort sofort ändern:

Set up

MFA kann man für das jeweilige Portal (Kandidat und/oder Kunde) über „Setup, Typen für benutzerdefinierte Metadaten, Portal Domain“ aktivieren. Nach der Aktivierung der Einstellung „Passwort mit MFA“ müssen die Portaleinstellungen über das Administratorkonto aktualisiert werden. Nach der Aktivierung von MFA verwenden die Administratoren MFA auch zur Bestätigung ihrer Anmeldung. Für Administratoren sollte daher ein Kontaktprotokoll vorhanden sein, wobei die E-Mail-Adresse, wie sie in der Portal Domain festgelegt ist, einem Benutzernamen für das Portal entspricht. Administratorkonten ohne Kontaktprotokoll werden also nicht mehr funktionieren, wenn MFA aktiviert wurde! Man sollte beim Einrichten von MFA auch beachten, dass das Öffnen des Kandidaten- oder Kundenportals nicht ausgehend von der Kontaktseite in MSR funktioniert, wenn man für dieses Portal eine Passwortanmeldung mit MFA eingerichtet hat.

Um die eingestellte MFA-Methode entfernen zu können, muss man die Schaltfläche „MFA entfernen“ in das Layout der Kandidaten- und/oder Kontaktseite einfügen. In der Komponente „Mobile Lightning-Aktionen“ aktiviert man die Schaltfläche „Remove MFA“.

Einführung

Wir empfehlen, die Vorgehensweise zur Einführung der MFA gut vorzubereiten und zu planen. Die Portalbenutzer brauchen also Instruktionen und die MFA muss in den Ablauf integriert werden, damit die MSR-Benutzer auch wissen, was sie machen sollten. Man kann Instruktionen anbieten, wie der Benutzer eine empfohlene Authentifizierungs-App (z.B. Google Authenticator oder Microsoft Authenticator) installieren kann, falls diese noch nicht verfügbar ist.

Im Release 2023-04 führen wir auch ein neues NIXZ-Plugin ein. Dies wird das aktuelle Mysolution SimpleRecruiter Plugin ersetzen. Es wird noch bis Ende dieses Jahres im Chrome Web Store verfügbar sein und dann nicht mehr.

Installation

Um das neue Plugin zu nutzen, muss man folgende Schritte ausführen:

1. Das neue Plugin aus dem Google Chrome Web Store herunterladen.
2. Gehen Sie im Browser zu Erweiterungen:

3. In der Übersicht der Erweiterungen sieht man (zusätzlich zu allen anderen installierten Plugins) die beiden Plugins von NIXZ :

4. Man deaktiviert NIXZ SimpleRecruiter for Mysolution über den Schieberegler auf der rechten Seite.
5. Jetzt öffnet man die Details für den NIXZ-Plugin und aktiviert die Einstellung „Zugriff auf Datei-URLs zulassen“:

Von da an ist das alte Plugin nicht mehr aktiv und man kann das neue verwenden.

Funktionsweise

Sobald man eine Profilseite in LinkedIn öffnet, sieht man, dass das Plugin aktiv ist:

Befolgen Sie die Schritte im Plugin:

1. In der Liste der Systeme wählt man Mysolution.
2. Man gibt den Domainnamen seiner Mysolution Recruitment Umgebung ein (z.B.: https://mysolutiondemo.lightning.force.com) und selektiert „Verbinden“.
3. Ein neuer Bildschirm wird geöffnet, in dem man um die Einwilligung zum Verbinden des NIXZ-Plugin mit der Salesforce-Umgebung gebeten wird.
4. Es folgt dann ein Bildschirm, bei dem man sich mit seinem NIXZ-Konto anmelden kann.

Sobald man angemeldet ist, kann man neue Kandidaten hinzufügen oder den Lebenslauf bei vorhandenen Kandidaten aktualisieren. Man kann sehen, dass das Plugin auf nicht relevanten Seiten automatisch eingeklappt wird. Sobald man sich auf einer Profilseite befindet, wird es wieder aktiv.

In diesem Release haben wir das Protokollieren zu dem Zeitpunkt hinzugefügt, zu dem ein Kandidat oder Kontakt seine Einwilligung erteilt oder zurückzieht. In Zukunft werden wir folgende Daten erfassen:

• Die IP-Adresse des Standortes, an dem die Zustimmung angenommen oder abgelehnt wurde (Logging Datenschutzerklärung)
• Zeitpunkt der Einwilligungserklärung (Zeitpunkt der Einwilligung für die Datenschutzerklärung). Das Datum wurde natürlich bereits immer gespeichert.
• Datum des Antrags auf Löschung der personenbezogenen Daten (Datum der Ablehnung der Datenschutzerklärung)
• Uhrzeit des Antrags auf Löschung personenbezogener Daten (Uhrzeit der Ablehnung der Datenschutzerklärung)

Um diese Funktion zu nutzen, muss nichts weiter eingerichtet werden. Falls gewünscht, können die neuen Felder in das Seitenlayout eingefügt werden, und man kann die Felder mithilfe von Berechtigungen vor Bearbeitung schützen.

In der DSGVO-Einwilligungsgruppe kann man festlegen, auf welche Landingpage ein Benutzer geleitet wird, nachdem er seine Zustimmung zur Verarbeitung personenbezogener Daten erteilt oder diese Zustimmung widerrufen hat. Man gibt hier einen relativen Pfad ein, der auf der eingestellten Website der entsprechenden Einstellung im Portal Domain basiert.

Wir haben jetzt die Möglichkeit geschaffen, auch in der DSGVO-Einwilligungsgruppe einen absoluten Pfad anzugeben. Dies betrifft nicht die vorhandenen Einstellungen. Wenn der Pfad mit einem „/...“ gekennzeichnet ist, handelt es sich um einen relativen Pfad. Wenn die Einstellung mit „https://...“ beginnt, wird dieser absolute Pfad verwendet, um den Benutzer nach dem Festlegen seiner Wahl umzuleiten.

Wir haben eine Änderung beim Informations-Pop-up beim Bewerbungsbildschirm vorgenommen.

Das Pop-up-Fenster wird jetzt nur noch in der Detailansicht angezeigt. Dieses Pop-up zeigt die ersten fünf relevanten Spalten der Übersicht an. In der Listenansicht sind diese Spalten bereits sichtbar, weshalb das Pop-up hier ganz bewusst nicht angezeigt wird. Um zu vermeiden, dass das Pop-up beim Bewegen des Mauszeigers als störend empfunden wird, wird es mit einer leichten Verzögerung angezeigt. Schließlich wurde das Pop-up-Fenster etwas breiter gestaltet, damit der Inhalt besser lesbar ist.

Das Verhalten dieses Informationsfensters ist in den Abschnitten Workflow, Job>Bewerbungen und Bewerbungsprozess identisch.

Mit der zusätzlichen Salesforce-Lizenz Salesforce Shield ist es möglich, Daten „In rest“ zu verschlüsseln. Dies ermöglicht einen zusätzlichen Schutz von datenschutzsensiblen Daten. Um diese zusätzliche Lizenz nutzen zu können, wurden in diesem Release Anpassungen beim Einstellen der Verschlüsselung vorgenommen. Somit sind drei Formelfelder beim Objekt „Person“ nicht mehr Teil des MSR-Installationspakets.

Das sind:

• Anrede förmliches Deutsch (msf__Salutation_Formal_German__c)
• Anrede förmliches Niederländisch (msf__Salutation_Formal_Dutch__c)
• Anrede Adresse Niederländisch (msf__Salutation_for_Address_Dutch__c).

Dies hat zur Folge, dass diese Felder nun von Administratoren geändert werden können. Wenn die Felder jedoch Teil des Installationspakets sind, ist die Anpassung recht begrenzt. Für die Nutzung spielt dies keine Rolle, die Felder funktionieren weiterhin. Wenn das Feld „Name“ des Objekts “Person“ verschlüsselt werden soll, müssen zunächst die oben genannten Felder entfernt oder geändert werden, damit die Verschlüsselung aktiviert werden kann. In diesen Feldern verwenden die Formeln Funktionen, die nicht verwendet werden können, wenn die zugrunde liegenden Namensfelder verschlüsselt sind. Wenn die Salesforce Shield nicht verwendet werden soll, muss natürlich nichts weiter unternommen werden.

Es ist nun möglich, den Checklistenstatus der Objekte Person, Platzierung, Arbeitsvertrag und Bewerbung abzurufen. Dies sind Objekte, bei denen man jetzt auch schon Checklist Items auf der Karte platzieren kann. Damit kann man z.B. festlegen, welche Dokumente man automatisch erzeugen lassen möchte, oder man kann jetzt in Flow anhand von Checklistenstatus selbst Aktionen durchführen. Man kann auch mit Dokumentenzusätzen prüfen, ob dies eine vollständige Checkliste ergibt, der wiederum automatisch Aktionen folgen können.

Die Flow-Aktion, die dafür verwendet werden kann, nennt sich „Get Document Checklist“. Dieser genehmigt den Record ID des Objekts, für das man den Checklistenstatus abrufen kann. Die Aktion liefert dann vier Listen:

• vollständig
• unvollständig
• needsApproval
• expiringSoon

Diese enthalten die IDs der einzelnen Checklist Items. Dies ist das Objekt in Salesforce, in dem die einzelnen Checklist Items erfasst sind. Dazu gehören Dokumentinformationen (Dokumentenart) und Genehmigung.

Es ist jetzt möglich, mehrere Kontaktpersonen im CC- und BCC-Feld einer E-Mail zu selektieren. Bisher konnte in jedem dieser Felder nur einen Kontaktdatensatz selektiert werden, aber ab jetzt können bis zu 5 Kontaktpersonen oder Benutzer selektiert werden.

Die ausgewählten Kontaktpersonen oder Benutzer werden untereinander angezeigt. Wenn mehr als 5 Personen selektiert wurden, erhält man eine Fehlermeldung.

Neben der Erweiterung im E-Mail-Bildschirm wurden auch die Flow-Komponenten SendMailTroughFlow (für das Versenden einer E-Mail an einen einzelnen Empfänger) und SendMailsTroughFlow (für das Versenden einer E-Mail an mehrere Empfänger) um 2 neue Parameter erweitert.

Dies sind BCC Ids und CC Ids. Im Flow muss man selektieren, ob man eine einzelne Kontakt- oder Benutzerdatensatz-ID zuweisen oder eine Mehrfachvariable verwenden möchte. Man kann nicht beide Parameter verwenden, dies führt zu einer Fehlermeldung.

Die Bildkomponenten Termin (Appointment) und E-Mail (Mail Component) wurden um zwei Parameter erweitert. Anhand derer ist es möglich, in einem Bildschirm-Flow die Termininformationen in der E-Mail-Vorlage zu verwenden. Das bedeutet, dass man ab sofort Lightning-E-Mail-Vorlagen verwenden kann, die Event merge-Felder enthalten.

In der Terminkomponente wurde ein neuer optionaler Parameter hinzugefügt: „Display Save button on flow“:

Diesem sollte man den Wert TRUE zuweisen. Durch diese Schaltfläche bekommt der Benutzer die Schaltfläche „Speichern“ auf dem Bildschirm. Dadurch wird der Termin gespeichert und man gelangt direkt zur nächsten Seite. Die Schaltfläche „Speichern“ kann nur in Verbindung mit dem Parameter „Flow Context“=TRUE verwendet werden.

Ein neuer Parameter ist auch in der E-Mail-Komponente verfügbar: Target Event Id:

Um den Termindatensatz aus dem vorherigen Schritt im Flow zu verwenden, gibt man den Parameter „Target Event Id“ mit der EventId ein. In der Liste im Abschnitt „Bildschirmkomponenten“ selektiert man „Termin“. Dann kann man die EventId selektieren:

Es ist auch möglich, der Datensatz-ID des erstellten Termins eine eigene Variablen zuzuweisen. Dazu klappt man in der Komponente „Termin“ den Abschnitt „Erweitert“ aus:

Wenn man die Option „Variablen manuell zuweisen“ selektiert, kann man eine Textvariable erstellen und diese zuweisen. Dann kann man diese Variable in der E-Mail-Komponente im Parameter Target Event Id verknüpfen.

Hat man die oben genannten Konfigurationsschritte durchgeführt, sieht der Bildschirm-Flow wie folgt aus:

Sobald man die Terminfelder ausgefüllt hat, selektiert man „Speichern“. Daraufhin wird sofort der Bildschirm für die E-Mail-Komponente geöffnet.

Wie bei dem Schritt für eine manuelle E-Mail werden die Event merge-Felder sofort beim Öffnen des Bildschirms erzeugt. Man kann der E-Mail noch Text hinzufügen und dann auf „Senden“ drücken. Danach kann der Bildschirm geschlossen werden.

In diesem Release haben wir eine technische Anpassung beim Skill Component vorgenommen, die im Layout der Job-, Kontakt- und Kontoseiten platziert werden können. Dadurch wird die Seite schneller geladen. Sollte es dennoch zu Verzögerungen beim Öffnen der Jobseite kommen, empfiehlt es sich, die Skill Component nicht direkt auf der Detailseite zu platzieren. Besser ist es auf folgende Weise:

1. Neue Registerkarte hinzufügen und die Skill Component dort platzieren:

2. Man fügt ein Akkordeon-Element zu einer Detailseite hinzu und zieht die Skill Component dorthin:

In der Akkordeon-Komponente muss man nur mit einem Abschnitt arbeiten und kann das Verhalten so einstellen, dass es immer automatisch ausklappt.

Beide Methoden werden von Salesforce empfohlen, um diese Art von relevanten Angaben in einem Seitenlayout anzuzeigen.

Die Kandidatensuche nach „Entfernung“ war bereits für Kandidaten in Belgien, Deutschland und den Niederlanden möglich. Dies kann nun auch auf der Grundlage von österreichischen Postleitzahlen erfolgen. Man gibt dazu eine österreichische Postleitzahl ein, wählen als Land „AT“ und die gewünschte Entfernung.

Übrigens ist dies bereits passend zu der Länderauswahl im Benutzerprofils voreingestellt, ob standardmäßig „NL“, „BE“, „DE“ oder „AT“ angezeigt wird.

Die Suche nach österreichischen Postleitzahlen ist auch bei Kontensuche möglich.

In diesem Release haben wir eine Änderung bei der Art und Weise vorgenommen, wie Kandidaten in Textkernel Search & Match indiziert werden. Die Indizierung erfolgt jetzt viel schneller.

Für diese Anpassung muss man nichts einstellen. Wenn man alle Kandidaten einmal indizieren möchte (z.B. nach einer Konvertierung aus einer anderen ATS-Software), muss man den folgenden APEX-Code ausführen:

database.executeBatch(new msf.TextkernelContactIndexerBatch('SELECT id from contact where msf__show_in_textkernel__c = true'));

Man kann die Abfrage um andere Kriterien erweitern, um eine noch spezifischere Indizierung für eine Gruppe von Kandidaten vorzunehmen.

Die Methode der Indexierung der Jobs selbst wurde nicht geändert.

Laden Sie sich hier die neuesten Fixed Features als PDF herunter >

In diesem Release haben wir die ChatGPT-Funktion zu Mysolution Recruitment hinzugefügt. Damit ist es möglich, an verschiedenen Stellen in der Anwendung Fragen an ChatGPT zu stellen und zudem Texte für Stellenanzeigen zu erstellen. 

Um ChatGPT nutzen zu können, muss man seine eigene OpenAI-Lizenz erwerben. Dies ist möglich, indem man zu https://platform.openai.com/signup geht und sich registriert. Man sollte einen kostenpflichtigen Account einrichten und einen API Key erstellen, den man verwenden kann. Diesen sollte auf jeden Fall gespeichert werden!

1. Dazu geht man zu Setup > Benutzerdefinierte Einstellungen und selektiert OpenAI Settings.
2. Das einzige Pflichtfeld ist „API Key“, hier gibt man den OpenAI API Key ein.
   1. Wir setzen standardmäßig das „Modell“ „text-davinci-003“ ein, aber davon kann man nach Wunsch auch abweichen. Weitere Informationen zu den verschiedenen Modellen sind in der OpenAI-Dokumentation nachzulesen.
   2. „Maximale Token“ gibt an, wie viel Text standardmäßig verwendet werden kann. Wenn man nichts eingibt, ist dieser standardmäßig auf 2048 eingestellt. Wenn man davon abweichen möchte, gibt man eine andere Zahl ein. Bitte die OpenAI-Dokumentation sorgfältig durchlesen.
3. Über Setup > Einstellungen für Remote-Standort fügt man einen neuen Remote-Standort Der Name kann zum Beispiel OpenAI sein, als URL gibt man https://api.openai.com ein.

1. Zu Setup > Objektverwaltung gehen und Job
2. Zum gewünschten Seitenlayout gehen und die Schaltfläche „Generate Job Description“ im Abschnitt „Aktionen für Mobile und Lightning“ hinzufügen.

Wenn man eine andere Beschreibung für den Titel im Pop-Up zuweisen möchte, kann man zu Setup > Benutzerdefinierte Bezeichnungen gehen. Dort sucht man nach GenerateJobDescription und klickt drauf, um „Neue lokale Übersetzungen/Überschreibungen“ hinzufügen. Wenn man einen anderen Namen für die Schaltfläche festlegen möchte, erstellt man eine Übersetzung, indem man zu Setup, Benutzeroberfläche, Übersetzungszentrum geht und dann auf "Überschreiben" klickt. Man wählt dort die folgenden Optionen aus:

• Paket: Mysolution
• Sprache: Deutsch (oder eine andere gewünschte Sprache)
• Installationskomponente: Aktion
• Objekt: Stellenangebot
• Aspekt: Feldbeschriftung

Dann geht man zur Zeile "GenerateJobDescription" und gibt im Feld "Beschriftungsüberschreibung für Schnellaktion" den gewünschten Text für die Schaltfläche ein.

Der Assistent öffnet sich, wenn man ausgehend von einer Stellenanzeige daraufklickt, und ergänzt automatisch den Titel und die Stadt. Man kann dann den Schreibstil und die Sprache ändern.

Durch das Generieren erhält man einen Stellenanzeigetext, den man in die Zwischenablage kopieren und in die Stellenbeschreibung einfügen kann. Die Frage, die wir ChatGPT gestellt haben, wird angezeigt, sodass man sie auch selbst bearbeiten und erneut erstellen kann.

Man kann die Antwort in diesem Bildschirm formatieren und bearbeiten, anschließend kopieren und in die Stellenanzeige einfügen.

1. Zu Setup > Objektverwaltung gehen und das gewünschte Objekt selektieren.
2. Eine Lightning-Aktion hinzufügen, bei der man Folgendes eingibt:
   1. Aktionstyp: Lightning-Webkomponente.
   2. Lightning Webkomponente: „msf:askChatGPTAction“.
   3. Standard-Bezeichnungstyp, Bezeichnung und Name wie gewünscht.
3. Man kann diese dann zum Seitenlayout hinzufügen.

1. Question (obligatorisch). Dies ist die Frage, die man ChatGPT stellen sollte. Das könnte also eine Frage sein, die man dem Benutzer über eine Bildschirmeingabe stellt.
2. Variability (optional). Dies ist eine Zahl zwischen 0,0 und 1,0, wobei
   1. 0,0 bedeutet, dass man auf die gleiche Frage so ziemlich die gleiche Antwort erhält
   2. 1,0 bedeutet einen höheren Grad an Zufälligkeit. Das bedeutet, dass auf die gleiche Frage mehrere unterschiedliche Antworten gegeben werden. Vorsicht, denn auch das kann von der Realität abweichen. Wir empfehlen, die Einstellung nicht zu ändern, es sei denn, man möchte es absichtlich feinjustieren.

Im letzten Release haben wir die Kanban-Ansicht für die Seite Kandidatenprozesse eingeführt. Auf dessen Einführung haben wir Rückmeldungen erhalten und haben diesen Bildschirm in diesem Release noch weiter optimiert.

Zunächst haben wir die Gestaltung und die Farbgebung der Kanban-Ansicht geändert. Die Standardfarbe des Status ist jetzt grau und die verwendete Schriftart wird schwarz dargestellt. Wenn man in Typen für benutzerdefinierte Metadaten bei einer Job Application Status-Einstellung eine Farbe für einen Status festlegt, wird dieser in weißer Schriftart angezeigt. Die Job Kandidat-Kachel hat jetzt nur einen Rahmen in dieser Farbe.

Außerdem wurde das Mouseover Pop-up-Fenster entfernt, das sich beim Mouseover über eine Kachel öffnete. Die Kachel zeigt nun standardmäßig 2 Felder an: vollständiger Name des Bewerbers und Job Name.

Benutzer können selbst wählen, welche Informationen in eine Kachel aufgenommen werden sollen, indem sie auf das Zahnrad oben rechts in der Kanban-Ansicht klicken. Dazu öffnet man den Feld-Selector:

In dieser Ansicht sieht man auf der linken Seite die nach Objekten gruppierten Felder und auf der rechten Seite die verfügbaren Felder bei der Kachel.

Wenn man sich diese Felder ansehen möchte, kann man auf den Pfeil unten rechts in der Bewerbungskachel klicken:

Wenn man mit Deadlines bei einem Job Kandidat Status (und damit Dringlichkeit) arbeitet, werden dringende Bewerbungen in der Kachel mit einem roten Symbol gekennzeichnet.

Wenn man auf eine oder mehrere Bewerbungskacheln klickt, wird ein Schattenrand sichtbar und die entsprechenden Job Kandidaten Schritte angezeigt.

Bei „Job Kandidaten Schritte“ haben wir eine Änderung vorgenommen, sodass sie in einer separaten Zeile angezeigt werden, wobei neben dem Symbol auch die Beschreibung angezeigt wird. Die ersten neun Schritte werden angezeigt, wenn noch weitere Schritte verfügbar sind, kann man auf die Punkte (...) klicken.

Wenn man auf einer Bewerbungskachel doppelklickt, wird sofort die Liste aller Aktionen geöffnet:

Schließlich wird jetzt registriert, ob man als Benutzer zuletzt eine Kanban-Ansicht auf der Kandidatenprozesse-Seite verwendet hat. Dazu muss der Benutzer jedoch über die Berechtigung für dieses neue Feld verfügen. Man passt dazu für alle Benutzer die Berechtigungen an und gibt ihnen im Objekt Benutzer Bearbeitungsberechtigungen beim Feld „Kanban View Selected“. Solange die Benutzer keine Berechtigungen für dieses Feld haben, wird beim erneuten Laden der Kandidatenprozesse-Seite entweder die Listenansicht oder die Detailansicht angezeigt.

Um die Gestaltung der Job Kandidat-Übersichten innerhalb von MSR einheitlich zu halten, wurden neben den Änderungen in der Kanban-Ansicht auch die anderen Job Kandidat-Seiten geändert. 

Wir haben die Workflow-Seite etwas kompakter gestaltet, indem wir die Kopfleiste unter den Job Kandidat-Kacheln verkleinert haben. Die Anzahl der Job Kandidaten pro Job und pro Status wird nun einheitlich mit einer Zahl in Klammern angegeben.

Die Registerkarte Job Kandidaten sieht jetzt wie folgt aus: 

Die Standardfarbe für Job Kandidat Status wurde von blau auf grau umgestellt. Es sei denn, man hat bei Typen für benutzerdefinierte Metadaten in der „Job Application Status“-Einstellung eine Farbe für diesen Status festgelegt, wie in diesem Beispiel. Die Schriftfarbe in einem grauen Status ist schwarz, bei einer eingestellten Farbe ist sie weiß. Darüber hinaus wurde der Stil der Statusleiste geändert, der weiße Raum zwischen den Pfeilen ist nun kleiner.

Wir haben für die Job Kandidaten Schritte eine Anpassung vorgenommen, sodass diese in einer separaten Zeile angezeigt werden, in der neben dem Symbol auch die Beschreibung sichtbar wird. Die ersten neun Schritte werden angezeigt, wenn noch weitere Schritte verfügbar sind, kann man auf die Punkte (...) klicken. Dies hat den zusätzlichen Vorteil, dass man nun leichter durch die Liste navigieren kann, da die Position der Vorwärts- und Rückwärtspfeile auf dem Bildschirm nicht mehr springt.

Schließlich wurden auf der Seite Jobs suchen die gleichen Stilelemente verwendet:

Wir haben in diesem Feature die Möglichkeit geschaffen, eine strengere Kennwortrichtlinie für das Kandidaten- und Kundenportal zu aktivieren. Diese Kennwortrichtlinie wird auf alle konfigurierten Portale angewendet, bei denen sich die Benutzer mit einem Benutzernamen und einem Kennwort authentifizieren. Die aktuelle Kennwortrichtlinie schreibt eine Mindestanzahl von 6 Zeichen für das Kennwort vor. Mit der erweiterten Kennwortrichtlinie werden die folgenden Bedingungen an ein Kennwort geknüpft:

• Mindestens 8 Zeichen
  Dies bedeutet, dass das Kennwort mindestens 8 Zeichen lang sein muss. Wenn das Kennwort diese Richtlinie nicht erfüllt, bekommt man die erste Meldung in der nachfolgenden Abbildung zu sehen.
• Mindestens 5 unterschiedliche Zeichen
  Dies bedeutet, dass das eingegebene Kennwort mindestens 5 eindeutige Zeichen enthalten muss. Zum Beispiel: 12345aaa. Hier sind die ersten 5 Zeichen eindeutig, die letzten 3 nicht. Wenn diese Richtlinie nicht eingehalten wird, bekommt man eine zweite Meldung wie in der Abbildung unten. Es ist also auch möglich, dass das Kennwort mehrere Teile der Richtlinie nicht erfüllt. In diesem Fall bekommt man auch mehrere Meldungen zu sehen.
• Mindestens 3 der 4 Zeichentypen vorhanden.
  Wir unterscheiden die folgenden 4 Zeichentypen:
  • Kleinbuchstaben, z. B.: abc
  • Großbuchstaben, z. B.: ABC
  • Zahlen, z. B.: 123
  • Sonderzeichen, z. B.: !@#

Setup
Zum Aktivieren der neuen Kennwortrichtlinie muss man in Setup > Benutzerdefinierte Einstellungen > Portal Settings ein neues Konfigurationselement erstellen, falls noch nicht vorhanden. Wenn es bereits vorhanden ist, sollte man die Option „Kennwortrichtlinie“ aktivieren. Sobald dies geschehen ist, gilt die neue Kennwortrichtlinie.

Bestehende Kennwörter können einfach weiterverwendet werden. Wenn diese jedoch geändert werden, muss das neue Kennwort der neuen Kennwortrichtlinie entsprechen.

Danach muss man sich als Administrator im Portal anmelden und über die Option Wartung die Übersetzungsschlüssel zu MSR synchronisieren. Dadurch werden die erforderlichen Übersetzungsschlüssel in der MSR-Übersetzungstabelle erstellt:

Über den App-Starter oben links, wählt man „übersetzen“. Man kann bei Bedarf die nachstehenden Übersetzungsschlüssel ändern, um daraus einen eigenen Text zu machen. Die PasswordPolicy 1x und 2x werden verwendet, wenn die neue Kennwortrichtlinie aktiviert ist. Es besteht keine Notwendigkeit, die {0} zu ändern.

Wir haben in diesem Release eine Reihe von Verbesserungen an der E-Mail-Komponente vorgenommen, die man in einem Bildschirm-Flow von den Job Kandidaten-Bildschirmen aus starten kann. In dieser Komponente sind jetzt 2 neue optionale Parameter verfügbar:

• Appointment Type: Hier gibt man den API-Wert der Auswahlliste im Feld „Terminarten“ im Objekt Aktivität Wenn man nichts eingibt, wird der Standardwert „Job Interview“ ausgefüllt.
• Subject: Man kann die Logik für den Aufbau eines Themas selbst festlegen. Bleibt es leer, wird das Thema anhand des aktuellen Status von Job Kandidat, Kandidatenname und Job Name festgelegt.

Zusätzlich zu diesen optionalen Parametern wurde auch die Validierung geändert. Man erhält nun eine Warnung, wenn man auf die Schaltfläche „Weiter“ klickt und kein Datum/keine Uhrzeit selektiert hat.

Im letzten Release haben wir ermöglicht, eine erweiterte E-Mail-APEX Komponente zu einem Flow hinzuzufügen. Mit „SendAdvancedEmailTroughFlow“ kann man eine E-Mail an einen einzelnen Kontaktdatensatz senden. In diesem Release haben wir einige weitere Änderungen vorgenommen und außerdem die Möglichkeit geschaffen, SMS-Nachrichten über einen Flow zu versenden.

E-Mail-Versand an mehrere Kontakte und Benutzer
Um die drei E-Mail-Komponenten besser unterscheiden zu können, haben wir die Beschreibung der verschiedenen Varianten angepasst:

Um über einen Flow eine E-Mail an mehrere Kontaktpersonen und Benutzer zu versenden, kann man jetzt die SendAdvancedEmailsTroughFlow-Komponente verwenden. Jeder Empfänger erhält eine eigene E-Mail-Nachricht, genau wie bei einer Mehrfachauswahl bei z. B. Personen suchen. 

Je nach Konfiguration sind eine Reihe von Optionen optional oder obligatorisch. Wenn man eine Option nicht verwendet, bleibt der Schieberegler auf „nicht einschließen“. Sobald man das selektiert hat, kann man die folgenden Parameter einstellen:

• Ids: dies ist eine Sammlungsvariable mit Kontaktdatensatz-IDs und Benutzerdatensatz-IDs, an die die E-Mail gesendet werden soll.
• BCC Id: Man kann hier die Kontaktdatensatz-ID oder Benutzerdatensatz-ID eingeben. Wenn man eine BCC an eine bestimmte E-Mail-Adresse senden möchte, muss man dafür einen Kontaktperson-Datensatz anlegen. Es kann maximal 1 E-Mail-Adresse im BCC verwendet werden.
• CC Id: Man kann hier die Kontaktdatensatz-ID oder Benutzerdatensatz-ID eingeben. Wenn man eine CC an eine bestimmte E-Mail-Adresse senden möchte, muss man dafür einen Kontaktperson-Datensatz anlegen. Es kann maximal 1 E-Mail-Adresse im CC verwendet werden.
• Documents: Wenn man Dokumentenanhänge zur E-Mail hinzufügen möchte, kann man dazu eine Sammlungsvariable mit mehreren Datensätzen verwenden, in die man die entsprechenden Datensatz-IDs des Objekts msrDocument Dabei sollte man sicherstellen, dass nur Datensätze mit dem richtigen Dokument Type abgerufen werden, bei denen die Eigenschaft "msf__To_Be_Deleted__c" auf FALSE gesetzt ist. Für die gefundenen Dokumente ist beim Hinzufügen zur E-Mail die Eigenschaft „Als PDF senden“ enthalten. Wenn die eingestellte Lightning-E-Mail-Vorlage einen festen Anhang hat, wird dieser ebenfalls hinzugefügt.
• Email Template Name: Namen der Lightning-E-Mail-Vorlage
• From (Email Address): Wenn diese nicht angegeben wird, ist es immer die E-Mail-Adresse des Benutzers, der den Trigger- oder Bildschirm-Flow startet. Man kann hier auch eine E-Mail-Adresse auf der Grundlage eines festen Wertes oder einer variablen Berechnung eingeben.
• From (Name): Wenn dies nicht angegeben wird, ist dies immer der Name des Benutzers, der den Trigger- oder den Bildschirm-Flow startet. Man kann hier auch einen Namen auf der Grundlage eines festen Wertes oder einer variablen Berechnung eingeben.
• RTF Body: Dieser Parameter wird nur benötigt, wenn man keine Lightning-E-Mail-Vorlage Damit kann man im Flow eine Textvorlage erstellen, die den Inhalt der E-Mail-Nachricht enthält. In der Textvorlage selbst kann man angeben, ob es sich um reinen Text oder um einen Body mit Formatierung handelt.
• Save as Activity: Standardmäßig wird die E-Mail in der Aktivitätenzeitleiste des Kandidaten oder der Kontaktperson gespeichert. Wenn man dies nicht möchte, muss man diese Variable mit der Konstante {!$GlobalConstant.False} füllen.
• Subject: nur anwendbar, wenn man eine Variable im RTF Body verwendet. Bei Verwendung einer Lightning-E-Mail-Vorlage wird der Titel der Vorlage verwendet.

Versenden von E-Mail an einen einzelnen Kontakt
Die bestehende Komponente SendAdvancedEmailTroughFlow wurde um einen neuen Parameter Save as Activity erweitert. Der Vollständigkeit halber geben wir eine Erklärung zu jedem Parameter:

• Id: Dies ist eine Kontaktdatensatz-ID, an die die E-Mail gesendet werden soll. Mit dieser Komponente kann man keine E-Mails an Benutzer
• BCC Id: Man kann hier die Kontaktdatensatz-ID oder Benutzerdatensatz-ID eingeben. Wenn man eine BCC an eine bestimmte E-Mail-Adresse versenden möchte, muss man einen Kontaktperson-Datensatz erstellen. Es kann maximal 1 E-Mail-Adresse im BCC verwendet werden.

• CC Id: Man kann hier die Kontaktdatensatz-ID oder Benutzerdatensatz-ID eingeben. Wenn man eine CC an eine bestimmte E-Mail-Adresse senden möchte, muss man dafür einen Kontaktperson-Datensatz anlegen. Es kann maximal 1 E-Mail-Adresse im CC verwendet werden.
• Documents: Wenn man Dokumentenanhänge zur E-Mail hinzufügen möchte, kann man dazu eine Sammlungsvariable mit mehreren Datensätzen verwenden, in die man die entsprechenden Datensatz-IDs des Objekts msrDocument abruft. Dabei sollte man sicherstellen, dass nur Datensätze mit dem richtigen Dokument Type abgerufen werden, bei denen die Eigenschaft "msf__To_Be_Deleted__c" auf FALSE gesetzt ist. Für die gefundenen Dokumente ist beim Hinzufügen zur E-Mail die Eigenschaft „Als PDF senden“ enthalten. Wenn die eingestellte Lightning-E-Mail-Vorlage einen festen Anhang hat, wird dieser ebenfalls hinzugefügt.
• Email Template Name: Namen der Lightning-E-Mail-Vorlage eingeben. 
• From (Email Address): Wenn diese nicht angegeben wird, ist es immer die E-Mail-Adresse des Benutzers, der den Trigger- oder Bildschirm-Flow startet. Man kann hier auch eine E-Mail-Adresse auf der Grundlage eines festen Wertes oder einer variablen Berechnung eingeben.
• From (Name): Wenn dies nicht angegeben wird, ist dies immer der Name des Benutzers, der den Trigger- oder den Bildschirm-Flow startet. Man kann hier auch einen Namen auf der Grundlage eines festen Wertes oder einer variablen Berechnung eingeben.
• RTF Body: Dieser Parameter wird nur benötigt, wenn man keine Lightning-E-Mail-Vorlage verwendet. Damit kann man im Flow eine Textvorlage erstellen, die den Inhalt der E-Mail-Nachricht enthält. In der Textvorlage selbst kann man angeben, ob es sich um reinen Text oder um einen Body mit Formatierung handelt.
• Save as Activity: Standardmäßig wird die E-Mail in der Aktivitätenzeitleiste des Kandidaten oder der Kontaktperson gespeichert. Wenn man dies nicht möchte, muss man diese Variable mit der Konstante {!$GlobalConstant.False} füllen.
• Subject: nur anwendbar, wenn man eine Variable im RTF Body verwendet. Bei Verwendung einer Lightning-E-Mail-Vorlage wird der Titel der Vorlage verwendet.
• Target Record Id: nur relevant, wenn eine Lightning-E-Mail-Vorlage verwendet wird, bei der die zusammenfügbaren Felder auf der Grundlage eines bestimmten Objekts eingefügt werden. Zum Beispiel ein Job Kandidat- Mit diesem Parameter kann man die Datensatz-ID für den betreffenden Job Kandidat eingeben, um so die Werte aus diesem Datensatz in die E-Mail zu übernehmen.

SMS-Versand an mehrere Kontakte und Benutzer
Wir haben jetzt auch die Möglichkeit eingerichtet, eine SMS an mehrere Kontaktpersonen oder Benutzer zu versenden. Dazu verwendet man die APEX-Komponente „CMMessagingFlow“. Hierfür benötigt man ein zusätzliches Abonnement von CM. Wenn man diese Komponente selektiert hat, kann man die folgenden Parameter einstellen:

• Email Template Name: hier gibt man die Lightning-Vorlage für den SMS-Versand an. Für SMS-Nachrichten kann man eine Lightning-E-Mail-Vorlage erstellen, in der man unnötige Zeichen und Formatierungen entfernt. Man kann auch die Spracherkennung verwenden, damit der Empfänger die Nachricht in seiner eigenen Sprache erhält. Dazu fügt man den API-Wert des Auswahllistenfelds „msf__language__c“ in die Beschreibung der E-Mail-Vorlage ein, z. B. [Englisch].
• Ids: Dies ist eine Sammlungsvariable mit Kontaktdatensatz-IDs und Benutzerdatensatz-IDs, an die die SMS gesendet werden soll.
• Save as Activity: standardmäßig wird die SMS in der Aktivitätenzeitleiste des Kandidaten oder der Kontaktperson Wenn man dies nicht möchte, muss man diese Variable mit der Konstante {!$GlobalConstant.False} füllen.
  

In Personen suchen kann man nach einem Auswahlkriterium selektieren. Manchmal ist eine Auswahlkriterium-Liste sehr umfangreich oder besteht aus mehreren Ebenen. Die Suchfunktion im Pop-up-Fenster „Suchwert hinzufügen“ hilft dabei, schnell das richtige Auswahlkriterium zu finden. Bei dieser Suchfunktion haben wir einige Verbesserungen vorgenommen.

• Suchfunktion verwenden, um mehrere Auswahlkriterien zu selektieren 
  Angenommen, man macht Folgendes: Man sucht nach Auswahlkriterium A und klickt darauf, um es zu selektieren. Man sucht dann nach Auswahlkriterium B und klickt darauf, um es ebenfalls zu selektieren. Ab sofort speichert die Software sowohl Auswahlkriterium A und B und wendet beide im Suchprofil an. Dies gilt natürlich für alle Auswahlkriterien, die auf diese Weise gesucht und angeklickt werden.
  

• Selektierte Auswahlkriterien jetzt auch in der Tag-Box sichtbar
  Die selektierten Auswahlkriterien A und B aus dem vorherigen Punkt waren bereits im Pop-up-Fenster durch einen farbigen vertikalen Balken links neben einem Auswahlkriterium erkennbar. Jetzt werden sie auch in einer separaten Tag-Box in alphabetischer Reihenfolge angezeigt. So hat man einen besseren Überblick über die selektierten Auswahlkriterien.
• Gefundene Treffer werden in aufgeklappten Ordnern angezeigt
  Angenommen, man sucht nach einem Auswahlkriterium mit „Kleidung“ in der Beschreibung und „Kleidung“ ist in mehreren Ebenen enthalten. Von nun an werden alle gefundenen Auswahlkriterien direkt in ihrem aufgeklappten Ordner angezeigt.

Ab diesem Release haben wir die Möglichkeit hinzugefügt, über den Mysolution Plugin Kandidaten ausgehend von XING zu erstellen. Um die Integration mit XING zu optimieren, wurde ein neues Feld zum Kontakt-Objekt hinzugefügt: XING-url. Darüber hinaus wurde das Mysolution Simple Recruiter Plugin angepasst. Ab Release 3.0.7 ist es auch möglich, Kandidaten ausgehend von XING zu erstellen, wobei das XING-Profil in dem neuen Feld gespeichert wird. Die Integration mit LinkedIn bleibt unverändert, das Profil wird im LinkedIn-URL-Feld gespeichert.

1. Die Berechtigungen für das Objekt Kontakt und das Feld XING-url
2. Dieses Feld stellt man in das Seitenlayout eines Kandidaten.

In diesem Release haben wir die Möglichkeit geschaffen, die Darstellung von Zahlen- und Datumfelder pro Dokumentvorlage zu definieren. Zu diesem Zweck wurde ein neues Objekt hinzugefügt: Kulturelle Einstellungen. In diesen Einstellungen kann man für jede Sprache das Dezimaltrennzeichen und das Tausendertrennzeichen sowie ein Datumformat festlegen. In der Dokumentvorlage selektiert man dann die entsprechenden kulturelle Einstellungen, die bei Erstellen des Dokuments verwendet werden sollen. 

1. Berechtigungssätze anpassen: alle Rechte für das neue Objekt Kulturelle Einstellungen gewähren. Als nächstes muss man in der Dokumentart Vorlage auch Rechte für das Feld „Kulturelle Einstellungen“ gewähren.
2. Seitenlayout in dem Objekt Dokumentart Vorlage anpassen, indem das Feld „Cultural Settings“ auf dem Seitenlayout platziert wird.

In einer der letzten Releases haben wir eine Funktion eingerichtet, um aus einer Dokumentart Vorlage die verwendeten zusammenfügbaren Felder in eine separate XML-Datei als Anhang einzufügen. Dies geschieht auf der Grundlage der Einstellung „Neue Methode verwenden zur Erstellung von Dokumenten“ im Objekt Dokumentart. Wenn das zusammengefügte Dokument jedoch zu groß ist, kann eine Fehlermeldung erscheinen, die verhindert, dass die Dokumentart Vorlage gespeichert wird. In diesem Release haben wir eine Änderung vorgenommen, sodass das Extrahieren der XML-Felder aus dem Dokument außerhalb von Salesforce erfolgt.

Zu den benutzerdefinierten Einstellungen wurde eine neue Einstellung „Mysolution Service Connection Settings“ hinzugefügt. Sie wird in Zukunft benötigt, um bestimmte Funktionen in MSR zu aktivieren.

Laden Sie sich hier die neuesten Fixed Features als PDF herunter >

Job Kandidaten werden nach Bewerbungsstatus gruppiert und in der Reihenfolge angezeigt, die dem in der Auswahlliste für den Bewerbungsstatus festgelegten Wert entspricht. Standardmäßig werden beim Öffnen der Kanban-Übersicht maximal 7 Job Kandidaten angezeigt. Mit der Schaltfläche "Mehr" am unteren Rand der Spalte können in der Übersicht weitere Bewerbungen angezeigt werden. 

Wenn Sie mit der Maus auf eine Bewerbungskachel gehen, wird das Standard-Popup auf Basis der sichtbaren Spalten in der Listenansicht angezeigt:

Der Kandidat wählt ein freies Zeitfenster aus dem Kalender aus und erhält dann eine Bestätigung per E-Mail oder SMS.

Vor dem eigentlichen Termin wird eine weitere Erinnerung verschickt. Der Kandidat kann den Termin auch über den bestehenden Link stornieren oder verschieben. Er erhält auch eine Erinnerung, wenn er noch keinen Termin vereinbart hat.

Um diese Funktion nutzen zu können, ist eine umfangreiche Konfiguration notwendig. In diesem Release wollen wir einige Kunden zu ihren Erfahrungen mit dieser neuen Funktion befragen. Wenn Sie daran interessiert sind, wenden Sie sich bitte an die Support-Abteilung, um die Möglichkeiten zu besprechen.

4. In der E-Mail-Bildschirmkomponente verknüpfen Sie die Sammlungsvariable im Parameter Sender E-Mails:
    

5. Nach Aktivierung des Flows können Sie das Ergebnis im Kandidatenprozesse-Bildschirm einsehen.

Wenn Sie in der Sammlungsvariablen nur eine E-Mail-Adresse zugewiesen haben, wird Ihnen als Benutzer diese E-Mail-Adresse als Standardadresse angezeigt und können Sie keine andere Adresse mehr auswählen.

Wenn ein Bewerbungsprozess mit dem ausgewählten Job verknüpft ist, werden nur die Status angezeigt, die im Rahmen dieses Prozesses möglich sind. Sie können einen Kommentar hinzufügen und nach dem Speichern wird die Bewerbung erstellt. Natürlich wird geprüft, ob eine Bewerbung bereits vorhanden ist. 

Das Hinzufügen zur Bewerbung kann entweder über eine Schaltfläche in der Aktionsleiste oder direkt aus der zugehörigen Liste der Bewerbungen erfolgen:

• Wenn Sie diese Schaltfläche oben auf der Seite platzieren möchten, müssen Sie die Schaltfläche "Person zum Job hinzufügen" auf das Seitenlayout im Abschnitt "Mobile und Lightning-Aktionen" ziehen.
• Um die Schaltfläche in der zugehörigen Liste verfügbar zu machen, navigieren Sie zu den zugehörigen Listen/ Bewerbungen im Seitenlayout und wählen die Eigenschaften der zugehörigen Liste aus:

Laden Sie sich hier die neuesten Fixed Features als PDF herunter >

In dieser Softwareversion haben wir die Möglichkeit eingebaut, eine oder mehrere Knockout Fragen bei einem Stellenangebot (Job) festzulegen, die der/die Bewerber*in beim Ausfüllen des Bewerbungsformulars mit Ja oder Nein beantworten muss. Aus der Bewerbung lässt sich dann ersehen, wie viele Anforderungen erfüllt sind, sodass Sie einen schnelleren Überblick über diejenigen Bewerber*innen bekommen, die die festgelegten (harten) Kriterien nicht erfüllen.

Zu diesem Zweck wurden neue Objekte und Felder hinzugefügt. Als Erstes gibt es ein mit dem Stellenangebot (Job) verbundenes Objekt: die „Job Knockout Frage“. Darüber hinaus gibt es ein mit der Bewerbung (Kandidat) verbundenes Objekt: Die „Knockout Frage Antwort“. Sie sehen neue Felder in Job Kandidat: „Gesamtzahl Knockout Fragen“, „Knockout Fragen Bestanden“ und ein erreichter „Knockout Fragen Bestanden Prozentsatz“. Wenn beim verknüpften Stellenangebot (Job) keine Knockout Fragen definiert wurden, bleibt der erreichte Prozentsatz leer. In allen anderen Fällen wird hier ein Prozentsatz angezeigt.

Knockout Fragen werden automatisch zu einem Sub Job hinzugefügt, wenn Sie diese beim Erstellen direkt mit einem Job verknüpfen. Auch die Anzahl der Knockout Fragen wird in der Bewerbung vorhanden sein, sobald diese in Job Kandidat erstellt werden. Wenn Sie später weitere Fragen hinzufügen, werden diese nicht automatisch verarbeitet!

Um diese neue Funktionalität nutzen zu können, sind folgende Konfigurationsschritte erforderlich:

1. Berechtigung oder Profil ändern: Berechtigung für alle Felder der neuen Objekte „Job Knockout Frage“ und „Knockout Frage Antwort“ erteilen.
2. Seitenlayout des Job-Objekts anpassen und die zugehörige „Knockout Fragen“-Liste auf der Seite einstellen. Beim „Job Kandidat“-Objekt fügen Sie die zugehörige „Knockout Frage Antwort“-Liste hinzu und integriert die 3 Knockout Frage-Felder ins Seitenlayout.
3. Um Knockout Fragen im Bewerbungsformular nutzen zu können, fügen Sie ein neues Feld hinzu unter „Setup (Einstellungen), Typen für benutzerdefinierte Metadaten, Portal Job Application Form Detail (Portal Bewerbungsformulardetail)“. Dieses Feld gehört zum Typ Knockout Frage.

Anschließend können Sie die Knockout Fragen passend zum jeweiligen Stellenangebot (Job) formulieren. Bei Knockout Fragen wird nur eine Ja/Nein-Auswahl erwartet, wobei nur die positiven Antworten in die Berechnung mit einfließen.

Bei einem Job sieht das so aus:

Die Antworten werden bei Job Kandidat verarbeitet:

Die Knockout Fragen können auch auf dem Portal übersetzt werden. Über den App-Starter erstellen Sie eine Übersetzung für „KnockoutQuestion_<<id der Knockout Frage>>“, zum Beispiel: KnockoutQuestion_a2P1x000001UgTMEA0. Sie können die ID auf der Detailseite der entsprechenden Frage abrufen:

Knockout Fragen können auch über die API abgerufen werden. Eine neue Klasse ist ebenfalls verfügbar. Über /apexrest/msf/api/job/GetKnockoutQuestions können Sie diese abrufen. Optionale Parameter sind IDs (hier können Sie eine oder mehrere Job-IDs getrennt durch Semikolon (;) eingeben), Limit und Offset. Die Antwortnachricht enthält u.a. die folgenden Felder:

    "Id": "a14AW0000089G5lYAE",
    "Name": "KOQ-00000",
    "msf__Job__c": "a18AW000000B6RtYAK",
    "msf__Knockout_Question__c": „Haben Sie eine Lehrbefähigung?“,

Darüber hinaus können Sie auch positiv beantwortete Fragen in der Apply API angeben, indem Sie die ID der entsprechenden Frage in den Antworttext aufnehmen. Die Antwortnachricht könnte wie folgt aussehen:

  "setApiName": "default",
  "status": "Application",
  "isExternalSource": false,
  "utm_campaign": "Q4-email-campaign",
  "utm_content": "call-to-action-button",
  "utm_medium": "email",
  "utm_source": "special-offer-mailinglist",
  "utm_term": "job-openings",
  "fields": {
    „Vorname“: {
      "value": „Otto“
    },
    „Namenszusatz“: {
      "value": „von“
    },
    „Nachname“: {
      "value": „Hülst“
    },
    „E-Mail“: {
      "value": „testmailmysolution@mail.com“
    },
    „Handy-Nummer“: {
      "value": „0049(0)171-12345678“
    },
        „Knockout_Questions": {
      "value": a14AW0000089G5lYAE"
    },
    „Datenschutzerklärung“: {
      "value": true
    }
  }
}

Sollte der Kandidat keine positive Antwort auf eine Knockout Frage geben, wird diese nicht mit der Antwort verschickt.

In den letzten Softwareversionen war es bereits möglich, im Kundenportal nach Kandidaten zu suchen. Ab sofort ist es auch möglich, einen Controller für die Bewerbersuche zur Verwendung in einem Kandidatenportal einzurichten. So können sich die Bewerber*innen auch gegenseitig suchen. Welche Informationen den Bewerber*innen im Portal angezeigt werden, ist abhängig von der Konfiguration des Controllers für die „Kandidatensuche“.

In „Setup (Einstellungen), Typen für benutzerdefinierte Metadaten, Candidate Status Setting (Kandidatenstatuseinstellung)“ gibt es ein neues Feld: „Use Search Candidate on Candidate Portal“. Hier können Sie angeben, ob Sie möchten, dass auch Bewerber*innen mit diesem Status im Kandidatenportal angezeigt werden. Die bisherige Einstellung bekam zugunsten der Deutlichkeit eine neue Bezeichnung: „Use Search Candidate on Customer Portal“.

Um dies einstellen zu können, muss das Seitenlayout von „Candidate Status Setting (Kandidatenstatuseinstellung)“ geändert und das neue Feld auf der Seite eingefügt werden. 

Sie können dann die üblichen Schritte ausführen, indem Sie einen Controller über den App-Starter erstellen, ein Portal Menu Item (Portal Menüelement) in „Typen für benutzerdefinierte Metadaten“ erstellt und die Portalkonfiguration aktualisiert.

Ab dieser Softwareversion besteht die Möglichkeit, Mitarbeiter*innen für bestimmte Projektkostenstellen zu autorisieren, sodass diese nur die zugewiesenen Kostenstellen im Stundenportal verwenden können. 

Zu diesem Zweck wurde das neue Objekt „Kostenstelle Berechtigung“ hinzugefügt, das einen Verweis auf den/die Bewerber*in (Kandidat), das Projekt, die Kostenstelle Platzierung/Projekt oder die Kostenstelle (Account) enthält. Hier geben Sie auch jeweils ein Start- und Enddatum ein. Die Kostenstelle Berechtigung kann ausgehend von Kandidat, Projekt, Kostenstelle Platzierung/Projekt oder Kostenstelle hinzugefügt werden. Ausgehend von jeder dieser Möglichkeiten wird die entsprechende Entität automatisch ausgefüllt und können die restlichen Felder selbst ergänzt werden. Außerdem wird geprüft, ob die ausgewählte Kostenstelle auch mit dem entsprechenden Projekt oder dem mit dem Projekt verbundenen Account verknüpft ist. 

Für das Objekt „Kostenstelle Platzierung/Projekt“ wurde eine Kontrolle hinzugefügt, sodass nur einer der Verweise zur Platzierung oder zum Projekt ausgefüllt werden kann, um die oben genannte Kontrolle zu ermöglichen.

Um diese Funktion nutzen zu können, sind folgende Konfigurationsschritte notwendig:

1. Über das Profil oder den Berechtigungssatz müssen dem Benutzer die Rechte zur Verwendung aller Eigenschaften des neuen Objekts „Kostenstelle Berechtigung“ erteilt werden.
2. Sie legen fest, über welche Objekte die Berechtigung erteilt werden soll und fügt im entsprechenden Seitenlayout die zugehörige Liste „Kostenstelle Berechtigung“ hinzu.
3. Beim Objekt „Kostenstelle Berechtigung“ muss im Seitenlayout bei „Aktionen in Salesforce Mobile und Lightning Experience“ das standardmäßige „Löschen“ durch die benutzerdefinierte Schaltfläche „Delete“ ersetzt werden:

Dadurch wird die entsprechende Anpassung sofort nach Entfernen des Objekts synchronisiert. Wenn die Standardschaltfläche nicht ersetzt wurde, lässt sich der Datensatz nicht entfernen.

Innerhalb von Mysolution Recruitment war es bereits möglich, ein Auto zu erfassen und einem/einer Mitarbeiter*in zuzuordnen. Ab dieser Softwareversion ist es auch möglich, ein Fahrrad zu erfassen und zuzuordnen.

Um dies zu ermöglichen, wurden Datensatztypen zum Objekt „Auto“ hinzugefügt: „Fahrrad“ und „Auto“. Letzteres gilt als Standardeinstellung. Wenn Sie beim Anlegen des Objekts die Datensatztyp „Fahrrad“ auswählen, können Sie die Fahrgestellnummer eingeben. Bei der Fahrzeugzuteilung kann einem/einer Mitarbeiter*in dann auch ein bestimmtes Fahrrad zugeordnet werden. Beide Datensätze werden auch synchronisiert.

Um diese Funktion nutzen zu können, sind die folgenden Einstellungen erforderlich:

1. Zunächst erweitern Sie die Berechtigungen im Profil oder Berechtigungssatz: Für das Objekt „Auto“ müssen die Datensatztypen „Auto“ und „Fahrrad“ aktiviert werden. Sie müssen auch über die Bearbeitungsrechte für das Feld „Fahrgestellnummer“ verfügen.
2. Im Objekt-Manager müssen Sie für das Objekt „Auto“ bei der Seitenlayoutzuweisung das „Bicycle“-Layout („Fahrrad“-Layout) mit der Datensatztyp „Bicycle“ („Fahrrad“) verknüpfen. Bei Bedarf können weitere Felder zum Seitenlayout des Objekts hinzugefügt werden, z. B. Status oder Marke. Sie können das Feld „Datensatztyp“ auch zum aktuellen „Car“-Layout („Auto“-Layout) hinzufügen.
3. Falls gewünscht, können Sie die Beschreibung des Objekts „Auto“ ändern in „Transportmittel“ sowie „Autozuteilung“ in „Transportmittelzuteilung“. Dies machen Sie über „Setup (Einstellungen), Registerkarten und Bezeichnungen umbenennen“, wo Sie einen anderen Namen eingeben können. Sie wählen die Sprache Deutsch aus und navigieren zu „Benutzerdefinierte Registerkarten“ und benennen „Auto“ und „Autozuteilung“

Wenn Sie „Fahrrad“ nicht als Objekt registrieren möchten, müssen Sie nichts weiter machen.

Laden Sie sich hier die neuesten Fixed Features als PDF herunter >