The Business Configuration UI (BCUI) allows administrators to maintain certain elements of the Succession Data Model using their end-user UI instead of maintaining these elements in XML. Since the BCUI is available in Admin Tools, administrators can make configuration changes that they previously had to contact colleagues for with access to Provisioning.
The BCUI covers the following frequent use cases:
● Changing labels
● Adding or changing translations
● Activating fields
● Changing the display sequence of fields
● Changing the visibility of fields
● Setting fields to “required”
● Adding custom fields
Limitations of the Business Configuration UI
If customers ask you to set up the BCUI for them, you need to point out that there are some limitations when using this UI.
Firstly, the sequence of actions is different compared to the sequence in XML as described in Recommended 13–
step implementation sequence [page 5]:
● Before the customer can use the BCUI, you have to upload the data models the customer wants to use. It is recommended that you also download already existing succession data models for backup purposes.
The XML has to be loaded, after you have set the switch in Provisioning.
● Wait until the upload and synchronization of a data model is completed before starting the upload and synchronization of another data model (for example, first complete this for the succession data model and then do this for the country-specific succession data model). The BCUI is locked during this synchronization.
● The customer can only assign picklists in the BCUI after these have been uploaded.
In addition, you need to point out that changes made and uploaded using XML will overwrite changes made on the BCUI. To include any changes made on the BCUI, you should download the data model and then make the changes in XML: This way, changes made by the customer on the BCUI will not be lost.
Finally, you need to point to some additional limitations of the BCUI.
These are:
● The XML-tags </format-group> and </format> or their attributes for HRIS element national ID card are not supported by the BCUI. You will need to maintain this information in the XML-file.
● The customer cannot use the BCUI for HRIS sync mappings of HRIS fields to userInfo elements. You will need to do this in the XML-file for the Succession Data Model.
● HRIS sync mappings for country-specific fields are not supported by the BCUI. In the XML the only specific use case for this are the country-specific address fields in the HRIS element homeAddress. If the customer requires this specific use case, you will need to maintain it in the XML-file for the country-specific Succession Data Model.
Tasks
Setting Up the Business Configuration UI
The BCUI is an opt-in feature. You have to set the switch in Provisioning in order for the customer to be able to use this UI. If a customer wants to use the BCUI, you will need to enable this. You need to enable this for every company, using a switch in Provisioning in the following sequence:
1. Log on to Provisioning with your username and password, and select the company from the list shown or through the initial letter of the company ID.
2. Select Edit Company Settings Company Settings
3. Select the following checkboxes:
● Enable Generic Objects (Not Ready for Sales/Production)
● Employee Central V2 (i.e. Event Reason Derivation) Requires Effective Dated Data Platform
● Enable Business Configuration in Admin Tools — requires “Enable Generic Objects”, “Employee Central V2 (i.e. Event Reason Derivation)” and “Effective Dated Data Platform”
After you set the switches in Provisioning, the customer administrator needs certain permissions to be able to use the BCUI.
1. Go to Admin UI Set User Permissions Manage Permission Roles 2. Select Meta Data Framework Select All
3. Select Manage Business Configuration Select All
After you have set the permissions, you need to synchronize the succession data model with the meta data framework (MDF) storage of the BCUI. To allow for the maintenance of configuration data, the data is stored as MDF generic objects. The data is maintained on the MDF UI. You can synchronize the SDM storage with the MDF storage in two ways:
1. Run the synchronization job in Provisioning
2. Upload the succession data model and the country-specific succession data model XML files in Provisioning If you chose option 2, the QUARTZ job from option 1 will run automatically for each XML upload. This makes option 1 the easier and quicker approach.
The sync of the BCUI and the succession data model needs to be carried out after the switch in Provisioning has been set and is required only once after you have set up the company and selected the provisioning features.
Option 1: Run the Synchronization Job in Provisioning:
a. In Provisioning, go to Managing Job Scheduler Manage Scheduled Jobs . Click Create New Job.
b. Select Synchronize Business Configuration under Job Type:
Use an admin user to run the job.
c. Run the job by going to Actions Select and then either
● Submit to run the job at a scheduled time
● Run It Now to run the job immediately
You can monitor the progress of the job on the Monitor Jobs UI.
Option 2: Upload the Succession Data Model and the Country-Specific Succession Data Model XML Files in Provisioning
The XML files of both SDM and CSFSDM can be uploaded again after the provisioning switch is set for the company.
You need to upload both files: first the SDM, then the CSFSDM. You do this in Provisioning. It is possible to download the XML files and start the upload using the downloaded files. This way, you ensure that the uploaded configuration is the same as the one currently stored in the company.
Running the sync job can take between 2 and 10 minutes, depending on the size of the data model and the
performance of the environment. The synchronization uses a QUARTZ job that runs asynchronously. During the run, you cannot access the BCUI and you get the following error message if you try to access it:
Please wait for the job to finish.
The customer´s administrator is now able to use the BCUI using the new Administration Tools UI.
Starting the Business Configuration UI — for Administrators
The customer´s administrator can access the BCUI by going to the new Administration Tools UI and then selecting Company Settings Manage Business Configuration .
On the left-hand side of the screen, an activity list appears with elements that can be configured using the BCUI. Two sections are available:
● Employee Central
Here you find the HRIS elements that are shown in Personal Information and Job Information.
● Employee Profile
Here you find standard elements and userInfo elements that are shown in the different portlets of the Employee Profile.
On the right-hand side of the screen you can maintain the actual elements. This picture shows you the layout of the BCUI. A check mark in the activity list on the left-hand side of the screen indicates the element is used.
Configuring HRIS Elements and Fields — for Administrators
Under the Employee Central section, the administrator can see all the configurable HRIS elements. On the BCUI, the administrator can maintain the country-specific fields, HRIS sync mappings to profile elements, or configurable rules.
Some typical use cases for configuring HRIS elements on an element level are:
● Changing the label
● Changing or adding translations for the label
● Disabling or enabling the element
If administrators disable an HRIS element, they in effect deactivate this element and removes it from the Succession Data Model. As a result, this HRIS element is not part of any XML download or export. We suggest you test this change before disabling any HRIS elements in a productive system.
Some typical use cases for configuring HRIS elements on a field level are:
● Changing a label
On the details screen, you see two attributes for labels. The Label attribute shows the label in your current logon language. This can be translated into all languages your instance supports. You see Default Label attribute in those cases where a label is not maintained in the current logon language.
● Changing or adding translations for a label
● Disabling or enabling a field
If administrators disable an HRIS field, they in effect deactivate this field and it will no longer be visible on any UI. The data already created in this field is then no longer accessible. We suggest you test this change before disabling any HRIS fields in a productive system.
If administrators enable a field for which permissions are controlled on a field level, they have to make sure that the correct permissions are maintained for the activated field. If they don´t do this, the field will remain invisible.
To change the permissions on the new Admin Tools UI, go to Set User Permissions Manage Permission Roles . Ensure that the permissions of the Employee Central Effective Dated Entities are checked:
● Adding a picklist to a field
In the attribute Type of Reference Object, select Picklist. Then, in the attribute Picklist, select a picklist from the list.
Note that picklists cannot be added for fields with the Data Type DOUBLE.
● Marking a field as required
● Changing the visibility of a field
● Masking a field
● Defining the number of digits after the decimal point and displaying the trailing zeros for floating point numbers
● Allowing the import of a field if the visibility is set to Show.
This allows the import of fields that are display-only on the UI during data migration.
● Changing the sequence of fields within an HRIS element
Adding Custom Fields and Fields Not Included in the Succession Data Model XML — for Administrators
Administrators can add custom fields or fields that were not included in the XML upload to an HRIS element. By using the up- and down arrows, they can then change the sequence of the fields for the element. If they use a custom field with field-level permissions, they need to set these permissions in Employee Central Effective Dated Entities as described above.
There are some additional use cases for custom fields:
● Custom fields can refer to either pre-delivered or custom-defined foundation objects. For this, administrators need to select Foundation Object in the Type of Reference Object attribute.
● Custom fields can refer to employees. For this, administrators need to select Employee in the Type of Reference Object attribute.
Working with Sections in HRIS Element jobInfo — for Administrators
The fields in the Job Information portlet appear in different sections:● Position Information
● Organization Information
● Job Information
● Time-Off Information
● EEO Information
The fields in the jobInfo HRIS element can be (re-)assigned to sections by using the BCUI. If sections are not defined, there is a standard assignment. However, administrators can change the standard assignment of a field. If they want to do that, they need to maintain the section attribute for all fields. This is the case for all global fields as well as country-specific fields.
Typical use cases are:
● Assigning a (custom) field to a specific section
● Assigning a country-specific field to a specific section A couple of restrictions need to be kept in mind:
● The field position can only be assigned to the section Position Information. Custom fields cannot be assigned to this section.
● Section assignments should not be different for a field that is defined both globally (in the succession data model) and locally (in the country-specific succession data model).
● Section assignments can be different for a field that is defined in more than one country, as long as it is not defined globally.
These restrictions are validated by the BCUI.
Assigning Configurable Rules to HRIS Elements and Fields — for Administrators
Administrators can assign rules to HRIS elements and fields, and trigger certain events. They maintain the rules they want to assign on the Admin Tools UI Company Settings Maintain Rule Objects . They must maintain the rule by using the HRIS element as the base object.
For more information, see Setting up configurable rules [page 105].
Administrators can assign rules on either the level of the HRIS element or of the field within the HRIS element that is the base object. The events that can be selected depend on the level the rule is assigned to.
The following use cases are supported on the BCUI:
● Assigning rules on HRIS element level
Event types onInit and onSave are available. The rule is triggered if the information of the HRIS element (in the portlet or the hiring wizard) is displayed for the first time or saved. Administrators can assign rules on HRIS element level in the Trigger Rules section on the BCUI. Here, they can also select the event type.
● Assigning rules on HRIS field level
Only event type onChange is supported. This means that the rule is executed each time the field content changes. Changes can be made in the portlet, during the upload, in a self-service scenario, or during the execution of a wizard. In this case, administrators assign the rules in the Details screen of a field.
Rules can only be assigned as configurable rules in the BCUI, if they have already been created in Manage Rules Objects.
Configuring HRIS Sync Mappings — for Administrators
Administrators can define the mapping of HRIS elements to standard elements (HRIS sync mappings) directly on the details screen for the HRIS field. The value help of the identifier attribute of the HRIS sync mapping provides a list of all standard elements that are enabled. Administrators can define these mappings for both pre-defined and custom fields. Some mappings between HRIS fields and standard elements are hard-coded, as described in Human Resource Information System (HRIS) synchronization [page 160].
Configuring Country-Specific Fields — for Administrators
Administrators can add country-specific fields to the following HRIS elements:
● globalInfo
● homeAddress
● jobInfo
● employmentInfo
● compInfo
Localized fields can only be entered after the administrator presses Save after the country-specific element is created.
HRIS fields for jobInfo, employmentInfo, and compInfo can be defined both globally and locally. if a field is defined more than once or for more than one country, all attributes must be the same (with the exception of label and displayOrderFollows). If the administrator changes attributes on a global or local level, this change is propagated to the respective local or global fields. The administrator will be asked to confirm those changes.
The fields regarding EEO of the jobInfo element are intended for use in the USA and should therefore only be defined as country-specific fields for the USA.
Country-specific fields for globalInfo can only be defined locally. This element must not have fields defined on a global level.
For more information about country-specific fields and special circumstances, see Setting up country-specific data models [page 69].
Some typical use cases for country-specific fields:
● Having a specific label for a global field in certain countries (valid for jobInfo, employmentInfo, compInfo)
● Defining the sequence for the global field differently from the local field (valid for jobInfo, employmentInfo, compInfo)
● Making a global field available only in a specific country (valid for jobInfo, employmentInfo, compInfo) For this, the field must only be defined in the country and not globally. There are some exceptions for this, where the field must be disabled in the succession data model. The BCUI will verify this.
● Using a custom field with different attributes in different countries (valid for globalInfo)
● Creating a specific address format for a country (valid for homeAddress)