Customizing Seeker: Searching custom data

In a previous post, I covered some details on Seeker – our full-text search engine, along with its integration with applications, such as Dovetail Agent.

One of the other things I really like about Seeker is its extensibility. Via configuration, Seeker can easily be extended to search additional (including custom) fields (such as a custom field on the case or solution). Here we’ll cover that scenario.searcher

Modify the documentSpecifications.xml file

Seek.exe is the application that performs the actual indexing. The documentSpecifications.xml is the configuration file that seek.exe uses so that it knows what to index.

The documentSpecifications.xml file consists of many dovetailDocumentSpecifications. For example, there is a specification for case, one for subcase, one for solution, etc. The contents section determines what columns are searched.

For example, the baseline contents for the case object includes id_number, title, and case_history:


We can customize it, in order to add our custom column(an x_notes column on the case table):


So when a user performs a search, the x_notes field will be included in the search.

Custom Fields

We can also add a column as a customField, which will allow us to perform a specific search on that column.

<customField title="casetype">

This would allow users to perform a search such as:


These types of searches are typically used by your power users, or if you need to use this search criteria programmatically. For example, in a SelfService scenario, you can use a customField to limit the users to only view public solutions by programmatically adding "AND public:1" to the end of every search query. The Dovetail Seeker documentation has more details on Custom Fields.


Now that we’ve modified the documentSpecifications.xml file, we can run seek.exe, which will re-index the data.

The documentSelectionCriteria is used to tell seek.exe which objects to index. By default:

creation_time > ${lastIndexUpdate} OR modify_stmp > ${lastIndexUpdate}

This essentially means that any cases created or modified since the last time seek.exe was run will be indexed.

However, if we simply add new fields to the documentSpecifications.xml file, but the case hasn’t been modified, then it won’t get re-indexed.

We have two options to deal with this:

  • Delete all the indexes (including the case indexes, subcase indexes, solution indexes, etc.)
  • Modify the documentSelectionCriteria (just for cases) so that it re-indexes all of the cases.

Option 2 makes more sense, so lets go with that. We want all cases to be re-indexed, so this criteria will work: objid > 0

Its full XML syntax looks like:

<documentSelectionCriteria><![CDATA[objid > 0]]></documentSelectionCriteria>

Now, simply run seek.exe –index, and all of the cases will be re-indexed, and the the indexes will include our customizations (x_notes and casetype).

After this is completed, we can change the documentSelectionCriteria back to its default setting.


When users execute a search, not only are they searching the case id_number, title, and case_history – they’re also searching the x_notes column.


Also, users can now search directly on case type.

I have a case type of "Equipment Repair", so performing a search of "casetype:Repair" will give me all of those cases.



Rinse, Lather, Repeat

You can repeat this same process that we did with the x_notes column, and have Seeker index any of your custom columns.

And as we did with the case type, you can enable your power users to search on specific pieces of data.

Indexing and Searching Custom Objects

Its all well and good that we can extend the objects that are defined: case, subcase, solution, part request detail, and change requests. But Seeker can also index and search completely new custom objects. For example, if you have a custom widget table, and want to be able to search for widgets, Seeker can handle that. This takes us into a whole other blog post – hopefully I’ll get to that post soon.