Why VertiGIS Studio search breaks ID lookups, and what to do about it
Essentials ran one literal LIKE query. Studio tokenizes, ranks and caps. If your users search by permit or asset number, plan for a workflow on every app.
Search is the feature everyone labels “easy config” on a Geocortex Essentials to VertiGIS Studio migration. In our testing it is the feature most likely to need a workflow on every single app. Here is why, and what the options are.
What Essentials did
Essentials global search was simple. You opted one field per layer into search. Typing a value fired one query per searchable layer:
LOWER(ID_FIELD) LIKE '%value%'
Contains match, case-insensitive, one field. An ID like PRM-2041-XK returned exactly the records carrying that ID.
What Studio does instead
Studio Web search is a different engine with different defaults. Each of these surprised us, and each is confirmed against VertiGIS’s own community thread on how search works.
- It tokenizes the input.
PRM-2041-XKbecomes three terms. Records matching any term come back, ranked by relevance. The same lookup that returned 12 records in Essentials returned about 80 in Studio. - It searches every field on every included layer by default. Essentials made you opt one field in. Studio makes you opt everything else out. On an eight-layer app that is dozens of fields to switch off instead of eight to switch on.
- Max Results caps per source, and defaulted to 10 in our app. Counts silently truncate and look like a matching bug. Designer allows up to 200.
- Layers toggled invisible are not searched. A hidden-but-searchable layer, common in Essentials, is not possible.
- Date fields are not searched at all. Any date-range search has to be a workflow.
- Numeric fields need an exact match. No partial matching on a number typed as text.
- It does a geometry intersection by default and ranks records in the current extent higher. Results reorder as the user pans, and on large layers the intersection is a real performance cost.
The quoting workaround
Wrapping the term in double quotes forces a literal phrase match and gets the 12 records back. It is unforgiving, one wrong character returns nothing, and geocoder suggestions are auto-quoted when picked from the dropdown but not when the user presses Enter. It works for staff who can be told. It is not shippable to the public.
The real options
- Rebuild the search box as a workflow on the search event that does a literal query. VertiGIS staff recommend this on their own forum and several customers have done it. It is the option we quote.
- Drop the search box. If the app also has a search form that covers the same fields, the box may have no users. Ask before you build.
- License the separate Search product for indexed, type-ahead search. A licensing conversation, not a migration task.
What it means for your estimate
Multiply by the number of apps whose users search by an identifier. For most public-sector estates that is all of them. Budget the workflow once, template it, and clone it. And confirm what your search-by-field workflow does with an apostrophe in the input before you clone it. Ours inherited an unescaped quote bug straight from the Essentials module it replaced.