nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to restrict linking more issues to a specific set of issues in Jira Cloud?

Vikrant Yadav

Hi Expert,

I have a requirement in Jira Cloud where I want to restrict issue linking for a specific set of issues within a project.

For example, I have issues like:

ABC-100
ABC-200
ABC-400

The restriction should apply only to this specific set of issues within the project, not to all issues in the project.

Is there any way to achieve this using:

Jira native configuration
Workflow validators
Automation
ScriptRunner or any other app?

If anyone has implemented something similar, I would really appreciate your suggestions.

Accepted answers

Trudy P Claspill

Hello @Vikrant Yadav

How do you decide on the subset of issues impacted by this? What do they have in common?

Automation Rules cannot truly be used to prevent things from happening because they don't execute until the triggering event is already completed. You could potentially create an automation rule that is triggered by the creation of a Link, and then evaluate if that happened with one of the issues in the subset, and then remove the link. This rule could be impactful to your system, though, because the triggering issue of a Issue Link Created trigger depends on the direction of the link, not where it was created from. So you would need to have a Global rule to check all links created regardless of direction for all projects, in order to catch links being created for the subset of issues.

Workflow Validators would only (potentially) help if you could limit the ability to create links to occur within a workflow transition. However, since links can be created between issues in different projects, changing the workflows for the one project would not block the ability to create links to the issues from issues in other projects.

If the issue subset is determined based exclusively on Status (all issues of a given type in that status cannot have more links created) then you could test using Workflow Properties to deny the Link permission when the issues transition to the specified status.

https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/

Thiago Wenceslau -Appfire-

Hi @Vikrant Yadav

I’m Thiago, a support engineer at Appfire.

If you are considering third-party apps, you could easily create a rollback event-based action using JMWE(Jira Misc Workflow Extensions), here’s an example:

Screenshot 2026-03-18 at 10.16.21.png

This action will restrict any issues trying to link with those matching the nunjucks criteria:


{{ issue.fields.summary == "Epic Link A" or issue.fields.summary == "Epic Link B" }}

However, keep in mind that the opposite will not trigger a link removal, that is, if you link from your restricted issue it will remain linked.

Please contact our support if you have any other questions about this.

Best regards, Appfire support team.

All comments

Arkadiusz Wroblewski

Hello @Vikrant Yadav

Not natively in Jira Cloud.

You can control linking through the Link issues / Link work items permission, but Jira does not provide a built-in rule to block adding more links only to a specific subset of issues.

If you need that level of control, I would look at issue security or an app/custom validator.

Take a look on this Apps:

https://marketplace.atlassian.com/apps/1232054/advanced-link-manager-for-jira

https://marketplace.atlassian.com/apps/1233642/workflow-building-blocks-for-jira

Trudy P Claspill

Hello @Vikrant Yadav

How do you decide on the subset of issues impacted by this? What do they have in common?

https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/

Thiago Wenceslau -Appfire-


{{ issue.fields.summary == "Epic Link A" or issue.fields.summary == "Epic Link B" }}

Best regards, Appfire support team.

Vikrant Yadav

Hi @Trudy P Claspill

Thanks for your response!

I have setup a scripted listner to achieve this.

As it's a single project, when anyone try to add an issue link, it delete the issue link and add a comment to the linked issue.

// Get event details
def linkId = issueLink?.id
def sourceIssueId = issueLink?.sourceIssueId
def destinationIssueId = issueLink?.destinationIssueId

logger.info("Link ID: ${linkId}")
logger.info("Source Issue ID: ${sourceIssueId}")
logger.info("Destination Issue ID: ${destinationIssueId}")

// Get Source Issue
def sourceIssueResp = get("/rest/api/3/issue/${sourceIssueId}")
.header("Accept", "application/json")
.asObject(Map)

def sourceIssueKey = sourceIssueResp.body.key

// Get Destination Issue
def destIssueResp = get("/rest/api/3/issue/${destinationIssueId}")
.header("Accept", "application/json")
.asObject(Map)

def destIssueKey = destIssueResp.body.key

logger.info("Source Issue Key: ${sourceIssueKey}")
logger.info("Destination Issue Key: ${destIssueKey}")

// Restricted destination issues
def restrictedIssues = ["ABC-953672","ABC-953684"]

if(restrictedIssues.contains(destIssueKey)) {

logger.info("Destination issue ${destIssueKey} is restricted. Removing link.")

// Remove issue link
delete("/rest/api/3/issueLink/${linkId}")
.asString()

logger.info("Link removed successfully")

// ADF Comment
def commentBody = [
type: "doc",
version: 1,
content: [
[
type: "paragraph",
content: [
[
type: "text",
text: "As the 26.4 Release QA Freeze deadline has passed, linking of pre and post deployments is no longer possible. Please reach out to the Release Team for further details."
]
]
]
]
]

post("/rest/api/3/issue/${sourceIssueKey}/comment")
.header("Content-Type", "application/json")
.body([
body: commentBody
])
.asObject(Map)

logger.info("Comment added on ${sourceIssueKey}")
}

Vikrant Yadav

Hey @Thiago Wenceslau -Appfire- thanks for your help!

But we don't have this plugin.

I have Scriptrunner for Jira (Scripted Listner ) which trigger on "Issue Link Created" event.

Arkadiusz Wroblewski

@Vikrant Yadav

If you said before that you have ScriptRunner, then I would advice you that solution much sooner 😅

Trudy P Claspill

The author mentioned Scriptrunner as a solution option in their original post. 😉

Arkadiusz Wroblewski

@Trudy P Claspill

Mentioning something is one thing, but actually having it and using it is another.

I always prefer to look at native Jira solutions first, and only then consider apps. Why pay for something if Jira can handle it natively? If we know he can Code, that will be much easier .

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud