Smart Alert Consolidation

Smart Alert Consolidation is a ticket lifecycle manager for ConnectWise PSA. It takes alert data from any monitoring tool — RMM, network monitor, uptime checker, or anything else — and automatically creates, updates, closes, and reopens service tickets based on alert state.

Key benefits:

• Reduces ticket spam — repeated failure alerts update the existing ticket instead of creating new ones
• Auto-closes on recovery — success alerts automatically resolve the matching ticket
• Reopens on recurrence — if a resolved issue comes back, the original ticket reopens with full history instead of creating a duplicate
• Consolidates notes — multiple alerts merge into a single timestamped note, keeping tickets clean and readable even under high-frequency alerting
• Attaches configuration items — automatically links the affected device by MAC, IP, or hostname

How it works in one sentence: the node matches alerts to tickets using a composite key of the Alert Name and Alert ID, then decides whether to create, update, close, or reopen the ticket based on the alert’s success or failure state.

---

Quick Start

To get a basic create-on-failure, close-on-recovery integration, you only need these fields:

Simplest scenario

1. Your monitoring tool detects a failure and sends data to n8n
2. The node creates a ticket: “SERVER01 is not responding” with status New
3. A second failure alert arrives — no new ticket is created; the existing one already matches
4. Your monitoring tool detects recovery and sends a success alert
5. The node finds the open ticket and sets its status to Closed

You now have a working integration. Read on to add messages, note consolidation, and reopening rules.

---

Recommended Setup

Most real-world integrations benefit from a few additional settings beyond the Quick Start. This section walks through what we recommend for a typical monitoring integration.

Use both detailed and short messages

The node uses two message types for each state — a detailed one and a short one — and picks the right one depending on context:

• Detailed messages are used when creating a ticket or adding the first resolution note. They contain full diagnostic context — links to your RMM, affected services, troubleshooting steps.
• Short messages are used when appending to existing notes, reopening, or updating. They’re one-liners that record what happened without repeating the full context.

This combination gives you rich context on the initial ticket while keeping subsequent notes compact. On a noisy alert, the short messages keep the ticket readable instead of dumping the same wall of text over and over.

Tip: You don’t need both detailed and short for every state. If you only provide a short message, it will be used everywhere — including the initial ticket description. This works well for success messages where a one-liner like UP: Ping restored is often all you need.

Enable note consolidation

Without note consolidation, every alert creates a separate note. If your monitoring tool sends an alert every 5 minutes, that’s 288 notes per day on a single ticket. Enable Append to Previous Note to merge repeated alerts into a single timestamped entry:

`2025-01-15 Wed 02:45:00 PM` DOWN: Not responding to pings
`2025-01-15 Wed 02:40:00 PM` DOWN: Not responding to pings
`2025-01-15 Wed 02:35:00 PM` DOWN: Not responding to pings

All three alerts live in one note, newest at the top. This is especially important for flip-flopping alerts — if a service goes down and back up repeatedly, each state change is logged in the same note instead of creating a flood of separate entries.

Set the Append Timeframe (e.g., 4 hours) to start a new note periodically. This gives technicians natural breakpoints to follow the timeline.

The Max Comments setting (default: 20) is a safety cap. When reached, the node updates the last note in-place instead of creating new ones, preventing PSA performance issues on noisy tickets.

Enable reopening

Without reopening, a failure alert for an already-resolved issue creates a brand-new ticket with no connection to the original. Enable Reopen Closed Tickets so the original ticket reopens with its full history intact. Set age limits (e.g., Max Creation Age of 30 days) to avoid reopening ancient tickets — if the ticket is too old, a new one is created instead.

Use Preview Mode during setup

Preview Mode runs the full decision logic without making any changes to ConnectWise. It returns exactly what would happen — which action, what the note would say, which configuration was matched. Use it to verify your configuration before going live, and again whenever you change settings.

---

How It Works

Every time the node runs, it looks up the ticket by the composite key (Alert Name + Alert ID), then follows this decision tree:

graph TD
    A["Alert received"] --> B["Look up ticket by Alert Name + Alert ID"]
    B --> C{"Existing ticket#quest;"}
    C -- No --> D{"Alert status#quest;"}
    D -- SUCCESS --> E["Nothing to close, skip"]
    D -- FAIL --> F["Create new ticket"]
    C -- Yes --> G{"Alert status#quest;"}
    G -- SUCCESS --> H["Close ticket and add note"]
    G -- FAIL --> I{"Ticket already closed#quest;"}
    I -- No --> J["Update ticket status and add note"]
    I -- Yes --> K["Reopen ticket and add note"]
    classDef start fill:#6366f1,stroke:#4f46e5,color:#fff
    classDef create fill:#22c55e,stroke:#16a34a,color:#fff
    classDef close fill:#3b82f6,stroke:#2563eb,color:#fff
    classDef reopen fill:#f97316,stroke:#ea580c,color:#fff
    classDef update fill:#a855f7,stroke:#9333ea,color:#fff
    classDef skip fill:#94a3b8,stroke:#64748b,color:#fff
    class A,B start
    class E skip
    class F create
    class H close
    class J update
    class K reopen

A few things to note:

• New tickets get the failure message as their initial description. Notes are only added to existing tickets.
• Closed tickets only appear in the search when Reopen Closed Tickets is enabled. Otherwise, only open tickets are matched.
• Open tickets are always matched regardless of age. Age restrictions only apply to closed tickets — this prevents duplicate tickets when an alert fires repeatedly for an already-open issue.

The deduplication key

The node combines Alert Name and Alert ID into a composite key for matching. For example, if Alert Name is ping and Alert ID is srv-01, the key is ping|srv-01.

• Alert Name is a short code that groups related alerts (e.g., ping, disk, backup). Max 40 characters.
• Alert ID identifies the specific entity being monitored (e.g., a device ID, hostname, or service name). Any length.
• The search is always scoped to the specified Company.

---

Configuration Reference

Alert Identifiers

Ticketing

Messages

Note Consolidation

Reopen Rules

Important: Age restrictions only apply to closed tickets. Open tickets are always found and updated regardless of age.

Configuration Item Attachment

These fields are inside the Configuration Attachment collection. They let you automatically find and link a ConnectWise configuration (managed device) to the ticket.

Processing Options

---

Using Text for Statuses and Priorities

By default, you select statuses and priorities from dropdowns, which pass numeric IDs to ConnectWise. But you can also type a text name using an expression, and the node will look it up automatically.

Why this matters:

• Statuses are board-specific. Each service board has its own set of statuses with its own numeric IDs. A status ID that means “New” on one board may not exist on another. If you enable Reopen on Same Board Only = Off (to match tickets across boards), you must use text names like "New" or "Closed" — they work on any board.

• Priority names from external tools. If your RMM sends priority as text like "High" or "Critical", you can pass it directly. The node does a case-insensitive lookup and resolves it to the matching ConnectWise priority.

To use text instead of a dropdown value, switch the field to Expression mode and enter a string like {{ "New" }} or pass a value from your input data like {{ $json.priority }}.

---

Note Consolidation

When multiple alerts arrive for the same ticket, you have control over how notes are organized. The key question is: does each alert get its own note, or do they get merged together?

graph TD
    A["New alert for existing ticket"] --> B{"Append to Previous Note enabled#quest;"}
    B -- No --> C{"At Max Comments limit#quest;"}
    C -- No --> D["Create new note"]
    C -- Yes --> E["Update last note in-place"]
    B -- Yes --> F{"Previous automated note exists#quest;"}
    F -- No --> G["Create new note"]
    F -- Yes --> H{"Within Append Timeframe#quest;"}
    H -- No --> I["Create new note"]
    H -- Yes --> J{"Still the last note on ticket#quest;"}
    J -- No --> K["Create new note"]
    J -- Yes --> L["Append to existing note"]
    classDef start fill:#6366f1,stroke:#4f46e5,color:#fff
    classDef create fill:#22c55e,stroke:#16a34a,color:#fff
    classDef append fill:#f97316,stroke:#ea580c,color:#fff
    classDef inplace fill:#a855f7,stroke:#9333ea,color:#fff
    class A start
    class D,G,I,K create
    class L append
    class E inplace

Which message is used where

The node picks detailed or short messages based on where you are in the ticket’s lifecycle. The rule is simple: detailed messages get one shot per state, then everything after uses short messages.

• Detailed Failure Message — used once, as the initial ticket description when the ticket is created
• Detailed Success Message — used once, as a standalone note for the first recovery on a ticket
• Short Failure Message — used for all subsequent failure notes (repeated alerts, reopening, consolidation)
• Short Success Message — used for all subsequent recovery notes after the first

You don’t need to provide all four messages. Every context has a fallback chain: if the preferred message isn’t provided, the node tries the other type, and if neither exists, it falls back to a generic string ("Alert failure" or "Alert success"). The fallback always crosses over — so if you only provide a detailed message, it will also be used in short contexts like consolidation lines. If you only provide a short message, it will be used for the initial ticket description too.

In practice, short-only works well for success messages where a one-liner like UP: Ping restored is all you need. Detailed-only works if you want the same rich message everywhere. Both together gives you the best of both worlds — rich context on first appearance, compact lines for everything after.

graph TD
    A["Alert for existing ticket"] --> B{"Alert state#quest;"}
    B -- Failure --> C{"Creating a new ticket#quest;"}
    C -- Yes --> D["Detailed Failure Message<br/><em>used as ticket description</em>"]
    C -- No --> E["Short Failure Message<br/><em>timestamped note</em>"]
    B -- Success --> F{"First recovery on this ticket#quest;"}
    F -- Yes --> G["Detailed Success Message<br/><em>standalone note</em>"]
    F -- No --> H["Short Success Message<br/><em>timestamped note</em>"]
    D -. "falls back to" .-> E
    G -. "falls back to" .-> H
    classDef start fill:#6366f1,stroke:#4f46e5,color:#fff
    classDef detailed fill:#3b82f6,stroke:#2563eb,color:#fff
    classDef short fill:#22c55e,stroke:#16a34a,color:#fff
    class A start
    class D,G detailed
    class E,H short

Example

With Append to Previous Note enabled and Prepend to Note on (newest first), here is what a ticket’s notes look like after three failures, a recovery, and then another failure:

Note 3 (new failure after recovery — starts a fresh note):

`2025-01-15 Wed 03:25:00 PM` DOWN: Not responding to pings

Note 2 (first recovery — uses Detailed Message):

SERVER01 (10.0.0.21) is back online. Ping restored.

Note 1 (consolidated failures — uses Short Message):

`2025-01-15 Wed 02:45:00 PM` DOWN: Not responding to pings
`2025-01-15 Wed 02:40:00 PM` DOWN: Not responding to pings
`2025-01-15 Wed 02:35:00 PM` DOWN: Not responding to pings

The initial ticket description (not shown as a note) used the Detailed Failure Message with the full diagnostic context. Subsequent failure alerts used the Short Message and were consolidated into a single timestamped note. The first recovery used the Detailed Success Message as a standalone note. When the alert failed again after recovery, a fresh note was started.

Flip-flopping alerts: When an alert alternates between failure and success rapidly, each state change is recorded in the same note rather than creating separate notes, as long as Append to Previous Note is enabled and the events fall within the Append Timeframe.

Max Comments is a safety net. Regardless of other settings, once a ticket reaches this limit, new content updates the last note in-place instead of creating more. This prevents ConnectWise from slowing down on tickets with hundreds of notes.

---

Configuration Item Matching

When you provide device identifiers (MAC address, IP, hostname), the node searches ConnectWise configurations to find and attach the best match. This is useful for RMM integrations where you want each ticket to link to the affected device automatically.

If multiple identifiers are provided, they are checked in priority order:

1. MAC Address (highest priority) — pattern match with wildcard support
2. IP Address — exact match (localhost is skipped)
3. Hostname Full Match — exact or wildcard pattern, case-insensitive
4. Hostname Smart Match — exact first, then prefix (e.g., server01 matches server01.example.com)

The first match at the highest priority level wins. The search is scoped to the specified company and only returns active configurations. If you specify Configuration Types, only those types are searched.

When Append Configuration Details is enabled, the initial ticket description is extended with available hardware info:

*Serial Number:* ABC123XYZ
*Model Number:* PowerEdge R740
*Tag:* ASSET-001
Notes: Located in Server Room B, Rack 3

Only fields that have values on the configuration are included.

---

Common Scenarios

Basic monitoring

Use only the Quick Start fields. One ticket per incident, auto-closed on recovery.

Best for: simple uptime monitors, infrequent alerts, or when you want a clean ticket per incident.

RMM integration with note consolidation

A typical RMM setup with device attachment and consolidated notes:

Controlled reopening

Reopen tickets for recurring issues, but only if they’re recent:

Cross-board tracking

When tickets may be moved between boards and you still want to match them:

---

Actions and Preview Mode

The node returns an action value that tells you exactly what happened (or what would happen in Preview Mode). You can use this in downstream nodes — for example, a Switch node on {{ $json.action }} to send notifications only when a new ticket is created.

Enable Preview Mode during setup. It runs the full logic without writing to ConnectWise, so you can verify every decision before going live.

Action values

Note action values

Using output in downstream nodes

• Switch node on {{ $json.action }} to handle different outcomes differently
• IF node on {{ $json.action === 'CREATE_TICKET' }} to trigger notifications only for new tickets
• Access the ticket ID with {{ $json.ticketId }} for further logic to modify the ticket or push to other systems