I've discovered a significant gap in how Zoho Creator handles Custom Filters for reports, and I'm hoping the Zoho team can address this in a future update. This limitation has been
raised before and
continues to be requested, but remains unresolved.
The Issue
According to the
official documentation, Custom Filters allow developers to create predefined filter combinations that users can select from a dropdown menu. This is a powerful feature for simplifying complex filtering scenarios for end users.
However, there is no way to set a default Custom Filter that automatically applies when a report loads, nor can Custom Filters be applied via URL parameters or Deluge scripts.
Example Use Case
Consider a simple Clients Report with Custom Filters for "Active Clients" and "Inactive Clients".
Desired behavior:
- Report loads with "Active Clients" filter pre-applied by default
- Users can remove the filter to see all clients
- Users can switch to "Inactive Clients" filter when needed
Current reality: The report always loads unfiltered, showing ALL clients. Users must manually select the "Active Clients" filter every single time they access the report—there's no way to set it as the default.
The Problem
Zoho Creator provides excellent support for field-based filtering via
functionality-based URLs—including operators like EQUALS, CONTAINS, BETWEEN, date ranges, and more. However, Custom Filters exist in complete isolation from all programmatic control.
| Capability |
Field-Based URL Filtering |
Custom Filters |
| User can manually apply |
✓ Yes |
✓ Yes |
| Apply via URL parameter |
✓ Yes
?FieldName=value |
✗ No |
| Use operators (CONTAINS, BETWEEN, etc.) |
✓ Yes
&FieldName_op=26 |
✗ N/A |
| Set as default on report load |
✓ Yes (Report Criteria) |
✗ No |
| Apply via openUrl in Deluge |
✓ Yes |
✗ No |
| Pre-select on embedded reports |
✓ Yes |
✗ No |
"Hard" vs. "Soft" Filtering — The UX Problem
This limitation creates a fundamental UX trade-off that developers shouldn't have to make:
| Approach |
Behavior |
User Experience |
Report Criteria
(Hard Filter) |
Permanently applied. Cannot be removed or changed by the user. |
Users are locked in. They cannot explore beyond the predefined criteria. |
Custom Filter
(Soft Filter) |
User-selectable. Can be applied, changed, or removed at will. |
Users start with a focused view but can remove it to see the bigger picture. |
The problem: We are forced to use "Hard Filters" (Report Criteria) when the use case actually requires "Soft Filters" (a sensible default that users can adjust). This hurts the end-user's ability to explore data.
The "AND Logic Trap" with Pages:
Report Criteria is global—it persists everywhere: direct browser access, mobile app, embedded in Pages, and exports. When embedding a report in a Page, any criteria added via the Page Builder uses AND logic with the existing Report Criteria:
Report Criteria: Status == "Active"
Page Embed Criteria: City == "New York"
Result: Status == "Active" AND City == "New York"
You cannot "subtract" or override Report Criteria. If your "Clients Report" has hard-coded criteria showing only "Active" clients, you cannot embed that same report on an "Archived Clients" page. This forces you to clone the report entirely.
Custom Filters are designed to solve this—allowing a single report to adapt to different contexts. But without the ability to set a default Custom Filter via URL or Page embed, this flexibility is completely inaccessible.
The Current Workarounds (All Suboptimal)
To achieve "default filter" behavior, developers are forced into one of these suboptimal approaches:
Workaround 1: Report Cloning ("Report Bloat")
Many users simply duplicate the "Clients Report," rename it "Active Clients Report," and set hard-coded criteria. This leads to:
- Application bloat with multiple near-identical reports
- Violates the DRY (Don't Repeat Yourself) principle
- Maintenance nightmare—changes must be applied to every clone
- Confusing for users who see multiple similar reports in navigation
Workaround 2: URL Parameter Construction
Abandon Custom Filters entirely and replicate the filter logic using URL parameters:
// Instead of simply setting "Active Clients" as the default Custom Filter,
// developers must construct URL parameters manually:
base_url = "https://creatorapp.zoho.com/myaccount/crm-app/#Report:Clients_Report";
// Replicate the Custom Filter logic with field-based parameters
filter_params = "?Status=Active&Status_op=18"; // 18 = EQUALS operator
openUrl(base_url + filter_params, "same window");
Additional friction: Finding the correct
Operator ID (e.g., 18 for EQUALS, 26 for CONTAINS, 58 for BETWEEN) requires digging through documentation. Custom Filters abstract this complexity away—losing them forces developers to deal with these obscure codes.
Problems with both approaches:
- Complex filter logic must be duplicated—once in the Custom Filter definition (for manual use) and again in Deluge scripts (for automation)
- No single source of truth for filter criteria
- Maintenance nightmare when filter logic changes—updates required in multiple places
- Users see raw URL parameters instead of friendly Custom Filter names
- Custom Filters with complex multi-field criteria become extremely verbose URL strings
What Should Happen Instead
Proposed Solution 1: Default Custom Filter Setting
Add a simple option in Report Properties to designate one Custom Filter as the default:
Report Properties → Custom Filters → [Filter Name] → ☑ Set as Default
When enabled, this filter would automatically apply when the report loads, while still allowing users to switch to other Custom Filters or clear it entirely.
Proposed Solution 3: Deluge Integration
Support Custom Filter names in openUrl calls:
// Clean, maintainable approach
openUrl("#Report:Clients_Report?zc_CustomFilter=Active_Clients", "same window");
// Instead of duplicating all the filter logic
openUrl("#Report:Clients_Report?Status=Active&Status_op=18", "same window");
Real-World Impact
This limitation affects any workflow requiring:
- Default filtered views — A Clients report should show "Active Clients" by default, not all clients
- Dashboard navigation — Clicking a KPI tile should open a report with the relevant Custom Filter applied
- Email links to filtered reports — "Click here to see overdue invoices" should pre-apply the appropriate filter
- Embedded reports in Pages — Different page contexts should show different default filter states without cloning reports
- Mobile experience — On mobile apps, filters are hidden behind menus. Users often miss them entirely. A default Custom Filter ensures users see relevant data immediately without navigating through menus on a small screen
- User onboarding — New users should see a sensible default view, not unfiltered data overwhelming them
Developer Impact: Custom Filters are excellent for end-user experience but nearly useless for automation and programmatic control. This gap forces developers to maintain duplicate filter logic—once in Custom Filters for manual use, and again as URL parameters for automation.
Request to Zoho Team
Can this be addressed in a future update?
The current implementation forces developers to choose between:
1. User-Friendly Custom Filters
Easy for users to understand and apply manually, but no programmatic control or default state
|
2. URL Parameter Filtering
Full programmatic control via ?FieldName=value&FieldName_op=constant, but complex to maintain and requires duplicating filter logic
|
We shouldn't have to choose—Custom Filters should support both user interaction AND programmatic control.
Community Input Requested: Has anyone else encountered this limitation or found a workaround? I'd love to hear how others are handling scenarios where a default Custom Filter is needed.
📚 Documentation References:
🔗 Related Community Discussions: