Jira DC Automation: Pin a bold red warning comment in under 10 minutes

[#1]

This guide shows how to add a formatted wiki‑markup warning comment on issue creation for a specific customer filter and then pin that comment via REST, all using native Automation for Jira on Data Center.

What you’ll build

A rule that triggers on Issue created, filters with your JQL, adds a bold red comment, waits up to 10 minutes, and pins the new comment so it’s always visible at the top.
Authentication options for the pin step using Personal Access Token (Bearer) or Basic, plus troubleshooting for 401 and 400 errors

Prerequisites and limits

Pinned comments are available in the 9.x line for Jira Software projects; Jira Service Management projects do not support pinning
Have permission to comment and edit issues where the rule will run
Create a Personal Access Token (PAT) if you plan to use Bearer authentication for the web request

The JQL condition

Use a JQL condition in the rule to scope the behavior to the customer key *********

project in (****) AND (
issue.property[dbcf].customfield_19480_BOSS_CUST_ID ~ *******
OR "Customer ID Scope" = ******
OR "Universal Customer Boss ID" ~ ****
)

This ensures only matching issues receive the warning and pin behavior.

Step 1 — Trigger
Add the Issue created trigger in your global or project rule
This fires the rule immediately when a new issue is created
Step 2 — JQL condition
Add a Condition: JQL using the filter above so only targeted issues proceed.
This keeps the flow efficient and avoids unexpected comments on unrelated issues.
Step 3 — Add the formatted comment
Use wiki markup to render bold and red so the message stands out in the classic renderer.
Comment body:
{color:red}*Please note that CSL Berhing has a dedicated CBG NOC team. If this ticket has been routed to you and you are not part of the dedicated CSL team, please reach out to Ahmed Hammad immediately.*{color}

The {color:red} macro and asterisks for bold are supported in Jira Data Center comments using the wiki renderer.

Step 4 — Re‑fetch issue data
Add a Re‑fetch issue data action immediately after the comment so smart value {{issue.comments.last.id}} resolves to the comment you just created
This avoids stale context when the subsequent web request needs the comment ID
Step 5 — Optional 10‑minute delay
If you must pin within 10 minutes but not earlier, insert a Delay action for 10 minutes before the pin step.
If “within 10 minutes” is acceptable without waiting, you can skip the delay and pin immediately after re‑fetch.
Step 6 — Pin the new comment via REST
Add a Send web request action configured as follows to call the pin endpoint
 

Method: PUT.
URL:
<BASE_URL>/rest/api/2/issue/{{issue.key}}/comment/{{issue.comments.last.id}}/pin.
 Headers: Content-Type: application/json and Authorization per one of the methods below.
Webhook body: Custom data with raw boolean true (no quotes).
The pin API requires the body to be exactly the unquoted JSON boolean true with application/json, otherwise you’ll get a 400.

Authentication options
 PAT Bearer (recommended): Set header Authorization to “Bearer <your_PAT>” using a Data Center Personal Access Token.
Basic: Build “username:password”, Base64‑encode it, and set Authorization to “Basic <base64>”.
Both approaches work if the account has Comment and Edit Issue permissions on the issue
Full example of the pin request

PUT <BASE_URL>/rest/api/2/issue/{{issue.key}}/comment/{{issue.comments.last.id}}/pin
Authorization: Bearer <your_PAT>
Content-Type: application/json

true

Replace Authorization with Basic <base64(username:password)> if using Basic auth instead of Bearer.

Verifying the pin

Optionally add a second Send web request step to GET <BASE_URL>/rest/api/2/issue/{{issue.key}}/pinned-comments and log the response to the audit log.
This makes it easy to confirm the correct comment is pinned in the rule audit without leaving Automation.

Troubleshooting

 401 Unauthorized: The Authorization header is missing, malformed, or the user lacks permissions; confirm the header format and account access.
400 Bad Request: Most commonly caused by sending an object in the body (e.g., “Issue data”) instead of the raw boolean true, or by an unresolved comment ID; switch to Custom data with true and ensure you re‑fetch.
Not supported: Pinning is available in the 9.x line for Jira Software but not for Jira Service Management projects; confirm your project type and version.



Ready‑to‑copy rule summary

Trigger: Issue created.
Condition: JQL (customer MC003559 filter).
Action: Add comment with wiki markup for bold red warning.
Action: Re‑fetch issue data.
Action: Delay 10 minutes (optional).
Action: Send web request PUT /rest/api/2/issue/{{issue.key}}/comment/{{issue.comments.last.id}}/pin with Content-Type: application/json and body true, using PAT Bearer or Basic auth.
This pattern strikes a balance between clarity and minimal friction for teams handling customer‑specific triage, while remaining fully native to Jira Data Center automation and REST

This is always open for suggestion.

Atlassian KB articles for reference

1. https://confluence.atlassian.com/spaces/AUTOMATION/pages/993924834/Jira+automation+actions
2. https://confluence.atlassian.com/display/JIRACORE/Jira+9.12+REST+API+change+log
3. https://confluence.atlassian.com/enterprise/using-personal-access-tokens-1026032365.html
4. https://developer.atlassian.com/server/jira/platform/basic-authentication/ 
5. https://jira.atlassian.com/browse/JSDSERVER-14894
6. https://confluence.atlassian.com/automation073/dealing-with-wiki-markup-and-html-1093013388.html