Jira Service Management Administration & ITSM Engineering
ITSM · Jira Service Management · IT Operations
I design and administer Jira Service Management environments that make IT support processes easier to manage, measure and improve — from request intake through resolution.
The problem
Most people use Jira Service Management as an end user — they raise a ticket and wait. The harder discipline is on the other side of the portal: designing the request types, workflows, queues, SLAs, automation and permissions that make a service desk actually run, and keeping them healthy as the operation changes.
I have 7+ years of hands-on JSM administration — building service projects from scratch and running their ongoing administration. This page shows that work at a generic, sanitized level: every queue, status, request and identity below is illustrative, and no confidential configuration appears.
The approach
Treat a service project as an operating system for support, not a form with a submit button. Model the real request categories, give each the states the work actually has, route and prioritize with JQL-driven queues, hold the process to response and resolution SLAs, automate the repetitive parts, and gate access with permission schemes that separate agents from customers.
Then keep it alive: administration is continuous — new request types, workflow tweaks, queue tuning, automation fixes, permission changes, reporting and troubleshooting. The diagrams below are the sanitized shape of that work; the technical view carries the configuration detail behind each stage.
My role — Hands-on JSM administration across 7+ years: service-project setup from scratch, request type and form design, workflow engineering, queue and SLA configuration, automation, permissions, reporting and ongoing service-desk improvement.
How it works
Workflow A — The service request pipeline
One request, end to end: intake, classification, workflow and automation, queue, SLA, resolution, closure and reporting. Select any stage — each is a real configuration surface, not decoration.
Swipe or scroll to explore the full diagram →
01Request intake
Someone needs something and starts at the self-service portal instead of sending an email. They pick what they need from clearly named options.
Select any node in the diagram to inspect it.
- Person
- Connected system
- Internal layer
- This project
- Info
- Success
Workflow B — Building a service project from scratch
The implementation sequence I follow to stand up a new JSM service project. Recruiter view shows the business flow; technical view shows the configuration behind each phase.
Swipe or scroll to explore the full diagram →
01Understand & scope
Understand the service, the people it serves and what a good outcome is — the step that stops you building the wrong thing quickly.
Select any node in the diagram to inspect it.
- Internal layer
- This project
- Success
Workflow C — Access request, orchestrated
A sanitized access-request flow — the kind JSM handles well and where it meets my IAM background. Alex Morgan is a sample identity; no real request is shown.
Swipe or scroll to explore the full diagram →
01Request raised
Alex raises an application-access request from the portal and fills in a short, specific form.
Select any node in the diagram to inspect it.
- Person
- Internal layer
- This project
- Info
- Success
Workflow D — Incident, from raised to reported
A sanitized incident flow with status progression and an escalation branch. Illustrative only — no real incident, priority target or team name appears.
Swipe or scroll to explore the full diagram →
01Incident raised & triaged
Something breaks and is reported. It's sized up — how bad, how urgent — which sets how fast it must move.
Select any node in the diagram to inspect it.
- Person
- Internal layer
- This project
- Info
- Success
Example output
Access Requests queue — illustrative
One queue, one SLA policy, synthetic data.
- Application access · Alex Morgan
- In Review — response SLA met
- New-starter onboarding
- Approved — within resolution SLA
- Distribution-list change
- In Progress — assigned by automation
- Password reset
- Resolved — SLA met
- VPN access
- In Progress — resolution SLA at risk
- Software install
- Waiting for approval — SLA paused
- Shared-mailbox access
- Open — response SLA breached
Illustrative queue for a single request type. Requests, people, statuses and SLA states are synthetic; no real ticket IDs, identities or SLA targets appear. Real queues are JQL-defined and vary per operation.
Architecture
A service project, in one picture
The sanitized shape of a JSM service project: customers and the portal in front, the configured project at the centre, integrations and reporting around it, and the administrator keeping it all healthy.
Swipe or scroll to explore the full diagram →
- Person
- Connected system
- This project
- Person
- Connected system
- This project
This is the shape of the work, not any real service desk. Every request type, queue, status, SLA state and identity on this page is synthetic. The access-request flow connects naturally to the IAM and SSO work elsewhere on this site; the reporting connects to the Multi-Project Operations Dashboard — JSM is where those disciplines meet a running service operation.
My contribution
7+ years of hands-on Jira Service Management administration — building service projects from scratch and running their ongoing administration. Grouped by configuration surface, this is the work behind the diagrams above.
Project setup & configuration
- Service projects from scratch
- Issue & request types
- Portal structure & forms
- Custom fields
- Screens & notifications
- Project roles
Workflows & automation
- Workflow design — statuses & transitions
- Approval stages
- Conditions, validators & post-functions
- Assignment & request routing
- Field updates & status transitions
- Escalations, reminders & notifications
Queues, SLAs & assignment
- JQL-driven queues
- Priority & team-specific queues
- Response & resolution SLAs
- Business calendars
- Start / pause / stop conditions
- Breach & at-risk visibility
Permissions, reporting & administration
- Permission schemes — agents vs customers
- Request participants & issue visibility
- Dashboards, SLA & workload reporting
- Ongoing configuration changes & queue tuning
- User / agent administration & troubleshooting
- Documentation & process improvement
What I build with JSM
- IT help desk & internal IT operations portal
- Employee support portal
- Access & application-access request management
- Onboarding / offboarding requests
- Incident management & operational escalation
- Service requests, approvals & SLA-based support
Key engineering decisions
- Service project setup from scratch
- Request types & forms
- Workflow engineering
- Queues & assignment
- SLA configuration
- Automation rules
- Permissions & roles
- Reporting & dashboards
Switch to the technical view for the engineering trade-offs behind these.
Challenges & limitations
- Everything on this page is synthetic: 'Alex Morgan', the illustrative queue, the sample statuses and SLA states. No real ticket IDs, employee names, internal project names, customer data, company-specific workflows, domains, URLs, credentials or confidential SLA targets appear.
- Capabilities are platform-accurate — nothing here claims a customization JSM does not support. The example use cases are described as solution types I can build and administer, not as separately named production projects unless the rest of this portfolio already supports them.
- No ticket volumes, team sizes, SLA figures, response times or business metrics are given, because none were supplied and inventing them would be dishonest. This page describes the discipline and the configuration, not statistics.
- Integrations shown — Slack, Confluence, PagerDuty-style escalation — reflect tools used in real operations and elsewhere on this site; the diagrams do not imply every JSM feature or integration is in play for every service desk.
What I learned
A service desk is only as good as the design behind the portal. Anyone can raise a ticket; the value is in the request types, workflows, queues, SLAs, automation and permissions that turn a stream of requests into a measurable, improvable operation — and in the ongoing administration that keeps it fitting the work as the work changes.
Project status
Hands-on Jira Service Management administration and ITSM engineering across service-project design, workflows, request types, queues, SLAs, automation, permissions, reporting and ongoing administration — presented fully sanitized with synthetic data only. Open to JSM setup, administration, automation, reporting and operational-workflow work.