Irreversible operation: Deleted Jira issues cannot be restored via the API. All linked data — comments, attachments, history, time logs — is permanently erased. Always implement a confirmation guard or approval gate in your workflow before executing this operation. In most cases, transitioning an issue to a "Cancelled" or "Invalid" status is a better alternative that preserves audit history.
When to Use
- Automated duplicate cleanup: A scheduled job detects duplicate issues created by an alert-flapping bug. After a human review gate confirms deletion is safe, the workflow deletes the confirmed duplicates — keeping only the canonical issue.
- Test data cleanup: In a QA environment, a post-test workflow deletes all issues created by test automation runs (identified by a
test-auto label) to keep the test project clean between runs.
- Stale issue archival: Issues in a sandbox project that have been in "Won't Fix" status for over 12 months and have no linked releases are identified via JQL and deleted after an admin confirmation step.
- GDPR data erasure: When a customer requests data erasure, a workflow searches for Jira issues containing the customer's name or ID, archives the content to a secure store, then deletes the source issues to comply with right-to-erasure requirements.
- Spam/bot issue removal: Jira instances open to external submission occasionally receive spam issues. An automated pattern-detection workflow flags and deletes these after confidence scoring exceeds a threshold.
Configuration
Connection
| Field | Required | Description |
|---|
Host | Required | Jira instance base URL. Example: https://acmecorp.atlassian.net |
Email | Required | Atlassian account email. Example: automation@acmecorp.com |
ApiToken | Required | API token from Atlassian security settings. Store in Credentials Manager. |
Operation Fields
| Field | Required | Description |
|---|
IssueKey | Required | The key of the issue to permanently delete. Example: PROJ-123. Triple-check this value before executing — deletion is irreversible. |
Sample Configuration
Delete a confirmed duplicate issue after human approval gate:
{
"resource": "issue",
"operation": "delete",
"Host": "https://acmecorp.atlassian.net",
"Email": "automation@acmecorp.com",
"ApiToken": "{{ $credentials.jiraApiToken }}",
"IssueKey": "{{ $json.duplicateIssueKey }}"
}
Validation Errors
| Error Code | Cause |
|---|
VAL_MISSING_ISSUE_KEY | IssueKey is empty or null. |
ISSUE_NOT_FOUND | No issue exists with the given key, or the user lacks access. |
PERMISSION_DENIED | The authenticated user does not have Delete Issue permission in this project. |
AUTH_FAILED | Invalid credentials or expired API token. |
Output Fields
| Field | Type | Description |
|---|
status | string | "success" or "error" |
issueKey | string | Key of the deleted issue. Example: "PROJ-123" |
deleted | boolean | true if the issue was successfully deleted. |
resource | string | Always "issue" |
operation | string | Always "delete" |
Sample Output
{
"status": "success",
"issueKey": "TEST-89",
"deleted": true,
"resource": "issue",
"operation": "delete"
}
Expression Reference
| Expression | Type | Example Value | Use |
|---|
{{ $output.deleteIssue.deleted }} | boolean | true | Confirm deletion succeeded before logging |
{{ $output.deleteIssue.issueKey }} | string | "TEST-89" | Log the deleted key in an audit trail |
Node Policies & GuardRails
- Always gate deletion with human approval: Never automate issue deletion without a human review step (Approval Node or similar). Automation errors that delete the wrong issue key cannot be reversed.
- Prefer status transition over deletion: In most workflows, closing or cancelling an issue is more appropriate than deleting it. Closed issues preserve the audit trail and can be referenced by future queries.
- Log before deleting: Before calling
issue/delete, call issue/get and log the full issue object to a MongoDB collection or audit log. This provides a recovery record if the deletion was in error.
- Restrict delete permissions: Ensure the service account used by this node has Delete Issue permission only on the specific projects where deletion is allowed. Do not grant instance-wide delete permissions to automation accounts.
- Test environment isolation: Use
issue/delete for test data cleanup only in environments where the project key is in an allow-list of test projects. Validate the project key before executing in any multi-environment workflow.
Workflow Examples
Example 1 — Test Data Cleanup with Label Guard
// Step 1: issue/getAll — find test issues
{
"Jql": "project = TEST AND labels = \"test-auto\" AND created <= -24h",
"Limit": 100
}
// Step 2: Loop over issues
// Step 3 per issue: IfCondition — confirm it's a test issue
// Condition: {{ $loopItem.labels }}.includes("test-auto")
// Step 4 (if confirmed): issue/delete
{
"resource": "issue",
"operation": "delete",
"IssueKey": "{{ $loopItem.key }}"
}
Example 2 — Duplicate Issue Removal with Approval Gate
// Step 1: Duplicate detection logic identifies confirmed duplicates
// Step 2: Approval Node — requires manager sign-off
// Step 3 (after approval): issue/get — log issue details
// Step 4: MongoDB/insert — archive issue data before deletion
// Step 5: issue/delete
{
"resource": "issue",
"operation": "delete",
"IssueKey": "{{ $json.confirmedDuplicateKey }}"
}
// Step 6: Slack notification — confirm deletion with audit reference
