Today in SolarWinds Service Desk, a ticket can only be assigned to a single agent. In real operations, many tickets require shared ownership (e.g., onboarding/offboarding, hardware + access, app + network, security + endpoint, after-hours handoffs, mentoring/training, or complex incidents). The current workaround is to rely on CC/watchers, internal notes, or manual communication, but those options don’t create true accountability and—most importantly—don’t reliably put the work in the other agent’s queue.
Feature request: allow more than one agent to be assigned to a ticket. If there must be a single “Primary Assignee,” that’s fine, but we need one or more “Secondary Assignees” (or “Additional Assignees/Co-Assignees”) who can see the ticket in their queue/workload views and can action it without taking ownership away from the primary.
Why this matters
- Shared accountability without losing ownership
Primary stays responsible, but secondary(s) are explicitly assigned and accountable for their portion. - Better workload visibility and reporting
Managers can see who is actively assigned to what, without inflating counts through duplicate tickets or forcing reassignment. - Faster resolution, fewer handoff gaps
Co-ownership is critical for multi-discipline tickets and for shift changes/after-hours escalations. - Training and coverage
A senior tech can remain primary while a junior tech is secondary for learning, with clear visibility in both queues.
Suggested behavior / acceptance criteria
- A ticket supports: Primary Assignee (required) + Secondary Assignee(s) (one or many).
- Any ticket where I am a primary or secondary assignee appears in “My Tickets” / queue views (with an obvious label like “Secondary”).
- Notifications can be controlled (optional per role), but default should notify both primary and secondary on updates.
- Permissions remain the same as current assignment (no new security risk introduced).
- Reporting/filters support: “Assigned to (any)” vs “Primary Assignee” vs “Secondary Assignee.”
- SLA ownership stays with the Primary Assignee (unless you choose to add options later).
- API/automation support for setting/removing secondary assignees would be a big plus (but the UI feature alone would still be very valuable).
Example use case
A ticket to onboard a clinician might require endpoint setup (desktop team), account provisioning (systems), and application access (app team). With secondary assignees, all involved agents see the same ticket in their queue, coordinate in one place, and the request doesn’t get split into multiple tickets or hidden in watchers.
Bottom line: This would materially improve collaboration, accountability, queue management, and time-to-resolution for teams that regularly share work across agents.
