- Object Association FAQ - Value Help - Employee Central
- Field-Criteria - how does it work?
- Employee Central Child to Parent Associations
Employee Central 2.0
How are Associations defined and how does Field Criteria work?
- General FAQ
- What is destinationFieldValue?
- What is sourceFieldName?
- 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)
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?
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?
Q) Can the field-criteria be maintained via Manage Business Configuration (BCUI)?
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 permissioned 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 this rule?
A) Yes - There is one, and it is explicitly defined in the Employee Central Master handbook "Setting Up Country-Specific Picklists for Pay Components or Event Reasons". Please note that this configuration should be followed explicitely as metioned in the handbook - and does not support adaption with other objects (meaning only Event Reason and Pay Component are supported)
Q) When specifying the destinationFieldValue, which field should be defined?
A) The Parent Object field in the Succession Data Model
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)
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" -:
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”. 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!
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
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 -:
<association id="id" multiplicity="ONE_TO_ONE" destination-entity="payGrade" required="true" />
<association id="id" multiplicity="ONE_TO_ONE" destination-entity="geoZone" required="true" />
Q) Should you still use field-criteria configuration?
A) Yes. In short it is still recommended to use the field-criteria configuration in the Succession Data Model.
<hris-field max-length="128" id="location" visibility="both">
<field-criteria destinationFieldValue="pay-grade" sourceFieldName="PayGrade"/>
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) -:
<association id="id" multiplicity="ONE_TO_MANY" destination-entity="LegalEntity" required="true" />
Example field-criteria from child field in Succession Data Model > note that you only need to specify the Object Code in this scenario -:
<hris-field max-length="128" id="location" visibility="both">
<field-criteria destinationFieldValue="company" sourceFieldName="LegalEntity"/>
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?
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.
For example -:
If you have further configuration questions please consult the Employee Central Master implementation guide - Working with Associations, Field Criteria and Value Help.
2522246 - Association troubleshooting
- 2315265 - Employee Central Implementation - Foundation Objects FAQ
- 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 , KBA , LOD-SF-EC , Employee Central , LOD-SF-EC-MDF , MDF & EC2MDF Migration , LOD-SF-EC-JOB , Job Information & Propagation XML , LOD-SF-EC-FOO , Foundation Objects - MDF & Legacy , How To