Enterprise Search

Introduction

Socotra Connected Core Enterprise Search brings performant, configurable discovery to your book of business.

Feature Summary

• Configurable indexing: you get to decide what entity fields are searchable

• “Fuzzy” and “starts with” matching on strings

• Advanced search syntax for inclusion, exclusion, and specific field matching

• Extensive set of returnable entities

• Optional “search summaries” that allow you to specify additional data that should be included in search record results

• Public API endpoint for conducting searches and fetching results programmatically

• New “Advanced Search” page in Core UI

Returnable Entities

Enterprise Search can return results referring to the following record types:

• Policyholder

• Policy

• Claim

• Payment

• Quote

• Premium Report

Subclaim matches are returned in a Claim result.

Returnable entities act as an umbrella for matches on sub-component data. For example, if you search for a data field value, and there is a match on a peril on some policy, the policy will be returned as the search result entity.

Configuration

Important

Avoid recreate deployments for Enterprise Search sandbox tenants. recreate deployments will halt Enterprise Search indexing for that tenant until Socotra staff reconnect the tenant to the indexing service. If recreate is required, please inform your Socotra representative so that we can minimize the time between deployment and Enterprise Search availability.

Data Field Configuration

Each of the entities in enterprise search scope - policyholder, policy/quote, claim, subclaim, premium report, and payment - may have custom data fields defined in your tenant config. With enterprise search, you may add a new search property to those fields to indicate that the field should be indexed for searchability.

Important

By default, Enterprise Search only indexes locators, so configuring fields for indexing will broaden the pool of potential matches and enable the “specific field” search syntax feature (see Search Syntax below).

The application inspects index configuration on every deployment, re-indexing as needed to align with your current search specification.

Search Field Configuration Example

Configuration using JSON

Given a policyholder field set definition (policyholder.dictionary.json) like this:

[
  {
  "name": "first_name",
  "type": "string"
  },
  {
  "name": "last_name",
  "type": "string"
  }
]

You can ensure that both first and last name are searchable with the following additions:

[
  {
   "name": "first_name",
   "type": "string",
   "search": "text"
  },
  {
   "name": "last_name",
   "type": "string",
   "search": "text"
  }
]

The search property may be added to string, email, or select fields in configuration for policyholder, policy, claim, subclaim, premium report, and payment entities. The value should be text, regardless of field type. To remove a field from indexing, simply remove the search property or set the search value to none.

Configuration using Config Studio

You may also specify field indexing in Config Studio. Checking “Searchable” for a field in Config Studio maps to "search": "text" in the underlying config.json.

Search Field Configuration Limitations:

• The field must be of type string, email, or select.

• For tenants with product versioning enabled, the complete indexing specification is drawn exclusively from the latest configuration deployment, ignoring search configuration in any prior config versions.

Search Summaries

To obtain basic human-readable information about individual search results without subsequent locator-based API fetches, you may configure a searchSummary for any of the returnable entities. A searchSummary is a configurable list of the entity’s custom field names whose values should be returned in the SearchResultResponse.

All returnable entities, with the exception of policyholders, have default entries in their search summary result sets:

• Policy, Quote

  • policyStartTimestamp corresponding to policy-level originalContractStartTimestamp

  • policyEndTimestamp corresponding to policy-level effectiveContractEndTimestamp

  • productName

  • state (quotes only: indicates the quote lifecycle state)

  • name (quotes only: indicates quote name)

• Claim, Subclaim

  • currentStatus

  • notificationTimestamp

  • incidentTimestamp

  • createdTimestamp

  • productName

• Payment

  • amount

  • currency

  • invoiceLocator

  • invoiceDisplayId

• Premium Report

  • startTimestamp

  • endTimestamp

  • reportName

Any additional fields referenced in the searchSummary configuration will appear after these default items.

Policyholders

The searchSummary for policyholders is configured in a new, optional configuration file: policyholder/policyholder.json.

{
 "searchSummary": [string]
}

Each string entry in the searchSummary list should correspond to the name of a custom field value defined in policyholder.dictionary.json.

All Other Returnable Entities

For all returnable entities other than policyholders, you may define the searchSummary as a peer of the fields field configuration for that entity. Here is a simple example of a searchSummary for policies, in /products/<product-name>/policy/policy.json:

{
  "fields": [
    {
      "name": "channel",
      "title": "Sales Channel",
      "width": 3,
      "type": "select",
      "values": [
        "Direct",
        "Agent",
        "Broker"
      ]
    }
  ],
  "searchSummary": [
    "channel"
  ]
}

Additional Notes

• Search summaries can only be specified at the top configuration level for the entity. searchSummary specifications on exposure or peril configurations will have no effect.

• Search summaries do not support field groups.

• Search summaries can refer to fields that are not indexed for search.

• If search summary configuration refers to a non-existent custom field, no entry for that field will be returned as part of the search result.

Core UI

Enterprise search retains and extends the familiar UI search elements in Core UI. When Enterprise Search is enabled,

• All searches from the search bar will use the enterprise search API endpoint.

• The results dialog box will have a link to the “Advanced Search” page.

• The “Advanced Search” page will allow convenient filtering and pagination via infinite scroll.

Search Result Cards

Each returnable entity has a fixed template for result cards shown in the UI, with information drawn from the SearchResultResponse or the default SearchSummaryItemResponse elements. These templates follow conventions established in the original Core UI search feature.

Policyholders are the exception: the policyholder result card will show the concatenated values of the first three searchSummary elements specified in policyholder/policyholder.json. This allows you to specify first and last names, or any other custom field values you deem most distinguishing among policyholder results.

Search Syntax

A search request consists of an array of search terms, which can be expressed as a “search string” (see SearchRequest documentation).

Search string syntax provides the ability to write search terms as a single string that can be expressed in a typical search form box.

A search string follows these rules:

• A sequence one or more searchTerm strings, separated by whitespace

• Each searchTerm string has the following form:

  • Form: [+|-][fieldName:]string[*]

    • The fieldName slug determines whether the match should be against a specific field name or any field.

    • Term relevance scoring:

      • If the term is prefixed with a +, the term is required for search result relevance.

      • If the term is prefixed with a -, the term must be excluded for search result relevance.

      • Absence of + or - before a term is interpreted as a suggestion: the presence of the term increases the relevance score, but does not require that the term be present or absent from a match candidate.

  • The default match behavior is fuzzy

    • Appending * to the term sets matching to startsWith.

    • Enclosing the term in double quotes sets matching to exact. Searches with spaces cannot be fuzzy searches.

Note

“Fuzzy” search is the default behavior when you provide a search string. In some cases, such as searching for exact identifiers, this can yield counterintuitive results in which the “exact” match record appears later in the search result list than an apparently less-relevant item. The extent to which this behavior arises is dependent on several factors, including the set of fields indexed for search and how similar those values are to each other and to the search string.

Two features can improve search result relevance in such situations: using exact match search syntax (i.e., wrapping terms in quotes), and/or leveraging product and policy filtering on the Advanced Search page.

Search String Examples

Search Intent	Search String
Search all fields for red	red
Search all fields for red	+red
Search all fields for excluding red	-red
Search all fields for red or green	red green
Search all fields for red and green	+red +green
Search all fields for (red or green) and blue	red green +blue
Search all fields for exact match “dark red” and green	"dark red" +green
Search “door” field for exact match “dark red” and all fields for green	door:"dark red" +green
Search all fields for dark or red or exact match blue	dark red "blue"
Search all fields for exact match “dark red” or exact match “dark green”	"dark red" "dark green"
Search “door” for red or “hood” for green	door:red hood:green
Search “front door” field for “dark red” and field “hood” that starts with “blue”	"front door": "dark red" +hood:blue*