Associating Foundation Objects

Associations define relationships between Foundation Objects and their records. You can configure these associations in Foundation Object settings, MDF objects, or XML. Once established, the records are linked. Implementation consultants typically configure these associations based on your specific business requirements.

Foundation data provides the core information for employee records. Foundation Object associations must align with employee data to ensure consistency. Available options in selection lists are restricted based on these defined relationships and hierarchies. This helps users find the correct values quickly and ensures data compliance with the organizational structure.

For example, ACE Corp has 30 global locations, but only 13 are in the United States. An association between the Legal Entity and Location objects links these records. Specifically, the 13 US location records are associated with the United States legal entity (ACE_USA).

This relationship must be reflected in the employee data structure. For instance, if an employee is assigned to the ACE_USA legal entity, only the 13 US locations appear as options, despite the system having 30 active locations globally.

The figure below shows the San Mateo office linked to the ACE_USA legal entity. When you set an employee’s company to ACE_USA, the system only allows you to select locations associated with that entity.

The type of association configured in the object will determine the relationship between the two entities and their behavior.

• Composite Association: This type of association creates a parent-child relationship, where the child record cannot exist outside the parent record. The child object's effective dating must always be From Parent. In a composite association, the relationship is configured in the parent object.
• Valid When: This type of association is used to create filtering capabilities between objects, creating a hierarchy structure. Objects associated with this relationship exist independently and have their own life cycle. An example from ACE’s configuration: The Department object is associated with the Division Object. In a Valid When association, the relationship is configured in the lower-level object. In this example, the association is configured in the department object.

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.

There are existing one-to-one relationships that come standard with Employee Central.

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.