7.2 Configuring the Succession Data Model with BCUI and XML

7.2 Configuring the Succession Data Model with BCUI and XML

Quick Answer: HRIS elements can be configured in Manage Business Configuration (BCUI) or directly in the Succession Data Model XML. BCUI changes are synced into the data model and vice versa. BCUI is convenient but has no undo and no version backup. XML is better for large simultaneous changes and keeps backup versions. Either way, a newly enabled field needs an RBP permission.

Manage Business Configuration for HRIS Elements

BCUI lets consultants and administrators update the Succession Data Model and the CSF Succession Data Model without XML. Prerequisites and cautions:

• Both models must be uploaded during implementation before BCUI can be used.
• After uploading them, run the Check Tool to find configuration issues.
• BCUI has no undo feature and does not create a backup version when you make changes.
• Entities open in view mode. Choose Take Action > Make Correction to edit.

In BCUI you can:

• set the label and default label of an HRIS element
• enable or disable the element
• assign business rules to the element (Trigger Rules)
• set a field label and enable or disable a field
• open Details to set attributes such as field type, required, and visibility

The left panel has an Employee Central section (HRIS and country-specific elements) and an Employee Profile section (standard and userInfo elements). SAP improves BCUI almost every release with new validations.

Worked Example: Attachment on Biographical Information

To let users add an attachment to Biographical Information: open personInfo, choose attachment-id from the field drop-down at the bottom, label it Biographical Attachment, set Enabled = Yes, and check that Visibility = Edit in Details. Save and confirm the data model changes. No extra RBP step is needed here, because Biographical Information is permissioned as an entire block. Other fields need field-level permissions.

Person Types

A Person Type in BCUI defines a set of fields for a group of persons, such as contingent workers. For each person type you can set Enabled, Mandatory, and Visibility.

• Person types can be defined for global and country-specific HRIS elements, and only for HRIS elements.
• When a person type is created, all its HRIS fields are copied from the base element. You cannot add a field that is not in the base element.
• Person types can be added only in BCUI. They have no corresponding entry in the data model XML.
• Possible types, depending on enabled modules: Employee, Dependent (Dependents Management), Student (Learning), Candidate (Recruiting), Onboardee, and Contingent Worker.

Dynamic Group Filters

To use an Employee Central field as a criterion in permission and workflow groups, add it as a Dynamic Group Filter in BCUI: Filters > Dynamic Group Filters > DG Filters. Choose Details, select the HRIS element, then the HRIS field (it must be enabled and visible), and save. You may need to log out and back in before the field appears in the People Pool categories.

A Generic Object as a Custom Field

Customers often want a generic object to behave like a foundation object in the employee file. THR81's parking example:

1. In BCUI, open the HRIS element (jobInfo) and add a custom-string field, for example custom-string4 labeled Parking, and enable it.
2. In Details, set Type of Reference Object = Foundation Object and Reference Object = the generic object's code, for example cust_parking. Codes are case- and space-sensitive.
3. If the object is filtered by an association, add field criteria. For example, Destination Field Value = location and Source Field Name = cust_toLocation.externalCode (Section 6.4).
4. Save and grant permissions for the new field under Employee Central Effective Dated Entities.
5. Test: change the location in Job Details and confirm that only the associated parking records appear.

The Check Tool includes a validation for existing or missing field criteria.

Configuring the Succession Data Model with XML

BCUI is valuable, but XML still has advantages:

• It is easier to make simultaneous changes to many global and country-specific fields. BCUI often returns errors for such bulk changes.
• Every data model upload creates a backup version, while BCUI records no history.

Rules for XML changes:

1. Download the latest version first. Use Export Succession Data Model in Admin Center, which also lists previous versions you can export or restore. Up to 100 previous versions are kept.
2. Save the file with your other models, increment the version number in the file name, and point the DOCTYPE to the local sf-form.dtd if your editor validates.
3. Do not change hris-element IDs or hris-field IDs.
4. Edit inside the right element. THR81 warns that a common mistake is placing a new field in the wrong hris-element.
5. Upload in Provisioning > Succession Management > Import/Export Data Model with a comment.

Changes made in BCUI are synced to the data model and vice versa. An attachment-id field enabled in BCUI appears in the exported XML with its label and visibility "both".

Worked Example: jobInfo Changes in XML

• Enable supervisor-level by setting visibility to both and relabel it Management Level.
• Add a custom field after the supervisor-level field and before is-cross-border-worker:

<hris-field id="custom-string8" visibility="both">
  <label>Additional Job Details</label>
</hris-field>

If a custom label does not show, add an en-US label line. After uploading, grant all permission levels (View Current, View History, Edit/Insert, Correct, Delete) for Management Level and Additional Job Details in Employee Central Effective Dated Entities. Then open the employee's Job Details, choose View all, and select Show empty fields to verify.

BCUI or XML?