How to Send a Jira Transition Alert to Your Team's Phones

To send a phone alert when a Jira work item enters one selected status, create a Jira Cloud Automation flow with a Work item transitioned trigger and a Send web request action aimed at a PingRoom incoming webhook. Keep the phone message short, use the work-item key and transition time as a stable event identity, and leave the summary, comments, files, assignee, and history in Jira.

This is a webhook recipe, not a native Jira integration. It suits a small group that needs one shared signal such as “APP-482 is ready for review” without subscribing everyone to every update on the work item.

Check Jira's own notifications first

Jira's mobile app can already notify people about work they watch, work assigned to them, work they reported, and new work. Start with Jira's notification controls when the recipients already participate in the Jira project and need those normal events.

A phone alert is an attention cue, not a replacement for the work record.

Create one destination Room

Create a private PingRoom Room for the people who need the transition. The Room owner needs PingRoom Pro for incoming webhooks.

Open the Room's Settings → Connections → From another app, add a webhook, leave Quick Ping on Custom message, and copy the complete webhook URL. A Room can have up to four incoming webhooks.

The URL contains the secret. Anyone who can read it can fire the Room, so treat permission to edit or inspect the Jira flow as credential access. Do not paste the URL into a work item, comment, screenshot, exported rule description, or public runbook. If it leaks, regenerate the secret in PingRoom and replace the URL in Jira.

The broader webhook setup guide explains PingRoom's request and response. The incoming-webhook reference carries the current field limits, cooldown behavior, and error shapes.

Trigger only the transition people need

In Jira Cloud, open the relevant project's automation area and create a flow. Choose Atlassian's documented Work item transitioned trigger.

Set From status to any status unless the source matters. Set To status to one useful destination—for example, Ready for review. A narrow destination filter prevents the rule from firing for edits, comments, reassignment, or every other state change.

Add the Send web request action:

• Web request URL: the complete PingRoom webhook URL.
• HTTP method: POST.
• Web request body: Custom data.
• Wait for response: on, so the Jira audit log can record PingRoom's HTTP result.

Atlassian notes that administrators can restrict which domains a web-request action may call. If the request is blocked before it leaves Jira, ask the Jira administrator to review the automation domain policy rather than weakening the rule.

Use these headers:

{
  "Accept": "application/json",
  "Content-Type": "application/json",
  "Idempotency-Key": "jira-{{issue.key}}-{{issue.status}}-{{issue.updated.jiraDateTime}}"
}

Use this custom body:

{
  "title": "Ready for review",
  "message": "{{issue.key}} is ready for review",
  "correlation_id": "jira-{{issue.key}}-{{issue.status}}-{{issue.updated.jiraDateTime}}"
}

Jira documents {{issue.key}}, {{issue.status}}, and {{issue.updated}} as work-item smart values; date values can use formats such as jiraDateTime. For a single transition run, those three values give the request one reproducible identity. PingRoom uses that identity in two places:

• Idempotency-Key makes an identical retry return the original completed result instead of creating another Ping.
• correlation_id carries the source identity with the Ping so connected systems can relate it back to the transition.

Reuse both strings unchanged for a retry of the same event. If the same key arrives with a different body, PingRoom returns 409 idempotency_conflict; changing the message while keeping the old key is not a new event.

The fixed message deliberately omits the summary, customer name, assignee, description, priority, and link. The work-item key gives an authorized teammate a locator without copying the work record onto a lock screen. If even the key is sensitive in your environment, use a fixed message such as One item is ready for review and keep the source identity only in the header and correlation field.

These AI-generated editorial illustrations feature approved PingRoom avatars and Pingo the Pigeon, PingRoom's fictional Chief Marketing Officer. They are not Jira or PingRoom screenshots and do not depict customers.

Pingo has no Jira account, no private-Room access, and no authority to transition work or send this Ping. In the illustration, he is only watching the detailed record stay at the table while the small signal passes through—a boundary the human team configures.

Keep the work in Jira

The phone alert should answer one question: what changed that needs attention now? Jira should continue to answer everything else.

Keep these details in Jira:

• the summary, description, comments, attachments, and customer information;
• the assignee, reporter, priority, due date, and approval state;
• why the transition happened and what Ready for review means;
• later edits, reversals, or a move back to another status.

A Ping reports that the configured transition occurred. It does not prove that the work is correct, complete, approved, or safe to release. If the state changes back, Jira remains authoritative. Add a separate alert only when that reverse transition genuinely deserves attention; do not make every movement noisy.

Read the response and audit log correctly

When PingRoom accepts the request, it returns HTTP 200 with success: true and a notification_id. That means PingRoom created and queued the Ping. It does not guarantee that every phone displayed it. Connectivity, notification permission, Focus settings, Room mutes, and operating-system policy still apply.

Review Jira's automation audit log after the first test. A 4xx response means the request needs attention rather than a blind retry:

Keep Wait for response enabled while validating the rule. Do not write the secret URL into a log action. Atlassian's action guide supports hiding sensitive header values; if your Jira editor offers that control, use it for any credential-bearing header you add in other recipes.

Test with harmless work

Before enabling the flow for real work:

1. Create a sample work item with no sensitive information.
2. Move it into Ready for review once.
3. Check Jira's automation audit log, the PingRoom Room history, and one recipient device.
4. Retry the same recorded request with the same key and body; confirm there is still one Ping for that event.
5. Change the body but keep the key in a controlled test; confirm the request conflicts instead of silently changing the prior event.
6. Move the sample item out of the status and back in; confirm the later transition gets a different update time and creates a new Ping.
7. Rotate the webhook secret once in a test Room, then replace the URL in Jira and confirm the old URL no longer works.

For this article, we substituted representative Jira values into the recorded headers and payload and sent them to a local mock of PingRoom's documented endpoint. The check covered JSON, field limits, stable identity, an idempotent replay, and a changed-body conflict. It did not use a live Jira site, PingRoom Room, or recipient phone.

Atlassian currently measures automation use in executed steps pooled at the organization level. A trigger and web-request action both contribute to that use, and allowances depend on the organization's subscriptions and plan. Check the current allowance in Atlassian Administration before connecting a high-volume project. A single selected destination status is easier to budget and understand than a flow that runs after every edit.

If one Jira transition deserves that shared signal, create the destination Room and its webhook, test it with harmless work, and keep Jira as the place where the work lives.

Jira is a trademark of Atlassian. PingRoom is not affiliated with or endorsed by Atlassian.