An incident enters PulseServe one of three ways: automatically from the alert-ingestion pipeline (severity maps to priority/impact/urgency), from the employee self-service portal (which may require manager approval depending on category), or created manually by an agent, manager, or admin.
The moment an incident exists, the AI orchestrator pipeline kicks off asynchronously in the background — correlation, triage routing, root cause analysis, and remediation planning — so a human reviewing the ticket sees findings land in near real time rather than waiting for the whole pipeline to finish.
States
- New — initial state on creation.
- Awaiting approval — a portal ticket awaiting manager sign-off before it enters the working queue.
- In progress — assigned and actively being worked.
- Resolved — a fix has been applied, awaiting closure (or the caller's confirmation).
- Awaiting caller confirmation — a portal ticket marked resolved, waiting on the original requester to confirm.
- Closed — final state.
- Duplicate — marked as a duplicate of a parent incident.
Assignment
Assignment happens through whichever of these paths applies first: a manual assignment by an agent or admin; an auto-assign rule matched on source, category, and priority that picks the least-loaded agent in the target group; or the AI triage routing agent, which classifies the incident into a support tier and auto-assigns when its confidence clears a configurable threshold (90% by default). A periodic escalation sweep can also reassign tickets that have sat too long in a given state.
Acknowledging an incident
Assignment and acknowledgment are two separate steps. Once an incident has an assignee, a countdown appears on its Overview tab — separate from the SLA timer — measuring time since assignment, not since the ticket was created. It moves through three states as time passes: awaiting acknowledgment, a warning once most of the window has elapsed, and an overdue state (counting up in red) if it's missed entirely. The assignee, an admin, or a manager clicks Acknowledge to clear it. Reassigning the ticket to someone else resets the countdown for the new owner. Leaving it unacknowledged past the configured threshold (set per priority under Settings → Ticketing Rules → Ticket Routing) is what triggers automatic reassignment — see Settings: Tickets, AI & Automation.
Closing the loop
Resolving an incident requires ownership and passes through any HITL review gate configured for the tenant. Portal tickets can additionally require the original caller to confirm the fix before the ticket auto-closes — after 72 hours of silence it closes automatically anyway. Closing a resolved incident triggers a CSAT survey.
Working an incident, step by step
- Create one manually — from Incidents, click + New Incident and fill in a short description, priority, and the affected configuration item if you know it (or start from a saved template — see Incident Tools & Collaboration).
- Claim it — open an unassigned incident in your queue and click Claim, or open it and assign it to yourself. This moves it to in progress and records the claim on the timeline. Acknowledge it once you're actually on it (see above).
- Work through the detail tabs — the core ones are Overview (fields, SLA and acknowledgment timers, assignment), Timeline (state changes and comments), Edit, Correlation (AI-matched alerts and changes), and AI Analytics (triage routing, RCA, and remediation output, with the HITL review controls and the dependency context graph both living inside this same tab). Beyond those, a long tail of situational tabs covers things like duplicates, watchers, attachments, and vendor handoff — see Incident Tools & Collaboration for the full set.
- Add a comment — open the Timeline tab, type your observation into the comment box, and submit. It is recorded with your name and a timestamp.
- Reassign it — open the Edit panel, change the assigned group or user, and save. The reassignment is recorded on the timeline.
- Resolve and close — resolving requires passing any configured HITL/ownership gates; closing a resolved ticket triggers a CSAT survey, and portal-submitted tickets may additionally wait on the original requester to confirm the fix.
Example
An employee submits "VPN not working" through the self-service portal. It lands as a new incident, auto-triaged by the AI agent to the L2 Technical Analyst group at 92% confidence. An L2 analyst claims it, adds a comment noting the user's OS and VPN client version, and resolves it once the fix is confirmed. Because it came in through the portal with caller confirmation required, it sits in Awaiting Caller Confirmation until the employee confirms — then closes automatically.