About Result Folding
About Result Folding
When there are items in your searchable content that have a parent-child relationship with one another, you may want to improve search page experience by grouping these results and rendering a hierarchical representation of their group, in which child items matching the query appear below the main result to which they’re associated. This is called result folding.
See also Folding results.
Users may naturally expect a search page to display query result items such as thread conversations as a group of items in which the original message is the parent of each subsequent reply.
Similarly, blog posts could be expected to have the related comments displayed underneath.
Enabling result folding in a search page may introduce search page behaviors that may look erroneous. See Why Are Result Counts Inaccurate With Folding Enabled? and Why Are Some Child Items Not Folded? for additional information.
To implement result folding in a search page, you must ensure that the items involved in the folding have some fields identifying how they relate one to another (see About Fields). The fields are the following:
A collection field, whose value is identical for all items related one to another.
An item identification field, whose value is a unique identifier for each item, such as its URI or its ID in the indexed system.
A parent item identifier field, whose value is the unique identifier of the parent item of another item.
Make sure that all three fields are configured for all item types involved in result folding. Don’t configure these fields for item types you don’t want to see folded.
Together, the following search results form a thread conversation. If they were displayed without result folding and among other search results in a search page, it would be difficult to link them and to understand how they’re related. With result folding implemented, the original message is displayed as the main search result, and the responses are displayed underneath. Similarly, attachments are displayed under the message to which they’re related.
In this example, the collection field is named
@conversationid. Each conversation has its own conversation ID, and all items in a conversation have the conversation ID as the
@conversationid value. This makes it possible for Coveo to identify all messages of a conversation and consider them as a part of the same group, the same “family”.
@messageid field is the item identification field. Its value is different for all items. By comparing the
@messageid value with the value in the
@parentid field, Coveo can determine which item is a child of which other item. For example, the response saying “Does this screenshot help?” has
15 in the
@parentid field. This means that the item with unique identifier
15, that is, the item that has
15 as the value of the
@messageid field, should be considered as a parent of this response. Similarly, the unique identifier of this response is
54. Therefore, any item with
54 in the
@parentid field is a child of this item.
You can choose to use the top parent item ID as a conversation ID, especially if the indexed system doesn’t provide such an ID (see Folding results). However, even if you do so, all three fields are still required to implement folding, that is, despite their redundancy, you can’t eliminate one. As a result, the
@parentidvalues are always identical.
The top parent item
@messageidvalue is the same as that in the
@parentidfor this item, as this item’s parent is the item itself.