When to Use
- Living status comment pattern: Instead of posting a new comment for each status update during a long-running deployment, post a single comment via
comment/add and store its ID. Each subsequent update overwrites it with the latest status via comment/update, keeping the issue timeline clean and uncluttered.
- Correcting automated comment errors: If a workflow posted a comment with incorrect data (e.g. a wrong version number due to a variable resolution error), a corrective workflow can update the comment with the correct text without deleting and recreating it.
- Incrementally building a report comment: A long-running batch process posts an initial comment "Processing started..." and updates it at each stage — "Processing 50/200 records..." → "Processing 150/200 records..." → "Complete: 200/200 records processed." — giving real-time visibility on the issue.
- Multi-phase incident comments: An incident issue has a pinned "Current Status" comment. As the incident progresses through detection → investigation → resolution → closed, the workflow updates this comment with the latest phase, actions taken, and next steps.
- Approval decision recording: After a human approval node completes, the workflow updates a placeholder comment on the issue with the approver's name, decision (Approved/Rejected), timestamp, and reasoning — all in a single structured comment.
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 that contains the comment. Example: PROJ-123. |
CommentId | Required | The numeric ID of the comment to update. Must have been stored from a prior comment/add response. Example: "10281". |
Body | Required | The new comment body text. Fully replaces the current body — the previous text is not preserved. Plain text with newline support. |
Full replace, not append: comment/update replaces the entire comment body with the new text. If you want to append to an existing comment, first call comment/get to read the current body, concatenate your addition, then call comment/update with the combined text.
Sample Configuration
Update a living deployment status comment after a successful deployment:
{
"resource": "comment",
"operation": "update",
"Host": "https://acmecorp.atlassian.net",
"Email": "automation@acmecorp.com",
"ApiToken": "{{ $credentials.jiraApiToken }}",
"IssueKey": "{{ $json.issueKey }}",
"CommentId": "{{ $json.statusCommentId }}",
"Body": "*DEPLOYMENT STATUS — {{ $now | date('YYYY-MM-DD HH:mm') }} UTC*\n\nStage: {{ $json.currentStage }}\nEnvironment: {{ $json.environment }}\nVersion: {{ $json.version }}\nProgress: {{ $json.completedSteps }}/{{ $json.totalSteps }} steps complete\n\nLast update: {{ $json.lastStepDescription }}\nNext: {{ $json.nextStep }}\n\n_Updated by BizFirst automation_"
}
Validation Errors
| Error Code | Cause |
VAL_MISSING_ISSUE_KEY | IssueKey is empty or null. |
VAL_MISSING_COMMENT_ID | CommentId is empty or null. |
VAL_MISSING_BODY | Body is empty or null. |
COMMENT_NOT_FOUND | No comment exists with the given ID on this issue. |
PERMISSION_DENIED | The API token user is not the author of the comment and lacks admin permission to edit others' comments. |
AUTH_FAILED | Invalid credentials or expired API token. |
Output Fields
| Field | Type | Description |
status | string | "success" or "error" |
commentId | string | ID of the updated comment. |
issueKey | string | Key of the issue the comment belongs to. |
resource | string | Always "comment" |
operation | string | Always "update" |
Sample Output
{
"status": "success",
"commentId": "10281",
"issueKey": "PROJ-123",
"resource": "comment",
"operation": "update"
}
Expression Reference
| Expression | Type | Example Value | Use |
{{ $output.updateComment.commentId }} | string | "10281" | Confirm which comment was updated |
{{ $output.updateComment.status }} | string | "success" | Gate continuation of multi-stage workflow |
Node Policies & GuardRails
- Only the comment author can update (by default): Jira only allows the comment's original author or a Jira admin to edit comments. Use the same API token account for both
comment/add and comment/update to avoid permission errors.
- Persist commentId for living comments: Store the
commentId from comment/add in a VariableAssignment or MongoDB document that persists across workflow executions so it can be referenced in future update calls.
- Append pattern requires a get first: If you need to preserve existing comment content and append to it, call
comment/get first, concatenate, then call comment/update. Do not assume the current body in expressions without reading it.
Workflow Example — Living Deployment Status Comment
// Step 1 (deployment start): comment/add — create initial comment
{
"IssueKey": "PROJ-456",
"Body": "DEPLOYMENT STARTED — {{ $now }}\nStage: Initialising\nProgress: 0/5 steps"
}
// Store commentId: {{ $output.addComment.commentId }} → VariableAssignment
// Step 2 (at each deployment stage): comment/update
{
"IssueKey": "PROJ-456",
"CommentId": "{{ $vars.deploymentCommentId }}",
"Body": "DEPLOYMENT IN PROGRESS — {{ $now }}\nStage: {{ $json.currentStage }}\nProgress: {{ $json.step }}/5 steps\n\n{{ $json.stageDetails }}"
}
// Step 3 (on completion): comment/update — final status
{
"IssueKey": "PROJ-456",
"CommentId": "{{ $vars.deploymentCommentId }}",
"Body": "DEPLOYMENT COMPLETE — {{ $now }}\nVersion: {{ $json.version }}\nAll 5/5 stages successful\nHealth checks: PASSING"
}