Configuring Foundation Object association during implementation

Associations enable you to define relationships between Foundation Objects and their records. The associations are built in the Foundation Object configurations, on the MDF object, or within the XML. Once the association is built, the records are linked together.

The standard predelivered Foundation Objects include prebuilt associations, such as the Location object. These have built-in associations with the Legal Entity object or the Pay Range object with its own built-in association with the Pay grade object.

Employee records rely on the Foundation Object structure. Any Foundation Object associations must also be aligned with the employee data. The choices that you see on the different lists will be restricted based on the relationships and hierarchies built. This makes it easier for the person working on the employee file to find the correct value and ensures the information complies with the defined hierarchy.

For example, ACE Corp has 30 locations worldwide. Only 13 of these locations are within the United States. The association between the Legal Entity Foundation Object and the Location Foundation Object establishes the relationship between these objects. The 13 US Location records are connected to the United States Legal Entity. When Ace USA Legal Entity is chosen on the employee data, only those 13 locations will display as options, even though we have 30 active Location records in the system.

Multiplicity determines how many records you can associate together. Whether you're creating Composite or Valid When associations, there are two types of Multiplicities: one to one and one to many. We'll go through examples of both types of multiplicities.

Here, you can see an example of a one-to-one association between Location Groups and Locations for ACE Corp. At the bottom of the chart, notice that the Seattle Location only belongs to the NA_West Location Group. Seattle does not connect to the NA_East Location Group. If none of the Location records ever belong to more than one Location Group, then you can set the multiplicity as one-to-one.

This means that a location can only belong to one Location Group.

One-to-one associations will display at the record level as picklists since you can only choose one option.

The most common type of multiplicity for Foundation Object records is one-to-many. The figure shows an example from ACE’s configuration of a one-to-many relationship between Job Classification and Country Specific Fields for Job Classification. The Account Manager job classification (parent) is associated with many country-specific job classifications (child), where the country-relevant fields for Account Manager are stored in the child object. The system displays one-to-many associations as a separate section at the bottom of the Foundation Object record, where multiple records can be connected.

There are four categories of Foundation Object associations. We'll cover MDF to MDF and XML to MDF associations in detail. XML to XML and MDF to XML will be discussed at a high level, as the processes are similar to the first two.

These are the fields required to be filled in when configuring relationships between objects:

• Name: a unique name for the association. All customer defined association is automatically prefixed with "cust_"
• Multiplicity: One to One or One to Many
• Destination Object: Depends on whether the association is composite or valid-when
  • For composite, the destination object refers to the child object being associated with the parent
  • For valid-when, the destination object refers to the high-level object in the hierarchical structure

• Type: Composite or valid-when (the other type, Join By column, is not used in this training).
• Label: Display label identifying one or more related records.

In this association, we are creating a hierarchical relationship (and a filtering effect) between two MDF-based objects. Business Unit to filter Division records. The steps to configure this type of association can be divided into three high-level steps:

1. Creating the relationship in the object.
2. Aligning the relationship in the Employee File.
3. Aligning the relationship in Position Management (applicable only if Position Management is enabled).

Watch the video for a demo of how associations are configured between two MDF-based objects.

Configure the association on the Foundation Object to be filtered (lower-level object in the hierarchy). The Business Unit is the higher-level object in the hierarchy structure, and the Division is the lower-level object.

The steps are as follows:

1. Type Configure Object Definitions in Action Search.
2. From the Search dropdown, select Object Definition and then from the next dropdown, select Division (the object to be filtered). The division's object definition is displayed.
3. Go to Take Action → Make Correction.
4. Go to the Associations section at the bottom.
5. Select Details. We will now set the association.

a. In the Name field, specify a name for the association.

b. In the Multiplicity field, select One to Many.

c. In the Destination Object field, select the higher-level object that will filter the values for the source object.

d. In the Type field, select Valid When

Ensure that the relationship between Foundation Object records is aligned with employee records by defining field criteria in BCUI (Manage Business Configuration UI) or Succession Data Model.

The steps are as follows:

1. Type Manage Business Configuration in Action Search
2. Go to HRIS Elements → jobInfo.
3. Navigate to the division field, which corresponds to the lower-level object (the object getting filtered). Go to Details → Field Criteria
4. The Destination Field Value is the HRIS field identifier of the higher-level object (the field doing the filtering), in this case, business-unit.
5. The Source Field Name has two parts. The first part is the Name of the association in Configure Object Definition. The second part is the fieldname of the internal code in the higher-level object. In this example, Source Field Name is written as cust_toBusinessUnit.internalId.

   The field name of the internal code on the parent Object (in this example, internalID) can be derived from the Configure Object Definition page. Look for the Database Field named InternalCode.

6. Save your changes.

This step is to be done only when Position Management is enabled. Define Field Criteria for the field related to the MDF FO being filtered. Just like the employee files, this ensures the relationships defined between FO records translate to the Position records.

The steps are as follows:

1. Go to Configure Object Definition in Action Search.
2. Go to Search → Object Definition → Position. The Object Definitions page is displayed.
3. Take Action → Make Correction.
4. In the Fields section, scroll to the MDF FO field to be filtered. In this case, division.
5. To view the configuration select Details
6. In the Field Criteria section, fill in the values mentioned in the figure.

In this association, we are creating a hierarchical relationship (and a filtering effect) between an XML-based and MDF-based object. Legal Entity to filter Location records. The steps to configure this type of association can be divided into three high-level steps:

1. Creating the relationship in the Foundation Object.
2. Aligning the relationship in the Employee File.
3. Aligning the relationship in Position Management (applicable only if Position Management is enabled).

Watch the video for a demo of how associations are configured between an XML-based and MDF-based objects.

Configure the association on the Object to be filtered. This allows you to attach the higher-level MDF Foundation Object doing the filtering (Legal Entity) to the lower-level XML Foundation Object being filtered (Location). Since the object being filtered is XML, the association is built in the Corporate Data Model. The steps are as follows:

1. Open the latest version of your corporate-datamodel.xml.
2. Navigate to the source Foundation Object to be filtered: location.
3. In the HRIS-associations section of the Foundation Object, add an association line:
   1. Set the multiplicity to ONE_TO_MANY

   2. The destination entity should be the id/code of the MDF destination object, which in this case: LegalEntity. This can be found in Configure Object Definitions.

4. Validate your data model.
5. Save your file as a new version. 
6. Upload your data model.

Ensure that the relationship between records is aligned with employee records by defining field criteria in BCUI (Manage Business Configuration UI) or the Succession Data Model. In the Succession Data Model, define the Field Criteria for the filtered XML Legacy Foundation Object field. Just like with the MDF/MDF associations, the XML/MDF association also needs field criteria to maintain the relationships in the employee files. While the step is the same, the information needed differs slightly.

The steps are as follows:

1. Type Manage Business Configuration in Action Search.
2. Go to HRIS Elements → jobInfo.
3. Navigate to the location field corresponding to the lower-level object (the object getting filtered). Go to Details → Field Criteria.
4. The Destination Field Value is the HRIS field identifier of the higher-level object (the field doing the filtering), in this case, company.
5. The Source Field Name is the id/code of the object doing the filtering in Configure Object Definition. In this example, the Source Field Name is written as LegalEntity.
6. Save the changes.

Do this step only when Position Management is enabled. Define Field Criteria for the source XML Foundation Object being filtered. The steps are as follows:

1. Go to Admin Center.
2. In the Tools Search field, type Configure Object Definitions.
3. From the Search dropdown, select Object Definition and then select Position from the dropdown next to it. The Configure Object Definitions page is displayed.
4. From the Take Action dropdown, select Make Correction.
5. In the Fields section, scroll to the field to be filtered. In this case, Location.
6. To view the configuration select Details .
7. In the Field Criteria section, fill in the values mentioned in the figure.
   

In this association, the configuration steps are similar to XML to MDF association. Watch the video for a demo of how associations work between two XML-based objects.

Several associations between two XML-based foundation objects are predelivered in the Corporate Data Model. In this example, let's create a custom association. The objective is for Location Group to filter location records.

1. Create the association in the Corporate Data Model. The association is placed in the Location object.

12345
 
 <hris-associations> 
           <association id="id" multiplicity="ONE_TO_MANY" destination- entity="locationGroup" required="false"/> 
    </hris-associations> 
 

2. Align the relationship in the employee file by creating a custom field (custom-string3) in the Job Information to display location group records (Location Group is not a standard Job Information field). In BCUI, add the field criteria in the location field to set custom-string3 (location group) to filter location records.

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

3. The steps for aligning in Position Management are the same as other association types. 

When configuring custom associations to filter MDF records based on XML-based Foundation Objects, a wrapper object for the legacy foundation object must be used. This is because you cannot directly define the associations. Foundation Object wrappers are predelivered MDF-based objects that represent the legacy objects in the Corporate Data Model. The association steps are similar to that of MDF-to-MDF Associations.

Watch the video for a demo of how associations are configured between MDF-based and XML-based objects and the records to be filtered are MDF.

In this example, let's create an association between the Location object (Legacy FO) and Garage (custom MDF-based).

1. Using Configure Object Definition, create the associations in the Garage object. The system won't allow a direct association to Location. You will use Location Wrapper as the destination object. When wrappers are used, the association type must be Composite instead of Valid-When.

2. Align the association by creating a custom field (custom-string4) in the Job Information to display the garage records. The field criteria is placed in the Garage field (custom-string4).

We use externalCode because it's the field that connects the wrapper to the legacy Foundation Object.

3. Same steps for aligning in Position Management as other association types.