Creating and triggering Business Rules

Objectives

After completing this lesson, you will be able to:

  • Create Business Rules using the Rules Engine
  • Identify use cases for configuring Business Rules using the Rules Engine
  • Define when rules are triggered

Business Rules overview

You can configure the business rule logic for various modules and features using the Rules Engine.

Business rules can cover legal regulations ('The FLSA status is required for employees working in the USA'), company policies ('All employees moving to the London office get a compensation for the high cost of living'), or other requirements. Because of specific customer requirements, rules are highly customizable and based on the previous configuration decisions customers have made.

The Rules Engine provides an easy-to-use tool to dynamically configure and manage the customer, country, or scenario specific business logic that needs to occur within GO.

  • Users do not need to be technically savvy to create business rules.

  • The intuitive UI allows users to configure rule conditions that need to be checked in order to trigger the rule actions.

  • These rules can be updated easily to meet the needs of customer’s ever changing business scenarios.

Business Rules are defined in the Rules Engine and the system executes these rules during runtime. Technically, the Rules Engine is based on the Metadata Framework (MDF), but uses its own administrative tool, Configure Business Rules.

Rules can be used to add validation to details entered by a user or autofill some field data (for example, time zone information can be auto filled based on location information).

There are two ways to define rules:

  1. Basic Rules (Not Recommended as it is error prone)

  2. SuccessFactors defined scenarios (Recommended)

Rule events

Business Rules could be attached to different events. These events include the following:

  • Initialize Rules: Initialization rules are triggered before all other rules; such rules are useful to autofill default values for different fields. They only run when a new record is created (initialized).

  • Validate Rules: Validate rules are triggered after a change to an object is submitted but before the change is saved. You can use these rules to validate field values entered by user. These are executed before Save Rules. When you import MDF data using the Import and Export Data UI, the validate operation triggers the validate rules associated with the MDF objects and returns errors found in the data. Administrators can then catch any data issues through validation and correct them before importing it. In fact, the validate rules are executed during both validate and import operations.

  • Save Rules: Save rules are triggered when a user saves changes. You can use these rules to populate or change field values before saving and they are based on user inputs values. For example, you want to auto populate region field based on country values selection.

  • Post Save Rules: Post Save rules are triggered after changes to an object have been saved. These rules are used when you want to send an alert message to the user. They are not used to set a field value.

  • Change Rules (onChange): They are used at the field level. Objects cannot be associated with change rules. Change rules are triggered when a value for a particular field is changed. You can use these rules to populate another field after the change. For example, you can populate the Country field with a certain value based on a change to the Position field.

  • Delete Rules: Deletion rules are triggered after an object record is deleted.

  • On Load Rules: On Load rules are UI specific rules that get executed once the UI is loaded. An example could be calculating total salary based on different fields available on given object.

  • UI Rules: These rules are applicable only for a UI built in the tool Configurable UI. These are UI specific rules to  make certain field required, visible or hide based on certain condition. Such rules will not  be applied when a user does the import. 

    Note
    Warning messages from the validate and save rules are shown before workflow confirmation messages from workflow rule execution.

Identify Use Cases for Configuring Business Rules Using the Rules Engine

  1. Workflow: You can define rules that automatically determine the right workflow when the manager or employee changes employee data. To achieve this, you create a workflow foundation object and assign it to the rule in the Rules Engine UI. For example, you can trigger an alternate workflow if the salary increase is over 10%.
  2. Propagation: You can define propagation rules to have the system automatically copy over the data from one field to another field. This way you can have the same data in several places of the system, while keeping just one data record. For example, you can propagate the job code to the Position MDF object.
  3. Calculations: You can define rules that automatically perform calculations using the various functions the Rules Engine supports. For example, you can get an employee's current age by calculating the difference between the current date and the employee's birth date.
  4. Validation: You can use validation rules to let the system check the user's input before saving. You can set a field to mandatory, or you can trigger error messages. For example,

    IF... the country is USA, THEN... the FLSA status is required.

  5. Eligibility: You can define which employees should be included in a bonus plan or compensation planning form. To achieve this, you have to integrate the modules Variable Pay or Compensation with Employee Central. For example, the rule could be:

    IF... the employee type does not equal Contract, Temporary or Union

    AND the employee is regular

    AND the rate type is 'Hourly' and 'Salaried'

    AND the hire date is after 10/01/2010

    AND the rehire date is after 10/01/2010

    AND the employee status is Active or STD

    THEN... this employee should be eligible (for a specific compensation form)

  6. Defaulting Values: You can define default values for specific fields. For example, if the Admin adds a new employee for the company COMP_USA, the employee is automatically eligible for stock, and the initial stock grant is set to 200.

Before configuring Business Rules

There are some settings you need to make before you can configure business rules using the Rules Engine.

Enabling Business Rules in Provisioning

  1. Go to Provisioning.

  2. Select your company.

  3. Under Edit Company Settings, choose Company Settings.

  4. Select Enable Generic Objects.

    This is the basis for using the Meta-data Framework (MDF).

  5. Scroll up and choose Save Feature.

Assigning Role-Based Permissions

You can only create rules if you are assigned the corresponding permissions.

Note
We recommend that any objects used for a rule should not be RBP-secured otherwise, depending on the permissions they've been assigned, certain users might not be able to run the rule.

  1. Use the action search to navigate to the Manage Permission Roles tool.

  2. On the Permission Role List page, under Permission Role, choose Permission Role for which you want to manage the permissions. The Permission Role Detail page opens.

  3. In the Permission settings section, choose the Permission button to specify the permission you want to assign to the role. The Permission Settings window opens.

  4. In the Administrator Permissions section, choose Metadata Framework.

  5. Select all the checkboxes on the right side of the dialog.

    Here is some information on what the permissions are used for:

  6. Save your changes.

Creating Business Rules

Business Rules are created and managed using the Business Rules Admin tool in Admin Center. You can use this tool to create new rules, view/edit or deleting existing rules in the system.

Note
The Business Rules Admin User Interface (UI) has been enhanced to make it possible to delete a single rule as well as several rules completely using the checkbox to the left of the rule. One or more rules can be selected to be deleted. If the user selects a rule to be deleted, it will be checked if the rule is still assigned in the system. Assigned rules cannot be deleted and will prompt an error message to forbid deletion and must be unassigned in order to delete them. Unassigned rules and rules based on Basic rule scenario can be deleted. For rules based on Basic rule scenario, the system cannot protect the user from deleting a rule which is assigned so deleting a rule based on Basic rule scenario should be treated with caution.

Rule scenario

A rule scenario is a rule object you can use to help you create rules correctly, based on the rule context and parameters for a given scenario. When you select a rule scenario, the screen changes and offers the basic elements of the chosen scenario.

There are application-specific scenarios and the legacy basic scenario.

Note

When you select the Basic rule scenario to create a business rule, you now receive the warning that the Basic rule scenario will be deprecated and that you should choose an application-specific scenario instead. You should only continue with the Basic scenario in cases where none of the application-specific scenarios meet your needs.For more information about the deprecation of the Basic rule scenario, refer to the Deprecation of Basic Rule Creation topic. Rules based on application-specific rule scenarios have reduced risk of misconfiguration and the process of rule creation is simpler.

Most legacy business rules have been created with the default Basic scenario. Since the basic scenario doesn’t provide any guidance about the various objects, parameters, and actions you can use to configure the rule, the resulting rules can often produce errors. As such, SuccessFactors recommend that you use application-specific rule scenarios instead.

The scenarios available in your system are displayed when you create a new rule under Admin Center → Configure Business Rules, where they’re categorized by application. Here you can see only the scenarios for the applications that you've enabled in the system.

When you choose your rule scenario, you must fill in some rule details before you can continue to the If/Then logic.

  • Rule Name: This is the label of the rule that will display in search tools.

  • Rule ID: The rule id is the unique identifier for the rule. The rule name is automatically copied into the rule id, however it is best practice to not have any spaces in your rule id.

  • Start Date: This is the effective start date for your rule. Rules can only be triggered after this date. The default value is 01/01/1900.

  • Rule Type: For the Basic Scenario, rule types can be used to organize your business rules. Any values added to the RuleType picklist will display here. Rule Types are optional.

  • Description: This is an optional field that you can use to provide more context around the business use for the rule.

  • Base Object: Select an object that the rule is based on. The base object defines which fields and related objects you can select when creating the rule.

Base objects

Base objects are the starting point for your rule. They correspond to the data objects available in the system, which are either EC objects (foundation objects, employment objects, or person objects) or MDF objects (GO). The base object defines the subject of your rule. You can use the fields, attributes, and related data objects of the base object as input.

For example, if you want to create a rule that is triggered when the employee status is changed, you choose Job Information as base object, as the employee status field is part of the Job Information EC object.

For application-specific scenarios, the scenario defines the base object, or limits which base objects you can choose when you're creating a rule.

For the legacy basic rule scenarios, there's no guidance in the system as to which is the right base object for your use case. Please make sure to refer to the application-specific documentation for more information on which base object to choose. For basic rule scenarios, you have to assign the rule to the base object used in the rule.

Note
To find out which fields are part of which EC object (which corresponds to an HRIS element), refer to the data object tables of the Employee Central Implementation Handbook. To find out which fields are parts of which MDF object, you can look up the object in the MDF UI.

If Then Logic

IF statements are the part of the rule that describe which condition has to be met before the system actions defined in the THEN statement are executed.

THEN statements define how the system reacts to the conditions contained in the IF statement of the rule. For example, an error message is raised, a field is set to a specific value, or new data is created. ELSE statements define how the system reacts if the IF condition is not true. The THEN statement is then skipped and the system executes what is defined in the ELSE statement.

Dropdown list of the left expression

Define rule statements following the logic "A is equal to B", with A being the left expression, and B being the right expression, connected by the comparison operator "is equal to". Left and right expressions are available in the IF section and the THEN section for the Set action. In general, the dropdown list for the right expression contains the same values as the left expression but limited to the entities that have the same field type as the left expression. In addition, there are some options in the dropdown list specific to the right expression.

In the dropdown list of the left expression, you can select:

  • Data related to the base object

  • Functions

  • Additional MDF objects

  • Variables

  • Current User

  • Effective Date

Dropdown menu of the right expression

In the dropdown menu of the right expression, you can select the following:

  • Field type

  • Fields assigned to the base object or the other added objects that have the same field type as the left expression

  • Functions that are available for the field type of the selected left expression

  • Variables

  • Current User

  • Effective Date

  • Null

Comparison operators

Comparison operators are used to define the relationship between values in the left and the right expression of a business rule.

The following comparison operators are supported:

Comparison OperatorField Types Supported
Is equal toAll field types
Is not equal toAll field types
Is greater than:>Number, Decimal
Is less than: <Number, Decimal
Is greater than or equal:>=Number, Decimal
Is less than or equal:<=Number, Decimal
Is beforeDate
Is on or beforeDate
Is afterDate
Is on or afterDate

Collection filters

Collection filters are used to get a unique value from a list of values. This is relevant when there is a parent-child relationship between data objects.

In the following business example, Job Relationship is the child of Job Information, which is the parent object. This means you can have multiple Job Relationships for a single employment. You use a collection filter to define which Job Relationship should be used in the rule, for example the HR Manager.

In the Rules Engine, collection filters ask you to select a unique value (Select….where…).

Function

A function performs a specific task on the data object or field of a rule. Functions help you to define more complex rules that perform calculations or application-specific tasks. In the system, you can identify functions by the brackets that follow the function name; for example, Add().

Assigning Business Rules

A rule is only triggered when it is assigned to the corresponding object.

Depending on how the application-specific scenario you're creating the rule for is set up, the rule needs to be assigned to an object, business process, event, action, screen, or some other entity. Therefore, please check the application-specific documentation to understand where the rule needs to be assigned to. Depending on the object type, you have to follow different ways of assigning the rule to the object.

If an application-specific scenario rule is assigned in the system and a user tries to delete it, it will raise an error message. To delete a rule, the assignment must be deleted in advance. Assignment information is not tacked for the basic scenario rules, therefore it is NOT recommended to delete rules with the basic scenario.

Rule events

When a user is assigning a rule, there is a new guided rule registration process to see all possible rule assignment options and go to the target page to assign the rule. This supports users in assigning rules to the right place in the system. This is only available for rules based on a rule scenario.

When assigning a business rule to an object or xml element, you need to define if the rule should be triggered before, during, or after a change is made. There are different types of rule events that define when a rule on an EC Object is triggered:

  • onInit: This event triggers a rule as soon as a new entity is created. For Employee Central, OnInit rules work only in Hire/Rehire scenarios and for legacy foundation objects. Since these rules are for new hires, they do not work for existing users.
  • onSave: This rule event is triggered when a user tries to save changes to an object. You can use these rules to check related field values for correctness. For example, a field could become required as a consequence of a save. You can also use this to create or updated data.
  • onChange: This rule event triggers a rule as soon as the user makes a change to a field. The rule triggers while the record is being filled out, not when the Save button is triggered.
    Note
    Attaching business rules to fields is the equivalent of an onChange rule event.
  • onPostSave: Trigger events for Intelligent Services.

Assigning rules to MDF Objects

Similar to assigning rules in the Manage Business Configuration tool, you can also assign business rules directly to MDF Objects. This is done in the Configure Object Definitions tool.

Rules can either be assigned on the Object level:

Rules can also be triggered on the Field level by configuring it within the details section of the triggering field. Keep in mind only the  onChange rule event can be used on the field level.  

For example, if you want to autofill an employee’s current location and division within a MDF Object, you would add the rule to the "trigger" field, which in this case would be the Employee field. The location and division fields would be filled as soon as the employee field was completed or edited.

Business Rule Execution Log

The Business Rule Execution Log makes it easier to analyze errors by enabling you to trace a rule’s execution details.

Using this Admin tool, you can specify which rules should be logged. Every time one of the specified rules is run, a log is created. You can then download logs in CSV format.

Note

You need the Access to Business Rule Execution Log permission before you can use the log. This permission belongs to the Metadata Framework group.

There are two separate permissions: one to create the rule trace, and another to both create the rule trace and view the resulting log. Since the log can contain potentially sensitive data on your users, we recommend that you only assign the view permission to the necessary people.

Once you have the permission, you need to define any rule traces you want to use.

  1. Use the Action Search to navigate to the Business Rule Execution Log.

  2. Choose Create New → Rule Trace.

  3. On the resulting screen, enter the following:

    • A name and a code for the rule trace.
    • A start date and an end date.
      Note
      You can set up a rule trace for a maximum time period of two days. This is to ensure that only new and up-to-date traces are active in the system at any particular time.

    • A user for whom the rules should be traced.

      Note
      "User" here refers to the user who is executing the rule, not the user whose data is evaluated or changed by the rule.
    • The rule or rules to be included in the log.

If you want to trace all rules for the specified user, just leave this field empty.

When you save the rule trace definition, the trace will start on the specified start date. If you have the necessary authorization, you can return to the Business Rule Execution Log and choose Download to see the content of the log. You can also edit existing rule traces using the Take Action option.

Note

  • The log file for a rule trace has a maximum threshold of 1MB. If the log file exceeds this threshold, entries within the log file will be deleted. As such, if you want to trace several large or complex rules we recommend that you use a separate rule trace for each one.

  • You can delete the log file whenever you don't need it anymore. However, the rule trace definition will remain.

Note

A list of rules including their rule assignments can be exported as a CSV file to get an overview of where the rules are used.

Create Message Definitions and Business Rules and then attach the Business Rule

Business example

You need to ensure car objects you create follow certain rules like having manufacturing dates in the past and not in the future.

ExerciseStart Exercise

Task 1: Create a Message Definition

Steps

  1. Use the Action Search to navigate to Manage Data.

  2. Create New: Message Definition

    1. Select Create New to open a dropdown list.

    2. Select the entry Message Definition.

  3. Enter in the following data:

    Text:The Date Purchased/Leased date must be in the current date or earlier.  

    externalCode:compCarError

    externalName:Company Car Error Message

    1. Enter the values provided in the Message Definition record.

  4. Check your work against the figure below:

    Example

Task 2: Create and attach a Business Rule

Steps

  1. Use the Action Search to navigate to the Configure Business Rules tool.

  2. Create New Rule by selecting the "+" icon.

    1. Select Create New Rule.

  3. Choose Metadata Framework → Rules for MDF Based Objects.

    1. Expand the basic rule scenario category.

    2. Select the basic rule scenario.

  4. Fill in the information below and select Continue.

    1. FieldValue
      Rule NameCompany Car ERROR
      Rule IDcompanyCarError
      Base ObjectCompany Car

    1. Enter Company Car ERROR in the Rule Name box.

    2. Enter companyCarErrorin the Rule ID box.

    3. SelectCompany Car as the Base Object.

    4. Select Continue.

  5. Use the Figure below to fill in the IF and Then statements.

    Example

    1. Select the Left Expression in the IF statement.

    2. Choose Date Purchased/Leased.

    3. Selectis equal to.

    4. Choose is after.

    5. Select Date (the right expression).

    6. Choose Today(), you may need to scroll down in the list to see it.

    7. In the THEN, Choose the Edit Expression button (Pen Icon).

    8. Choose Select output type.

    9. Choose Raise Message.

    10. Select the Message button to open a dropdown list.

    11. Choose the entry for the message created in the last exercise.

    12. Select the Select Severity button.

    13. Choose Error.

  6. Save your Rule.

Task 3: Attach Business Rule

Steps

  1. Use the Action Search to navigate to the Configure Object Definitions tool.

  2. Search: Object Definition → Company Car.

    1. Select theSearch button to open a dropdown list.

    2. Select the entryObject Definition.

    3. Select Company Car in the 2nd search box.

  3. Choose Take Action → Make Correction.

    1. Scroll to the validate rules.

    2. Select the Save Rules button to open a dropdown list.

    3. Select the rule you created in the previous exercise.

    4. Select Save.

    5. Select OK.

Task 4: Testing steps

Steps

  1. Test this by using Action Search to navigate to Manage Data.

    1. Select Create New Company Car.

    2. For Employee Name enter HR Coordinator.

    3. For Effective Start Date enter today's date.

    4. For Model enter Golf.

    5. For purchase date enter a date in the future.

    6. Click Save: notice the error message created earlier is displayed.

    7. Change the Purchase date to today's date.

    8. Click Save: this time the new company car is created.

Log in to track your progress & complete quizzes