Jira has an assignee field, an automation engine, and no idea who is on call. Pagerly knows who is on call and has no opinion about your Jira workflow. Connecting the two takes about five minutes and removes an entire category of stale tickets.

There are three ways to do it. Which one you want depends on where the ticket is created.

Option 1: Jira Automation

This is the one to start with. It runs inside Jira, needs no code, and covers every issue created in a project regardless of who created it or how.

The rule is two components. Fetch the on-call user's Atlassian account ID from Pagerly, then assign the issue to it.

Building the rule

Create a new automation rule with Work item created as the trigger. If you only want this on bugs rather than everything, add a condition — Work item type equals Bug — before the actions.

Then add the first action: Add component → Action → Send web request.

Web request URL: https://api.pagerly.io/pagerly/o/currentusersforjira?teamname=<teamname>, replacing <teamname> with your Pagerly team name.
HTTP method: GET
Body: empty
Header: X-APIKEY set to your Pagerly API key.

Now the important part. Tick "Delay execution of subsequent rule actions until we've received a response for this web request".

If you skip that checkbox, the rule fires the request and immediately runs the next action without waiting. The smart value holding the response is empty, the assign action receives nothing, and the issue is created unassigned — with a green tick in the audit log. It is the single most common reason these rules appear to do nothing.

Then add the second action: Add component → Action → Assign work item. Choose Smart value as the method, and under User enter:

{{webhookResponse.body.accountId}}

Save, enable, and file a test bug.

What the endpoint gives you

curl --location 'https://api.pagerly.io/pagerly/o/currentusersforjira?teamname=devops' \
  --header 'X-APIKEY: <API-KEY>'

{ "accountId": "63c18e6494d18cbf677351fa" }

Pagerly resolves the current on-call user for that team — respecting overrides, swaps and holiday calendars — looks their email up in your connected Jira instance, and returns the Atlassian account ID directly. The automation never has to do its own user search, which matters more than it sounds like it should, because Jira user search is unreliable in exactly this situation. Many Atlassian instances withhold email addresses from the user search API depending on each user's profile visibility settings, so searching by email returns nothing and you silently fall back to display-name matching.

Handling the gap

If nobody is on call at that moment — a rota gap, an overnight window with no cover — there is no account to return. Add a condition between the two components:

{{webhookResponse.body.accountId}} is not empty

On the else branch, assign to a fallback lead or add a comment tagging the team. The point is that the ticket ends up somewhere visible rather than back in the unassigned pile you were trying to eliminate.

Making open tickets follow the rota

The rule above assigns at creation. Some teams also want in-flight work to move at shift handover. That is a second, scheduled rule running at your handover time, with a JQL filter and the same two components:

project = SUP AND status = "In Progress" AND labels = follows-oncall

Note the label. Do not move everything. An issue someone is three hours into debugging should not change hands because the clock struck six — you lose all the context that makes the next hour productive. Label the tickets that are genuinely rota-owned and leave the rest with their owner.

Option 2: the Jira REST API

For tickets your own services create. Two calls: ask Pagerly, then assign.

ACCOUNT_ID=$(curl -s \
  'https://api.pagerly.io/pagerly/o/currentusersforjira?teamname=devops' \
  -H "X-APIKEY: $PAGERLY_API_KEY" | jq -r '.accountId')

curl -s -X PUT \
  "https://your-domain.atlassian.net/rest/api/2/issue/SUP-1423" \
  -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d "{\"fields\": {\"assignee\": {\"id\": \"$ACCOUNT_ID\"}}}"

A successful assignment returns 204 No Content.

If you want more than the account ID — say you also want to post a Slack message mentioning the assignee — use the generic endpoint instead, which returns the name, email and Slack member ID:

curl -s 'https://api.pagerly.io/pagerly/o/currentusers?teamname=devops' \
  -H "X-APIKEY: $PAGERLY_API_KEY"

[{ "name": "mansi", "email": "mansi@pagerly.io", "id": "U04CTTV5Z6G", "imageurl": null }]

That id is the Slack member ID, so <@U04CTTV5Z6G> in a Slack message produces a real mention. In practice the Slack ping does more work than the Jira notification — Jira notification settings are personal, frequently muted, and email-based.

Option 3: creating the ticket from Slack

The third path skips the assignment problem entirely by never creating an unassigned ticket in the first place.

When Jira is connected to Pagerly, a Slack conversation can become a Jira issue directly — react to a message with a configured emoji, or fill in a short form. The issue is created already assigned to the team's current on-call, and the Slack thread and the Jira issue stay linked from then on. Comments flow both ways, and status transitions can be driven from the thread.

This matters for a specific and common case: the bug that gets reported in a channel rather than filed. Someone says "checkout is throwing 500s for EU cards" in #support, three people reply, and it never becomes a ticket. An emoji reaction turning that into an assigned issue in two seconds is the difference between it being tracked and it being forgotten.

What usually goes wrong

Issue created, assignee empty, no error in the audit log. The delay checkbox on the web request is not ticked. This is the first thing to check, every time.

The assign action returns 400. The account ID was empty, which means nobody was on call. Add the not-empty condition and a fallback.

The rule assigns the wrong person. The teamname parameter points at a different Pagerly team than you think. List your teams with GET /o/zapier/allteams and check the exact name.

The account resolves but the assignment fails. The user has no Jira licence, or no browse permission on that project. Being on the rota does not grant Jira access — either fix the permission or take them off that rota.

It worked for months and now it does not. Somebody renamed the Pagerly team. The URL still returns a response, just not the one you want. This is a good argument for alerting on non-200s from the endpoint rather than assuming it always works.

Pick the right distribution model

One decision worth making deliberately: whether every ticket in a shift goes to the shift holder, or whether assignment advances round-robin per ticket.

Time-based is right when on-call means "you own production today" and volume is low enough that one person seeing everything creates useful pattern recognition. Round robin is right for support volume, where balanced load matters more than continuous context. Both are backed by the same Pagerly endpoint, so the automation you build today does not need to change if you switch models later.

Full setup details are in the Jira assignment documentation. For the wider pattern across tools, see assigning bugs and tickets to the current on-call.