Human Capital Management Blogs by Members
Gain valuable knowledge and tips on SAP SuccessFactors and human capital management from member blog posts. Share your HCM insights with a post of your own.
Showing results for 
Search instead for 
Did you mean: 
Here i am trying to cover almost everything we have implemented for our customer in the last 15 days for Alerts and Notifications. The Blog will cover the Overview of the service and the scenarios we have faced during implemention of it after Go-Live.

Business Scenario :This service was part of the orginal Go-Live for 7 scenarios but somehow missed by the implementation partner. After few months of Go-Live, Customer realised that Alerts and notifications services is not working at all. After initial investigations, we found out that all the system settings(Will be discussing later) were in place except the implementation partner have not created the provisioning job used to trigger the notifications.

Overview of the Service:

Alerts and Notifications is an important functionality on whcih HR Administrators/Manager/Authorised User rely to act on a particular piece of information accordingly. The most common example of this service used are for

  1. Contract End Date

  2. Contingent Service End Date

  3. Probation Period End Date

  4. Jury Service

  5. Disciplinary Sanctions

In all such cases, Customer can set up an Alert rule to monitor the Job information changes. When the information change match the business rule criteria, an email notification will be sent to the or a ToDo item will displayed to the workflow participants on the alert effective date. Customer can customize the email and todo message.

Broad Steps in setting up the Alerts and Notifications Services:

I will not go into details of each steps as they are being in various documentation. A summary of the steps though are:

Step 1: Identify HRIS Element

Identify for which HRIS Element customer wants to create Alerts and Notificatios and whether it is suported to create the saveAlert rule in SuccessFactors. Currently the following HRIS element are supported for saveAlert rules in successFactors:
TIME_OFF(MDF) - the create alert side is handled in time_off postSave event with event bus. The trigger alert side handled in EC alert and notification side.
Any HRIS Element not mentioned above cannot be accessed by the EC Alert engine currently.

Step 2: Adjust Alert Message Length

Adjust the length of the alertDescription fields to the length customer feels would be enough for the messages.

In Admin tools-> Company Settings -> Configure Object Definitions, search for AlertMessage.

Step 3: Create the Alert Message

Now we need to create the actual alert message we wants to create for each scenarios.
Go to Admin tools-> Employee Files -> Manage Data, Create New AlertMessage.

Following tags are supported :
•Subject user : [[SUBJECT_USER]]
•Event reason : [[EVENT_REASON]]
•Effective start date : [[EFFECTIVE_DATE]]
•Start date : [[START_DATE]]
•End date : [[END_DATE]]
•Time off type : [[TIME_OFF_TYPE]]
•Time off status : [[TIME_OFF_STATUS]]

Step 4 : Define the To-Do and Emails notifications recievers

In this step, you create a workflow for defining the To-Do and email reciepients.Approvers recieve a To Do Alert.Cc Role's recieve an email Notification.A reciepient need to be both an Approver and a Cc Role, to recieve both an Alert and Notification.

Go to Admin Tools-> Manage Organisation, Pay and Job Structures, Create a workflow.

Step 5: Define Business Rules for Alerts/Notifications

Create the backbone of the Alert and notifications services,The business rules to define the checks based on which Alerts/Notifications will be triggered.

The IF conditions is the logical part where we can define different criterias based on which the Alerts will be generated.
The THEN condition define the actions which will be done once any records in the HRIS Element satisfy the logical conditions.
Here we use the workflow information defined in step 3 to define the reciepients, set the effective date on which alerts/notifications will be sent and the actual message for that particular scenario as shown in the attached screen.

If we do not define any alert message, the default message formet will be:
Email Header/todo name: Alert for "subject user name", "event reason"
Email Body/todo detail: Alert fot "subject user name", "event reason" on "effective start date".

We can use Date Plus() function to define when the alert will be sent. If you wish for the alert to be triggered days before or after the Probation End date.(-10   means 10 days before)

Step 6: Add the business Rules created to HRIS Element in SDM

Here we assign the business rule to the corresponding HRIS element the field is related to, for which we are creating the Alerts/Notifications.
We can do this in SDM XML : <trigger-rule event="saveAlert" rule="rule_name"/> Or
via Admin Center > Manage Business Configuration > jobInfo element > Rule Type = saveAlert).

Step 7: Create and run the "EC Alerts and Notifications" Job in Provisioning

Here we create a recurring job which should be running daily to have a consistent notifications behaviour across the board. Whenever we create a job having gaps in between, there have been inconsistencies observed for Alerts/Notifications.

So this was the process to setup the Alerts/Notifications in an ideal world.

As I started this blog giving the scenarios which my customer was in, I will provide insight how we overcame that situations and tried to minimize the effect of the old business rules and provisioning Job not created and run since the Go-Live.

Customer wants to change with 4 scenarios after Go-Live but i will walk you through Contract End Date here. At the time of Go-Live, the Alert message, Workflow and business rules were all setup and assignment were made to Job_Information HRIS element as well.
The only piece which were missing was the "EC Alerts and Notifications Job" in provisioning.

So this means that Alerts were created statically and were sitting statically in the system for the records whenever the business rules IF condition is satisfied. If the Provisioning Job was created having the LAST MODIFIED SINCE date in job parametrs as the Go-Live date, the Alerts and Notifications would have started to work again.

But when we analysed the business rules as well,and Customer also changed their requirements, we have to change the business rules as well.

The rules dont have anything in the IF condition and would have created an Alerts/Notifications whenever there was a save on the Job_Information HRIS element. The Alerts/Notifications would have been sent 1 month prior to contract end date to the reciepients defined in the managerAlert workflow.

This would have created multiple and duplicate notifications for the same records. Also customer wanted to have no Alerts/Notifications for the dates in the past. Also there should not be any Alerts/Notifications for the Inactive employees as well.

This forced us to amend the business rules as well. the new rules which was according to customer requiement were as follows:

Here the first two conditions ensures there was no multiple/duplicate Alerts/Notifications send.
Third conditions ensure no Alerts/Notifications for the past dated records.
The last conditions ensures that no incative employee recieves the Alerts/Notifications.

Now the Provisioning Jobs needs to be created with LAST MODIFIED SINCE as the date on whcih we created the new business rules. This was to ensure no notifications is sent using the old business rules.

Key Learnings for EC Alerts/Notifications:

  • Alerts are triggered when the 'IF' condition of the business rule is meet when clicking save on the corresponding portlet.

  • The alert message is then triggered and waits statically in the system until the effective date is reached.

  • When the effective date is reached and the 'EC Alerts and Notifications' job in provisioning is ran the alerts are sent.

  • The Job should be created as recurring and run daily.

  • When creating a Business Rule to trigger an EC Alert & Notification, you should use a ‘Model’ Base Object.

It means the Alerts/Notifications are created based on the business rules IF conditions and then provisioning job checks records which are modified from a particular date (For recurring job, its the last date since job run) and sends the alerts.

Hope this article will clear few of the doubts which my community friends may have and we encountered while implementing this service after the Go-Live.
Labels in this area