Approval tab in Jira

[Naveena Tati]

We work for IT team and get escalated tickets from service desk and many of them require manager or/ and security team approvals. can we have multilevel approvals in Jira?

example flow > we get ticket> in approval tab we tag manager > tickets goes on hold > once approved tag again the sec team > approved tickets move to inprogress

[Shreyas_Quietmill]

@Naveena Tati 

Ah - a Sprint board changes the answer. That means Jira Software, and native approvals don't exist there at all: they're a JSM feature, and the request to bring them across (JRACLOUD-62053) has been open for years. That's also why the suggestions keep coming back to custom fields - on a Software board, anything approval-shaped is a convention, not an enforcement.

Two honest routes:

1. If these escalated tickets already touch a service desk, put the approval there. In JSM the approval only spawns when a request enters the approval status, so "approval only when needed" is just a rule that routes requests around that status when they don't need it. Nothing changes on your Sprint board and no custom field is involved.

2. If it has to live on the Software board itself, it will be an app rather than configuration - there are Marketplace apps that add approval steps to Jira Software. Full disclosure, I build an approvals app myself, but it's JSM-only, so it's genuinely not the answer to yours - you'd be looking at the ones built for Jira Software specifically.

[Shreyas_Quietmill]

Hi @Naveena Tati 

The answers above have the structure right: two statuses, each carrying its own approval step. Two things to add from setting these chains up, because both bite late.

1. Set the approvers before the request reaches the approval status, not on entry. The approval step reads the Approvers field at the moment the request enters the status. If your automation populates the manager on the transition itself, it can lose that race and the approval spawns with nobody in it. The reliable pattern is a short triage status in front: the rule runs there, fills the Approvers field, then transitions the request into "Awaiting manager approval".

2. You said "manager or/and security", which sounds like some tickets don't need the security step at all. You can keep one workflow for both cases: a rule on the manager-approve transition checks whatever marks a ticket as security-relevant on your side (request type, a label, a checkbox the desk sets) and, when it isn't there, moves the request straight through to In Progress.

A side effect of the sequential setup worth having: the security team hears nothing until the manager has actually approved. One inbox at a time, and nobody approves out of order.

[Tomislav Tobijas]

Hi @Naveena Tati ,

Yes - you can add an approval step to any status in your workflow. Basically, you would have two distinct statuses, each with its own approval config.

In short, select each status (before "On hold" and before "In progress") and add approval on each.

And in each status/approval, configure who would need to approve it.

Also, you could use Jira automation to populate these approver fields based on some parameters. Here's one example of that: Use custom field for Approvers using Automation Rule 

Hope this helps.

Cheers,
Tobi

[Naveena Tati]

Hello, Thanks for the answer, but we dont want to have a custom field in Jira as all tickets dont need approval- We want a solution where we can trigger a workflow for approval when needed. Any suggestions on this?

[Germán Morales]

Hi @Naveena Tati , yes, and your flow is the textbook case for it, as long as this queue is a Jira Service Management project, since approvals are a JSM feature and not part of plain Jira Software. The trick for sequential levels is one approval status per level in the workflow, rather than a single tab trying to do both.

Model it like this: a status "Awaiting manager approval" with an approval step whose approver is the manager, and its approve transition leads to a second status "Awaiting security approval" with its own approval step for the security team, whose approve transition then leads to In Progress. The ticket sits in each approval status while it waits, which is your on-hold, and only advances when that level approves. Each of those statuses needs an Approve and a Decline transition for the approval step to be available.

For who signs off, use the standard Approvers field for individuals or Approver groups for a team like security, and set how many people must approve. You can fill those per request type or set them dynamically before the ticket reaches each step.

Setup steps: Add an approval to a workflow and the wider approvals overview.

[Naveena Tati]

Hello, ours is a Sprint board.Thanks for the answer, but we dont want to have a custom field in Jira as all tickets dont need approval- We want a solution where we can trigger a workflow for approval when needed. Any suggestions on this?