Irreversible: Deleted attachments cannot be recovered via the API. Always archive the file to an external store (S3, Google Drive) before calling attachment/remove if there is any chance the file will be needed again.
When to Use
- Post-archival cleanup: After archiving Jira attachments to S3 cold storage, a workflow removes them from Jira to free instance storage quota. This pattern is most common for attachments older than 90 days on closed issues.
- Sensitive file removal: A security workflow detects that an attachment contains PII or credentials. It archives the file to a secure encrypted store and then removes it from Jira to prevent broader access via the issue.
- GDPR right-to-erasure: When a data subject requests erasure, all files associated with their data must be deleted. A workflow identifies attachments linked to the subject, archives them to an erasure record store, and removes them from Jira.
- Test environment attachment cleanup: After automated test runs in a test Jira project, a cleanup workflow removes all log and screenshot attachments posted during the test run to return the environment to a baseline state.
- Superseded file replacement: When an updated document replaces a previous version, the workflow removes the old attachment after uploading the new version, keeping only the current revision on the issue.
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 |
AttachmentId | Required | The numeric Jira attachment ID to delete. Example: "10044". Verify this ID with attachment/get before deleting to confirm it targets the correct file. |
Sample Configuration
{
"resource": "attachment",
"operation": "remove",
"Host": "https://acmecorp.atlassian.net",
"Email": "automation@acmecorp.com",
"ApiToken": "{{ $credentials.jiraApiToken }}",
"AttachmentId": "{{ $json.attachmentId }}"
}
Validation Errors
| Error Code | Cause |
VAL_MISSING_ATTACHMENT_ID | AttachmentId is empty or null. |
ATTACHMENT_NOT_FOUND | No attachment exists with the given ID, or the user lacks access. |
PERMISSION_DENIED | The authenticated user does not have delete attachment permission. |
AUTH_FAILED | Invalid credentials or expired API token. |
Output Fields
| Field | Type | Description |
status | string | "success" or "error" |
attachmentId | string | ID of the deleted attachment. |
deleted | boolean | true if the attachment was successfully removed from Jira storage. |
resource | string | Always "attachment" |
operation | string | Always "remove" |
Sample Output
{
"status": "success",
"attachmentId": "10044",
"deleted": true,
"resource": "attachment",
"operation": "remove"
}
Expression Reference
| Expression | Type | Example Value | Use |
{{ $output.removeAttachment.deleted }} | boolean | true | Confirm deletion before updating audit record |
{{ $output.removeAttachment.attachmentId }} | string | "10044" | Record deleted ID in the archival log |
Node Policies & GuardRails
- Always archive before removing: Download the attachment content using
HttpRequest with Basic Auth and save to S3 or another store before deleting from Jira. Treat this as a mandatory pre-step for all production attachment removal workflows.
- Verify ID with attachment/get first: Before removing, call
attachment/get to confirm the file name and author match what you expect. Reduces risk of accidentally deleting the wrong attachment due to stale IDs.
- Log deletion in audit trail: Write a record to MongoDB or an audit log before and after deletion, including the attachment ID, file name, file size, the issue it belonged to, and the deletion timestamp.
- Post-deletion comment: After removing an attachment, optionally add a comment to the issue noting that the file was removed, archived, and where it was stored. This maintains the issue's audit trail even after the file is gone.
Workflow Example — Archive and Remove Old Attachments
// Step 1: issue/getAll — find closed issues older than 90 days
{
"Jql": "project = OPS AND status = Done AND resolved <= -90d",
"Limit": 50
}
// Step 2: Loop over issues
// Step 3 per issue: attachment/getAll
// Step 4: Loop over attachments
// Step 5 per attachment: HttpRequest — download file to S3
// Step 6: S3/putObject — archive file
// Step 7: attachment/get — verify ID before deletion
// Step 8: attachment/remove
{
"resource": "attachment",
"operation": "remove",
"AttachmentId": "{{ $loopItem.attachmentId }}"
}
// Step 9: MongoDB/insert — log archival record
// Step 10: comment/add — note archival on issue