Skip to main content
Mitratech Success Center

Indexing

Indexing

This page provides reference material on how TeamConnect works with Global Search indexing. For instructions on building indices, see Global Search Index Tool.

Many different fields are included in an object's index, but not all of the fields can be searched, even though they are indexed. However, some of these fields can be used to filter search results. For example, Boolean fields (checkboxes) cannot be searched, but you can use Boolean fields to filter results. TeamConnect does not have the option to add numbers as a filter display. 

Fields that are indexed but not searchable include:

  • Number fields
  • Boolean fields
  • Custom fields excluded from search

Notes:

  • Only custom Boolean fields appear in the search filter dropdown options
  • For information on configuring filter displays, see Global Search Filters.
  • The first time a custom filter display is added to an object, the filter display might not appear until the object's index is rebuilt. 

What happens with indexing when you extend a system object with custom fields?

When adding custom fields onto a system object, some objects are immediately ready to for searched (for example, Tasks and Contacts). Other objects require a manual re-index (ex: Appointments). For example:

  • Creating a task, the task is indexed, and then a custom field is added: all existing tasks are updated with the custom field and can be searched on immediately after the refresh interval, no manual re-index is necessary.
  • Adding a custom field to tasks, then creating a new task: all existing tasks are updated with the custom field, and the newly created task is indexed with the new custom field. All tasks and their custom fields can be searched on without re-indexing.
  • Creating an appointment, the appointment is indexed, and then a custom field is added: all appointments require a full re-index for the custom field to be searched on. Any new appointments created after the custom field is created cannot be searched on.
  • Adding a custom field to appointments, then creating a new appointment: all existing appointments must be re-indexed to search on the custom field, but can be searched on with their pre-existing searchable fields.

How did indexing change from TeamConnect 6.0 and TeamConnect 6.1?

Two main changes occurred between TeamConnect 6.0 and TeamConnect 6.1:

  • Using one index per object instead of one index for all objects
  • Using 2.x API Indexers for Elasticsearch indexing

One index per object

In TeamConnect 6.0 and earlier versions, all TeamConnect was stored in one index in Elasticsearch. To improve performance, facilitate upgrades, and allow users to search during re-indexing, TeamConnect 6.1 indices now have homogeneous types (object entityTypes) and one index per object, along with a STATUS index. 

In TeamConnect 6.0 and earlier versions, the "ElasticSearchUUID" system setting is stored in the database and the UUID value is the name of the index. The new TeamConnect 6.1 naming convention for the indices is in the format UUID-[uniqueCode for object]. For example, index name for Contacts will be <UUID>-cont. For this reason, existing clients must delete their index in the previous version of TeamConnect before upgrading, then rebuild the index after the upgrade. Existing clients with Search Guard must do the following when upgrading:

  • Since these configurations added the index name (the UUID from the database) added to their certificate on the node, update the certificate to include a wildcard after the UUID name.
  • In the SG_ROLES.YML file, the index names under each role refer to the ElasticsearchUUID from the database. At the end of each index name, add an asterisk at the end of the name, before the closing single quote.

For example, In TeamConnect 6.0 and earlier versions:

clipboard_ebc8bfe99192d7e21eb5967367a6bd972.png

In TeamConnect 6.1:

clipboard_e07ea0072d1927d66342b485132ddce8e.png

API Indexers

To improve the speed of indexing, TeamConnect 6.1 now uses 2.x objects rather than 3.x objects on all of the indexers for serialization. With 3.x objects, the LegacyBuilder classes loaded parts of the objects that are not needed for the indexer classes, resulting in excessive database access. Additionally, using 2.x objects eliminates the need for the recurring thread to convert the objects from 3.x. 

  • Was this article helpful?