Bulk search by multiple serial numbers

Allow multiple serial numbers to be entered/pasted into the search field (e.g. semi-colon separated), returning a combined result list. From there, the customer should be able to select all (or a subset) and apply bulk actions such as changing location.

Why this matters:
The equipment isn’t unique on any other searchable property (location, brand, type, etc.), serial number is the only attribute that distinguishes it. Because of this, the customer has no way to isolate and bulk-edit this specific set of equipment through normal search.

This is especially important when sorting large orders. The customer often receives equipment in batches that share the same properties (brand, type, etc.), but which need to be split across different locations. Right now, they have to search up and handle each item one by one, which is time-consuming for large orders.

100% support this feature, with one minor caveat: comma separation may trigger some unwanted search results, as period and comma are direct punctuation which personnel may use by mistake when making serial numbers. “123456.07” and “123456,07” are unintended variations on the same serial number naming convention that is often used for series of custom produced lifting equipment like steel ropes. However, the use of semi-colon ; is also widely accepted as a divider in many systems, including Excel, which is a system used by almost 800 million users world wide, and is also one of the two standards in .csv file structure, supported by Onix.

1 Like

Hi @julie.nymo, thank you for sharing this idea. To help us understand the need better, could you clarify what is missing from the current functionality?

In Onix Work, customers can filter equipment by Order no. or another shared field or property. They can also create custom views with default filters. Are there any use cases where these filtering options do not fully meet the need?

Thanks for the quick follow-up!

To clarify, this isn’t about filtering or sorting by a shared field/property. The use case is specifically about searching on a list of serial numbers (often x amount, copied directly from an Excel sheet) and getting back an equipment list containing only those exact items.

Filtering by Order no. or another shared property doesn’t cover this, because in many of these cases the equipment doesn’t share any common property to filter on (same order, same location, same brand, etc.). Serial number is the only thing tying the list together. Custom views with default filters have the same limitation, since they rely on a shared attribute existing in the first place.

So the missing functionality is more like a multi-value search: paste/enter a list of serial numbers → Onix returns only the matching equipment in the equipment list → user can then select all and perform bulk actions (e.g. change location).

Let me know if it’d help to walk through a concrete customer example.

1 Like

Hi Julie,

Thank you for the product idea.

We have another feature planned that could help the customer achieve the same result. This feature will allow customers to select an item, perform a new search, select another item, and continue this process as needed.

While it won’t allow customers to search for all items at once, it will provide more flexibility, especially in cases where they need to apply different filters to find specific items.

Do you think this would fulfill the customer’s need?

Thanks for the answer Nabil!
For this specific customer need it won’t fully fulfill the request, to be honest. They typically need to look up a list of around 50–100 pieces of equipment at once (usually pasted in from an Excel export), and selecting items one search at a time wouldn’t be practical at that volume.

From the customer’s perspective, this is likely to feel insufficient, because it does not solve the underlying efficiency problem they are trying to address.

In short, the customer is not asking for more flexibility in selecting individual items, they are asking for a way to identify and handle all matching items in one go. Without that, I believe they would see this as only a partial workaround rather than a satisfactory solution.

That said, it would still be a better workaround than what’s available today, so it’s a welcome improvement :smiley:

Thank you for the feedback, Julie.
We see the need that you’re describing, so I’ll open up this product idea to see if other customers have the same need :slight_smile:

1 Like