Both existing answers use Automation for Jira's Send web request — that works, but there's a third approach worth knowing about that's often cleaner for "fire a webhook on a specific transition":
Native admin webhook with a JQL filter using the CHANGED operator.
In Settings → System → WebHooks, create a webhook subscribed to "Issue updated" and set the JQL filter to:
status CHANGED FROM "To Do" TO "In Progress" AND issuetype = Story
What this does: the JQL CHANGED operator matches issues at the moment their status transitions from one specific value to another. Jira evaluates the filter at the platform layer before the webhook fires — so only "Story moved from To Do → In Progress" events reach your endpoint. Nothing else triggers.
Why this is often preferable to the Automation approach:
- Doesn't consume Automation execution quota. Each Send web request counts toward your monthly rule-execution limit. Native webhooks don't.
- One webhook config, no Automation rule to maintain. Simpler to audit, easier to hand off.
- Multiple from/to combinations in one filter. Want to also fire on In Review → Done? Combine with OR:
(status CHANGED FROM "To Do" TO "In Progress" OR status CHANGED FROM "In Review" TO "Done") AND issuetype = Story
- The filter logic lives where the data lives — no "fastest path" / "slow path" execution variations between rules.
The CHANGED FROM/TO syntax is JQL's most underused operator — once you start thinking in "I want to know when X transitions to Y" terms instead of "field changed" terms, a lot of webhook and automation logic gets simpler.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.