TL;DR
Dashboard and Report filters support flat per-condition logic only — same dimension produces an implicit OR, different dimensions an implicit AND, with no user control over connectors and no ability to group conditions. The recently introduced Dashboard-level Filters are a welcome step forward in usability, but the underlying filter logic model remains flat. This idea requests fully explicit AND/OR control and grouped nested filter logic across both Dashboards and Reports.
Description
Raised by TAM Thomas Kazmierczak on behalf of NOVO NORDISK.
Current documented state The Cloudability documentation confirms that Dashboard widget filters support conditions against a Dimension or Metric — including Business Dimensions, Business Metrics, Account Groups, and Tags — using operators such as equals, not equals, less than, greater than, contains, and others. The August 2026 release of Dashboard-level Filters extended this by allowing a common filter set to be applied across all compatible widgets in a dashboard simultaneously, removing the need to configure the same filter on each widget individually.
These are genuine usability improvements. However, the underlying filter logic model has not changed: conditions remain flat, AND/OR connectors are implicitly determined by whether a new or existing dimension is selected, and there is no ability to group conditions or place explicit connectors between groups. The filter engine in Cloudability's own Business Mapping feature — by contrast — supports full AND/OR logic, mixed boolean conditions, and short-circuit evaluation. The reporting surface has no equivalent.
What this idea requests — in order of priority:
Explicit AND/OR connectors — users should be able to define whether any two conditions are combined with AND or OR, independent of whether they share a dimension. Logical connectors should be a deliberate user choice, not an automatic consequence of dimension selection.
Condition grouping — users should be able to group conditions together, assign an AND/OR connector to the group as a whole, and combine groups against each other with their own connector. This is the standard advanced filter model illustrated in the attached screenshot, and the model that Cloudability's own Business Mapping engine already uses internally.
Nested group logic — groups should be nestable within other groups, enabling expressions such as (A AND B) OR (C AND D) or ((A OR B) AND C) OR (D AND E) to be constructed and saved as a Report or Dashboard filter.
Consistency across Dashboards and Reports — any filter logic enhancement must ship equally across both surfaces. A pattern observed across multiple product releases is that improvements arrive in one area but not the other, leaving customers with an inconsistent experience depending on which surface they are working in.
Example use cases unlocked:
- Show Production costs for Team A alongside Staging costs for Team B in a single Dashboard widget — today this requires two separate widgets or two separate reports because (Environment = Prod AND Team = A) OR (Environment = Staging AND Team = B) cannot be expressed
- Build a single showback report where Finance sees only their data services and Engineering sees only their compute services, each scoped with independent condition groups
- Combine two anomaly signals — an EC2 spike in one account and region, an RDS spike in another — into one report for side-by-side investigation without toggling between views
- Exclude multiple known low-signal cost categories using negated condition groups on an executive Dashboard, without post-export filtering
- Express per-BU chargeback boundaries with independent account, region, and tag conditions per business unit in a single report, without populations bleeding into each other
