Skip to main content

PRTG Alerts with Autotask CI Association

PRTG sends alerts from a shared system address, so the sender does not tell Autotask which customer owns the affected device. Without another way to identify the customer, tickets can land on the wrong account and require manual cleanup.

This tutorial uses the device's Configuration Item (CI) as one way to identify the customer. The automation looks up the CI in Autotask by a device identifier, then creates the ticket on that CI's account. This version sends unmatched alerts to a catch-all account, but you can choose to stop with an exception instead.

Overview​

PRTG sends alert emails that include a device identifier (such as a probe ID, sensor name, or hostname). The automation uses the Create Autotask Ticket by Configuration Item action to extract the identifier, match it to a CI in Autotask, and create a ticket in one step. A fallback rule handles alerts that cannot be matched.

Related pages:

Before You Start​

  1. Create a Hosted Mailbox for PRTG alerts (for example, [email protected])
  2. Configure PRTG to send alert notifications to this address
  3. Send a few test alerts through so they appear in History, then open them to see the exact email format PRTG produces
  4. Identify the device identifier in the email body (for example, Probe ID:, Sensor:, or Device: followed by a value)
  5. Confirm which field on the Autotask CI stores the matching value (Serial Number, Reference Title, or a User-Defined Field)

We recommend a dedicated Hosted Mailbox because it keeps PRTG rules and History separate from other automations. There is no technical requirement to use one; you can process PRTG alerts in a shared Hosted Mailbox or Remote Mailbox when rule conditions clearly identify them.

Step 1: Create the Rule​

  1. Open your PRTG alerts Hosted Mailbox and click Add New Rule
  2. Name it Process PRTG Alert
  3. Leave the Expression empty so every email is processed by this rule

Step 2: Add the "Create Ticket by CI" Action​

This action handles identifier extraction, CI lookup, and ticket creation in one step.

  1. Click Add New Action, select Create Autotask Ticket by Configuration Item, click OK
  2. Name the step Create Ticket for PRTG Alert

Configuration - Identifier Extraction:

FieldValue
Identifier SourceUnlock the field, then enter: {{after_string email.body "Probe ID: " flags="tn"}}
If identifier not foundSkip this action

The after_string helper looks for Probe ID: in the email body, captures everything after it up to the next newline (n flag), and trims whitespace (t flag). Adjust the label to match whatever your PRTG emails use (for example, Device: or Sensor: ).

Unlock Identifier Source because its picklist accepts one fixed choice. Unlocking it lets you enter a text expression instead. Type { to open the variable and helper picker, then enter or select the expression.

Learn more about text helpers

Configuration - CI Matching:

FieldValue
CI field to matchSelect the Autotask CI field that stores the same value PRTG includes in the email (for example, Serial Number, Reference Title, or a UDF)
If no CI foundSkip this action

Configuration - Ticket Fields:

Fill in each required field (fields marked with an asterisk in the UI are required). At minimum:

FieldValue
StatusNew
PrioritySet as appropriate for alert severity
QueueYour monitoring alerts queue
Title{{email.subject}}
Description{{email.body}}

Action When Complete: Set to Stop processing the actions on this rule and all other rules (completely stop)

Both approaches are valid

This tutorial uses the Create Autotask Ticket by Configuration Item workflow action, which handles extraction, CI lookup, and ticket creation in one step. The Monitoring Alerts Tutorial shows how to build the same pattern using individual API call actions chained together, which gives you more control over each step. Choose whichever approach fits your needs.

Step 3: Add a Catch-All Ticket​

Choose what should happen when the email has no identifier or Autotask has no matching CI:

ChoiceSetupTradeoff
Create a catch-all ticket (this tutorial)Keep both skip settings from Step 2, then add the action below. Use a dedicated default account or your zero account.Every alert becomes a ticket, but a technician must identify and move unmatched alerts.
Stop and notifySet If identifier not found and If no CI found to generate an exception. Do not add the catch-all action.No ticket lands on the wrong account, but someone must correct the CI match and replay the email from History.

The person designing the automation chooses which tradeoff fits the team. The Identify the Customer section explains other ways to identify an account when a CI is not the best match.

  1. Click Add New Action, select API: Create an Object, click OK
  2. Name the step Create Catch-All Ticket
  3. Set Entity Type to Ticket
  4. Configure the required fields:
FieldValue
AccountIDYour dedicated catch-all account, or your zero account (unlock the field and enter its ID, such as 0 for the zero account)
StatusNew
PriorityMedium
TitleUnmatched PRTG alert: {{email.subject}}
Description{{email.body}}
QueueIDYour monitoring alerts queue

Step 4: Add a Final Stop​

  1. Click Add New Action, select Stop processing this message completely, click OK
  2. Name it Stop

Rule Summary​

The final rule has three actions:

  1. Create Ticket for PRTG Alert (CI action): if the identifier is extracted and the CI is found, creates a ticket on the CI's account and stops the message
  2. Create Catch-All Ticket (API create): runs only when action 1 skips; creates a ticket on the fallback account you selected
  3. Stop: stops the message so no further rules fire

What happens now​

  • PRTG sends an identifier that matches a CI: the first action creates a ticket on the CI's account, links the CI, and stops processing.
  • The identifier is missing or no CI matches: the first action skips. This tutorial's fallback creates a ticket on the account you selected, then the final action stops processing.
  • You chose exceptions instead: processing stops and notifies you. After you correct the identifier or CI, replay the alert from History.

Test the Automation​

  1. Replay a PRTG alert email from History (or send a new one)
  2. Open the processing log and verify:
    • The identifier was extracted correctly
    • The CI was found in Autotask (or not, for the catch-all path)
    • A ticket was created on the correct account
  3. Open the ticket in Autotask and confirm the CI is associated

To test the catch-all path, send an email with a device identifier that does not exist in Autotask. Verify that the catch-all action created a ticket on the fallback account you selected.

Key Takeaways​

  • A dedicated Hosted Mailbox or Remote Mailbox is a useful preference: it keeps PRTG rules isolated, but a shared Hosted Mailbox or Remote Mailbox also works with clear rule conditions
  • Send sample emails first: open them in History to see exactly how Email2AT parsed the email before building extraction logic
  • Choose the unmatched-alert behavior: use a catch-all account to keep every alert moving, or stop with an exception to avoid tickets on the wrong account
  • Choose the right CI field: the field must store the same value that PRTG includes in the alert email
  • Customer identification can start from the CI or the alert text: this tutorial uses the CI; the Monitoring Alerts Tutorial extracts a customer value from the alert and can use a UDF or account name