This flags every ticket that has the OT label or Rollover Page = Yes, excluding test/duplicate tickets. It works correctly and runs fast on its own.
The problem: I have a separate calculated measure that groups multiple Environments values under one combined label. When I put Environments in the column area alongside this flag, tickets with more than one environment get counted multiple times — once per environment — instead of once per ticket. So a single ticket tagged with 3 environments contributes 3 to the total instead of 1.
What I need: a way to make sure each ticket always counts as exactly 1 in this measure, regardless of how many environments it’s tagged with, when Environments is used as a column.
What you are experiencing is actually the expected behavior of multi-choice fields like Environments (or Labels, Components, Fix Version) in eazyBI. When a field can hold multiple values per issue, eazyBI counts that issue once for each matching value. So if a single ticket has 3 environments, it will contribute to all 3 environment columns, this is by design, as eazyBI categorizes and aggregates data per dimension member.
There are two approaches to solve this:
Option 1: Import Environments as a CSV dimension (recommended for performance)
This allows you to analyze issues by their combination of environment values rather than by each individual value. Each unique combination (e.g., “Env A, Env B”) becomes a single dimension member, so an issue is counted only once.
In import options, edit the advanced settings for the Environment field; add parameter csv_dimension = true. During the next import, eazyBI will create a new dimension “Environment CSV” which you can use for filtering and grouping data.
See this community post for more details on a similar use case:
Option 2: Calculated measure to count issues that were flagged.
An alternative is to create a calculated measure to count each issue only once, regardless of how many matching environments it has. The formula would look something like this:
NonZero(
Count(
Filter(
--iterate through individual issues
DescendantsSet([Issue].CurrentHierarchyMember, [Issue].[Issue]),
--issue is flagged and matches report context (selected environments and other fields)
[Measures].[Afterhours Issue Flag] > 0
)
)
)
The calculation iterates through all imported issues to check their flag and assigned environments, therefore, it may affect report performance on large datasets.
Thanks for the reply Zane. Option 2 works best for my situation. The only problem is that it takes 15 seconds to load the chart, do you have any suggestions for a way to reduce the time?
@Timi, both solutions are built on the assumption that you have a JavaScript-calculated measure that shows flagging based on the specific date.
The behavior of result multiplication is caused by the multi-choice field Environment; therefore, the solution lies within the Environment dimension.
Calculated measures using Descendants() of imported Issues are resoucefull because they iterate over individual items. In some cases, those calculations can be optimized for a specific report layout, but will still remain resourceful. Pelase give a try to Report Optimizer Assistant.
That’s an important constraint. The double-counting occurs because an issue linked to multiple environments within the same calculated environment group (e.g., both [Environments].[COC] and [Environments].[COF] in [Environments].[Options]) gets its flag summed multiple times. The original Count(Filter(..., flag > 0)) correctly counts each issue once because > 0 acts as a distinct check per issue.
This means the issue-level iteration cannot be eliminated with the current data model — you need it to deduplicate issues across environments.
The only way to truly fix this at the data level would be to modify the JavaScript precalculated field so it stores the flag in a way that avoids double-counting when aggregated. For example:
Store the flag as 1 / number_of_environments_for_this_issue so that summing across environments yields the correct distinct count. However this is complex and fragile.
Or, store a separate measure that tracks afterhours issues counted only against a primary environment (e.g., the first environment value), so each issue is counted exactly once per group.
This kind of data model design is beyond the scope of report profiling optimization. I’d recommend reaching out to support@eazybi.com with this specific requirement — they can advise on the best JavaScript field design to enable efficient distinct counting across a multi-value dimension.
Which of the bullet points do you think is the better option? How do I achieve it?