Release approval workflow stuck at manager level in Jira Data Center

ALM Atlassian Jira Software
, , , , , , ,
1

We’re experiencing a critical issue where release approval requests in our Jira Data Center instance remain stuck at the manager approval stage. The workflow is configured to escalate after 48 hours, but the automation rule isn’t triggering and releases are blocked from deployment.

Our workflow automation rule configuration:


TRIGGER: Scheduled (every 6 hours)
JQL: project = RELEASE AND status = "Manager Approval" AND updated < -2d
ACTION: Transition to "Director Approval"

The JQL query returns the expected issues when run manually, but the automation doesn’t execute the transition. We’ve verified the service account has transition permissions. This is blocking our release deployment pipeline and causing significant delays. Has anyone encountered similar escalation trigger issues in Data Center?

2

I’ve implemented similar escalation workflows in multiple Data Center environments. Here’s the comprehensive solution addressing all three critical areas:

1. Workflow Automation Rule Configuration Your current rule has several issues. First, the scheduled trigger interval (6 hours) creates gaps. Second, the rule configuration needs explicit error handling:


TRIGGER: Scheduled (every 1 hour) - more frequent for timely escalation
JQL: See corrected version below
CONDITIONS:
  - Issue fields condition: Status equals "Manager Approval"
  - Advanced compare condition: {{issue.created}} < {{now.minusDays(2)}}
ACTIONS:
  1. Add comment: "Escalating to Director due to 48-hour timeout"
  2. Transition issue to "Director Approval"
  3. Send notification to release team
ERROR HANDLING: Log action execution failures

2. Escalation Trigger JQL Conditions The fundamental problem is using updated < -2d which resets on any field change. Replace with a date-based approach:


project = RELEASE AND status = "Manager Approval" AND created < -2d AND "Approval Requested Date" < startOfDay(-2d)

You’ll need to add a custom date field “Approval Requested Date” that gets set when transitioning TO “Manager Approval” status. This field should be read-only and set via a separate automation rule:


TRIGGER: Issue transitioned
FROM: Any status
TO: Manager Approval
ACTION: Set "Approval Requested Date" to {{now}}

This creates an immutable timestamp for escalation logic.

3. Permission Validation for Approval Roles The service account needs multiple permission layers:

  • Project permissions: Edit Issues, Transition Issues, Add Comments
  • Workflow transition permissions: On both “Manager Approval” status screen and “Director Approval” transition
  • Automation execution permissions: Verify the service account is in the “jira-administrators” group or has “Automation Administrator” role

Critical Data Center consideration: Check System > Automation > Settings and verify “Allow automation rules to execute as the rule creator” is enabled. In DC, automation rules execute under specific user contexts.

Additional Troubleshooting Steps:

  1. Enable automation rule logging: Set com.atlassian.jira.automation=DEBUG in logging configuration
  2. Verify the automation executor node in your DC cluster isn’t overloaded
  3. Test the JQL query manually with the service account credentials to confirm query permissions
  4. Check transition validators on the “Director Approval” transition - hidden validators can block automation
  5. Review the transition screen for required fields - automation must provide values for all required fields

Implement the custom date field approach first, then update your automation rules. This pattern ensures escalation timing is independent of issue updates and provides reliable workflow progression for your release approval process.

3

Check if your automation rule is actually enabled and not paused. Also verify the service account isn’t locked or disabled. In Data Center, automation rules sometimes fail silently if there are permission issues at the project level, not just the transition level.

4

Rule is definitely enabled and the service account is active. I checked the automation audit log and there are no execution records for this rule at all - it’s like the scheduled trigger isn’t firing. Could this be a Data Center clustering issue?

5

I’d also look at the transition screen configuration for “Director Approval”. If that transition has required fields that aren’t populated in the issues, the automation will fail to execute even if permissions are correct. The automation might be trying to transition but silently failing due to validation errors. Check the transition screen scheme.

6

In DC environments, scheduled automation rules only execute on one node. Check which node is designated as the automation executor in your cluster configuration. If that node is under heavy load or has issues, scheduled rules won’t run. You can verify this in System > Clustering > Node information.