A small filter toggle can change a report more than its chart type. “Stage is Proposal AND amount is at least ₹500,000” describes large proposals. “Stage is Proposal OR amount is at least ₹500,000” also admits large deals in every other stage and small proposals. Both queries are valid, but only one may answer the decision in front of the team. The danger comes when a plausible result hides a population nobody stated explicitly.
Intelligent CRM’s report builder supports multiple typed filters with an All or Any choice. The backend validates each field and operator against the selected source, normalizes the value, and combines the resulting conditions. All produces conjunction. Any produces one OR group for the report-authored filters. The mandatory team condition is never placed inside that OR group, so a broad condition cannot reveal records outside the authenticated workspace.
This guide explains how to select operators, combine conditions, handle empty and multi-value fields, keep date ranges distinct from ordinary filters, and interpret filters on historical report types. It also provides a debugging method for surprising totals. The objective is not to create the longest filter list. It is to define a population that another person can read, reproduce, and challenge without reverse-engineering a chart.
Choose All, Any, or a separate report
One global All or Any choice is intentionally simpler than an arbitrary expression tree. Split distinct questions instead of hiding complex logic in a title.
| Approach | Logical shape | Best for | Common mistake |
|---|---|---|---|
| All filters | Access AND A AND B AND C | A narrow cohort meeting every requirement | Adding alternatives that make the population impossible |
| Any filters | Access AND (A OR B OR C) | An exception queue where any condition deserves attention | Assuming the OR includes access, date, or pipeline boundaries |
| Included values | One field matches one of several selected values | Several stages, owners, or categories on the same dimension | Creating many filters when one multi-value selection expresses the intent |
| Separate reports | Two independently named populations | Questions requiring nested logic such as A AND (B OR C) | Forcing complex business rules into one flat All or Any list |
Write the population as a logical sentence
Begin with the noun and scope: visible Deals in the selected pipeline, current Companies, personally assigned Tasks, or active records for one custom object. Add conditions in ordinary language and say the conjunction aloud. “Visible open Deals where region is West and amount is at least ₹500,000 and next activity is empty” is an All population. “Visible open Deals where next activity is empty or expected close date is before today or priority is High” is an Any exception queue.
Add parentheses explicitly when reading Any: viewer access AND (missing next activity OR overdue close date OR high priority). This prevents the mistaken interpretation that any high-priority Deal in the workspace becomes visible. If the desired sentence needs nested groups such as Enterprise AND (India OR Singapore), one flat global choice may not express it. Prefer a governed category, a formula field that encodes a deterministic rule, or separate reports with precise names rather than approximating the logic silently.
Select operators that match the field type
Text and multiline fields can support equality, inequality, contains, starts with, ends with, and empty checks. Numbers and currency add greater than, greater than or equal, less than, less than or equal, and between. Dates and datetimes use equality, before, after, and between. Boolean fields support equality and inequality. Select and relationship fields use their supported equality, membership, or textual operators according to schema metadata. The builder should offer only operators the server declares for that field.
Typed operators reduce ambiguity but do not define business meaning. Amount greater than zero may include a placeholder estimate. Created date after a boundary says nothing about when the Deal entered its current stage. A relationship display label can change while its stable identifier remains the safer filter. Read field definitions, use the narrowest operator that matches the decision, and preview representative boundary values. A between range needs both endpoints; a missing endpoint is an invalid configuration rather than an open-ended assumption.
Use All for cumulative qualification criteria
All logic requires every report-authored condition. It is the natural choice for a cohort such as active Companies in one segment with an assigned owner and a renewal date in the next quarter. Each additional filter can only maintain or shrink the result. When a new All condition unexpectedly increases a count, investigate configuration, comparison state, record changes, or a different viewer; ordinary conjunction should not broaden an otherwise unchanged population.
All can also reveal impossible combinations. If a result becomes zero, inspect whether two select values are mutually exclusive, date windows conflict, or an equality operator is being used where one field contains several values. Do not relax the entire report to Any simply to make a chart appear. Remove one condition at a time, inspect calculated rows, and decide whether the business requirement was wrong or the underlying data needs correction. A zero can be an important answer when the criteria are valid.
Use Any for independent reasons to enter one queue
Any logic is useful when each condition independently justifies attention. A Deal risk queue might include an overdue expected close date, no next activity, or High priority. A data-quality queue might include missing owner, empty domain, or absent lifecycle stage. A record satisfying several conditions still belongs to the population once; the report filter is not a reason counter. If the team needs to know which reason fired, group by a governed reason field or use separate cards rather than assuming the aggregate explains itself.
Any is usually too broad when one condition is meant to qualify another. “Enterprise segment OR missing next activity” includes non-Enterprise Deals with missing activity and every Enterprise Deal even when well managed. If the decision is Enterprise Deals that have either missing activity or an overdue close date, the desired nested logic cannot be represented by a flat three-filter Any setting. Create an Enterprise-only report with a governed exception field, split the views, or model the deterministic exception as a formula that can be filtered exactly.
Treat empty, zero, false, and unknown as different states
Is empty and is not empty require no filter value and should be used deliberately. Empty is not automatically zero, false, “Unknown,” an empty option, or a missing relationship. A currency value of zero may be valid; a boolean false is an explicit answer; an Unknown option indicates a categorized lack of knowledge. Collapsing them hides whether the team lacks data or has recorded a meaningful negative value. The report schema and storage type determine how emptiness is tested.
Empty checks are powerful for operational queues: Deals without a next activity, Contacts without an owner, or custom records missing a required review date. They also risk exposing process design problems rather than customer risk. Pair the card with an owner and remediation workflow. When combining empty checks under Any, remember that one record can be missing several fields but is still one record. Use calculated counts or separate quality cards if operations needs a reason-by-reason workload estimate.
Use one field’s included values instead of unnecessary OR filters
Grouping and stage configuration can include several concrete values and optionally an empty bucket. Select filters can support membership operators, while multi-value select fields may support contains-any or contains-all semantics. These are different questions. A Deal whose tags contain any of Security and Enterprise qualifies under contains-any; contains-all requires both. A stage selection containing Proposal and Negotiation is one ordered status dimension, not two unrelated report filters.
Prefer one multi-value control when the alternatives belong to the same field because it communicates the intent and reduces duplicated conditions. Keep display labels and stable option values aligned through schema changes. Decide whether empty should appear as its own category rather than silently merging it with Other. If a status value is deleted or renamed, review saved reports and historical meaning before assuming current option metadata can reinterpret old ledger entries correctly.
Keep team scope, date range, pipeline, and report semantics outside filter logic
The All or Any choice applies to the report’s field filters. The server first creates the immutable team, object, and source scope and then adds the user-authored group. Under Any, the shape remains boundary AND (filter A OR filter B). The report’s date range, selected pipeline, ordered stages, historical ledger requirements, and object boundary are also validated calculation constraints. They do not become optional merely because the filter logic is Any.
This separation makes broad operational filters safer. An administrator can build and preview an Any query; another teammate can execute and view the saved report over the same workspace records without exposing another team’s data. A custom-object report cannot escape its object identifier. A Task report remains assigned to the current user. Test aggregate and preview responses for this property, not only visible tables. Counts, empty buckets, comparison values, and CSV rows can all leak existence if any query path drops the mandatory boundary.
Interpret filters carefully on historical reports
Historical values, Funnel, Time in stage, and Stage changed use recorded stage or status evidence, while team scope and ordinary record filters commonly evaluate current state. A current-owner filter selects records owned by that person now; it does not reconstruct who owned each record during every historical bucket. An ownership transfer can therefore change an explicitly owner-filtered population or grouping, but it does not remove the record from another same-team viewer’s scope. Metric time is report-path specific: generic semantic-v2 completed buckets and stage-change events use captured snapshots, while an open bucket, current-mode segmentation, and legacy Deal stage-change numeric aggregation can use current values.
Document these semantics whenever filters appear to describe history. If the question requires owner-at-the-time, amount-at-the-time, or another temporal property, confirm that the selected path captures that property at the required moment; a current-field filter cannot supply it. Use count-only occupancy when it best matches available evidence, display the earliest tracked date, and avoid causal claims from a filtered trend whose population can change retrospectively. Historical charts are trustworthy when their temporal contract is explicit.
Debug surprising filter results methodically
First capture the viewer, workspace, source, report type, saved definition version, active dashboard period override, and time zone. Then read the filter sentence with parentheses and confirm All or Any. Inspect every field type, operator, normalized value, empty behavior, included value, pipeline, stage, and date field. Open calculated values and compare record counts with numeric metric counts; an average may exclude records whose numeric field is absent even when those records belong to the filtered population.
Next compare a broad baseline and add one condition at a time. Check archived, merged, transferred, recently edited, and custom-object records. For historical types, compare the earliest ledger date and current-field dependencies. Test as an administrator and a restricted user without expecting identical totals. Export calculated rows when a reproducible artifact helps. Change the definition only after identifying whether the surprise comes from logic, data quality, access, time boundaries, history coverage, or presentation.
Build an Any report without weakening pipeline or viewer boundaries
A sales administrator wants a card for visible open Deals needing attention. The independent reasons are no next activity, expected close date before today, or High priority. The report uses Any for those three filters, selects the Open pipeline stages, counts Deals, groups by current owner, and uses a 30-day created-date range only after confirming that the team wants newly created Deals rather than all active risk. The title states the cohort and the dashboard notes explain that owner is current, not historical. The logical sentence is: viewer-accessible open Deals created in the period AND (next activity is empty OR close date is overdue OR priority is High).
Every same-team user sees workspace Deals satisfying at least one reason. A Deal matching two reasons is counted once. The team later needs Enterprise Deals with either missing activity or overdue close date, so operations creates a deterministic exception category rather than changing the flat filter to Enterprise OR missing OR overdue. Calculated rows and a sample review confirm the revised population before the report replaces the original card.CRM report filter checklist
- Write the filtered population as one sentence with explicit parentheses
- Choose All only when every condition must be true
- Choose Any only when each condition independently admits a record
- Avoid approximating nested logic with a flat global toggle
- Use operators declared for the selected field type
- Provide both endpoints for a between condition
- Distinguish empty, zero, false, unknown, and not applicable
- Use contains-any and contains-all according to multi-value meaning
- Prefer one included-values control for alternatives on the same field
- Keep access, object, pipeline, stage, and date constraints mandatory
- Verify OR logic cannot cross the authenticated workspace boundary
- Document current-field filters used on historical report types
- Inspect record counts and numeric metric counts separately
- Test boundary dates in the configured reporting time zone
- Add filters one at a time when debugging a surprising result
Good filters make the population reviewable
All and Any are simple controls with consequential meaning. All defines cumulative qualification; Any defines independent alternatives. Their safety depends on typed operators, explicit empty behavior, clear time semantics, and a mandatory access boundary that never participates as an optional OR branch. A well-named report should let another teammate reconstruct that logic before inspecting the chart.
Start with a short population sentence, choose the fewest conditions that express it, and verify the result through calculated rows and representative records. Split reports or create a governed deterministic field when the desired logic becomes nested. Filters are trustworthy when they narrow authorized data into an understandable cohort—not when they merely produce the number a meeting expected to see.