Automating Jira Service Management from the CLI

atlassian-cli is an independent, community open-source project, not affiliated with, endorsed by, or sponsored by Atlassian, and is not Atlassian's official CLI (acli). Product names are used only to identify compatibility.

What service desk automation means from the CLI

Service desk automation from the command line means driving Jira Service Management (JSM) with commands and scripts instead of clicks: raising requests, working queues, moving tickets through their workflow, and reading SLA timers from a single terminal binary. Anything you can do repeatedly in the agent portal, you can wrap in a shell script, a cron job, or a CI step so it runs the same way every time.

This post is a broad overview of that workflow using atlassian-cli. It covers the three things most service desk automation needs: requests (intake and updates), queues (what the team is working), and SLAs (whether you are on time). For deeper dives, the sibling posts on request management and the underlying Jira Service Management API pick up where this overview stops.

One clarification before the commands. atlassian-cli is an independent, community open-source project. It is not Atlassian's official CLI (acli) and is not affiliated with Atlassian. Use the official acli if you want first-party vendor support; use atlassian-cli if you want a single free Rust binary that spans Jira, Confluence, Bitbucket, and JSM under an MIT license.

Setup: authenticate and find your desk

Automation starts with a stored credential so scripts run unattended. Authenticate once with an API token and give the profile a name you will reuse:

# Store a reusable profile (API token from id.atlassian.com)
atlassian-cli auth login \
  --profile support \
  --base-url https://your-org.atlassian.net \
  --email you@your-org.com \
  --token $JSM_TOKEN \
  --default

Before you build anything on top of it, confirm the profile actually works. The auth test command exits non-zero on a bad credential, which makes it a safe first line in any script:

# Verify the credential before running automation
atlassian-cli auth test --profile support --format quiet && echo "auth ok"

Every JSM command takes an internal service desk ID, not the project key you see in the portal. List your desks once to find it:

# List service desks and note the numeric id
atlassian-cli jsm service-desk list --limit 25

# Inspect one desk in detail
atlassian-cli jsm service-desk get 10

Requests are also raised against a request type, which has its own numeric ID per desk. List the types for a desk so your create scripts point at the right one:

# Request types available on service desk 10
atlassian-cli jsm request-type list --servicedesk-id 10 --limit 25

# Which fields a request type expects
atlassian-cli jsm request-type fields 10 7

The command map

Before the details, here is the shape of the whole jsm surface. Most service desk automation is a combination of these building blocks. Every command accepts the global --format json flag, so any of them can feed a script.

Automating request intake

The most valuable automation is turning signals from other systems into tickets. A monitoring alert, a form submission, or a scheduled check can all raise a JSM request with one command instead of a human filling in the portal:

# Create a request from a script
atlassian-cli jsm request create \
  --servicedesk-id 10 \
  --request-type-id 7 \
  --summary "Access issue" \
  --description "Can't log in"

Once a request exists, the rest of its lifecycle is scriptable too. You can read its current status, add a public reply that the reporter sees on the portal, or add an internal note:

# Read one request and its current status
atlassian-cli jsm request get SD-123
atlassian-cli jsm request status SD-123

# Public reply visible to the customer
atlassian-cli jsm request add-comment SD-123 \
  --body "Investigating, we'll update you shortly." \
  --public

# Add a watcher so an on-call engineer is looped in
atlassian-cli jsm request add-participant SD-123 --account-id 5f...1a

To review intake in bulk, list all requests on a desk and switch the output to JSON for downstream tooling. The --envelope flag wraps list results in a {"data": [...], "count": N} object, which is easier to parse in a script:

# All requests on a desk, as parseable JSON
atlassian-cli jsm request list \
  --servicedesk-id 10 \
  --limit 50 \
  --format json --envelope | jq '.count'

Working queues from the terminal

Queues are how JSM agents decide what to pick up next. Reading them from the CLI lets you build your own dashboards, load reports, or alerts without touching the UI. Start by listing the queues on a desk, then pull the issues inside a specific queue by ID:

# List the queues configured on service desk 10
atlassian-cli jsm queue list 10

# Inspect one queue's definition
atlassian-cli jsm queue get 10 5

# Pull the issues currently in queue 5
atlassian-cli jsm queue issues 10 5 --limit 25

Combined with --format json and jq, queue data becomes a simple way to answer questions like "how many unassigned tickets are waiting?" without opening Jira. For example, count the issues in a queue as a scheduled check:

# Count issues waiting in the triage queue
atlassian-cli jsm queue issues 10 5 \
  --format json | jq '. | length'

Because the command exits non-zero on failure and prints structured data on success, this fits naturally into a cron job that posts a morning summary to your team chat, or a CI gate that fails a deploy when the incident queue is above a threshold.

For a weekly report that a manager can open, swap the format to CSV and write it to a file. The same data that drives a script becomes a spreadsheet without any extra tooling:

# Export a queue's issues to CSV for a weekly review
atlassian-cli jsm queue issues 10 5 \
  --format csv > triage-queue.csv

Tracking SLAs programmatically

SLAs are the point of a service desk: are you answering and resolving inside the time you promised? The CLI reads the SLA timers on any request, so you can flag breaches before they happen instead of finding out in a monthly report.

# Every SLA metric on a request
atlassian-cli jsm sla list SD-123

# One specific metric, e.g. time to resolution
atlassian-cli jsm sla get SD-123 --sla-id time-to-resolution

The real value comes from combining SLA reads with queue reads on a schedule. Pull the open issues in a queue, then check each one's SLA and surface anything close to breaching. In JSON form, the ongoing cycle carries the remaining time, so a short script can decide what to escalate:

# Loop the triage queue and print SLA state per request
for key in $(atlassian-cli jsm queue issues 10 5 --format json | jq -r '.[].key'); do
  echo "== $key =="
  atlassian-cli jsm sla get "$key" --sla-id time-to-resolution --format json
done

This is service desk automation at its most useful: a scheduled job that watches the numbers a human would otherwise have to remember to check.

Approvals and transitions in scripts

Many service desk workflows pause on an approval, an access request that needs a manager's sign-off, or a change that needs a review. Both approvals and workflow transitions are scriptable, which is what lets you automate the routine parts of a fulfilment process.

# See pending approvals on a request
atlassian-cli jsm approval list SD-123

# Approve or decline a specific approval
atlassian-cli jsm approval approve SD-123 --approval-id 1
atlassian-cli jsm approval decline SD-123 --approval-id 1

Transitions move a request through its workflow. Always check the available transitions first, because valid targets depend on the request's current status:

# List valid transitions, then move the request
atlassian-cli jsm request transitions SD-123
atlassian-cli jsm request transition SD-123 --transition "In Progress"

A full end-to-end example

Here is a small script that ties the pieces together: it raises a request from an alert, adds an internal note, and prints the resolution SLA so an on-call engineer sees the clock immediately. This is the kind of glue you would trigger from a monitoring webhook.

#!/bin/bash
# Raise a JSM request from an alert and report its SLA
set -euo pipefail

PROFILE="support"
DESK=10
TYPE=7

# Step 1: create the request, capture its key from JSON
KEY=$(atlassian-cli jsm request create \
  --profile "$PROFILE" \
  --servicedesk-id "$DESK" \
  --request-type-id "$TYPE" \
  --summary "[auto] Checkout latency high" \
  --description "p95 latency breached threshold at $(date -u)" \
  --format json | jq -r '.issueKey // .key')

echo "Created $KEY"

# Step 2: add an internal note for the on-call engineer
atlassian-cli jsm request add-comment "$KEY" \
  --profile "$PROFILE" \
  --body "Auto-raised from alerting. Runbook: check the checkout service dashboard."

# Step 3: print the time-to-resolution SLA so the clock is visible
atlassian-cli jsm sla get "$KEY" \
  --profile "$PROFILE" \
  --sla-id time-to-resolution

echo "Done."

Every command here is a real subcommand, and every one accepts --profile so the same script can target staging or production by swapping a single value. Start with read-only calls (service-desk list, queue issues, sla list) to confirm your IDs before wiring up anything that writes. For the full list of flags on every JSM command, see the command reference.

FAQ

Related Resources