DEV Community: Mortise Apps

See the whole blocker chain in Jira: from a flat list of issue links to a dependency graph

Mortise Apps — Fri, 02 Oct 2026 05:30:48 +0000

A blocker chain in Jira is a sequence of issues joined by blocks / is blocked by links: F1 blocks F2, F2 blocks F3, F3 blocks F4. Jira records every link faithfully but shows them as a flat list inside one issue at a time, so the fact that F4 is ultimately waiting on F1 is never visible anywhere. A dependency graph draws the whole chain as cards and arrows on one canvas, blockers on the left and blocked work on the right. LinkLens for Jira draws that graph for a whole project or for the issue you are looking at.

What Jira gives you today

Atlassian's documentation is clear that linked work items exist "to surface, understand, and manage dependencies". Each link type has two labels, one per direction: blocks seen from the blocker, is blocked by seen from the blocked issue. It is one link, one type, read from two sides.

The issue view lists those links under Linked work items, grouped by label. Boards can show a small linked-items icon on cards. Plans (Advanced Roadmaps) draws dependency lines on a timeline for the issues in a plan. All three show what is directly attached to the issue in front of you. None of them follows the chain.

The request for a project-wide picture is not new. JRASERVER-2544, "Graph link dependency map", was filed in 2003 and eventually closed as won't fix. Twenty years later the flat list is still the default, which is why a whole category of Marketplace apps exists to draw the graph.

A real example: the payments feature and the infrastructure ticket

A storefront team is shipping "Apple Pay and Google Pay in checkout" this sprint. On the issue view it shows one link: is blocked by "Save payment method for next purchase", which is in progress. Looks fine.

Open that blocker and it has its own link: is blocked by "Rotate API keys for payment gateway", a task in the platform team's project, still in the backlog. Open that one and there is a fourth hop: the key rotation waits on "Shared auth service upgrade" in a third project, owned by a team that is not in the sprint review.

Nobody lied and nobody forgot to link anything. The chain is four issues long, spans three projects and two teams, and the only way to discover it is to click through issue after issue. The sprint review is where it gets discovered, three hops too late.

How to do it with LinkLens

LinkLens adds two views and one rule: pick one link type, and both of its directions are used automatically.

The Dependencies page (whole project)

Open the project and select Dependencies in the project sidebar.
In Link type, pick Blocks (blocks / is blocked by). It is preselected on most sites.
Read the canvas left to right. An arrow from A to B means A blocks B. The legend under the canvas restates the rule for whatever type you picked.

For the storefront project the payments chain appears as one row: key rotation, then save-payment-method, then Apple Pay, then the guest checkout story it blocks in turn. The "Shared auth service upgrade" issue from the other project shows as a dimmed, dashed card labelled outside scope, so the cross-project blocker is visible without leaving the page. Widen the JQL scope to project in (SHOP, PLAT) and its own chain is drawn too.

Only issues that have at least one link of the chosen type are drawn; the rest are counted in the stats line ("17 issues in scope, 16 in chains") so the picture stays readable. Hide Done removes finished issues and their links. Click a card to pin its whole upstream and downstream chain while everything else fades; double-click to open the issue. PNG exports the graph with a legend for a Confluence page or a slide.

The Dependency chain panel (one issue)

Open any issue. Select the apps button under the title and choose Dependency chain.
Set Depth to 3 to 5 hops.

The current issue sits highlighted in the middle. Everything to its left blocks it directly or indirectly; everything to its right waits on it. For the Apple Pay story that is the whole four-issue chain on one small canvas, including the other projects.

Choosing the link type

Choose the type whose outward label means "must happen first". Blocks is the usual one. If your admins created a custom type such as Depends on, check which side is the outward label; if the arrows look reversed, the type's labels are defined the other way round.

What LinkLens cannot do

It is read-only in this version: it draws links and does not create or delete them, so use Jira's Link work item action to fix a chain. It draws one link type at a time by design; a chain that mixes blocks and depends on has to be viewed twice. Parent and child relationships (epic to story, story to sub-task) are not drawn as edges yet. The project page caps at 2,000 issues per graph and the issue panel at 300 issues and 5 hops. Links to issues on a different Atlassian site are not followed, and it is Jira Cloud only.

FAQ

Does it work across projects?

Yes. Linked issues outside the current scope are shown as dimmed cards so cross-project blockers never hide. Set the JQL scope to several projects to draw their chains in full. The issue panel follows cross-project links by default.

Does it show issues I am not allowed to see?

No. Every read runs as the person viewing the graph, so Jira's permissions apply and hidden issues are absent, including as external ends.

What does it cost?

Free for sites with up to 10 users. Above that about USD 0.20 per user per month, roughly USD 10 a month for a 50-user site, billed by Atlassian with a 30-day trial. It is on the Atlassian Marketplace; details are on the LinkLens page.

Sources

Link work items, Atlassian Support - link types have outward and inward descriptions; where links are shown.
JRASERVER-2544, Graph link dependency map - the 2003 request for a project-wide dependency map, closed won't fix.
Dependencies in Advanced Roadmaps, Atlassian Documentation - incoming and outgoing dependencies as blocks / is blocked by.

Originally published on the Mortise Apps blog.

How to see every dependency chain on a monday.com board

Mortise Apps — Thu, 01 Oct 2026 20:42:26 +0000

To see how work on a monday.com board depends on other work, you add a Dependency column and pick, for each item, the items it waits on. monday.com then draws each link as a line in the Gantt view and can push dates when a predecessor moves. What it does not show is the structure: which item sits at the start of a chain, how many items a slip would drag along, and where two items wait on each other in a loop. This article covers what the built-in tools do, how far you get with them, and how to see the whole picture with LinkLens Dependency Map, our board view.

What monday.com gives you out of the box

The Dependency column stores, for each item, the items it depends on. Three things use it:

The Gantt view draws a connector line from each predecessor to the item that waits on it, laid out on the Timeline column. Good for one release plan on one screen.
Dependency automations, such as "when a date changes, push the dependent items". These keep dates consistent but say nothing about risk.
Connect boards columns, which link items across boards. They are not dependencies by themselves, but many teams use them that way: a vendor contract on one board that a launch on another board waits for.

The monday.com support article on dependencies covers the setup. It is quick, and for a short plan it is enough.

Where the Gantt view stops

The Gantt view answers "what comes before this bar". It struggles with three questions that project managers ask every week.

How far does a delay spread? If CMS setup slips, the Gantt shows the line to Content migration. It does not show that SEO redirects, QA testing and Launch are behind that, five items deep. You follow the lines by hand.

Which item is the real bottleneck? The item with the most work behind it is rarely the one that looks urgent. A small task that three chains pass through is the one to staff first, and nothing in the Gantt ranks items that way.

Where are the loops? A loop (A waits on B, B waits on C, C waits on A) means none of the three can finish first. Loops usually arrive through Connect boards columns, imports, automations or the API rather than by hand, and a Gantt line has no way to say "this one goes backwards".

Items on other boards add a fourth problem: the Gantt only shows one board, so a cross-board dependency is invisible until someone opens the other board.

What you can do natively

Question	Built-in answer	Effort
What comes right before this item?	Dependency column, Gantt connector	Low
What is everything upstream of this item?	Follow Gantt lines by hand, or a formula per hop	High, breaks past two hops
Which items block the most work?	No native view	Not available
Are there circular dependencies?	No native check for chains longer than two	Not available
Dependencies across boards	Enterprise cross-project dependencies, or Connect boards columns read by hand	Plan-dependent
A report for stakeholders	Export the Gantt as an image	Shows lines, not risks

If you only need the first row, stop here; monday.com does it well.

See the whole structure: LinkLens Dependency Map

LinkLens Dependency Map is a monday.com board view. Add it to a board, pick the Dependency column (or a Connect boards column) and it draws every chain on the board as one graph: blockers on the left, blocked work on the right, separate chains stacked, items without links counted but not drawn. Each card shows the item's group and status.

What that gives you, using the questions above:

Delay spread. Hover any item and its whole chain lights up, upstream and downstream. Double-click to open the item.
Bottlenecks. The layout puts the first blockers on the left; the item with the most cards to its right holds up the most work.
Loops. A circular dependency is drawn with a red dashed arrow and every loop is listed under the map.
Other boards. With a Connect boards column, linked items on other boards appear as dashed outside cards with their board name and status.
Focus. Hide done removes finished items and their links, so what remains is the work that is really blocked today.

The dependency health report

The Report button turns the same data into a document you can hand to stakeholders: a 0-100 dependency health score, every risk found on the board explained in plain English with the items involved and a suggested fix (circular dependencies, overdue and stuck blockers, bottlenecks, stale blockers, date conflicts), which items are predicted to finish late and by how many days, when the open linked work is likely to clear at the recent pace, and 8-week trends of links added against blockers finished. It downloads as PDF or HTML.

The predictions come from the board, not from guesses: LinkLens follows each chain forward from today using the Timeline or Date column, and if a blocker ends after the item behind it is due, that item is predicted late by the difference. Everything is calculated in your browser; no board data leaves monday.com.

Ask Sidekick instead of opening the view

LinkLens also adds a tool to monday Sidekick, monday.com's AI assistant. Turn the LinkLens tool on and ask, in the chat, "What is blocking Launch?", "What does CMS setup delay?" or "Are there circular dependencies on this board?". Sidekick calls LinkLens for the answer, which comes from the board's real links.

What LinkLens does not do

It does not change dates, create links or write to your board; it is read-only. It does not replace the Gantt view for scheduling. And it reads items as the person viewing the board, so it never shows anyone an item they could not already open.

FAQ

Do I need the Enterprise plan for cross-board dependencies?

Not for LinkLens: it reads Connect boards columns, which exist on every plan that has them, and shows linked items on other boards as outside cards. monday.com's own cross-project dependencies feature is separate.

Does the Dependency column allow circular dependencies?

Loops rarely come from typing them in by hand. They arrive through Connect boards columns, board imports, automations and the API. LinkLens draws them in red and lists them so you can remove the link that points backwards.

Can viewers and guests see the map?

Yes. The view is read-only, so viewers and guests get the same map and report; only their view settings are not saved.

Sources

Dependencies on monday.com, monday.com support: setting up the Dependency column and how the Gantt view and automations use it.
Working with the dependency column, monday.com developer documentation: how dependency data is stored and read.
Task dependencies in project management, monday.com blog: dependency types and why chains matter.

Originally published on the Mortise Apps blog.

Search Jira by team name: teamIn() and noTeam() instead of Team UUIDs in JQL

Mortise Apps — Wed, 30 Sep 2026 14:35:07 +0000

In Jira Cloud, a JQL search on the Atlassian Team field has to use the team's UUID, not its name. "Team[Team]" = 36885b3c-1bf0-4f85-a357-c5b858c31de4 works; "Team[Team]" = "Payments" returns nothing. TeamLens for Jira adds two JQL functions that remove the copy-and-paste: issue in teamIn("Payments") matches issues by team name, with a trailing * for prefixes, and issue in noTeam() returns every issue whose Team field is empty. Both work in filters, boards, dashboards, Jira Service Management queues and Automation.

Why names do not work in JQL

The Team field is a custom field (typically customfield_10001) whose stored value is a team id, a UUID such as 36885b3c-1bf0-4f85-a357-c5b858c31de4. Atlassian's developer documentation for the field shows the JQL form directly: "Team[Team]" = <uuid>. The team's display name is metadata attached to that id; JQL never compares against it.

Atlassian recorded the consequence years ago in JRACLOUD-84663, "JQL Search for Team does not Recognize Team Names". The ticket is now closed, and a related ticket (JSWCLOUD-19523) notes that Jira has been rolling out team name lozenges in the JQL editor, which helps when you type a query interactively. It does not help when the query lives in a saved filter, a board, an Automation rule or a queue definition, where you still see and maintain the raw UUID.

Finding a team's UUID means opening the team's profile page and copying the last segment of its URL. Do that for eight teams, paste them into a filter, and you have a query nobody can read and nobody dares to edit.

A real example: one JSM queue per support team

A service desk has three tiers of support, each an Atlassian Team so that Jira Plans and the Team field on requests line up. The service manager wants a queue per tier and a board per tier that only shows that team's open requests.

The native version of each queue filter looks like this:

"Team[Team]" = 5f2a0c1e-8f4b-4b2e-9c6d-2c1a4f7b9d31 AND statusCategory != Done

Six months later the Tier 2 team is renamed and merged with a new team. Whoever inherits the queues has three UUIDs and no idea which is which. The filter for "requests nobody has picked up" is worse: there is no function for "empty Team", so it is written as "Team[Team]" is EMPTY, which works but is not something a queue owner will discover on their own, and it cannot be combined with "or belongs to any tier whose name starts with Tier".

How to do it with TeamLens

TeamLens registers two functions. Because Jira exposes app functions through the issue in ... form, that is how they are written.

Queue per team

issue in teamIn("Tier 1 Support") AND statusCategory != Done

Names are matched case-insensitively against the team's display name. If no team matches, JQL shows an error naming the value, so a typo fails loudly instead of returning an empty queue. A raw UUID is also accepted, so existing filters can be migrated one clause at a time.

All support tiers at once

issue in teamIn("Tier*") AND status = Open

The trailing * matches every team whose name starts with the prefix. New "Tier 4 Support" team next year? The queue picks it up with no edit.

Everything except one team

issue not in teamIn("Tier 1 Support")

Work nobody owns

issue in noTeam() AND statusCategory != Done

Put that one behind a scheduled Automation rule that runs every Monday and comments or emails the service manager, and unowned work stops hiding.

Steps in Jira:

Install TeamLens from the Marketplace (Jira admin, under a minute, no configuration).
Open the issue navigator, switch to JQL, and type issue in teamIn("Your Team Name"). The autocomplete lists the app functions after the first character.
Save it as a filter, then use the filter for a board, a JSM queue, a dashboard gadget or an Automation condition exactly as you would any other filter.

The team list is cached for ten minutes, so a team renamed a moment ago may still resolve under its old name for a short while.

Migrating existing UUID filters

You do not have to rewrite every filter on day one. Because teamIn() accepts a raw UUID as well as a name, a filter such as "Team[Team]" in (uuid-a, uuid-b) can become issue in teamIn("uuid-a", "uuid-b") first, then have each id swapped for the team's name as you touch it. Keep one saved filter per team with a clear name ("Team: Tier 1 Support, open") and point boards, queues and gadgets at the filter rather than repeating the JQL, so a rename means editing one place. A useful check after migration is a dashboard gadget with issue in noTeam() AND created >= -30d: if it is not close to zero, the Team field is not being set on new work and the per-team views are undercounting.

What TeamLens cannot do

The functions match team names and ids; they cannot match team members, because the Teams API only answers a human's API token, not an app's own auth context, so apps cannot read Atlassian Team membership on their own yet (app access is tracked as JRACLOUD-92072). A myTeams() function that returns the issues of every team the current user belongs to is planned for when that API opens. The functions are also written as issue in teamIn(...), not Team in teamIn(...), because that is how Jira Cloud exposes every app-provided JQL function. And they are Cloud only.

FAQ

Does teamIn() work in Jira Service Management queues?

Yes. Queues are JQL filters, and app functions are allowed in them. issue in teamIn("Tier 2 Support") AND status = Open is a valid queue definition.

Can I use these functions in Automation rules?

Yes, both as a JQL condition inside a rule and in the JQL of a scheduled trigger. The weekly "unowned work" rule above is the typical use.

Is this cheaper than building it myself?

There is no do-it-yourself route: JQL functions can only be added by apps. TeamLens is free for sites with up to 10 users and USD 1 per user per month above that, with a 30-day trial, on the Atlassian Marketplace. Details are on the TeamLens page.

Sources

Team field in Jira REST API, Atlassian Developer - the UUID value and the "Team[Team]" = uuid JQL form.
JRACLOUD-84663, JQL Search for Team does not Recognize Team Names - JQL accepts team ids, not names.
JSWCLOUD-19523, JQL Search for Team does not Recognize Team Names - team name lozenges in the JQL editor.
JRACLOUD-87808, Team field not supported for sorting on gadgets, JQL or boards - the wider Team field JQL limitations.
Teams in Jira projects, Atlassian Support - UUIDs must be used when referencing teams in workflows.

Originally published on the Mortise Apps blog.