Who is this article for?

Users who want to learn about child-level fields

No elevated permissions are required.

A module is constructed using various fields, which can include types such as text, date, number, and more. No matter the type of field, they can be categorized into two distinct levels:

• Header-level: This category encompasses fields that are restricted to holding a single value at any given time for each record. These fields are crucial for maintaining clarity and consistency within the data structure.
  • Some common examples of header-level fields include Title, Date Created, and Current Task. Each of these fields serves a specific purpose.
  • While the value assigned to the field may change over the duration of the record's existence, there will always be only one value designated as the field's value at any moment.
  • This limitation ensures that the data remains organized and prevents confusion that may arise from having multiple concurrent values in these critical fields.
• Child-Level: In contrast, child-level fields are designed to accommodate multiple values within a single record. This flexibility allows for a more comprehensive representation of data.
  • Examples of child-level fields include Trend Codes, Actions, and Comments. Each of these fields can be viewed as a separate table where one or more rows can be created, and each row may contain various columns that represent different values associated with that field.
  • This structure allows for a detailed capture of information, allowing users to record multiple actions, trends, or comments that pertain to a single value, thereby enriching the data set and providing deeper insights.

The child-level data is often displayed in the form of radio buttons, picklists, grids, tags, or cards. The search results can encompass all items that have child-level field values when specific search criteria are met.

While each record can have many child-level field values. If a search for multiple records is set, the search results will only display the records header-level field values, not the child-level field values displayed in the grids or cards.

Child-Level Reporting
The Ideagen Business Intelligence (BI) search engine does not currently apply data table criteria to the data table (child-level) rows – instead, it applies the criteria to find ANY record with data tables having at least one matching entry.

When using multiple filters, the search works on an AND basis. This means that the results shown will only include items that satisfy all the filter criteria. You can check out Performing a Search for more helpful search tips.

Building a report with child-level data
Custom search reports can include child-level criteria when a custom visualization called "Other" is built. See Getting started with visualizations for more information.

Displaying child-level fields

Child levels can be presented in several ways within a module. The most typical display is a data table with rows and columns. Large tables will display all of the rows by default with an option to collapse and re-enable paging.

If only one child-level field needs to be collected per row, the module could display the child-level field as a chip or tag. Notice that while this looks like there is only one field value, there are multiple child-level field values.

Regions with text columns can display lists marked by checkbox radio buttons or dropdown picklists can display child-level fields where one or more options can be chosen.

Add Multiple values at once
Select shift/control+click to select multiple values from a search reference pop-up display or grid when they are listed in the desired order.

When a lot of information needs to be visible, or the child-level rows are references to other objects, the child-level field values can be displayed in a card view. A child-level card view works well when some fields in the child-level need to store a substantial amount of information such as the description field. The child-level field values are concatenated, and filter controls are added to the top of the card to dynamically sort, show/hide, and search for specific cards.

Careful consideration should be given to header and child-level reporting.
See Creating a legacy table BI report for more information.