Service Project Standards for JSM
Capture what one good service project looks like. Compare every other one against it. Know the moment any of them drift.
Published by Matify for Atlassian Jira Service Management Cloud. Read-only: the app never writes to your Jira or JSM configuration.
What it is for
A Jira Service Management site accumulates service projects the way a filing cabinet accumulates
folders: each one starts as a copy of a reasonable idea and slowly drifts as different people configure
it over time. Nothing in Jira tells you which desk still matches the standard, which one quietly lost a
request type's required field, or which queue's JQL stopped matching what the portal actually shows.
This app closes that loop, read-only, end to end:
- An administrator captures a standard from a reference service project: its request
types, form fields (including hidden and preset fields), queues, workflow/issue-type/screen/permission/
notification scheme content, screens, roles and components.
- The app compares every assigned service project against that standard, on a daily
light scan and a weekly full scan, or on demand.
- Each project gets a score, and every deviation becomes a finding
with a plain-language summary and a rebuild checklist — because Atlassian publishes no write API that
would let any app safely fix the deviation for you.
- The change log records what moved between two scans — the record Jira itself does
not keep for request types, fields and queues.
- Exceptions let an admin accept a specific deviation, with a reason, an owner and an
optional expiry, without it re-appearing as a finding on every scan until it is reviewed again.
- Evidence export produces a CSV or a printable HTML summary of the whole matrix, for
an auditor who was not in the room when any of this happened.
Where things live
| You want to | Go to |
|---|
| Capture a standard, see the matrix, manage exceptions and settings | Jira Settings → Apps → Service Project Standards |
| See one service project's own deviations and rebuild checklist | That project's Project settings → Standards check |
| Put the conformance score and drift on a dashboard | Add the Service project standards gadget to a Jira dashboard |
What it deliberately does not cover
Stated in the product's own Coverage tab and repeated on every exported evidence pack, not hidden in a
footnote: SLA goals/calendars/conditions, automation rules, portal branding and settings, customer/portal
permissions, fields that live in a JSM Form, issue security scheme association, team-managed service
projects (they have no shared schemes to compare), and exactly who changed something and when (Jira's own
audit log does not record it for these object types — the change log reports what changed between two
scans, not a timestamped author). Each exclusion names the actual API limitation behind it rather than
saying "not supported."
Requirements
- Jira Service Management Cloud, company-managed (classic) service projects. Team-managed projects are
listed as not comparable rather than silently skipped.
- A Jira administrator to install the app, capture the first standard and assign projects to it.
Documentation
Trust
The app runs entirely on Atlassian's platform. It makes no external network call of any kind — no
analytics, no error reporting, no content delivery network, no remote fonts. Its Jira permission set is
30 granular read scopes plus its own storage scope and the personal-data reporting scope: zero write
scopes, zero manage:* scopes, zero issue-content scopes. It stores Atlassian account ids and
a compact, hashed form of your service project configuration — never issue content, never a display name
or email address.
Support
mira.maty@web.de, or the support page. Please do not include
credentials, personal data or confidential content in a support request. Suspected security
vulnerabilities go to the email address privately, never to a public issue.