Configuring MDF Objects

Most of the MDF object configurations are maintained using Configure Object Definitions in Admin Center. Before you start using or populating data to an MDF objects, you have to create new Generic Object (GO) definition or review existing Generic Object definition. There are several areas of a Generic Object (GO) that controls different aspect of the GO.

Use the Action Search to navigate to the Configure Object Definition tool and select Create New: Object Definition.

Once a new object definition is opened, the different areas that can be configured are displayed.

This section determines the overall behavior of the Generic Object (GO).

• Code: Unique identifier for Object. All custom objects created are automatically prefixed with cust_.

• Effective Dating: This defines if an object instance can have only a single record or multiple records based on different dates. Please do not confuse this with audit, which can be enabled irrespective of the configuration of this field.

Available Effective Dating options are:

None: Only a single record can be maintained for a given object instance. Whenever you make changes, you overwrite the previous saved information.

Basic: Multiple records for a given object instance can be maintained, but only one record can be added for given date.

Multiple Changes Per Day: Multiple records can be maintained for each given date.

From Parent: This is used for child objects so that they will match the parent’s effective dating. Parent/Child relationships between objects will be discussed in the association section. An Object instance for a child object cannot be maintained independently and can only be maintained along with parent object. 

• API Visibility: All MDF Objects data and some of MDF Object configuration can be accessed via oData API using this setting. 

  Available Options are:

  Not Visible: This is the default value; the object will not be allowed to be accessed via oData. 

  Read Only: Object instance will be accessed as Read Only without edit capabilities. 

  Editable: Object instance will be accessed with both Read and Write capabilities like Create, Update, Insert, and Delete. 

• Status: Set object status.

  Available Options are:

  Active: Object can be used.

  Inactive: This status cannot be used if an object instance exists or if the object is referenced by another active object. An inactive object will not be visible anywhere in the system, including the configurable UI designer, Rules, RBP or Import/Export.

• MDF Version History: The MDF Version History allows you to capture Audit data for any changes done to object instances. Any operation such as Create, Update, Insert or Delete will add audit records in the system.

Available options are:

No Selection/ No: If any of these options is selected, no audit records will be created for any of the operations.

Delete History: Only Delete operation will create audit records. 

Complete History: Audit Records will be created for all operations like Create, Insert,  Update and Delete. 

• Default Screen: Users can create a Configuration UI for a given object. If you would like to use the Configuration UI created to be displayed on the Manage Data, you can assign the Configuration UI here. Leaving this blank will display the Generic Object (GO) in the standard UI.

• Label: This is the name of the object displayed on different UIs. 

• Description: This is for capturing a short summary about the object.

• API Sub Version: This field controls whether the technical fields are exposed in the oData API or not.

Available Options:

No Selection: With this option system will behave as if you selected V1.1.

V1.0: System fields that are not of much use will be exposed in oData API.

V1.1: System fields will not be exposed on oData API. This is the recommended option if you are creating a new object.

• Subject User Field: This defines which field contains subject user information for the object, which is then used to determine workflow routing. Only fields that are of Data Type User can be used for this configuration. If the External Code field is defined with Data Type User, it will be used as the default value for this configuration.

• Workflow Routing: This allows workflow routing to the object. If you select a workflow configuration record, then the corresponding workflow will be triggered for any operation done on an object instance. Workflow Routing requires the Employee Central Foundation Objects feature to be enabled in Provisioning.

• Pending Data: This lets you control if changes must be available with or without approval. If you have chosen a Workflow Routing that involves an approval and you want changes to take effect only after approval, set this field to Yes.

• To Do Category: This is used when Pending Data is set to Yes. This determines what subsection of the To Do list workflow approvers will see notifications for this Generic Object (GO) on the Home Page.

• Object Category: There are different object categories available to determine the type of data that an object represents: Uncategorized, Configuration, User Transactional, Non-User Transactional and Technical.

• Name: This is the identifier for the field and must be unique within current object definition including association names. The application automatically appends "cust_" in front of the name of any custom field.

• Maximum Length: Applicable only for String, Translatable, Number, and Decimal Data Type. This defines how many characters can be entered for this field. The default length for fields is 255 for String and Translatable, 38 for Number, and 21 for Decimal but it can be changed by end user. The maximum allowed value for pre-delivered field can vary from one object to another object and controlled by different applications.

• Data Type: This determines what kind of values can be supplied for a field. There are several different Data Types to choose from. These include:

  • String: Accepts any text.

  • Translatable: Same as String but value entered can be translated into available languages. Number:

  • Number: Accepts only number without decimal values. The display of this field value will be determined based on the logged-in user’s chosen locale.

  • Decimal: Accept number along with decimal values. The display of this field value will be determined based on the logged-in user’s chosen locale.

  • Auto Number: System automatically generates a new number for each record. This field should always be set as read-only. The end user must not be allowed to enter values manually.

  • Boolean: Provides Yes or No as the allowed values.

  • Picklist: Users must choose an option from pre-defined values configured in a picklist.

  • Generic Object: Create reference to another Generic Object and the end user can select any instance of referenced GO while entering data.

  • Foundation Object: Create reference to Employee Central Foundation Objects. Location is one example of an EC Foundation Object which are managed outside of MDF.

• Data Source: This field is used only for pre-delivered fields and cannot be changed by end users.

• User: References any active or inactive user in the system.

• Date: Accepts date information. The display of this field value is determined based on the logged-in user’s chosen locale.

• DateTime: Accepts both date and time information (hours, minutes and seconds).

• Time: Accept only time information (hours, minutes, seconds)

• Attachment: Allows uploading a document or file to object instance.

• Valid Values Source: This attribute is applicable only for Data Type Picklist, Generic Object, Foundation Object and Data Source. Enter the id/code of referenced object. To reference a field to the Country Generic object, you would enter a value as ‘Country’. For a picklist configuration, consider the following example: The Position object has a field called Criticality and you want to create a connection between that field and an MDF picklist. You will first need to determine the code of the picklist that you want to link to that field in the Picklist Center and then specify the Picklist code in the Valid Values Source of the Criticality field in the Position object.
• Hide Old Value: For Effective Dated Object, field values which are changed from previous effective dated records are shown along with old value with strikethrough. If this is set to Yes, then the old value will not be displayed.
• Decimal Precision: Applicable only for Decimal Data Type. This specifies how many digits past the decimal point is allowed.
• Show Trailing Zeros: Applicable for Decimal Data Type. If set to Yes, it will show trailing zeros for decimal precision if number of digits after decimal are not matching the Decimal Precision.
• Include Inactive Users: Applicable only for User Data Type. If the value is set to Yes, then inactive users will be included for selection. Default value is No.
• UI Field Renderer: This field can change UI behavior. For example, setting value displayPickListWithoutExternalCode will hide Code for picklist dropdown and using displayGOWithoutExternalCode will hide external code for GO selection. Please note these are pre-delivered values and are applicable for specific data type. If applied incorrectly, it will result in undesired behavior or application errors.
• Transient: Set to Yes to make the field transient. Values of transient field are not stored in the database but are populated at runtime in the user interface. Usually, this is done with the help of rules. For example, the age of a person is based on the Date of Birth.
• Help Text: This is a translatable option. If a value is provided it will display an icon next to the field to show the instruction.
• Private or Sensitive Information: You can hide sensitive information on the UI to avoid accidentally exposing the value. If you set this to Yes, asterisks (*****) will be shown in place of actual value. The user needs to select the field and confirm their intent to show the values on the UI.
• Default Value: You can set a default value for that field. Not all data types support this configuration.
• Hide Seconds: Used for the DateTime and Time data types. It removes the seconds information if set to Yes.

• Required: If set to Yes, the field is mandatory, and the user must enter a value before a record can be saved.
• Visibility: Determines if field is Editable, Read Only, or Not Visible on the UI.
• Status: Field can be set as Active or Inactive. Inactive fields aren’t available in the system. Please note a customer defined field cannot be set to inactive.
• Label: A translatable field which allows you to change the field label displayed on the UI and other areas of the application.
• End Of Period: Applicable only for DateTime data type. This is to distinguish between if 00:00:00 is the start of a date or the end of a date.
• Log Read Access: Enable if a field needs to be tracked for Read Access. This feature is not yet available.
• Database Field Name: Read-only field and determined by system.
• Rules: This section allows to add one or more Business Rules to the field. When a field value is changed these rules are triggered.
• Field Criteria: Allows you to restrict the possible values for the field by specifying the related fields under this section.
• Condition/ Condition Values: Allows you to show or hide the field based on a value entered on an other field available on the object.

MDF supports the following association types:

1. Valid When (VW): For this association type, associated objects have their own lifecycle and exist without the object that is currently being configured. Valid when associations are often used to create filtering capabilities between fields on a given object. For example, in the Employee’s Job Information you haveBusiness Unit and Division fields. When you select the Division field, you want to see valid division values which are applicable for selected Business Unit. But Divisions and Business Units can be maintained independently from the employee’s record. In this case, you would define a Valid When association on Division referencing ‘Business Unit’.
2. Composite: This association type creates a parent-child relationship. The entity being associated is a child entity and it cannot exist outside the parent object. The child object must have effective dating ‘From Parent’ for this association type. Also the child object can be association with only one parent object.

   For example, the picklist values are child entity of the picklist entity. It would not make sense to create Picklist Value entity that does not exist with a picklist entity (the parent).

3. Join by Column (JBC): This association type allows you to associate two objects with a One to One Relationship which one object always has reference to the other object. Set one field of the parent object definition as the source object column and one field of the child object definition as the destination object column, then join-by-column association will make the value of these two object columns reference each other.

   For example, a Person could be one object which represents a real person and Personal Information could be another object which stores information about the person. The Person and Personal Information objects could be One to One composite relationship. In that case the Personal Information cannot exist without a Person.

   However, if the association was a one to one JBC association, a user would be able to maintain personal information outside the person object. In this configuration, you would configure the External Code of Person to reference the External Code of Person Information object.

You can define fields that can be used to do search for an MDF object instance. Each of the fields added to this section will be included in searching on different places in application. In the field, enter the names of the fields and/or association that you want to make searchable. You can also use the field reference to include in search. For example if you have Object with a Country field which refers to country object you can add cust_country.code to search based on the country code.

When a field is associated with a picklist, you can add the field name + ".label" like in the screenshot.

Business key fields are a combination of two or more fields and are defined for an object so that you can uniquely identify its records. You can type the business key fields in this area. You can also delete or add more fields by selecting the corresponding icon.

Setting up security allows you to control which users can view, edit, or import/export data for an object or field. With MDF you can set up security at the object or field level. For objects and fields, you can control access based on RBP roles within the system.

Optionally, you can define which fields in the object definition are used to determine the target population in Role-Based Permissions. You can specify any user field in the current object definition as the RBP Subject User Field. The value of the specified RBP Subject User Field can then be used to create user-based permission groups in RBP. You can use any field in the current object definition of the type ‘user’ as the RBP Subject User Field. It does not have to be the externalCode.

• Secured: All new custom MDF objects mandate that the Secured field is set to Yes at the time of creation. Existing MDF objects and the objects linked to parent records remain unchanged. You receive a validation error if you attempt to save a new custom MDF object with the Secured field set to No. MDF objects with effective dating FROM_PARENT and the existing custom MDF objects aren't impacted and the Secured field remains as No. Once you change the Secured field of an existing custom MDF object from No to Yes, this action is irreversible. You can't switch back to No. You can no longer create a new custom MDF object as non-secured or change a secured MDF object to non-secured.

  Since release update 2605, for new customers, the following standard objects have been set to secured by default:

  • Hire Date Correction
  • Fallback Event Reason Configuration
  • Alternative Cost Distribution
  • Recurring Deductions
  • One-Time Deductions
  • Document Generation Template
  • Document Generation Template Email Options
  • Document Generation Group
  • Document Generation Screen Look Up
  • Income Tax Declarations (ItDeclaration)
  • Declaration Type (DeclarationType)
  • Time Bound for Income tax Declarations (ItDeclarationTimeBound)
  • Tax Regime Declaration (TaxRegimeDeclaration)
  • Fiscal Year Variant (FiscalYearVariant)
  • Fiscal Year to Country/Region Map (FiscalYearToCountryMap)
  Note

  Don't select Custom. The option isn't supported and will be removed in future releases.

  This Secured field is set to Yes by default for creating custom objects. This is recommended to keep all custom objects as Secured=Yes so that RBP permissions must be granted before the object can be accessed. You can grant access to non-secured objects (Secured=No) using the Metadata Framework permission for "Access to Non - RBP Secured Objects".

• Permission Category: This specifies what area of the Permissions section in the RBP Permission Role the object can be found.
• RBP Subject User Field: Specify a required user field of the current object definition. The value of this field is used to set up target population in RBP.

Once the MDF object definition is created, you can create object instances of that definition in your application. Creating an instance of an MDF object is the way to populate the object with data. From the Action Search go to Manage Data. The search results in Manage Data display records that are created and those that are pending for approval in a configured workflow.