Alerts in Employee Central for User Notifications Extended to Custom MDF

Objects and Processes

by Eric Wood, SAP ERP HCM/SuccessFactors Solution Architect, Presence of IT

April 10, 2018

Learn how to implement alerts in SAP SuccessFactors Employee Central to remind users to take
appropriate actions as key dates and deadlines approach. Understand how to create to-do alerts and
email notifications within Employee Central, leveraging workflows and business rules in SAP
SuccessFactors to create system alerts based on unique business requirements. Extend the
capabilities of alerts to Metadata Framework (MDF) objects with recent upgrades from SAP
SuccessFactors, allowing you to use alerts around custom objects and processes in your SAP
SuccessFactors application.

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 organizations 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.

(The MDF provides a platform for building new applications, data objects, and processes that are
tightly integrated with workflow, rules engine, reporting, and now the Employee Central alert
capabilities within SAP SuccessFactors.)
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

Note: Tags used within Alert Message headers and descriptions must always use double brackets
[[..]]. If you are implementing alerts for the first time, you may experience the description text
field of the Alert Message object being limited for character size. You can increase the allowed
characters for the Alert Message description (alert body text) by going to Admin Centre >
Configure Object Definitions and changing the length of the description field accordingly (the
maximum is 4,000 characters).
Define Workflows for Alert Recipients

While Alert Messages 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:

1. Go to Admin Centre > Manage Organization, Pay and Job Structures (Figure 5)

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

Note: The same role or group can be included in both the step approver and CC role section of a
workflow used for an alert. Recipients in this case receive both the ToDo list and email notification
alerts when they are triggered.
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.

Figure 7
Sample IF statement for a business rule used for probation alert

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.

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):
Figure 11
THEN condition for alert involving MDF objects

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

Note: When creating alert business rules for Time Off or MDF objects, you do not need to add the
Alert parameter to the rule definition as you do with standard Employee Central object alert
business rules.
Assign Alert Rules

After defining alert business rules and the related Alert Message 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 save Alert. 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 save
Alert 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

When you are assigning alert business rules for Employee Central standard data elements, the
business rules are assigned to the respective elements (i.e., Job Information) as saveAlert event
types. By assigning the rules as saveAlert types, you set up the business rule so that it does not
trigger immediately at the moment the data in question for an employee is saved. Instead, these
saveAlert rules are triggered later during a scheduled background job used to process Employee
Central alerts. This job looks at standard Employee Central object data changes modified from a
particular date (i.e., the last successful job run) and executes identified saveAlert rules at that point.
For rules that successfully process via the job, alert messages are created in the system and sit
statically until their effective date is reached, at which point the alerts are sent to the appropriate
recipients.
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

Under the Job Parameters > Modified Date since option for the alerts job (as shown in Figure 14),
there are two options to select. The first time you run the alerts job, you may wish to have the
system check historical data records back to a certain point in time to process alerts for data that
has been modified on or after a specified date. When this option is selected, the alert job checks
all applicable records that have been modified on or after the date specified. It is not checking
historical data for Time Off/custom MDF objects, however. This scan of historical changes is
limited to the supported standard Employee Central HRIS elements for alerts only (i.e., job
information and compensation information).

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.

Alert AlertMessage Business rule

Probation Object: ProbAlert2Months Rule: ProbAlert2Months
End 2 Months

Unique messaging for two If conditions

months prior to probation
alert
  Probation End Date >= Today’s Date
+ 2 Months

Then

 Trigger Alert with 2 month Probation

Alert Message
 Effective Date = Probation End Date –
2 months

Probation Object: ProbAlert1Month Rule: ProbAlert1Month

End 1 Month

Unique messaging for one If conditions

month prior to probation
alert  Probation End Date >= Today’s Date
+ 1 Months

Then

 Trigger Alert with 1 month Probation

Alert Message
 Effective Date = Probation End Date –
1 month

Probation Object: ProbAlert7Days Rule: ProbAlert7Days

End 7 Days

Unique messaging for If conditions

seven days prior to
probation alert  Probation End Date >= Today’s Date
+ 7 Days

Then

 Trigger Alert with 7 day Probation

Alert Message
 Effective Date = Probation End Date –
7 days

Table 2 Example approach for implementing staggered alerts using multiple alert messages and
rules
Each alert interval has its own Alert Message 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 SuccessFactors 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.