Managing Alerts and Notifications in Employee Central

[Sharath_T_N]

Introduction:

This blog post introduces you to the SuccessFactors Implementation Design Principle (SFIDP) document: (Employee Central: Managing Alerts and Notification) that was published a few months back. Implementation Design Principle documents are owned and managed by SAP SuccessFactors Product Management who engage and collaborate with select, interested partners along with SAP Professional Service to tap the rich implementation experience that is distilled in the document after a formalized product review process before wider publication.

Alerts and Notifications in Employee Central

Employee Central Alerts are period/time-based triggers based on specific conditions that create a To-Do alert or sends an email notification to the user with a configured message. Notifications are pre-defined messages provided to employees/administrators that specifies an approaching due date. This triggers a reminder for the users to take appropriate action that is required before the due date (In some cases after a date).

This document showcases typical business scenarios needing alerts and notifications with business rules in an efficient way. The document helps in understanding the job for alerts. This will also recommendations on how to avoid some common mistakes during configuration.

 

EC Alerts and notifications Job

One of the most important topics that needs to be understood well is the Job for alerts and notification.

 

This job is run every day, it executes the business rules that are attached to the portlets(example JobInfo) as “saveAlert” rules. It also is responsible to send the alerts to the end-users for those records that match the job run date (that is already in the alert object). If the data change of the due date requires approval, the alert is created only after the workflow is completed.

The crux of the whole concept of EC alerts and notifications depends on the Job for alerts and notification. Often it is a misnomer that the business rule for alerts is called when the portlet is saved, but this is not always true. The business rules for alerts are executed when the Job is run for the portlets based on HRIS elements like Job info. For MDF based alert events the rules are processed on the “Post Save” event.

 

There are 3 major steps of the Job

1. Execute the business rules for Alerts

                      

 

This goes through the portlets that are supported, picks up those records that are between the “last successful run date” and the “last modified date”

and the IF condition is evaluated in all the alert business rules. When the condition is met, the job creates an alert.

 

2. Trigger the alerts /notifications

In addition, the job compares system-date with the alerts that are due, if it is due it sends out the alerts in the To-Do /Take Action tile and the email notifications to the appropriate users as defined in the workflow.

3. Update the Alert objects for which the notifications have been sent

Once the email notifications/ To-Do list has been sent those records should be marked as sent (updates he status of the pending alert to completed) in the alert object. The job also picks up the MDF alerts in the alert object and creates the notifications for them when the job run date matches an alert effective day.

 

Recommendations on running the Job.

First Time only:

When the job is run for the first time (Specify a date) in the system, schedule a one-time job by specifying a reasonable start date. Please note that if the job is scheduled to date that significantly in the past the job can take a longer time to execute.

 

Setting after the first run:

After the first job, you can change the date to the Last successful EC Alert job run date. If you choose to run from the Last successful EC Alert job run date, the job will scan the records that are updated after the last successful run date of the job.

SCENARIOS

Scenario 1 – Alert Dynamic Group for Contract End Date in Job Information

In this example, an alert is triggered 14 days before the end of a Contract to users in two dynamic groups. Both an alert is created in the To-Do section as well an email notification is sent.

Alert Message

In Admin Center -> Manage Data, specify the alert message by entering the alert header and text.

Dynamic Group

• In Manage Workflow Group, create a dynamic group HR_RECRUIT_GROUP which includes a group of recruitment users.

                  

• Create another group called HR_ADMIN_GROUP that includes 4 HR administrators.

          

Workflow

In “Manage Organization, Pay and Job Structures” transaction, set up the workflow. In this example, the alert is sent to the dynamic groups HR_RECRUIT_GROUP and HR_ADMIN_GROUP. They are specified in Step 1 and Step as recipients of alerts. In order to send an email to both groups, they are also defined in the CC Role section. As a result, all three recruitment users and all four HR Administrators will get an alert in the Take Action tile as well as an email notification.

   

Business Rule

Go to Configure Business Rules, assign the workflow and message to the business rule. The condition in this scenario is to create an alert 14 days before the contract ends. The alert is created when the contract end date has been changed for an active employee and today’s date is more than 14 days before the contract end date. It checks for future records (end-date after today) or current record where the event start date was in the past, but today fulfills the criteria to trigger the alert. The alert is triggered when it is exactly 14 days before the contract end date.

Trigger

 

In Manage Business Configuration under Trigger Rules section, add the business rule created in the previous step to HRIS-Element Job Information (jobInfo) as Event Type saveAlert.



Note that if the contract end date is extended before it expires, the original alert is deleted. A new alert based on the new contract end date becomes the active alert.

OTHER SCENARIOS

There are many scenarios that are mentioned in the Implementation design principle document like the ones listed below.

Scenario	Alert on Object	Action Triggered
1	Job Information - Contract End Date (Already covered above)	Create an alert and email notifications to two dynamic groups 14 days before Contract End Date.
2	Global Assignment – Planned End Date	Alert a manager 5 days before the global assignment ends for the direct report. The alert helps to prepare the employee to return to the home assignment.
3	Position (MDF Object) – custom date field	Send an alert to a manager and a dynamic group14 days before the end date of a temporary unapproved position. Position can either be extended or convert to a permanent position.
4	Work Permit Expiry Date	Trigger multiple alerts before the work permit expires. One alert is sent 3 months before and another alert 1 month before the expiry date. Multiple alerts help to ensure legal documents are renewed in time to avoid time gaps in the work permits.
5	Time Off – Return from Leave	A manager receives an alert 2 days before the direct report returns from a paid leave.
6	Time Off – Duration of Leave	When an employee has reached 25 days into a 12-month leave, an alert is sent. The alert is used to monitor leaves that have reached a threshold.
7	Work Order End Date	An alert is triggered when the work order is going to end in 90 days using the Off-Cycle Event Batch.

 

The document also talks about some leading practices on the following topics

• 
  
  
  
  • Multiple countries with different document types and alert days
  
  
  • Best way to handle Global Assignment for alerts
  
  
  • How to debug an alert and test
  
  
  • How to make sure there are no duplicates in alert object
  
  
  • How to avoid inactive employees
  
  
  • How to avoid alerts created for historical records
  
  
  • Orphaned Alerts
  
  
  • How to stop Alerts
  
  
  • What Not to do in Business Rule for Alerts
  
  
  
  

For more details please read Implementation design principle document .

Conclusion/Key Takeaways:

This Implementation design principle document had valuable contribution from SAP SuccessFactors partners towards authoring and include Imelda Schwenger from HRIZONS

I would also acknowledge Mary McHale-Roe from SAP for helping and reviewing the document.

We hope this blog post helped you get acquainted with the basic understanding of the concepts & use cases defined and discussed in the SFIDP. We recommend you to further explore the document for a full-fledged discussion that will aid you in better product implementation as well as help you align with the industry leading practices. We look forward to your valuable comments/feedback/queries on this blog post.

 

Check out the new updates in the new blog