FlowRunner
PricingContact
Theme
Start Free

SolarWinds Service Desk

Helpdesk & ITSM

Connect AI agents to SolarWinds Service Desk, the cloud ITSM platform formerly known as Samanage. Agents create and update incidents, append comments, and look up users, hardware assets, and categories to triage and route tickets.

7 actions API key available
A monitoring alert fires for a service outage, or an inbound request email arrives
List Categories resolves the right category name for this class of issue
List Users looks up the requester's email so the ticket is attributed to a real person
Create Incident opens the ticket with a summary, description, priority, and category
The agent inspects the affected system and drafts a triage note with probable cause
The on-call engineer reviews the triage and decides whether this is resolved or needs escalation
Update Incident applies the engineer's decision, changing state and appending the resolution comment

What This Integration Enables

SolarWinds Service Desk is where an IT team's obligations become visible: every incident carries a state, a priority, and a requester who is waiting. The failure mode of most service desks is not bad engineers, it is that the queue is fed and groomed by hand. FlowRunner agents take over the feeding and grooming: they open incidents from alerts and forms, look up the right requester and category, keep state and priority current, and append comments so the activity trail reflects what actually happened. - Open incidents automatically from monitoring alerts, forms, and inbound email - Triage state, priority, and category, and append public or internal comments - Look up requester and assignee details when routing or enriching tickets - Reconcile the hardware asset inventory and link assets to incidents - Pull queue data into spreadsheets and channels for SLA reporting The deeper win is that the service desk stops being a place where context goes to die. Because agents write their diagnostics into the ticket as comments, using the internal-only flag for material the requester should not see, the incident record becomes the actual investigation log rather than a summary someone reconstructs afterward. When the same class of alert fires next quarter, the history is in the queue where the next engineer will look, not in a chat scroll that expired. The place FlowRunner's [human-in-the-loop](/concepts/human-in-the-loop) discipline matters here is state. Agents can move a ticket all the way to the edge of Resolved, but the claim that a requester's problem is fixed belongs to a person. Everything before that line, opening, categorizing, prioritizing, commenting, is machine work, and the team's attention gets spent only where judgment is actually required.

Without FlowRunner

Alerts and tickets live apart Monitoring fires in one tool while the service desk queue fills up by hand, hours later
Triage is retyping Engineers copy alert context into tickets before they can even start diagnosing
Closure is guesswork Tickets get resolved in bulk cleanups, and nobody is sure the requester's problem was actually fixed

With FlowRunner

Every alert is a ticket Incidents open themselves with category, priority, and requester already set
Context arrives pre-assembled The agent appends diagnostics and probable cause as comments before a human ever opens the ticket
Resolution is a decision State changes to Resolved or Closed only after a person confirms the fix, with the reasoning on the record

Use Case Scenarios

Alert to attributed ticket in one motion

A disk usage alert fires for a database host. The agent calls Create Incident with the alert payload as the description, sets priority from the alert severity, resolves the category with List Categories, and attributes the requester by matching the service owner through List Users. A message posts to [Slack](/integrations/slack) with the incident number and priority so the on-call engineer starts from a formed ticket, not a raw alert.

SLA reporting without the Friday export

On a schedule, the agent calls List Incidents and pages through the open queue, capturing number, state, priority, assignee, and age. Each row lands in [Google Sheets](/integrations/google-sheets) via an append, and a summary posts to the ops channel flagging tickets approaching SLA breach. The service desk manager reads live queue health instead of a week-old CSV, and breaches get attention while they are still preventable.

Resolution notes that requesters actually receive

An engineer marks a fix complete in the ops channel. The agent calls Get Incident to pull the full ticket, drafts a plain-language resolution summary from the comment trail, and pauses for the engineer to approve the wording. On approval, Update Incident sets the state to Resolved and appends the summary as a public comment, and [Gmail](/integrations/gmail) sends the requester next steps. The requester hears what happened in words meant for them, and the ticket record matches the email.

Human-in-Loop Highlight

Update Incident can set an incident's state to Resolved or Closed, and that state change is a claim made to a waiting requester: your problem is fixed. Close wrongly and the requester reopens angrier, the SLA clock restarts against you, and the incident history says the team declared victory early. So FlowRunner agents in a SolarWinds Service Desk workflow never close on their own judgment. The agent assembles the evidence, the diagnostics it ran, the comment trail, the fix that was applied, and puts the state change in front of the assignee: "Alert cleared 40 minutes ago, fix deployed, requester notified. Close it?" The engineer says yes, and only then does the state move. Machine speed for the paperwork, human authority for the promise.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via preferred channel
Human decides
Agent resumes with decision

Agent Capabilities

7 actions

Incidents

4
  • List Incidents Retrieves a paginated list of incidents with number, name, state, priority, requester, assignee, and category. The read behind queue browsing and SLA reporting.
  • Get Incident Retrieves the full detail of a single incident by ID, including description, comments, and audit information. Used to assemble context before a triage or closure decision.
  • Create Incident Creates a new incident with a required summary and optional description, priority, requester by email, and category by name. The write that turns an alert or request into a tracked obligation.
  • Update Incident Updates an incident's state, priority, and category, and can append a public or internal comment. Only the fields you supply change. The action this page's human gate exists for.

Directory and Assets

3
  • List Users Retrieves users with name, email, role, and department. Used to resolve requester and assignee addresses before creating or routing tickets.
  • List Hardware Retrieves hardware assets with name, serial number, status, and assigned owner. Used to reconcile inventory and link affected assets to incidents.
  • List Categories Retrieves the incident categories configured in your account. Used to discover valid category names before a create or update.

Frequently Asked Questions

What can FlowRunner do with SolarWinds Service Desk?

FlowRunner agents can run List Incidents, Get Incident, and Create Incident in SolarWinds Service Desk, plus 4 more actions.

Does connecting SolarWinds Service Desk to FlowRunner require OAuth?

No. SolarWinds Service Desk connects to FlowRunner with an API key, no OAuth flow required.

Can SolarWinds Service Desk trigger a FlowRunner workflow automatically?

SolarWinds Service Desk doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with SolarWinds Service Desk

$100 in credits. No card required. Connect in minutes.