Auroranexis

Incidents record operational events that affect client delivery. Log impact, assign responders, track resolution against SLA targets, and control what client portal users see. Each incident belongs to a client, supports severity classification, optional linkage to related risks, and maintains history suitable for post-incident review and contractual reporting.

Overview

Incidents move through statuses from open through investigating to resolved and archived. The Incidents list and client detail pages show open items, severity, assigned owner, and SLA timer status. Critical incidents surface in dashboard alerts and may trigger escalation rules configured in Settings → Escalation.

SLA policies assigned to clients determine response and resolution targets by severity. Timers start when incidents are created and update as responders change status and add resolution notes. Breach and warning states appear on incident detail pages and client SLA summaries.

Each incident supports separate internal and client-facing content. Internal description and resolution notes capture technical detail for your team. Client summary and portal visibility control what external users see when transparency is required.

Linked risks maintain traceability when an identified threat becomes active impact. Post-incident, teams often open new risks for preventive work discovered during root cause analysis.

Purpose

Incident management gives agencies a structured response path when something goes wrong. Recording incidents promptly preserves timelines for SLA measurement, client communication, and internal retrospectives that improve future delivery.

Separating internal technical detail from client-facing summaries lets operators be thorough internally while presenting clear, appropriate information in the client portal. Clients receive status updates without unnecessary jargon; your team retains full context for remediation.

Incident history feeds health scores, published reports, and compliance discussions. Accurate severity classification and timely status updates ensure metrics reflect real performance rather than administrative backlog.

Core Concepts

Severity levels

Incident severity definitions

Severity	Description
Low	Limited impact; standard response cadence per client SLA policy.
Medium	Noticeable client impact; prioritize in daily standups and owner updates.
High	Significant disruption; involve account owner and leadership promptly.
Critical	Severe impact; follow escalation playbook and Settings → Escalation rules immediately.

Status lifecycle

Incident status values

Status	Description
Open	Reported; initial triage underway; SLA response timer active.

Features

Create incidents from Incidents → New incident with client and severity.
Assign internal responder and link related risks where applicable.
SLA response and resolution timers based on client policy and severity.
Status updates with activity history and timestamps.
Portal visibility toggle and client-facing summary field.
Resolution notes and resolved-at timestamp for closure documentation.
Open incident counts on client detail pages and operational dashboards.
Related incident references in generated client reports.
Critical incident surfacing on Operations Command Center.
Integration with Settings → Escalation for breach notifications.
Severity-based SLA evaluation consistent with assigned client policy.
Archive workflow after post-incident review completion.
Search and filter across organization incident portfolio.
Health score impact from open and recent critical incidents.

Step-by-step usage

Confirm client impact exists; if only potential impact, consider creating a risk instead.
Open Incidents → New incident and select the affected client.
Set severity aligned with your SLA policy tiers and describe impact in the internal description.
Assign a responder responsible for triage and communication.
Set status to Investigating when active work begins; save to update timestamps.
Monitor SLA timers on the incident detail page and client SLA summary.
Enable portal visibility and write a client summary if external transparency is required.
Update client summary as status changes so portal users see current information.
Move to Resolved when impact is addressed; add resolution notes with root cause context.
Link related risks if the incident realized a previously identified threat.
Conduct brief post-incident review for repeat issues; open follow-up risks if needed.
Archive after final client communication and internal documentation are complete.

Best Practices

Maintain a severity cheat sheet aligned with your SLA policies and train on-call staff to use it during stressful outages. Consistent classification matters more than perfect labels in the first minute.

Log incidents as soon as client impact is confirmed—delayed creation skews SLA metrics.
Update status promptly; stale investigating records distort compliance reporting.
Use client summaries written for non-technical readers; avoid internal jargon and blame.
Conduct brief post-incident reviews for repeat issues and document follow-up risks.
Align severity with your SLA policy tier definitions on each client.
Link related risks when the incident realizes a previously identified threat.
Notify account owners on High and Critical incidents even if they are not the assigned responder.
Disable portal visibility for internal-only issues that do not require client notification.
Reference significant incidents in published reports when contracts require disclosure.
Review breach incidents monthly to identify process improvements, not only individual fault.

Examples

Marketing agency

A marketing agency logs a Medium incident when a scheduled campaign fails to launch, assigns the channel lead as responder, and keeps portal visibility off while resolving internally. They reference the incident in the next monthly report transparency section per contract requirements.

AI automation agency

An automation agency opens a Critical incident when a production workflow stops processing client orders, enables portal visibility with a plain-language summary, and resolves after rollback. A linked High risk captures the missing dependency that caused the failure.

MSP

An MSP logs High incidents for network outages affecting multiple sites, triggers Settings → Escalation on SLA warning states, and updates client summaries hourly until Resolved. Post-incident review produces a Medium risk for firmware updates scheduled during the next maintenance window.

Consultancy

A consultancy documents a Low incident when a deliverable misses internal review deadline without client impact, resolves after publication, and avoids portal visibility. The account owner cites timeline lessons in the engagement closeout report.

Enterprise deployment

A large agency routes Critical incidents through a defined command channel, requires manager approval before portal visibility on global accounts, and archives only after legal review when client communications touched regulated data.

Troubleshooting

Common incidents module issues

Problem	Cause	Solution
SLA breach shown incorrectly	Wrong policy or severity on client	Verify client SLA assignment and incident severity matches policy tier definitions.
Client cannot see incident in portal	Portal visibility disabled or no portal users	Enable portal visibility on the incident and confirm active portal users on the client.
Cannot change status to resolved	Role limited to early statuses	Staff roles may be limited; ask an admin for incident close permissions if appropriate.
Timers not appearing on new incident	No SLA policy assigned to client	Assign an SLA policy on the client detail page before relying on timer evaluation.
Escalation did not notify team

FAQ

When should I create an incident versus a risk?: Create a risk for potential or emerging threats. Create an incident when client delivery is actively affected or service is disrupted.
Do incidents affect client health scores?: Yes. Open incidents, SLA violations, and critical monitoring events contribute to client health scoring alongside other operational signals.
Can I edit the client summary after enabling portal visibility?: Yes. Update the client summary as the situation evolves so portal users see current information. Major changes should be reflected in status updates.
How are SLA response and resolution times calculated?: Targets come from the SLA policy assigned to the client, using severity-specific response and resolution minutes defined in Settings → SLA.
What is the difference between resolved and archived?: Resolved indicates the issue is addressed. Archived closes the record for long-term history after any final review or client communication is complete.
Should every incident be visible in the client portal?: No. Enable portal visibility only when clients need transparency. Internal-only issues can remain off the portal while still documented for SLA and health metrics.

Need help?

Contact support@auroranexis.com for onboarding support, billing questions, or product guidance. Include your workspace name, the module you are working in, and a brief description of your goal so we can respond efficiently.

Client visibility

Portal visibility and client summary fields control what external users see on the client portal. Enable visibility only when you have client-appropriate text ready. Update summaries as situations evolve so portal users are not left with stale status.

Internal fields remain visible to your team regardless of portal settings. Align severity labels with SLA policy tier definitions on the client record so timers evaluate correctly.