Most of the day is spent finding a record rather than editing one. Search is built for that, and it is scoped to the project you are in.
Two ways to reach something
The search box looks across item groups, items, products and models in the current project. It matches on the name only, so type a fragment of the name rather than a code.
Typing several words narrows rather than widens: every word has to appear in the name, in any order. “oak chair” finds Chair, oak and Oak dining chair, and not a chair in walnut.
Autocomplete inside a form is the same lookup, narrowed to whatever that field accepts. A relation field only offers its target group; a product field only offers products.
| # | Name | Price | |
|---|---|---|---|
| 412 | Wooden leg, oak | 40.00 | Edit |
| 418 | Oak tapered leg | 60.00 | Edit |
Results are paginated
Long lists load as you scroll rather than all at once, so a group with thousands of items stays usable. Keep typing to narrow instead of scrolling to find.
What to reuse
Troubleshooting
I cannot find an item I know exists
Check which project you are in. Search never crosses projects, which is deliberate, two clients’ catalogues should never be one search away from each other.
Searching a code returns nothing
Search matches names, and a code usually lives in a field instead. Search for a fragment of the name, then filter within the group on the field that holds the code.
If your team searches by code often, put the code in the name as well, for example Chair, oak (CH-1042). From then on both work.
