SolarWinds Service Desk

SolarWinds Service Desk

Cloud-based ITSM platform following ITIL practices. Manages the full IT service lifecycle: incident → problem → change → release, plus asset management and procurement.

Entity Model

Service Management (ITIL)

• Incidents — service disruption reports. Lifecycle: New → Assigned → In Progress → Resolved → Closed. Priority/severity levels drive SLA timers.
• Problems — root cause investigations linked to multiple incidents. Lifecycle mirrors incidents with additional root cause analysis fields.
• Changes — planned modifications to IT infrastructure. Full CAB workflow: Requested → Planned → Approved → Implementing → Completed.
• Releases — bundled changes deployed together. Tracks deployment scheduling and success/rollback status.
• Risks — risk register entries with impact/probability assessments. Can link to changes and releases.

Asset Management / CMDB

• Assets — general IT assets (software licenses, cloud resources).
• Hardwares — physical IT equipment (servers, laptops, monitors) with specs, warranty, and location.
• Mobiles — mobile devices (phones, tablets) with carrier, IMEI, and MDM data.
• Configuration Items — CMDB entries with relationships to other CIs. The authoritative record for infrastructure dependencies.
• Catalog Items — requestable items in the self-service portal (new laptop, software access, etc.).

Procurement

• Contracts — vendor agreements with renewal dates, cost, and linked assets.
• Vendors — supplier directory with contact info and contract relationships.
• Purchase Orders — procurement requests linked to vendors and budget lines.

Organization

• Users — service desk agents and end users.
• Groups — assignment groups for routing incidents/changes.
• Roles — permission sets assigned to users.
• Departments — organizational structure for reporting and assignment.
• Sites — physical locations. Assets and users are associated with sites.
• Categories — hierarchical taxonomy for classifying incidents, changes, and assets.
• Solutions — knowledge base articles for known issue resolution.
• Audits — change audit trail across all entities.
• Change Catalogs — templates for standard/pre-approved changes.

Operational order

1. Ticket work: List incident, problem, and change queues; fetch one record by id when you need full detail; create by omitting id on the write path, update by passing id; add timeline comments on the parent ticket; delete only when retiring test or duplicate rows.
2. Knowledge: Search knowledge solutions before drafting agent replies; create or revise articles when publishing fixes.
3. Assets / CMDB: Browse hardware, other assets, and configuration items for inventory; creates need upstream-required fields (hardware serial; other assets manufacturer + asset_type).
4. Org routing: List assignment groups, users, departments, and sites for routing context; categories and roles are read-only directory lookups.
5. Procurement: List vendors, contracts, and purchase orders for spend and renewal reviews.
6. Compliance: Tenant-wide change history is available as read-only audit listings.

Gotchas

• Regional tenant: Token auth routes to a regional API base — United States, Europe, or Asia-Pacific. Match the credential region to the tenant (European console sign-in implies the EU region).
• Create payloads: Incidents, problems, and changes require a registered requester_email on create. The API wraps bodies as {incident: {...}}, {problem: {...}}, etc.
• Comments: Timeline notes attach to incidents, problems, or changes — use the parent record id and the matching collection type (incidents, problems, or changes).
• Pagination: List endpoints use integer page and per_page (default 25, max 100). List responses are JSON arrays.
• Hardware vs other assets vs CIs: Hardware needs serial numbers; other assets need manufacturer and asset_type; configuration items track CMDB dependencies separately.
• Roles and categories: Exposed as read-only lists — permission and taxonomy edits stay in the admin UI.