StoreBuilt’s review of Shopify’s current search and filtering guidance shows why an old screenshot is a poor foundation for an operating process. Some admin lists now use a combined search bar and view menu, while others retain tabs. We start with the work the team needs to find, then check how that particular resource list supports the required filters and display settings.
Shopify saved views can make recurring admin work easier to locate. Their usefulness depends on what they include, what they exclude and whether a colleague understands the result. This guide covers practical view design for UK ecommerce teams, from an order exception list to a product preparation queue. The examples are suggested operating patterns, not prebuilt Shopify automations.
In this guide
- Give each view one job
- Build from filters you can explain
- Make inclusion and exclusion explicit
- Test a view with known records
- Select columns for the next decision
- An illustrative morning dispatch review
- Treat bulk actions as a separate decision
- Maintain the definition as the business changes
- StoreBuilt point of view
Give each view one job
Describe the decision the view supports in a single sentence. “Find unpaid orders that need finance review” is clearer than “important orders”. The first description tells the team why a record belongs; the second depends on personal judgement that the filters cannot reliably reproduce.
Choose a resource list that matches the work. An order question belongs with orders, whereas an incomplete product launch belongs with products. A view cannot solve a mismatch between the question and the available fields. If the required fact lives only in a support conversation or warehouse system, define how it will be represented before trying to filter for it.
Keep the initial set small. A dozen overlapping views can make staff slower because they must decide which list to trust. Start with a few recurring tasks, assign an owner to each definition and retire views that no longer support a real decision. The goal is less searching, not a larger collection of saved configurations.
Build from filters you can explain
Shopify’s views documentation describes both enhanced and tabbed experiences. In the enhanced experience, the view menu sits with search and filters. Create or save the configuration using the controls available on that list; do not assume a tutorial showing separate tabs matches your current screen.
Apply one condition at a time and inspect the result after each addition. Begin with a broad list, then narrow it using the fields that actually define the task. If the count changes unexpectedly, investigate immediately instead of continuing to add filters until the list merely looks plausible.
Use the visible filter controls where possible, particularly while the team is learning the supported values. A copied search string can contain a subtle mistake or a field inappropriate to the resource. Keep a plain-English definition alongside any more technical expression so the business owner can review the logic without understanding search syntax.
Make inclusion and exclusion explicit
A filter that includes two alternative statuses is different from one requiring two conditions simultaneously. Shopify’s enhanced filtering supports logical combinations, but the important operating question is whether the resulting list matches the intended set. Test the boundaries with records whose expected treatment is already known.
| View purpose | Intended inclusion | Deliberate exclusion |
|---|---|---|
| Payment review | Orders matching the chosen unpaid states | Fully paid orders outside the review |
| Dispatch check | Orders with the agreed fulfilment conditions | Completed work with no remaining action |
| Product preparation | Products in the selected preparation state | Released products outside that workflow |
| Supplier range review | Products belonging to a defined vendor | Similarly named items from other vendors |
| Campaign follow-up | Records matching the documented campaign marker | Unrelated records with similar wording |
These are design examples, not instructions to assume every field exists on every list. Confirm the available filters and their meaning in your store. Where a tag is part of the rule, its maintenance process must be reliable. Our order tag governance guide explains that separate dependency.
Test a view with known records
Choose at least one record that should appear and one that should not. Add an edge case that could expose ambiguity, such as a partially completed order or a product with a similar vendor name. Compare the expected membership with the actual result before sharing the view as part of a team process.
An empty result is not automatically a success. It could mean there is no work, or it could mean the conditions contradict each other. Open a known matching record separately and verify its current fields. This is especially useful after a status change, an integration update or a revised tag convention.
Test what happens when a record leaves the workflow. If a completed item remains on the list because a marker is never cleared, colleagues may investigate the same work repeatedly. The view’s entry and exit conditions should make sense together. A reliable queue depends on the underlying records being maintained, not simply on saving a clever filter.
Select columns for the next decision
Where column customisation is supported, show the information needed to act without opening every record. Prioritise identifiers, status and the field that determines urgency. Avoid displaying every available column merely because the screen allows it. Excess detail makes the list harder to scan, particularly on smaller displays.
Choose a sort order that matches the task. The newest records may be useful for checking a launch, while the oldest unresolved work may matter more for a backlog review. Explain that choice in the view definition so a colleague does not reverse it and unintentionally change the team’s priority order.
Shopify’s documentation notes that view management is performed on desktop, although views can be accessed on mobile. Test the display on the devices staff actually use. A configuration that works on a wide monitor may require opening individual records on a phone; the operating instructions should acknowledge that difference.
An illustrative morning dispatch review
Imagine a small UK accessories retailer checking orders before the courier collection. Two colleagues use slightly different filters, so one sees orders the other believes have already left the queue. This is an illustrative scenario, not a reported client result. The disagreement is about list membership rather than staff effort.
The team writes down the purpose of the review and identifies which fulfilment states genuinely require attention. They select a few known orders, including a partially completed one, and compare the view with the warehouse’s current position. Any external information is checked in its owning system rather than inferred from an order label.
The saved view becomes a consistent starting point for the conversation. It does not reserve work, notify a colleague or stop dispatch by itself. The team still needs a separate assignment and acknowledgement process. This boundary prevents a helpful filter from being mistaken for a complete workflow system.
Treat bulk actions as a separate decision
A saved view can make bulk selection convenient, but membership is not approval to change every record. Before a bulk action, check the selected scope and sample the records again. A dynamic list may include newly matching items that were not present during yesterday’s review.
For consequential changes, state the intended outcome before acting. “These products should receive the approved launch tag” is testable. “Clean up the view” is not. Preserve enough evidence to explain what was selected and why, and use the store’s established review process for changes affecting customers or stock.
Avoid using a broad saved view as a shortcut around individual exceptions. A few unusual records may require separate handling. If the team repeatedly excludes the same category by hand, revise the view definition or create a clearly named exception path rather than relying on memory.
Maintain the definition as the business changes
Views should have owners in the operating documentation, even when the platform does not assign that responsibility. The owner reviews changes to filters, underlying conventions and the task itself. A warehouse move, new payment process or seasonal campaign can make a previously sensible view misleading.
| Review question | Useful evidence | Action when unclear |
|---|---|---|
| Does the name describe the task? | A colleague can explain its purpose | Rename and document |
| Are matching records correct? | Known positive and negative examples | Adjust conditions |
| Can work leave the queue? | Completed examples disappear appropriately | Fix exit conditions |
| Is the display usable? | Staff can find the next action | Reduce or reorder columns |
| Is the view still needed? | A recurring decision uses it | Retire redundant views |
Record a brief change note when the definition changes materially. Teams need to know why a count has moved before interpreting it as a business trend. A saved view is a working lens on current records, not necessarily a stable historical KPI. Use a defined reporting process when you need comparable performance measures over time.
StoreBuilt point of view
The best saved view has a clear purpose, tested boundaries and a person responsible for keeping it useful. Start with the decision and build the filter around it. If teams are compensating for missing integration data or unclear responsibilities, StoreBuilt’s Shopify implementation services can help address the underlying workflow.