Keeping employees and managers informed of key dates and deadlines related to HR tasks can prove more challenging than it really should be for most organizations. It’s hard to rely on users to know when probationary periods end, certifications expire, or other tasks require upcoming or immediate attention.

SAP SuccessFactors provides features for addressing these challenges across the suite, including the use of alerts within Employee Central. Alerts allow users to create to-do lists and email notifications for individuals or groups of users when a particular period is approaching its end or another deadline is nearing so that appropriate actions can be taken. Alerts provide push communication to users from SAP SuccessFactors, thereby removing the reliance on users for keeping separate track of these end-of-period actions.

Employee Central alerts are flexible and are configured using a collection of Employee Central-related data elements. Alerts around standard Employee Central data objects have been a feature of the product for quite some time. However, SAP SuccessFactors recently extended alert capabilities to custom Metadata Framework (MDF) objects, thereby allowing organizations to use alerts around custom objects and processes—a task that organizationsorganizations could not do before the Q3 2017 release. I provide an overview of the Employee Central alerts functionality, what alerts can be triggered, and how to configure them in your system for both standard Employee Central objects and custom MDF objects.

Types of Alerts

Alerts in SAP SuccessFactors come in two forms: ToDo list alerts and email notifications. ToDo list alerts are notifications that are presented to users within SAP SuccessFactors itself, with the alert being placed within a user’s to-do list or section on the user’s SAP SuccessFactors home page (Figure 1). Users can view the alert from their home page and confirm (close) the alert accordingly.

Figure 1

ToDo alerts from the SAP SuccessFactors home page

Alerts can also be sent to users as email notifications. In this way alerts can be sent to users outside of SAP SuccessFactors, providing the same information via email (Figure 2).

Figure 2

Alert sent as email notification

The Building Blocks for Employee Central Alerts

Employee Central alerts are constructed through the use of three different objects in SAP SuccessFactors: alert messages, workflows, and business rules.

Alert messages provide a template for defining what information is displayed in a ToDo list or email notification alert. Users can define their own alert messages for use in Employee Central alerts using the AlertMessage data object. Optionally, they can allow the system to use a default message format when alerts are processed. Alert messages define an Email Subject/ToDo Item Name along with Email Body/ToDo Item Detail text that make up the content of an alert.

Workflows are then used by Employee Central alerts for determining who receives alerts and notifications. Workflows defined in SAP SuccessFactors are typically used to define approval roles, contributors, and CC recipients. The workflow approval steps must be processed by each defined individual or group. However, workflows for alerts do not require a formal process. Instead, through the use of approval steps and CC users, the system defines who should receive ToDo list alerts (approval step participants) and who should receive email notifications (CC users or roles).

Lastly, in the overall process for Employee Central alerts within SAP SuccessFactors, business rules are used to define situations that should trigger alerts within the system. Business rules for alerts trigger an appropriate alert for a particular alert message and workflow along with an effective date for the alert in which it should be processed (distributed) by the system.

As business rules are executed for alerts in SAP SuccessFactors and alerts are triggered accordingly for future effective dates, to-be processed alerts are saved by SAP SuccessFactors for later distribution. A background job in provisioning is then used to evaluate stored alerts within the system and to send alerts to appropriate users as effective dates of alerts are reached.

Objects Available for Employee Central Alerts

The Employee Central alert feature has been available within SAP SuccessFactors for a number of standard Employee Central objects for quite some time. With the original Employee Central alert capabilities provided in the system, users could define alerts per their own requirements for changes done to the following HRIS elements or records (excluding country-specific fields):

• Job Information
• Compensation Information
• Employment Information
• Global Assignments
• Recurring/Non-Recurring Pay Components
• Work Permit
• Time Off

In the Q3 2017 release, SAP SuccessFactors extends alert capabilities to custom MDF objects. The Metadata Framework within SAP SuccessFactors allows users to create data objects for their own requirements and integrate these objects into the existing HR datasets captured for employees within the system. Workflow and other capabilities accessible within the MDF can allow organizations to create extensible datasets and processes to complement the standard HR data and processes supported in SAP SuccessFactors. Alert functionality can now be leveraged by custom MDF objects, providing further core features to the extension framework for customers.

If you wish to use alerts for MDF objects, you must first enable a feature in provisioning. Follow these steps to enable alerts for MDF objects in your instance (note that access to provisioning is only available to SAP SuccessFactors or certified partners, not customers):

1. Log in to provisioning and select the appropriate customer instance
2. Click Company Settings
3. Find the feature for Enable MDF Alerts for MDF objects [Not Ready for Sales/Production] and check the box next to the option (Figure 3)
4. Save the settings accordingly

Figure 3

Enable alerts for MDF objects via provisioning

Next, I discuss the process of creating alert messages, workflows, and business rules for creating alerts for both standard Employee Central-supported HRIS elements and custom MDF objects. Slight differences in configuration are required for implementing alerts across these two scenarios.

Create Alert Messages

Alert messages provide a template for alerts processed in SAP SuccessFactors. In this template you define two elements of the alert message: a header (subject) and a body (detail). Alerts can be received either via ToDo list items (available in the user’s ToDo tile or section) or via email. Alert messages are generic objects themselves and can be created by following these steps:

1. Go to Admin Centre > Manage Data (Figure 4)
2. Create a new object for an AlertMessage using the Create New selection field
3. Specify the required fields for the Name (externalName), Code (externalCode), Status (effectiveStatus), Header (alertHeader - subject), and Description (alertDescription - body) of the alert.

Figure 4

Create an alert message

Certain tags can be used in alert messages to place dynamic information about the alert in the alert header and body. The tags available depend on the type of the alert processed. Table 1 summarizes the tags available for standard Employee Central alerts, Time Off alerts, and custom MDF object alerts.

Table 1

Available tags for using dynamic information in alert messages

Define Workflows for Alert Recipients

While AlertMessages define the information contained within an alert, workflows define which users receive alerts and notifications. Workflow objects can be used across Employee Central for triggering approval processes for specific types of data changes or requests. The use of workflows for alerts in Employee Central is unique in that no approvals take place for an alert. Therefore, it is important to understand how the standard workflow attributes are processed for triggering alerts.

Workflows define three main sets of actors within a workflow process, including:

• Step approvers – Users or roles required to approve a workflow
• Contributors – Users who do not act as approvers, but can follow a workflow as it is executed (notified of changes and provide comments)
• CC roles – Users or roles who are informed whenever a workflow is completed

For the use of Employee Central alerts, however, these three sets of actors within a workflow process serve a different purpose. Any users or roles defined as workflow step approvers in a workflow for an Employee Central alert receive the alert in their ToDo lists or sections. Any users or roles defined as a CC role receive email notifications for the alert. Step approvers in a workflow for an alert are also considered equal participants. No steps to complete an approval process need to be followed for alert workflows. All defined step approvers for an alert workflow receive the alert notification at the same time. Lastly, contributors do not have any role in alerts.

To create a workflow for use in an Employee Central alert, follow these steps:

2. Create a new workflow object using the Create New selection field.

3. Specify the required workflow configuration as needed, including: a. Define any users/roles required to receive ToDo list notifications for the alert in the Step Approvers section. Specify the approver step information including Approver Type, Approver Role, Content, and other applicable field selections. b. Define any users/roles required to receive email notifications for the alert in the CC role section. Specify CC recipient information including CC Role Type, CC Role, and other applicable field selections.

Figure 5

Create a workflow object for use in alerts

Building Business Rules for Triggering Alerts

After you define an appropriate alert message and workflow objects for a desired alert, the next step is to create a business rule for the system to use to trigger the alert under the appropriate conditions when data changes occur in the system. Business rules can be used for a range of purposes in SAP SuccessFactors, including defaulting of values and field attributes, message processing, and alert triggers. When creating a business rule for alert processing purposes, you should create the rule for the base object that matches the element in which the rule is triggered.

To create a business rule, follow these steps:

1. Go to Admin Centre > Configure Business Rules
2. Create a new basic rule, specifying a rule ID/Name and optional Rule Type and Description
3. If you are creating an alert rule for standard Employee Central objects (not Time Off or custom MDF objects), you must add a Parameter to your rule for the alert as shown in Figure 6
4. Create the required If/Then statements for your business rule (described below)

Figure 6

Add the Alert parameter to business rules used for standard Employee Central HRIS data elements

Business rules are basically IF/THEN statements, and when you use them for alert purposes, the following general approach is used.

IF: Condition(s) that should be true to trigger an alert

THEN: Function to trigger the actual alert within SAP SuccessFactors

IF conditions within a business rule should always be specified when used for triggering an alert. In SAP SuccessFactors you can create business rules that have no IF conditions (they are set to always evaluate as true). In the case of alert processing, this would result in alert rules always being triggered for data changes against a particular object and could lead to duplication and resending of alerts to recipients, including potential performance issues due to the number of alerts created. Always ensure proper IF conditions are defined in business rules for alerts.

The IF conditions used for alert business rules depend on particular requirements. Following are a couple of use cases for alerts with examples of If conditions for business rules.

Use Cases

The first use case, shown in Figure 7, is a probation alert. It is set up to send an alert one month prior to the end of probation (Date field in Job Information HRIS-element). Job Information is one of the many data elements that make up an employee’s HR data in SuccessFactors. It stores data particular to an employee’s job, including the position held and other employment classifications or related fields.  A date field for Probation End Date is typically stored in Job Information.

Summary: Check to see that the probation period end date has changed, that the probation period end date is one month or more away from the current system date, and that the job information record in question is currently effective or effective in the future.

Figure 7

Sample IF statement for a business rule used for probation alert

The second use case, shown in Figure 8, is an alert to return company property as stored and tracked via a custom MDF object. The alert to turn in a laptop is to be sent out three weeks prior to the return date. It also checks to see if the company property log object is currently effective or effective in the future.

Figure 8

Sample IF statement for business rule for company property MDF object

When you are creating IF conditions, consider these tips:

• Always define IF conditions (do not create alert rules that always evaluate as true)
• Consider using model-based objects (i.e., a Job Information Model) where you can compare previous and new field values. This may be applicable to certain alerts when you only want to consider triggering the alert if a field value is changing (i.e., change in a Probation Period End Date). Base objects are the core objects upon which a business rule is built.  After you define a base object for the business rule, that then drives what data is available to you within the rule to use in the rule’s IF/THEN statements.
• Consider current/future records only by specifying IF conditions around an Event/Effective Date, including: Check if the Event/Effective Date is greater than or equal to Today’s Date OR. Check if the Event/Effective Date is less than Today’s Date AND the End Date is greater than or equal to Today’s Date.
• For alerts driven off key dates (i.e., Probation/Contract End Date) that need to send an alert X days prior to the key date in question, set an IF condition comparing the key date in question to be greater than or equal to Today’s Date plus the number of days or months prior in which the alert should be sent (i.e., one month prior to the Probation End Date)

While the IF conditions of an alert business rule act as the gatekeeper for determining when an alert should be triggered, the THEN conditions used for business alerts are responsible for actually triggering alerts within SAP SuccessFactors. Depending on the type of alert being triggered, the THEN condition performs a function or sequence of functions to create the alert. These functions reference the previously created Alert Message and Workflow objects to be used for the overall alert processing in addition to setting an effective date for the alert. The effective date for an alert is important as it represents the date that the alert should be sent to the applicable recipients (i.e., the alert notifications, both the To-Do list and email).

Next, I provide details on how to structure the THEN condition for alert business rules when triggering alerts for standard Employee Central alerts, Time Off alerts, and custom MDF object alerts.

Standard Employee Central Alert THEN Condition

SET expressions can be used in the THEN condition of a business rule used to trigger an alert for supported Employee Central data elements using the following (and illustrated in Figure 9):

• Alert.Workflow Information – Defines the workflow object to use for determining the recipients of the alerts (both the ToDo list and email notification)
• Alert.Effective Date – Defines the date in which the alert messaging is to be triggered and sent to recipients
• Alert.Alert – Defines the custom Alert Message object to be used for the alert message format (header and body). If no custom Alert Message object is defined, the system uses the default message template.

Figure 9

THEN condition for alert involving standard Employee Central data elements

Time Off THEN Condition

Instead of using SET expressions to trigger an alert, for Time Off objects the EXECUTE function Trigger Employee Time Alert Event () is provided for triggering alerts with the following format (and illustrated in Figure 10):

Execute Trigger Employee Time Alert Event ():

• Workflow Information – Defines the workflow object to use for determining the recipients of the alerts (both the ToDo list and email notification)
• Effective Date – Defines the date in which the alert messaging is to be triggered and sent to recipients
• Alert Message – Defines the custom Alert Message object to be used for the alert message format (header and body)
• External Code – Employee time object external code reference

Figure 10

THEN condition for alert involving a Time Off object

Custom MDF Object THEN Condition

THEN conditions for the newly supported MDF object alerts are similar to the Time Off THEN conditions that use an EXECUTE function for triggering the alert. The function Trigger MDF Alert Event () is provided for triggering alerts for MDF objects with the following format (illustrated in Figure 11):

Execute Trigger MDF Alert Event ():

• Workflow Information – Defines the workflow object to use for determining the recipients of the alerts (both the ToDo list and email notification)
• Alert Due Date – Defines the date in which the alert messaging is to be triggered and sent to recipients
• Alert Message – Defines the custom Alert Message object to be used for the alert message format (header and body)
• Generic Object – Reference to generic object for which the alert is triggered

Figure 11

THEN condition for alert involving MDF objects

Assign Alert Rules

After defining alert business rules and the related AlertMessage and workflow objects, you need to assign the alert rules themselves to their respective objects so that when applicable actions are taken in the system, such as changing or saving data records, the rules are triggered correctly. Again depending on the type of alert, the way in which the alert rules are triggered differs.

Assigning Alert Rules for Standard Employee Central HRIS Elements

Alert rules for standard Employee Central HRIS elements (i.e., Job Information) should be assigned in the Trigger Rules section against the applicable element with the Event Type specified as saveAlert. To assign rules for these types of objects follow these steps:

1. Go to Admin Centre > Manage Business Configuration
2. Select the appropriate HRIS data element in the menu
3. In the Trigger Rules section (Figure 12) toward the bottom of the object configuration that is displayed, add the previously created rule. Specify the Event Type of the rule as saveAlert and save the object configuration using the Save button (not shown).

Figure 12

Assignment of alert business rule for standard EC data elements

Assign Alert Rules for Time Off and Custom MDF Objects

Alert rules for Time Off objects and custom MDF objects are assigned against the applicable object configuration definition under the Post Save Rules section under Configure Object Definition used in SuccessFactors for managing configuration of MDF objects.  To assign rules for these types of objects follow these steps:

1. Go to Admin Center > Configure Object Definition

2. Select the appropriate object from the object selection provided. Ensure the assigned object is the base object used for the business rule (i.e., for Time Off alerts, this would be the employeetimes object). MDF object alerts cannot be assigned to composite objects.

3. Select the Take Action menu option and Make Correction

4. In the Post Save Rules section (Figure 13) of the object configuration, add the alert business rule and save the object configuration using the Save button provided (not shown)

Figure 13

Assignment of alert business rule for Time Off and MDF objects

When Alert Business Rules Are Triggered

Now that you understand how to assign Employee Central alert business rules to respective objects, it is imperative to understand when alert business rules will be triggered in the system. When these rules trigger differs again between whether the alerts are set up for Employee Central standard data elements or Time Off/custom MDF objects.

Triggering of Alerts for Standard Employee Central Data Elements

Triggering of Alerts for Time Off/Custom MDF Objects

For Time Off/custom MDF objects, alert business rules are configured against the object as Post Save Rules. These rules trigger immediately after the object in question is successfully saved in the system. The previously mentioned provisioning job for processing Employee Central alerts does not trigger these Time Off/MDF object business rules itself. As these rules are triggered in real time, alert rules that execute fully create alert messages that are stored statically in SAP SuccessFactors. The Employee Central alert background job then processes these alerts on their effective dates, similar to how alerts for standard Employee Central objects are processed.

Processing Employee Central Alerts

To process Employee Central Alerts, you need to set up a provisioning job to run on a periodic basis (i.e., daily) that does the following two actions previously discussed, including:

• Triggering saveAlert business rules for alerts related to Employee Central standard HRIS elements for records that have been modified since a specified date (i.e., the last successful job run date) and creating static alerts for completed alert rules as required
• Processing created/saved alerts whose effective dates equal the current system date (alerts for both standard Employee Central objects and Time Off/custom MDF objects)

To schedule the Employee Central Alerts provisioning job, follow these steps (note that provisioning access is only provided to SuccessFactors and certified partner consultants?customers do not have access):

1. Log in to provisioning and select the appropriate customer instance

2. Under the Managing Job Scheduler, click the Manage Scheduled Jobs link

3. On the Manage Scheduled Jobs page, click the Create New Job button

4. On the new job creation page, specify the following selections for the Employee Central Alerts processing job:

• Job Name – Desired name for job
• Job Type – Employee Central Alerts and Notifications
• Job Owner – Specify a valid user in the system (admin user with appropriate permissions)

Figure 14 provides an example of the definition of the job to be scheduled in provisioning for managing EC alerts.

Figure 14

Employee Central alerts and notifications job for scheduling in provisioning

Determination of what date to use here should be considered carefully. Consider how many data record changes may exist for your population. The more employees you have and the further back in time you go mean a higher number of records that the job needs to evaluate. Also consider the alert rules you set up in the system. Data record changes that occurred too far back in the past may not be applicable for alerts, as any alert that may be created for these historical records would not be applicable at the time you go live with your alert processing.

After you run an initial Employee Central Alerts job for a specified date in the past, you can set the Modified Date Since parameter to the option for Last Successful Employee Central Alert Job Run Date. All further Employee Central Alert jobs that are run on the periodic basis you set (i.e., daily) scan records that are updated after the last successful run date of the job. When run, this job is looking at modified record dates for consideration in alert processing, not effective dates, so changes you make today for records with effective dates in the past are still considered by the alert processing job.

Understanding How Alerts are Created and Managed

Alert business rules created and triggered against respective Employee Central standard data elements and MDF objects result in alert messages being created in the system for effective dates in the future. The alerts sit statically in SAP SuccessFactors until they are processed on their individually derived effective dates. At the time an alert’s effective date is reached, the system processes the alert and creates the respective ToDo list and email notifications.

It is also important to understand how AlertMessage objects are a key for alerts for employees in the system, whereby an employee can have only one alert for a particular alert message created in the system at any time. If an alert is created for an employee for a particular alert message initially, but then a later data change is made that triggers a business rule for the same alert message, but with a different effective date, the prior alert is deleted in the system and the system creates a new alert for the employee, AlertMessage, and new effective date. Here is an example of this scenario:

• An employee is hired with a probation period end date specified of April 1, 2018
• A probation end date alert is created and saved in the system for an effective date of one month prior to the probation end date (i.e., March 1, 2018) as defined by the business rule for the alert
• On February 15, 2018, the probation period end date for the employee is changed to April 15, 2018. This change results in the alert business rule triggering again for the probation alert and now determining an effective date of March 15, 2018, for the alert (using the same Alert Message).
• The prior alert that was created and saved (sitting statically) in the system with an effective date of March 1, 2018, is deleted and a new probation alert is created for the user in the system with an effective date of March 15, 2018
• Assuming no further changes related to the employee’s probation end date are entered into the system, the probation alert for the employee is triggered on March 15, 2018, resulting in the appropriate ToDo list entry and/or email notification being sent to the defined recipients of the related alert workflow

The Time Off alert scenario is similar. Alerts can be created to inform managers X number of days prior to an employee’s return from a leave of absence. While an initial alert may be created before the leave is undertaken (at the time of submission of the leave request), if a change to the request is then done at a later date, extending the end date of the leave, the previously created alert for the original effective date is deleted and a new alert is created with an effective date based upon the adjusted leave end date.

Triggering Alerts for Staggered Dates

While single alerts related to a particular key date or deadline may be sufficient in certain business cases, another common requirement is to send multiple alert notices to recipients at particular intervals as the key date or deadline approaches. For instance, you may want to send Probation End Date notifications to recipients two months, one month, and seven days prior to the probation period end date. This task can be completed with multiple AlertMessage objects and business rules that trigger the desired interval notifications. Table 2 provides an example of how this kind of staggered alert notification can be achieved.

Each alert interval has its own AlertMessage and business rule. Each business rule is then assigned to the respective base object against which it should be triggered (i.e., Job Information) and is then triggered independently whenever a change is made to the object. In this scenario, assuming the Probation End Date for an employee is more than two months in the future, each rule triggers the appropriate alert (three in total), which wait statically in the system until the respective effective dates are reached. As their effective dates are reached and processed by the Employee Central Alerts provisioning job, each alert is sent to the specified recipients at two months, one month, and seven days prior to the probation end date.

Current Considerations for MDF Object Alerts

While the alert functionality for MDF objects has been recently introduced in the Q3 2017 release of SAP SuccessFactors, there are a couple of important considerations to keep in mind with respect to how MDF object alerts function compared with standard Employee Central Alerts, including:

• While multiple alert business rules can be triggered for standard Employee Central HRIS elements, only one alert rule is currently supported per MDF object as of the Q3 2017 release. SAP plans to add an enhancement to this functionality in the Q1 2018 release to support multiple alert rules on single MDF objects. It’s called out in a Knowledge Base Article (KBA) (2560623) from SAP SucessFactors as a result of a ticket I created for a customer after the 1708 release, when we discovered that we could only have one alert rule on a single MDF object
• For objects with a parent/child relationship in which alerts are to be triggered, the alert rules should be assigned only to the parent object. Rules set against child (composite) objects are not triggered.

Eric Wood

Eric Wood is an SAP ERP HCM/SuccessFactors Solution Architect at Presence of IT.  He has 11 years of experience in corporate and consulting roles, focused on the strategy and development of HRIS solutions, specifically SAP ERP HCM. Eric has worked across a range of HR modules, both on-premise and in the cloud, for clients across various industries while based in the United States and Australia.  Eric is also a frequent conference speaker at SAP conferences in the U.S., Europe, Australia, and Singapore. You may contact the author at eric.wood@presenceofit.com.au. If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.