Navigating child-level searches in the Classic UI
Who is this article for?
Users who want to learn about child-level searches in the Classic UI
Reporting authorities, roles, and record access controls restrict data visibility.
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.
In the example record above the relationship between the header-level fields of Title, Date Created, Current Task, and Current Assignee the many child-level rows of trend codes and actions each with multiple fields per row.
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.
When a module includes fields that are specific to child levels, it retrieves all items that have at least one corresponding child row that meets the specified criteria. This means that if any child-level field matches the search parameters, the parent item will be included in the results. It is important to note that if multiple criteria are applied to child-level fields within a search, the search will be broadened to encompass all relevant parent items, rather than focusing on individual rows. T
Creating a BI report
If you have BI and you create a report where you expand by a child level against which you're also filtering, note that the report will contain all child records, not just ones that match your search criteria, because the search criteria applies against the parent item as a whole, not individual children. To further filter your report, you should create a BI report filter.
Child-level and Task-level Reporting
If your module has child-level fields defined as reportable or it's a workflow-enabled module, a Create a separate row for each...: drop-down will appear in the search criteria panel that lets you choose applicable child levels or the Workflow Tasks level.
This option is only available in Report output, not List, Grid, Trend, or Calendar.
When you choose to "Create a separate row for each" child or task level, search results will flatten out so that each child or task instance is a row in the result set. If you choose to expand by a child and there are no children for a particular object, the values for those child fields will display as blank.
The number of rows returned is a child row. Since using this feature adds a row for each child, the N items returned depiction in the bottom right-hand corner of the window will now account for all child rows, not just the parent row count. Do not interpret this as a total for the number of parent records.
Maximum rows error message
A maximum of 1,000,000 rows can be returned and displayed. An error will be displayed to the user if the search results in more than one million rows. If this happens, it will be necessary to add or modify filters to reduce the number of rows. You can only use this feature with one child level field at a time.
Workflow Task reports incorporate a variety of special fields along with a specific measure. Each of these elements is distinctly prefixed with Task -, ensuring clarity and consistency throughout the report. This prefix not only helps in identifying and clearly labelling each field but also aids in distinguishing it from other fields that may be present in the report.
Measurement of duration
Task - Durationis measured in decimal days.
As an alternative to the Create a separate row for each...: drop-down, module developers can configure modules to display child-level fields directly in the list of available fields when building ad hoc reports. These child-level fields can be configured to display aggregated values (sum, average, minimum, maximum, or a concatenation of each value) across each child row.
Example of child level field Action - Title with multiple values in the same cell: