Manage Service Desk Requests from the Terminal

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.

The JSM Request CLI in One Minute

The jsm request cli in atlassian-cli lets you create, transition, and comment on Jira Service Management requests entirely from the terminal. Instead of clicking through the agent view for every ticket, you run one command: atlassian-cli jsm request create to raise a request, atlassian-cli jsm request transition to move it through the workflow, and atlassian-cli jsm request add-comment to reply to the customer or leave an internal note.

That matters most when the work is repetitive or scripted. Bulk-raising onboarding tickets from a CSV, auto-acknowledging every new request in a queue, posting a maintenance-window notice across a batch of open requests: these are minutes on the command line and a long afternoon of clicking in the browser. Every command speaks the Jira Service Management REST API directly, so the actions are exactly the ones an agent would take in the portal, just faster to repeat and easy to wrap in a shell script.

This guide covers the full lifecycle of a single request from the terminal. If you want the higher-level tour of every JSM command group, start with the JSM CLI guide or the JSM command hub. Here we go deep on the request itself.

Find Your Service Desk and Request Type IDs

Creating a request needs two numeric IDs: the service desk it belongs to and the request type (the "form" a customer would pick, like Get IT help or Report a bug). Both are quick to look up.

# List every service desk you can see, with IDs
atlassian-cli jsm service-desk list --limit 25

# List the request types available in service desk 10
atlassian-cli jsm request-type list --servicedesk-id 10 --limit 25

Before raising a request programmatically, it helps to know which fields a request type expects, especially if some are required. Inspect them directly:

# Show the fields for request type 7 in service desk 10
atlassian-cli jsm request-type fields 10 7

Add --format json to any of these and pipe the result into jq when you want to script the ID lookup instead of reading it off the screen. Authentication is a one-time atlassian-cli auth login; see the auth setup docs if you have not connected your site yet.

Create a Request

With the two IDs in hand, raising a request is a single command. The summary and description are the only content you need for a basic request:

# Create a new request in service desk 10, request type 7
atlassian-cli jsm request create \
  --servicedesk-id 10 \
  --request-type-id 7 \
  --summary "Access issue" \
  --description "Can't log in to the VPN since this morning"

The command returns the newly created request key, for example SD-123. That key is the handle for everything that follows: transitions, comments, participants, and status checks all take it as their first argument. Capture it in a script so the next steps can act on the request you just made:

# Create a request and capture its key with jq
KEY=$(atlassian-cli jsm request create \
  --servicedesk-id 10 \
  --request-type-id 7 \
  --summary "New laptop for starter" \
  --description "MacBook Pro, start date 2026-07-20" \
  --format json | jq -r '.issueKey')

echo "Raised $KEY"

Transition a Request

Requests move through a workflow: Waiting for support, In progress, Waiting for customer, Resolved, and so on. The available transitions depend on the current status and the workflow the project uses, so list them before you apply one. Guessing a transition name that does not exist just returns an error.

# Step 1: see which transitions are available right now
atlassian-cli jsm request transitions SD-123

# Step 2: apply one by name
atlassian-cli jsm request transition SD-123 --transition "In Progress"

After transitioning, confirm the state landed where you expected:

# Check the current status of a request
atlassian-cli jsm request status SD-123

The list-then-apply pattern is the same shape as Jira issue transitions, which keeps the mental model consistent whether you are working a software board or a service desk queue. When you script it, fetch transitions with --format json, pick the target by name, then apply it, so the automation adapts to whatever workflow the project happens to use.

Comment: Public Reply vs Internal Note

Comments are where the request CLI earns its keep, because the same subcommand handles both customer-facing replies and agent-only notes. The difference is one flag.

# Public reply: the customer sees this on the portal
atlassian-cli jsm request add-comment SD-123 \
  --body "We're investigating and will update you within the hour." \
  --public

# Internal note: visible to agents only (omit --public)
atlassian-cli jsm request add-comment SD-123 \
  --body "Reproduced on staging, escalating to network team."

Add --public and the comment is posted as a reply the requester sees in their portal and email. Leave it off and the comment is an internal note that stays with the agents. This split is the whole reason the flag exists: a single scripted step can acknowledge the customer publicly and log context privately without touching the UI.

Reading the conversation is just as direct:

# Read the most recent comments on a request
atlassian-cli jsm request comments SD-123 --limit 25

Because add-comment takes plain text on --body, you can template it. A shell loop can post the same maintenance notice to every request in a list, or feed a per-customer message generated upstream. That is the kind of repetitive reply that is tedious in the browser and trivial from the terminal.

Participants and Subscriptions

Two more actions round out day-to-day request handling. Participants are extra people looped into a request (a manager, a second engineer), and subscriptions control whether you personally get notified about updates.

# Add someone as a participant on a request
atlassian-cli jsm request add-participant SD-123 --account-id 5f...1a

# Remove a participant
atlassian-cli jsm request remove-participant SD-123 --account-id 5f...1a

# See who is currently participating
atlassian-cli jsm request participants SD-123

# Follow / stop following notifications for a request
atlassian-cli jsm request subscribe SD-123
atlassian-cli jsm request unsubscribe SD-123

Participants take an --account-id, which is the Atlassian account identifier for the person you are adding. Add them when a request needs an extra set of eyes, and subscribe or unsubscribe to tune your own notification noise without leaving the terminal.

Request Subcommand Reference

Every request action lives under atlassian-cli jsm request. Here is the full set, so you have one table to scan instead of nine separate examples.

Every command accepts the global flags too: --format json|csv|yaml for machine-readable output, --profile to target a specific site, and --debug to log the underlying HTTP calls when something misbehaves. The complete list lives in the command reference.

A Scripted Intake Example

Here is where the pieces combine. This snippet raises a request, immediately acknowledges the customer, logs an internal note, and moves the ticket into progress, the exact opening moves an agent makes, done in one pass.

#!/bin/bash
# Raise a request and run the standard intake steps
set -euo pipefail

# 1. Create the request and grab its key
KEY=$(atlassian-cli jsm request create \
  --servicedesk-id 10 \
  --request-type-id 7 \
  --summary "VPN access down" \
  --description "Multiple users cannot connect since 09:00" \
  --format json | jq -r '.issueKey')

# 2. Public acknowledgement to the customer
atlassian-cli jsm request add-comment "$KEY" \
  --body "Thanks for flagging this. We're on it and will update shortly." \
  --public

# 3. Internal note for the on-call engineer
atlassian-cli jsm request add-comment "$KEY" \
  --body "Suspected gateway outage, paging network on-call."

# 4. Move it into progress
atlassian-cli jsm request transition "$KEY" --transition "In Progress"

echo "Intake complete for $KEY"

Wire that into a webhook, a cron job, or a chat command and your standard intake is a single step instead of five clicks per ticket. For handling requests already sitting in a queue, and for reporting on how fast they clear, see the sibling guides on service desk automation and queue and SLA reporting.

How This Differs from acli

atlassian-cli is an independent, community open-source project. It is not Atlassian's official CLI (acli) and is not affiliated with, endorsed by, or sponsored by Atlassian. Use the official acli when you want first-party vendor support. Use atlassian-cli when you want a single free, MIT-licensed Rust binary that spans Jira, Confluence, Bitbucket, and Jira Service Management with the same command grammar across all four. The jsm request group covered here is one slice of that unified surface.

FAQ

Related Resources