You open your Dependency Map and it’s overwhelmed with issues you don’t care about — closed sprints from last quarter, completed issues, releases you already shipped. The first instinct is to open the Jira filter and “fix the JQL”. But JQL has limits, and the filter is often shared with dashboards, reports, or teammates — so you can’t always change it without breaking something else.

That’s the gap Value filtering fills. It works on top of the Jira filter: each fetched issue is matched against expressions you build in the map’s configuration panel, and only matching issues end up on the map.

The mental model in one sentence: fields have properties, you write expressions against properties, and all expressions across all properties must hold for the issue to appear.

Here are three patterns to get you started:

1. Hide what’s done — without touching your Jira filter

The scenario: Your team’s Jira filter pulls every sprint the board has ever had. Half of them are closed and just clutter the map.

The fix:

  • Field: Sprint
  • Property: State
  • Expression: State 'is not' closed

Why this matters:

  • You don’t have to re-scope the underlying Jira filter (which other things may depend on).
  • You can flip the filter off again any time via the Enable value filtering checkbox — useful when you want a historical view.

Creating a value filter to hide closed sprints

The simplest possible filter, and often the most satisfying.

2. Focus on what matters — filter on multiple fields

The scenario: You have hidden closed sprints, but the map is still busy. You want to focus on issues for a certain set of components — say anything that matches comp2 to comp5.

The fix:

Start with the same value filter for sprint as in the first example:

  • Field: Sprint
  • Property: State
  • Expression: State 'is not' closed

Next add a value filter for components:

  • Field: Component
  • Property: Name
  • Expression: matches comp[2-5], enable regex.

Why this matters:

  • Allows you to combine value filtering of multiple fields even if the fields are not displayed in the map.
  • Filters across fields are AND’d together — adding another one always narrows the result, never widens it.

Accept components matching ‘comp[2-5]’

Layer filters across fields to narrow in fast — no JQL gymnastics required.

3. Filter on properties JQL can’t reach

The scenario: You want to see only sprints that end this quarter, regardless of which board they came from. JQL can filter issues by sprint, but it can’t easily filter by a sprint’s end date.

The fix:

  • Field: Sprint
  • Properties: State, EndDate
  • Combine expressions across properties (all must be true).

Why this matters:

  • This is the uniquely valuable part of Value filtering vs. JQL: you’re filtering on properties of the field’s values, not just the values themselves.
  • The same trick works for other field types: filter Epic links by summary, or filter versions by release date.

Example of expressions for State and EndDate.

Reach properties JQL can’t — the field is the door, the properties are the rooms.

Watch out for: the multi-valued gotcha

One thing to watch out for: some fields hold multiple values per issue.

  • Labels, Components, Sprints — an issue can belong to several.
  • For those, an issue passes the filter if any of its values satisfies the expressions.
  • The expression Label 'Does not match' "Hide me" will still show an issue whose labels are {“Hide me”, “Show me”}, because “Show me” satisfies the expression.
  • If you need stricter matching, layer in expressions on other fields or — when available — on other properties of the same field (e.g. a specific ID).

See also:

Wrap-up

The Jira filter fetches; Value filtering focuses. Open your noisiest map, add Sprint State 'is not' closed, and see how much disappears. When you’re ready for more, see the manual for the full feature set: