2287729 - Employee Central - Object Association Field Criteria FAQ and Troubleshooting Tools

This KBA covers the topic of Object Associations and Field Criteria, including FAQ, the different types of Associations and how to set the up along with Troubleshooting Tools. 

• What are Field-Criteria - how does it work?
• Employee Central Child to Parent Associations Types and How to Configure Them. 
• Troubleshooting Tools 

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

SAP SuccessFactors Employee Central 

Index

• General FAQ
• What is Field Criteria and why is it required? 
• What is the Field Criteria composed of? 
• What is destinationFieldValue?
• What is sourceFieldName? 
• Different Types of Associations and How to set up the Field Criteria: 
• GO to GO (Generic Object to Generic Object)
• FO to FO (Foundation Object to Foundation Object)
• FO to GO (Foundation Object to Generic Object)
• GO to FO (Generic Object to Foundation Object)
• Troubleshooting Associations and Field Criteria Issues
• Check Tool
• Admin Alerts

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

General FAQ

Q) Which direction do associations go?
A) Associations always go from the Child object to Parent object. In other words, the association is being placed on the Object you expect to be filtered based on the Parent value selected. Example - Location (Child) to Legal Entity (Parent). After selecting Legal Entity, a filtered list of Locations will be available, based on the selection made in Legal Entity.

Q) Which object should have the Association created on it?
A) The Child object

Q) Should all associations have field-criteria defined in the Succession Data Model?
A) Yes, all custom made association should have field criteria. There are some standard associations which do not require field criteria for example the association for the Name Format feature.

Q) Is the field-crtieria configuration case sensitive?
A) Yes. You need to ensure that destinationFieldValue and sourceFieldName are set correctly as upper and lowercase text is respected

Q) Can the field-criteria be maintained via XML?
A) Yes

Q) Can the field-criteria be maintained via Manage Business Configuration (BCUI)?
A) Yes

Q) If the field is hidden in the UI using RBP - will the Value Help (field-criteria) still be utilized by the UI?
A) No. This can be misleading when troubleshooting associations issues in for example - Job History or MSS UI - where the field is NOT permitted for the end user (is not visible because of RBP - not because of field visibility config), but in New Hire wizard, you find the issue occurs because in Add New Employee wizard, RBP is not used.

Q) Are there any exceptions to the above mentioned considerations?
A) Yes - There are two association configurations that have specific configuration requirements. "Implementing Employee Compensation Data in Employee Central" guide in the "Setting Up Country/Region-Specific Picklists for Pay Components" Chapter and "Implementing Employee Central Core" guide in the "Configuring Country/Region-Specific Event Reasons" Chapter. Please note that this configuration should be followed explicitly as mentioned in the Guide

 

What is Field Criteria and why is it required? 

Field criteria is used to filter the value of a field based on the value of another field. Field Criteria should respect the relevant association between the two objects on both fields. It enables the association to be respected on the fields and to be filtered respecting the association.

What is the Field Criteria composed of? 

Field criteria is composed of the following two sections:

Source Field Name is the field that you want to control by applying restrictions. For example, if the field is of type FO and the object is legal entity, this attribute can be the field name in the legal entity for which you want to control the output, for example, Startdate. This is a required field.

Destination Field Value is the field value that restricts the value of the source field.

What is destinationFieldValue?

Q) When specifying the destinationFieldValue, which field should be defined?
A) The Parent Object field in the Succession Data Model

Examples -:

destinationFieldValue="company" = Value Help will be performed base on the selection made in the “company” field. The “company” field is the Parent field in this association relationship. The field being pointed to, must be the same object that you are pointing to in the Child objects association configuration.

destinationFieldValue="jobInfo.company" = Value Help will be performed based on the selection made in the Job Information field “company” (this example is where the Parent field is defined in a different element)

 

What is sourceFieldName?

Q) When specifying the sourceFieldName, which field should be defined?
A) In “sourceFieldName” you must define typically the “Association_Name . Parent Object internalCode field name” but this is not always the case. The below example is of a GO to GO association.

For Example the first part of the sourceFieldName comes from the Child Objects Association "Name" to the Parent object -:

Second part of the sourceFieldName comes from the Parent Objects "Name" value from the Database Field "internalCode" -:

 

Return to the Top

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Different Types of Associations and How to set up the Field Criteria: 

The below sections go though the different types of Associations and how the field criteria must be set up for each type:

GO to GO

A GO to GO association is one between two Generic Objects. Generic Objects are configured in Configure Object Definitions and their entities can be seen in Manage Data.

Q) Is an association between an MDF Foundation Object and a Generic Object (or Vice Versa) any different from an association between a Generic Object and another Generic Object?
A) There is no difference. Foundation Objects that have been migrated to MDF are Generic Objects, and there is no difference in creating field-criteria between an MDF FO and a regular GO or vice versa.

Q) Which field on the Parent object, do we use in the “sourceFieldName” condition?
A) When it is an association between GO and GO you always need to use the “Name” value of the Database Field Name “internalCode”. For Foundation Objects migrated to MDF this is typically named “InternalId” (example Department). But, for custom Generic Objects, this could be different. Typically, a custom Generic Object is created, the Database Field Name “internalCode” has the default Name “mdfSystemInternalCode” instead of “internalId” but note - the Name can be manually changed also, so always check the Parent object if you are unsure what it should be!

Example: 
The below example is for an association between Cost Center and Legal Entity. The association name on the Cost Center object is "cust_CostCentre_to_LegalEntity":

The destinationFieldValue should be "company" in this case as the parent field for Legal Entity is the "company" field.

The sourceFieldName will be "cust_CostCentre_to_LegalEntity.internalID". This is made up of the association name "cust_CostCentre_to_LegalEntity"  the “Name”  of the “internalCode” on the LegalEntity object, "internalID" which can bee seen in the below screenshot:

The below screenshot shows what this would look like in Manage Business Configuration:

Q) Can the interalCode "Name" value be changed to a custom name value?
A) Yes. You can change the "Name" value for the "internalCode" field. Please refer to the Objects configuration for the correct field Name to use

 

 

FO to FO

A FO to FO association is one between two Legacy Foundation Objects. Legacy Foundation Objects are configured in Corporate Data Model and their entities can be seen in Manage Organisation, Pay and Job Structures.

Q) When configuring an Association between a legacy Foundation Object (Child) and another legacy Foundation Object (Parent) can the Association be made via Admin Center?
A) No. This change needs to be made in the Corporate Data Model. The direction of the association (Child > Parent) is still the same.

Example -: hris-association configuration from Corporate Data Model for Pay Range -:

<hris-associations>
    <association id="id" multiplicity="ONE_TO_ONE" destination-entity="payGrade" required="true" />
    <association id="id" multiplicity="ONE_TO_ONE" destination-entity="geoZone" required="true" />
</hris-associations>

Q) Should you still use field-criteria configuration?
A) Yes, field-criteria is still required for an FO to FO association.

Q) How should the “sourceFieldName” condition be configured for an FO to FO association?
A) The sourceFieldName is simply the externalCode of the parent object. For example an association with Pay Grade as the Parent would use "PayGrade" as the sourceFieldName.

Example: 
The below example is for an association between Location and Pay Grade Entity.

The destinationFieldValue should be "pay-grade" in this case as the parent field for Pay Grade is the "pay-grade" field.

The sourceFieldName will be "PayGrade" as this is the externalCode of the Pay Grade Object. We can see how this would look in the Succession Data Model from the below code

<hris-field max-length="128" id="location" visibility="both">
   <label>Location</label>
   <label xml:lang="en-US">Location</label>
   <field-criteria destinationFieldValue="pay-grade" sourceFieldName="PayGrade"/>
</hris-field>

 The below screenshot shows what this would look like in Manage Business Configuration:

FO to GO

A FO to GO association is one between a Legacy Foundation Object as the child and a Generic Object as the Parent.  Legacy Foundation Objects are configured in Corporate Data Model and their entities can be seen in Manage Organisation, Pay and Job Structures.  Generic Objects are configured in Configure Object Definitions and their entities can be seen in Manage Data.

Q) When configuring an Association between a legacy Foundation Object (Child) and a Generic Object (Parent) can the Association be made via Admin Center?
A) No. The association configuration needs to be performed in the Corporate Data Model. Then also field-criteria will be needed to be configured in the Succession Data Model.

Example hris-associations section configuration from Corporate Data Model for Location (FO) > Legal Entity (GO) -:

<hris-associations>
<association id="id" multiplicity="ONE_TO_MANY" destination-entity="LegalEntity" required="true" />
</hris-associations>

Q) How should the “sourceFieldName” condition be configured for an FO to GO association?
A) The sourceFieldName is simply the externalCode of the parent object. For example an association with Legal Entity as the Parent would use "LegalEntity" as the sourceFieldName. 

Example: 
The below example is for an association between Location and Legal Entity.

The destinationFieldValue should be "company" in this case as the parent field for Legal Entity is the "company" field.

The sourceFieldName will be "LegalEntity" as this is the externalCode of the Legal Entity Object. We can see how this would look in the Succession Data Model from the below code

<hris-field max-length="128" id="location" visibility="both">
<label>Location</label>
<label xml:lang="en-US">Location</label>
<field-criteria destinationFieldValue="company" sourceFieldName="LegalEntity"/>
</hris-field>

 The below screenshot shows what this would look like in Manage Business Configuration:

GO to FO

An GO to FO association is one between a Generic Object as the child and a Legacy Foundation Object as the Parent. Generic Objects are configured in Configure Object Definitions and their entities can be seen in Manage Data. Legacy Foundation Objects are configured in Corporate Data Model and their entities can be seen in Manage Organisation, Pay and Job Structures.

Q) When configuring an Association between a Generic Object (Child) and a Legacy Foundation Object (Parent) can the Association be made directly?
A) No. You need a Wrapper object to link the Child with its Parent. Wrapper objects have been pre-delivered for all remaining legacy Foundation Objects (such as Location, etc) to allow you to associate these objects.

Q) Do I need to create my own Wrapper object?
A) No. You will find that a Wrapper Object already exists for all current legacy Foundation Objects.

Q) Will I need a wrapper for an objectafter the legacy FO is migrated to MDF?
A) No.

Q) Which field on the Wrapper object should be used for the “sourceFieldName” extension?
A) For legacy Foundation Objects, the system will match values using the “externalCode” field in the Wrapper objects. For example, as this would be a Wrapper object, externalCode field is configured as type “Foundation Object” and points to the Parent legacy Foundation Object.

 

Example: 
The below example is for an association between Cost Center and Location. The association name on the Cost Center object is "cust_to_Location":

The destinationFieldValue should be "location" in this case as the parent field for Location is the "location" field.

The sourceFieldName will be "cust_to_Location.externalCode". This is made up of the association name "cust_to_Location"  the “externalCode" on the Location Wrapper object, "externalCode". We can see how this would look in the Succession Data Model from the below code 

 <hris-field max-length="128" id="cost-center" visibility="both">
<label>Cost Center</label>
<label xml:lang="en-US">Cost Center</label>
<field-criteria destinationFieldValue="location" sourceFieldName="cust_to_Location.externalCode"/>
</hris-field>

The below screenshot shows what this would look like in Manage Business Configuration:

Please Note: field criteria is not supported for country specific fields (CSF)  in any element.

Note: Associations only work when referencing fields or objects within a given element or object. Associations will not work if you wanted to filter a field in a custom MDF object based upon the selection of a field from a HRIS element like jobInfo. It would only work if you make a selection in a parent field on that object, and then it filters a field within that object.

Return to the Top

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Troubleshooting Associations and Field Criteria Issues:

There are multiple way to troubleshoot Association and Field Criteria issues.

Below we will discus two tools that can assist with this.

Check Tool:

Using the Check Tool Feature, you can see potential issues with you object associations and field criteria:

• Generic objects that reference another generic object (custom wrapper) in their external code.
  • The custom wrapper will be used to find the association rather than the generic object. For example: If you have defined a custom wrapper for the Business Unit generic object, then all associations that have Business Unit as their destination object would cancel out the filtering by field criteria.
• Necessary field criteria exist.
  • HRIS element fields can reference foundation or generic objects. If this object has an association whose destination object is used in another HRIS element field, then at least one such usage should be referenced by the field criteria. This ensures correct filtering and data consistency when entering data for such fields.
• The field criteria are valid.
  • HRIS element fields can reference generic or foundation objects that are associated with each other. To ensure correct filtering of the field values, the destination and the source of the field criteria must be set up correctly.

These checks can be found in the Employee Central Core Application Area under the Associations section:

Looking at an example error in the below screenshot, we can see an error with an existing field criteria. In this case we can see that a field criteria has been added to the department field which is not valid and does not exist on the Object Department. From here you can then review the Object Association and correct the field criteria:

Permissions are required to access the check tool and can be provided in Permissions Roles under Administrator Permissions > Check Tool > Access Check Tool which authorizes users to access the tool.

Further Details on how to use the check tool can be found in the following Guide:

Using the Check Tool

Admin Alerts:

These Option will be included in the 2H 2022 Release. Once the Release is deployed to your instance the below steps can be used to assist with your troubleshooting. 

Using the admin Alerts tool, you can highlight employees who have data or configuration Job Information Issues with associations.

These Alerts can be seen under the section HR Data Issues > Job Information Issues in the Admin Alerts UI.

As with other Admin Alerts, permissions are required to view the alerts, this can be provided in Permission Roles under Admin Alerts Object Permissions > Job Information Admin Alert permission.

Under the “Invalid Foundation Object association” & “Invalid Association on Generic Object” Issue, you will see all users who have issues with association on there Job Information, highlighting which field is impacted under the “HRIS Field”:

You can also filter on “User ID” or “User Name” via the Settings UI and the Filter Tab, if you wish to see results for specific users:

Full details on how to use Admin Alerts for Job Information Issues can be found in the following section of the guide:

Implementing and Managing the Employment Lifecycle (from Hiring to Termination): Working with Alerts for Job Information Issues

Return to the Top

If you have further configuration questions please consult the Implementing Employee Central Core - Configuring Associations Guide.

• 2787298 - Custom Object Association and Field Criteria to Legal Entity is not Working
• 2522246 - Association Troubleshooting
• 2315265 - Employee Central - Foundation Objects
• 2285359 - Adding an Association from Custom Foundation Object to MDF Foundation Object (GO to GO)
• 2285593 - Adding an Association from Custom Foundation Object to a Legacy Foundation Object (GO to FO) - Employee Central

Object, Association, Value Help, Parent, Child, GO, FO, mFO, cGO, Employee Central, Foundation Object, Custom Foundation Object, Generic Object, MDF Object, field-criteria, field criteria, value filtering, MDF Foundation Object, FieldCriteriaCheck,  admin alerts, admin alerts 2.0, hr data issues, FAQ, check tool, CustomWrapper, MissingFieldCriteriaCheck, ExistingFieldCriteriaCheck , KBA , LOD-SF-EC-JOB-OAS , Object Associations and Field Criteria , LOD-SF-EC-JOB , Job Information , LOD-SF-EC-MDF , MDF & EC2MDF Migration , LOD-SF-EC-FOO , Foundation Objects (Organisation, Pay and Job Structures) , How To

SAP SuccessFactors Employee Central all versions ; SAP SuccessFactors HCM Suite all versions