Factorant

Docs / Jira Service Management

Jira Service Management

For sites with service spaces. A separate check from the scan: it starts the first time you open Service spaces, and Check again runs it any time.

It reads request types, their forms, queues, roles, organizations, request counts and approvals. It never reads what a request says. To find stuck approvals it reads each waiting approver's account, to see whether it is active, and keeps none of it: only counts, names and, for stuck approvals, the request key.

Requests and forms

Request types that cannot be raisedBreaks requests

A required field hidden from the form, with no preset or default value.

How it decides

Requests of that type fail on the portal, and by email too if the email channel uses the type.

Request types customers cannot find

Request types in no portal group.

How it decides

Fine if the type is meant for agents or email only.

Unused request types

No requests of a type in the last 180 days, while the space had others.

How it decides

Counted with Jira search, numbers only, in the first 50 service spaces and up to 100 request types a space. Requests the app cannot see, such as those under an issue security level, are not counted. Fine if the type is seasonal or new.

Queues

Broken queuesQueue broken

Queues whose search Jira says is not valid.

How it decides

A syntax or function error: agents get an error instead of the queue. Customers can still raise requests.

Queues worth a look

Queues whose search names a field or value Jira does not show the app, or that Jira warns about.

How it decides

Jira judges the search with the app's permissions, so the field may be deleted, or only hidden from the app; agents may see a working queue. Open the queue to check.

People and customers

Agents without access

People in a space's Service Desk Team role with no Jira Service Management access.

How it decides

People with another Jira licence can still view requests and comment internally, which can be on purpose. Counted per space; members of groups in the role are not checked.

Empty or unused organizations

Customer organizations with no members, or in no service space the app can see.

How it decides

Remove them if nobody needs them, or add them where their customers are.

SLAs and approvals

Signs of SLA trouble

In the last 30 days: requests with no SLA, an SLA paused with almost no time used, or an SLA breached on half or more of its requests.

How it decides

Apps cannot read SLA settings, so these are symptoms seen in request counts, with minimum request counts, so one or two requests do not raise a flag. Check the SLA's conditions, goals and calendar.

Requests stuck on approvalStuck

Requests waiting on an approver whose account is deactivated.

How it decides

When every approver it waits on is deactivated, the request cannot move on. Up to 25 waiting requests a space are checked, in the first 50 service spaces and 200 requests in all; the page says when it stops there. Only the request key is kept, never who.

What it cannot check

Atlassian gives apps no way to read SLA goals and calendars, customer permissions, email channels or approval steps. The page lists them with how to check each yourself.