Searching Tips & Tricks

Overview

This article gives you tips for searching effectively in StoreFeeder, covering Search Everywhere, grid filtering, wildcard usage, and what to do when searches are slow.

Search Everywhere

Search Everywhere enables lightning-fast searching when you are looking for a specific order, product, page, or support article. It is handy when a customer calls in and gives you their order number, email address, or postcode. Simply enter the search term and select the matching result to go directly to the correct page in StoreFeeder. It also works with help articles.

Use Search Everywhere as your primary method when you know exactly what you are looking for and expect only a small number of results.

At the time of writing, listing information is not indexed in Search Everywhere, but additional data types are being added over time.

Grid filtering and searching

When you need broader data — for example, all orders from a specific country, or all products with fewer than 10 units in stock — use the filters on the grids. These are best for getting a list of many records or for exporting data.

Because grid searches can cover a large dataset, be as specific as possible. Limiting order searches by channel or product searches by supplier can significantly improve speed.

You can also save filter sets so that frequently used combinations can be applied with a single click. This is useful for recurring reports such as month-end order data, where you only need to update the dates.

See the Saving Grid Filters article for more details.

When (not) to use wildcards

Wildcard searching (using *) is powerful but must be used carefully. In the wrong situation it can severely affect search speed and efficiency.

Example — inefficient:

Entering *smith* (double wildcard) searches every record in the database for surnames containing "smith". This returns "Smith", "Smithy", "Blacksmith", and so on. This is very inefficient and will likely lead to timeouts. Avoid multiple asterisks unless absolutely necessary.

Example — better:

Entering Smith* limits the search to surnames that begin with "Smith", which is far more efficient. A good use case for a leading wildcard is SKUs with a shared prefix followed by size information — for example, MyProd* returns:

• MyProd-Sml
• MyProd-Med
• MyProd-Lrg

Wherever possible, limit your search further by filtering additional columns such as Supplier or Warehouse.

Example — also inefficient:

Entering *smith (trailing wildcard) again forces a full-table scan and should be avoided unless necessary.

Finally, never combine double wildcards across multiple fields. A forename of *Jo* combined with a surname of *Smith* will almost certainly time out due to the volume of data that must be scanned.

Slow searches and timeouts

If searches for specific information are taking too long or failing, the system may need optimisation. Contact the support team and provide as much information as possible:

• The page you were on
• The filters and values you used (text is more helpful than screenshots, as it can be copied directly)
• Whether the issue affects multiple users
• Any error messages displayed
• Any other relevant details

The more information you provide, the faster the team can identify and resolve the issue.