Understanding 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 email conversations as a group of item in which the original message is the parent of each subsequent reply.

Search-ResultFolding

Similarly, blog posts could be expected to have the related comment 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.

Folding Fields

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 Understanding 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.

    Together, the following search results form an email 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.

    Search-ResultFoldingFields

    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”.

    The @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, i.e., 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, i.e., despite their redundancy, you can’t eliminate one. As a result, the @conversationid and the @parentid values are always identical.

    • The top parent item @messageid value is the same as that in the @parentid for this item, as this item’s parent is the item itself.

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.

Recommended Articles