Triage new Jira Service Management requests before anyone opens them

When a new customer request is raised in Jira Service Management, I want it triaged before a human ever opens it. Trigger this workflow from a Jira Service Management webhook that fires when a request is created.

Use Get Customer Request to pull the full request: the summary, the description, and the request type. Read the customer's actual wording rather than trusting the request type alone, because people routinely file under whichever category was easiest to find in the portal.

From that wording, judge two things: the category of the problem, and how urgent it genuinely is. Base urgency on real impact signals in the text, such as how many people are blocked, whether something is completely down versus merely awkward, whether money or a hard deadline is at stake, and what consequences the customer describes. Treat urgent sounding language on its own as weak evidence, since some people write every ticket in capitals and others understate a genuine outage.

Use Search Service Desk Articles to look for an existing knowledge base article that already answers the request. Only treat an article as a match if it actually addresses this customer's problem. If nothing genuinely fits, carry on without one rather than linking something loosely related.

Then act on the underlying issue. Jira Service Management customer requests are Jira issues, and the request key (for example HELP-13) also works against the Jira platform API for anything the service desk API does not expose. So use the Jira Edit Issue action to set the priority field to match your urgency judgement and to add triage labels for the category you decided on. Add labels to the existing set rather than replacing it, so nothing already on the issue is lost.

Use Create Request Comment to post a public acknowledgement back to the customer. Keep it plain and warm rather than robotic. Confirm in a sentence what you understood the problem to be, so they know they were actually read, and say that a person will follow up. When you found a genuinely matching knowledge base article, link it and briefly say why it might help in the meantime. Never promise a specific resolution time.

Use the Slack Send a Message action to alert the support channel, but only for requests you judged high urgency, so the channel stays meaningful. Everything else should be triaged silently. The Slack message should carry the request key, a one line summary of the problem, the priority and labels you set, the reason you judged it urgent, and a link to the request.

Never resolve, close, or transition a request on your own, and never change its status. This workflow prepares the ticket and greets the customer; a human always does the actual resolution. If a request is too vague to judge confidently, set a normal priority, label it for manual review, post the acknowledgement without an article link, and skip the Slack alert.