About fields
About fields
A field is an index-wide data container that holds specific information about each individual item whose corresponding source mappings include rules to populate this field.
Each Coveo organization source automatically comes with a set of standard system fields populated from standard metadata. You can also create fields that are filled with the content or metadata of your choice when adding mappings for sources (see Add or edit a field). Fields can be leveraged in a search interface to optimize the global search experience.
|
Notes
|
Field origins
On the Fields (platform-ca | platform-eu | platform-au) page, the Origin column indicates the field provenance (Default or Other).
Default
Default fields are required by the Coveo index and apply to all sources. They’re automatically created on the Fields (platform-ca | platform-eu | platform-au) page and, for the most part, automatically filled by Coveo.
@title
, @author
, and @uri
.
See also About the SYS field name prefix.
Other
Other fields are either custom fields or standard source fields.
-
Custom fields are created by Coveo users through the Add a Field panel (see Add or edit a field). This feature makes it possible to customize how source metadata is handled or displayed.
-
Standard source fields are associated to certain sources only. When you create a source, the corresponding source-specific fields are automatically created on the Fields (platform-ca | platform-eu | platform-au) page.
Some standard source fields are prefixed so that they can easily be associated to the source connector to which they relate.
Notes-
Not all source connectors have a corresponding prefix for their specific fields.
-
Only fields that are only associated to a certain source have a corresponding prefix. Fields that can be associated to more than one source don’t have a prefix.
For example, fields exclusive to the RSS source have the prefix
rss
. However, an RSS source also fills the@objecttype
field, which is used by Microsoft Dynamics 365 sources as well.
Source connector Standard source field prefix s3
box
ec_
conf
None (user-defined field names)
gd
db
None
None (user-defined field names)
gmail
ji
andjive
cs
li
dy
None
rss
sf
sn
sp
andspo
sp
None
sitemap
None
None
yt
zendesk
ExampleSalesforce fields
@sfaccount
,@sfshippingstreet
, and@sfuser
. -
Field types
The possible field types are the following:
-
String
ExampleThe value of the
@department
field isSales
.NoteThe String type is also used for Boolean metadata.
For example, the value of the
@published
field istrue
. -
Integer 32
ExampleThe value of the
@rgbcolor
field is54,117,136
. -
Integer 64
ExampleThe value of the
@timesinceepoch
field is1517341713150
. -
Decimal
ExamplesThe value of the
@weight
field is5.25
. The value of thelength
field is3
. -
Date
ExampleThe value of the
@date
field is2018-01-30
. -
Example
The value of the
@personalizationdata
field is[0.235, 0.1234, 0.789, 0.765]
.
Field uses
You can leverage fields in several parts of Coveo.
-
Facets in a search result page are based on field values (see Using facets). Search page users can filter their search results by selecting only the desired values for a facet field.
-
You can configure your search page interface so that search results display certain field values. This provides additional information on the item to your search page users.
ExampleYour company uses Coveo to search for text documents. When configuring your search result template, you choose to display the
@source
and@author
field values. This makes it easier for your search page users to determine the item origin. -
You can configure your search interface so that it offers the option to sort search results based on the value of a certain field.
ExampleYour company uses Coveo to search for engine parts and maintenance manuals. When configuring your search page interface, you choose to offer the following sorting options to your users:
-
Sorting results by date the item was entered in your system (
@date
field) -
Sorting results by part weight (
@weight
field) -
Sorting results by file size (
@size
field)
-
-
You can configure your search page interface to implement result folding, i.e., so that some search results are displayed as child items of another search result (see About result folding and Folding results).
-
When you know the name of a field, you can make advanced field queries to retrieve items for which this field value matches your entry (see Advanced field queries).
Multi-value fields
A multi-value field is a field to which many string values are associated. Multi-value fields are also supported in facets (see Multi-value facet).
-
An item contains English text and its Spanish translation. The
@language
field values for this item are thereforeEnglish
andSpanish
. -
John Smith creates an item, and then his coworker Barbara Allen edits it. Both are therefore marked as authors of this document. The
@author
field values for this item are thereforeJohn Smith
andBarbara Allen
. -
John Smith sends an email to Barbara Allen, with a copy to Mary Davis and Lisa Brown. The
@to
field is therefore not a multi-value field in this case, but it could be. The@cc
field, however, is and containsMary Davis
andLisa Brown
as values.
|
Notes
|
Dynamic fields
A dynamic field is temporarily created by a query function. It contains a value resulting from the query function calculation. Dynamic fields aren’t listed on the Fields (platform-ca | platform-eu | platform-au) Administration Console page, since they only exist within the operations in which a query consists.
Geolocalized search results and discounted prices are typical examples of operations requiring a dynamic field (see Leverage geolocalization and the discounted price example).
Dictionary fields
A dictionary field lets you assign different values to that field depending on the context that’s sent when an end user performs a query. The most common use case is in commerce environments, when you have multiple store locations with varying prices.
|
Notes
|
Index dictionary fields
When indexing an item, to set a value for a dictionary field, pass an object with key-value pairs as metadata.
{
"data": "item data",
...
"myfield": {
"": "default",
"key1": "value1",
"key2": "value2"
},
...
}
This will index all the different values under myfield
on the item.
This field needs to already exist in your list of fields.
You can have multiple dictionary fields per item.
You can specify the default value for a dictionary field by using the empty string ""
as a key.
If you don’t specify a default value, and the context isn’t provided, the field won’t exist on the item.
|
Note
While this abstracts multiple values under one field, in the index, it will actually be creating one field per key, meaning that indexing a dictionary with thousands of keys will create thousands of fields. Although there’s no limit, going above a few hundred keys will cause negative performance impacts. |
Query dictionary fields
The Search API exposes the dictionaryFieldContext
query parameter that lets you send the desired key to be selected per field.
{
"dictionaryFieldContext": {
"myfield": "key1",
"myotherfield": "key2",
...
},
}
This lets you select a different key for every field. If no context is selected for a dictionary field, the default value will be returned, if one exists. If there’s no default value, the field will be undefined. You can’t select more than one key per field. Facets, ranking rules, and filters are all able to use this value as a regular field type.