AricieGrid Advanced Filtering for Power Users

AricieGrid gives DotNetNuke portals a practical way to display, sort and interrogate business data without forcing users into separate reporting tools. Its filtering features become especially valuable when a grid contains customer records, property assets, budgets or operational transactions.

This tutorial focuses on advanced filtering techniques: selecting the right column types, combining conditions, handling dates, preserving useful views and keeping results responsive. The examples suit Australian teams working across offices in Sydney, Melbourne, Brisbane or regional locations.

Understand The Filtering Model

A filter is a rule applied to one grid column. Typical operators include equals, does not equal, contains, starts with, greater than, less than and is empty. The available operators usually depend on the underlying data type, so a date column should be filtered as a date rather than as ordinary text.

Power users should first separate display decisions from data decisions. Hiding an irrelevant column makes a grid easier to read, but it does not necessarily remove that field from filtering or exporting. Apply filters to the actual business requirement, such as “active properties in Queensland” or “invoices issued after 1 July”.

When a label is unclear, inspect the column configuration and sample values before building a complex rule. Inconsistent values such as “NSW”, “New South Wales” and “N.S.W.” can produce incomplete results even when the filter itself is correct.

Prepare Columns For Reliable Results

Strong filtering begins with clean source data. Use numeric fields for amounts, dates for due dates, Boolean values for active status and controlled lists for categories. A column containing $1,250 as formatted text may sort and filter differently from a numeric value of 1250.

Dates deserve particular care. Australian users commonly read dates as day/month/year, while databases and APIs may store them in another format. Confirm whether a filter is interpreted using the browser locale, server culture or an ISO-style value such as 2025-07-01.

For financial or property data, keep the raw value separate from its display format. For example, an internal rent field can remain numeric while a presentation column shows currency. This makes range filtering dependable and avoids errors caused by commas, dollar signs or currency symbols.

Combine Conditions With Precision

Simple filters work well for a single criterion, but advanced searches usually require grouped logic. An AND relationship narrows a result set, such as “status is Active” and “region is Victoria”. An OR relationship broadens it, such as “region is NSW” or “region is Queensland”.

Use parentheses or filter groups where the interface supports them. The intended logic for “active properties in Melbourne or Brisbane” is:

Active = Yes AND (City = Melbourne OR City = Brisbane)

Without grouping, the system may interpret the expression in an unintended order and return inactive properties from one of those cities. Build the filter one clause at a time, checking the row count after each addition.

Text searches also benefit from deliberate operator choice. “Contains” is useful for partial names, while “equals” is safer for codes, postcodes, ABNs or status values. For long lists of permitted values, use an in-list or multi-select operator if the installed AricieGrid version provides one.

Choose The Right Filtering Strategy

The most efficient option depends on the field, dataset and user task. The following comparison helps power users choose an appropriate approach before creating a saved view.

Filtering approach	Best used for	Common risk	Practical control
Exact match	Statuses, codes and IDs	Misses inconsistent spelling	Standardise source values
Contains text	Names, descriptions and suburbs	Returns unrelated matches	Add a second condition
Numeric range	Budgets, prices and quantities	Formatted text behaves poorly	Store values as numbers
Date range	Deadlines and reporting periods	Locale confusion	Verify date format and timezone
AND group	Narrow operational queues	Results become too narrow	Review each clause
OR group	Multiple regions or categories	Results become too broad	Group conditions explicitly

A useful workflow is to begin with the most selective condition, then add secondary criteria. Filtering a property register by a unique portfolio or financial year first can reduce the working set before applying suburb, manager or status rules.

If the grid supports server-side filtering, use it for large datasets. The server can return only matching records instead of loading every row into the browser. For smaller lists, client-side filtering may feel faster because results update immediately without a request.

Save Views And Share Results

A carefully designed filtered view can become a repeatable operational tool. Save views for tasks such as overdue invoices, vacant properties, unassigned service requests or contracts approaching renewal. Give each view a precise name that states both the subject and the period.

Check whether a saved view stores filters, visible columns, sorting and page size. Some configurations preserve only the filter expression. If users need the same layout, save the column arrangement separately or document the expected display settings.

For teams sharing a portal across Australia, confirm permissions before distributing a view. A finance filter may expose sensitive information, and a property view may contain personal details. The Privacy Act 1988 and Australian Privacy Principles make access control and responsible data handling important parts of grid administration.

When validating a deployment checklist alongside technical reference material, record the filter logic, source fields and expected row count. This gives administrators a repeatable way to test changes after a DotNetNuke upgrade or data import.

Power User Checklist

Before publishing an advanced filter, verify the data and logic rather than relying on the visual result alone.

• Confirm column types and date interpretation
• Test blank, null and zero values separately
• Compare the result count with a known sample
• Check permissions before sharing the view

Use a second pass to test how the grid behaves for everyday Australian workflows, including mobile access and regional data.

• Test suburb, postcode and state variations
• Check financial values against GST-inclusive records
• Validate filters during AEST and daylight-saving periods
• Export a small result set for reconciliation

Improve Performance And Troubleshooting

Slow filtering often comes from large unindexed datasets, broad text searches or too many records loaded into the browser. Reduce the initial result set with required fields such as financial year, organisation or active status. Avoid leading-wildcard searches across lengthy descriptions when an exact category field is available.

If a filter returns no rows, remove conditions from right to left until results reappear. This identifies the restrictive clause. If too many rows appear, inspect OR groups, whitespace, capitalisation and duplicate source values. A visible “Active” label may hide trailing spaces or different database codes.

Australian organisations may also need to reconcile GST treatment, ABNs and local reporting periods. Treat these as separate fields rather than embedding several meanings in one text column. A clean data model makes AricieGrid filtering easier to maintain and audit.

Deploy With Confidence

Advanced filtering is most effective when it reflects a consistent data model, clear business rules and controlled access. Start with reliable column types, build grouped conditions carefully, and save views only after testing realistic records and edge cases.

Create one production-ready AricieGrid view for a priority workflow, document its criteria and validate it with the relevant business team. Then extend the same method to financial, property or service datasets across your Australian operations.