Zu den wichtigsten Erweiterungskonzepten in SuccessFactors Employee Central gehören das MDF-Datenmodell sowie Business Rules. Ersteres kann benutzt werden, um gänzlich neue Objekte aber auch Portlets für die Mitarbeiterstammdaten zu erstellen. Business Rules werden durch eine IF-THEN-ELSE Struktur umgesetzt. Wenn also eine Bedingung erfüllt ist, kommt es zu einem bestimmten Systemverhalten. Wichtige Anwendungsbereiche sind das Festlegen von Vorschlagswerten, das Auslösen eines Genehmigungsverfahrens sowie das Anzeigen von Warn- und Fehlermeldungen.
Beim Erstellen von Business Rules müssen eine ID, ein Titel sowie ein Base Object festgelegt werden. Vielen bereitet die Auswahl des korrekten Base Objects größere Schwierigkeiten. Die entscheidende Frage ist, wodurch die Business Rule ausgelöst werden soll. Wenn beispielsweise beim Anlegen eines neuen Objektes, z.B. einer Position, ein Workflow ausgelöst werden soll, dann ist das Base Object genau dieses Objekt (also „Position“). Der Trigger, also der Auslöser, ist ein onSave Event. Dies bedeutet, dass alle Daten der Position eingegeben werden und beim Betätigen des Speichern-Buttons wird die Business Rule, und damit das Genehmigungsverfahren, ausgelöst.
Oftmals sollen Business Rules im Zusammenhang mit der Änderung der Personalstammdaten aufgerufen werden. Das korrekte Base Object richtet sich hierbei nach dem Portlet, welches bearbeitet wird.
Grundsätzlich wird für Änderungen des Job Info Portlets das „Job Information“ Base Object verwendet. Für den Fall, dass die Änderung des Job Info Portlets jedoch während des Einstellungsprozesses erfolgt, wird eine an und für sich korrekte Business Rule nicht aufgerufen. Die Fehlersuche erfolgt oftmals in der Business Rule selbst. Was jedoch das Problem nicht beseitigt. Die Lösung: für Hire/Rehire Prozesse muss das „Employee Information“ Base Object genutzt werden.
Grundsätzlich kann in den meisten Fällen problemlos das „Job Information“ Base Object genutzt werden. Soll jedoch geprüft werden, ob der aktuelle und der vorherige Feldwert gleich oder unterschiedlich sind, dann kommt das „Job Information Model“ Base Object zum Zuge. Weitere Anwendungsfälle sind, wenn das sichtbar-Attribut (visibility) oder das Optional/Mussfeld-Attribut (required) unter bestimmten Bedingungen angepasst werden soll. Für manche Mitarbeitergruppen soll bspw. ein Feld angezeigt, für andere ausgeblendet werden.
Wenn nun die Änderung des visibility- oder required-Attributes während eines Hire/Rehire-Prozesses erfolgen soll, ist das hierfür notwendige Base Object „Employee Information Model“.
Bisher musste das visibility-Attribut durch das Eintippen eines der Werte „none“, „edit“ oder „view“ gesteuert werden. Dies ist fehleranfällig, nicht zuletzt auch, da auch „true“ und „false“ nicht wirklich falsch klingen (aber nicht zum gewünschten Ergebnis führen).
Dank der Neuerung steht nun eine Pickliste mit den folgenden Werten zur Verfügung:
Damit erübrigt sich die Frage wie der korrekte Wert heißt.