Parent and Child Object Mapping

When mapping objects in a package, it is very important to map every object to its lowest level. The Advanced Package Mapping page for each package lists the objects in the package file and corresponding objects in the target instance. The objects are divided into categories for easier navigation. Parent objects must be mapped before child objects can be mapped. When an object has child or related objects, a drill-down link is provided after the parent object is mapped.

Note: A warning appears if Archer detects that 2 mapped objects depend on other objects whose system IDs do not match. You can map dependent objects with mismatched IDs, or you can leave the dependent objects unmatched; it is recommended that you verify all objects and dependents are mapped as intended before you commit your mapping changes.

On this page

Child elements and dependencies for each root object

The following figures show the child elements and dependencies that might need to be mapped for each type of root object.

Applications

Download the source file of the diagram here: Platform - Mapping Applications Diagram

Diagram of mapping the application objects.

Questionnaires

Download the source file of the diagram here: Platform - Mapping Questionnaires Diagram

Diagram of mapping the Sub-Form objects.

Sub-forms

Download the source file of the diagram here: Platform - Mapping Subform Diagram

Diagram of mapping the Sub-Form objects.

Other root objects

Download the source file of the diagram here: Platform - Mapping Other Root Objects Diagram

Diagram of all stand-alone root objects, including Global Values list.

Note: Global Values List is used by applications, questionnaires, and sub-forms.

Mapping child objects in fields

The following table describes how to ensure that all of the child elements are mapped correctly in the following field types.

Field Type

Remediation

CAST

Verify that the child objects match in both the source and target instances. This mapping includes the associated application, application level, and values list fields.

Cross-Reference

Verify that the relationships match between the source and target instances for cross-reference fields. It is possible to map a cross-reference field to a different module, thus creating error situations after package install.

Global Values Lists

Verify that the Global Values Lists (GVLs) match across the source and target instances. If the package changes or removes existing values in a GVL, verify that these changes do not adversely impact other objects or features that use the same GVL. Note that this is not a concern when values are added to a GVL.

Matrix

Verify that the values lists referenced by the matrix field match in both the source and target instances.

Scheduler

Verify that the associated applications match in both the source and target instances.

Sub-form

Verify that the sub-form fields map to the same sub-form in both the source and target instances.

To verify if child objects are mapped correctly, review the Status column of a child object.

The following table describes the icons.

Icon

Description

Source object is mapped to an object in the target instance

Indicates that the source object is mapped to an object in the target instance. After you verify that the object is mapped as intended, nothing more needs to be done with these objects in Advanced Package Mapping.

System could not automatically match the source object to a corresponding object in the target instance

Indicates that the system could not automatically match the source object to a corresponding object in the target instance.

Objects marked with this symbol must be mapped manually.

New objects should not be mapped. Select Do Not Map from the drop-down menu to clear this icon for an individual object, or click Do Not Map to clear the icon for all unmapped objects.

Mapping values lists

Mapping Values Lists can be complex. The differences between the 3 components are:

  • Values List field. The field in the application that contains the values list.
  • Values List. A field-specific, or custom values list, a global values list, or a questionnaire values list.
  • Values List values. The items within the values list.

Consider the following points when you map these components:

  • When mapping values lists, be sure to map the values list field, the values list, and the values list values. If you do not map all 3 components, you may have unexpected results that can be difficult to remedy.

    If you map only a values list field and not the associated values list and values list values, Packaging does not create a new values list for that field and a warning message is logged. Anything associated with that values list, such as calculations or data driven events, may not function properly until the values list values are added.

    If you map a values list field and its associated values list, but none of the values list values, Packaging either updates the existing or creates new values list values under that values list. This process can potentially create duplicate values. Anything already associated with the values list, such as calculations or data driven events, are changed to point to the new, duplicate values.

  • You cannot map to different types of values list components. For example, you cannot map a custom values list to a global values list. In the rare instance in which you may want to map to a different type, it is recommended that you update the object in either the source or target instance so that the objects match. After making the updates, regenerate the package.

Note: These recommendations also apply to the values lists in matrix fields.