Add or edit a field

This is for:

Developer System Administrator

Members with the required privileges can add and edit fields (see About fields).

  1. If not already in the Add/Edit a Field panel, access the panel:

    • To add a field, in the main menu, under Content, select Fields > Add Field.

      OR

    • To edit a field, in the main menu, under Content, select Fields > field row > Edit in the Action bar.

  2. When adding a new field, in the Field name box, enter a required descriptive name for the field. Note that it’s impossible to have two fields of the same name.

  3. When adding a new field, in the Type dropdown menu, select a field type.

    Notes

    • For a Boolean metadata, select a String type. The value will be either true or false.

    • The Type isn’t editable once the field has been added.

  4. (Optional) In the Description box, enter information such as the creation date of the field or the value (metadata) that you want to be populated for this field.

    Note

    The field Description isn’t editable once the field has been added.

  5. If you selected String in step 3, optionally select one or more of the following uses for your field:

    Note

    When editing a field, if you change the following parameters, you don’t need to rebuild the sources that use this field. However, you may observe a delay before your changes become effective in affected sources. The delay period depends on the size of your index.

    See String options.

  6. Optionally, click Advanced Settings, and then choose one or more options. See Advanced settings for option details.

    Notes

    • Some settings aren’t always editable, depending on the field origin. When editing Default fields, you can’t change the following settings: Search operator, Displayable in results, Free text search, Ranking, and Stemming.

      Moreover, some settings aren’t always editable, depending on the field type (see Available options per field type).

    • When editing a field, depending on the changes made in the Advanced settings section of the Add/Edit a Field [FieldName] panel, you may need to rebuild the affected sources for the changes to be effective.

  7. Click Add Field or Save.

String options

Facet

When you select the Facet option for a field, you can later add a facet based on this field in your search interface, therefore allowing its users to further filter their results by selecting or excluding field values (see Using facets). A facet field can also be used to identify a group of items to promote with a featured result rule (see Manage featured result rules).

Example

In your content metadata, the values of the @author field are author names such as John Smith, Mary Davis, Christopher Todd, etc. You select the Facet option so that you can put an Author facet in your search page. With such a facet, search interface users can narrow down their search results to only those authored by one of the selected people.

Author facet

By default, the Facet Generator option is enabled for facet and multi-facet fields. This lets the Facet Generator provide facets based on the input query and the content of your index.

Optionally, enter a name to display when a facet based on this field appears in your search interface. For example, if your field name is @sysauthor, you can enter Author as the display name. If you don’t enter a name, the facet will display the field name.

Notes

  • Numeric (Integer 32, Integer 64, and Decimal) and Date fields are facetable by default.

  • Enabling the Facet option on a String field increases the time it takes to index items that populate this field, and also requires additional index space and memory. Therefore, you should only select this option when required.

  • When changing the value of the Facet option for a field, you don’t need to rebuild the sources that use this field. However, you may observe a delay before your change becomes effective in affected sources.

Multi-value facet

You can select the Multi-value facet option as an alternative to the Facet option to indicate that a field may have several values. A facet based on a multi-value field looks and works similarly to a facet based on a regular field (see Using facets). Search results with more than one value for a facet field are kept on the search result page from the moment you select one of these values in the facet.

Example

You index items that may have been edited by several individuals. Their names are indexed in the @author field, so you check the Multi-value facet box for this field. In your search interface, when an end user selects names in the Author facet to refine their search results, the items with multiple authors are visible as long as one of their names is selected in the facet.

By default, the Facet Generator option is enabled for facet and multi-facet fields. This lets the Facet Generator provide facets based on the input query and the content of your index.

Optionally, enter a name to display when a facet based on this field appears in your search interface. For example, if your field name is @sysauthor, you can enter Author as the display name. If you don’t enter a name, the facet will display the field name.

If you don’t check the Multi-value facet box for a field with many values, Coveo interprets these values as a single one. It’s therefore impossible to use them as separate values in a facet, and they instead appear as a single option (for example, value1;value2;value3). Selecting this facet option filters out any item that doesn’t have exactly this set of values.

Note

When changing the value of the Multi-value facet option for a field, you don’t need to rebuild the sources that use this field. However, you may observe a delay before your change becomes effective in affected sources.

Sortable

Notes

  • Numeric (Integer 32, Integer 64, and Decimal) and Date fields are sortable by default.

  • Select only when you use this field to sort results with a sort component in a search interface since adding sorting fields can have an impact on index size and indexing performance.

  • When changing the value of the Sortable option for a field, you don’t need to rebuild the sources that use this field. However, you may observe a delay before your change becomes effective in affected sources.

Advanced settings

The following table lists the available options depending on the field type and sometimes the field use.

Option or field type String Integer 32 Integer 64 Decimal Date Vector
Search operator check check check check check check
Displayable in results check check check check check check
Free text search check
Ranking check
Stemming check
Use cache for sort check check check check
Use cache for computed fields check check check check check
Use cache for nested queries check check check check check
Use cache for numeric queries check check check check check

Search operator

If the Search operator box is cleared, the index ignores all field operations based on that field, including field queries (for example, @date=today). This means that even components code-generated field expression produced by facets, tabs, etc. can’t leverage that field.

Notes

  • Selected by default since there’s also no meaningful cost to select this option for all fields.

  • Changing the value of the Search operator option requires a rebuild of all the sources using this field for the change to be effective.

Displayable in results

If the Displayable in results box is cleared, the index never includes the field in query results, which implies that you can’t leverage the field in the result templates of any of your search interfaces (including the Content Browser).

Notes

  • Selecting this option for all fields takes minimal disk space.

  • Changing the value of the Displayable in results option requires a rebuild of all the sources using this field for the change to be effective.

Free text search

Check the Free text search box when you want the content of the field to be queried using free text. This option isn’t selected by default and is available only if the field type is String.

Essentially, when you enable this option, the field gets "merged" with the body of each item it has a value for in the index.

Tip
Leading practice

This implies that the item body size increases with the size of its free text searchable fields. With fields that contain a lot of text, this could have a performance impact. Therefore, you should only enable the Free text search option when necessary.

Let’s say you have an item whose body is A tasty, sweet, rather sticky liquid made from the sap of a tree that grows in North America." and whose free text search enabled @productname field value is maple syrup. Submitting maple, syrup, maple syrup (or any stemming or permutation of these two keywords) in the search box would match the item instead of having to search for @productname=="maple syrup".

Example

If free text search is allowed on @author, items returned when querying @author=John are also returned when querying John; however, the query John also returns items containing the word John in their content, not only in the author field).

Note

Changing the value of the Free text search option requires a rebuild of all the sources using this field for the change to be effective.

Ranking

Check the Ranking box when you want the field to be used in the standard ranking score calculation. This option isn’t selected by default since the option has a significant impact on query performance.

Example

If ranking is enabled for the product field, when a customer searches for "Product A" and some search results have Product A as a value of this field, these results would be ranked higher.

Note

Changing the value of the Ranking option requires a rebuild of all the sources using this field for the change to be effective.

Stemming

Check the Stemming box to allow stemming on field queries. This option isn’t selected by default since the option has a significant impact on query performance.

Example

The words search, searching, and searched share the same root or stem: search-. When a user queries searching in item titles (@title=searching), Coveo returns items with a title containing the words searching, search, searches, and searched.

Note

Changing the value of the Stemming option requires a rebuild of all the sources using this field for the change to be effective.

Use cache for sort

Check the Use cache for sort box when you want to keep the entire field in memory for fast sorting.

Notes

  • Fields that are configured for sorting and are often used should be kept in memory.

  • When changing the value of the Use cache for sort option for a field, you don’t need to rebuild the sources that use this field. However, you may observe a delay before your change becomes effective in affected sources.

Use cache for computed fields

Check the Use cache for computed fields box when you want to keep data in memory for computed fields. The following two use cases require the option to be selected:

Notes

  • If not selected in these scenarios, queries related to these fields might take over a second to return results, depending on your number of items.

  • When changing the value of the Use cache for computed fields option for a field, you don’t need to rebuild the sources that use this field. However, you may observe a delay before your change becomes effective in affected sources.

  • Calculated facet

    Example

    You calculate the average of the size field value to populate the field author, which is used as a facet field. The size field must therefore use the cache.

  • Query function expression that references a field

    Example

    The following query function requires the filesizekb field to use the cache: function:"@syssize/1024" : fieldName:"@filesizekb".

Use cache for nested queries

Check the Use cache for nested queries box when you want to keep in memory the data required to perform nested queries.

Notes

Use cache for numeric queries

Check the Use cache for numeric queries box when you want to keep the proper information in memory to execute operations on numerical fields, including operations on dates.

Notes

  • This option also makes the calculations related to numerical range facets faster. Therefore, using the cache significantly improves the performance to automatically generate the interval values in numerical range facets and to dynamically update those values based on the content returned by the index following a user query.

  • Using the cache for numeric queries allows to use numerical fields as facets, specify the number of ranges, and let the Coveo index establish the ranges.

  • Executing a query on a numerical field, especially a query that covers the entire range, impacts the query performance if the field doesn’t use the cache.

  • If your numerical field is stored as a String, you must change its type.

  • When changing the value of the Use cache for numeric queries option for a field, you don’t need to rebuild the sources that use this field. However, you may observe a delay before your change becomes effective in affected sources.

What’s next?