Skip to main content

Monitoring Alerts with Auto-Create and Auto-Close Tickets

This tutorial walks through building a workflow that handles "device offline" and "device online" alert emails from a monitoring tool. It automatically creates a ticket when a device goes offline and closes that same ticket when the device comes back online.

The pattern applies to any monitoring or alerting tool that can send email: Pingdom, Uptime Robot, PRTG, Auvik, custom scripts, or anything else that emails you on state changes.

What You Will Build​

Two rules in a single dedicated mailbox:

RuleExpressionWhat it does
Close Existing Ticket (runs first)Only fires when email indicates device is onlineFinds the open alert ticket for the device and closes it
Create New Ticket (runs second)Always fires (no expression)Creates a new alert ticket for the device

The rules are ordered so that the close rule runs first. If it fires and stops, the create rule never runs. If the close rule does not fire (because this is an offline alert, not an online alert), the create rule fires and creates a ticket.

Prerequisites​

  • An Email2AT account with Autotask connected
  • Your monitoring tool configured to send alert emails to an Email2AT address
  • Configuration Items (CIs) in Autotask for the devices being monitored, with a consistent identifier field you can match against (such as hostname, serial number, or reference title)

If you have not yet set up a mailbox, start with Create Your First Mailbox.

Step 1: Create a Dedicated Mailbox​

Create a separate mailbox specifically for this monitoring tool. Do not use your general support mailbox.

  1. Navigate to Email2AT in the console and click Hosted Mailboxes
  2. Create a new mailbox, for example: [email protected]
  3. Click Save

The mailbox has no rules yet. Configure your monitoring tool to send its alert emails to this address before proceeding, or use test emails as described in the testing steps below.

One mailbox per tool

Create a separate mailbox for each monitoring tool you integrate. This keeps History readable, simplifies troubleshooting, and means a misconfigured rule in one workflow cannot interfere with another.

Step 2: Understand Your Alert Emails​

Before building rules, examine the actual emails your monitoring tool sends. The workflow depends on being able to extract a device identifier from the email, a value that is also stored on the Autotask CI for that device.

What to look for:

  • Device identifier: a hostname, serial number, IP address, or other value that appears in every alert and is unique per device
  • State indicator: something in the email (subject or body) that distinguishes an "offline" alert from an "online" alert

Example email pair (simplified):

Subject: Server ABC-123 status: offline
Body: Server: ABC-123
      Status: offline
Subject: Server ABC-123 status: online
Body: Server: ABC-123
      Status: online

From these, the device identifier is ABC-123 (the server name) and the state indicator is the word offline or online in the subject.

Step 3: Create the "Create New Ticket" Rule​

Build the create rule first. It is simpler and you will clone it to build the close rule.

Add the rule​

  1. In your new mailbox, click Add New Rule
  2. Name it Create New Ticket
  3. Leave the Expression empty. This rule should fire for every email. The close rule, added later, will be placed above it and stop processing for online alerts.

Action 1: Extract data from the email​

Use the Extract Strings action to pull the device identifier and the alert state out of the email body in one step.

  1. Click Add New Action, select Extract Strings, click OK
  2. Name the step Extract Alert Data
  3. Add two definitions:

Definition 1: hostname

FieldValue
Extraction TypeRegular Expression
Pattern/Server:\s*([^\n]+)/
Input{{email.body}}
Variablehostname
If EmptyGenerate an exception and stop processing

Definition 2: status

FieldValue
Extraction TypeRegular Expression
Pattern/Status:\s*([^\n]+)/
Input{{email.body}}
Variablestatus
If EmptyGenerate an exception and stop processing
  1. In Store results in variable, enter parsedAlert

After this step, {{custom.parsedAlert.hostname}} contains the device name (e.g., ABC-123) and {{custom.parsedAlert.status}} contains offline or online.

Adapting to your alert format

The patterns above match lines in the format Server: ABC-123 and Status: offline. If your monitoring tool uses different labels or formatting, adjust the patterns to match. You can use regex101.com (PCRE2 flavor) to test patterns against a sample email body, or contact support with a sample and we will help you build the right patterns.

You can also use Text Expression mode instead of regex for simple line-by-line extraction. For example, {{after_string email.body "Server:" flags="tn"}} extracts everything after Server: on the same line, with no regex required.

Action 2: Look up the Configuration Item in Autotask​

  1. Click Add New Action, select API: Query for One Object, click OK
  2. Name the step Find Config Item
  3. Set Entity Type to InstalledProduct (this is what Autotask calls Configuration Items in the API)
  4. Add query conditions:
    • IsActive equals true
    • The field you use to identify devices (e.g., ReferenceTitle) equals {{custom.parsedAlert.hostname}}
  5. Enable Generate an exception if no results. If no CI matches, you want to know about it.
  6. In Store results in variable, enter configItem

After this step, {{custom.configItem.id}} is the CI's Autotask ID and {{custom.configItem.accountId}} is the account it belongs to.

Which CI field to use

The field you match against must contain the same value that appears in your alert emails. Common choices:

  • ReferenceTitle often stores the device's hostname or display name
  • SerialNumber works well for hardware identifiers
  • ReferenceNumber is a general-purpose identifier field

Check your existing CIs in Autotask to see which field holds the right value.

Alternatively, use the Create Autotask Ticket (by Configuration Item) workflow action, which handles the CI lookup and ticket creation in a single step.

Action 3: Create the alert ticket​

  1. Click Add New Action, select API: Create an Object, click OK
  2. Name the step Create Alert Ticket
  3. Set Entity Type to Ticket
  4. Configure the required fields:

Ticket fields:

FieldValue
AccountID{{custom.configItem.accountId}} (unlock the field to enter this)
StatusNew (or whichever status is appropriate for new alerts)
PrioritySet as appropriate for alert severity
QueueIDYour alert monitoring queue
Title{{email.subject}}
Description{{email.body}}
InstalledProductID{{custom.configItem.id}} (unlock the field to enter this; links the ticket to the CI)
  1. In Store results in variable, enter newTicket. You will not need this value here, but it is available if you want to reference the ticket number in a subsequent step.
Tag your tickets for easy retrieval

Add a consistent value somewhere on the ticket (in a note, a UDF, or the source field) that identifies it as being created by this workflow. You will use this when building the close rule to ensure you only locate tickets created by this specific alert. For example, set the Source field to a dedicated value like Ping Alert.

Action 4: Stop​

  1. Click Add New Action, select Stop Processing This Message Completely, click OK
  2. Name it Stop

Step 4: Create the "Close Existing Ticket" Rule​

Now create the rule that handles online alerts. Clone the create rule if your UI supports it, or create a new rule from scratch.

Add the rule​

  1. Click Add New Rule
  2. Name it Close Existing Ticket
  3. Set the Expression to fire only when the email indicates the device is back online

Example expression: email.body contains Status: online

This ensures the rule only fires for online alerts. For offline alerts, the expression is false and the rule is skipped entirely, allowing the Create rule to run.

Action 1: Extract alert data (same as create rule)​

Add the same Extract Strings step as in the create rule:

  1. Extract Strings with the same definitions (hostname and status), same inputs ({{email.body}}), and same variable name (parsedAlert)

Action 2: Look up the Configuration Item (same as create rule)​

Add the same CI lookup step:

  1. API: Query for One Object with the same query conditions and same variable name (configItem)

Action 3: Find the original open ticket​

  1. Click Add New Action, select API: Query for One Object, click OK
  2. Name the step Find Open Alert Ticket
  3. Set Entity Type to Ticket
  4. Add query conditions:
    • InstalledProductID equals {{custom.configItem.id}}
    • Status does not equal Complete (or whatever your closed status is)
    • Add any additional filter to ensure you only match tickets created by this alert workflow. For example, if you set Source to Ping Alert, add SourceID equals that source.
  5. Set Sort to CreateDate descending. This returns the most recently created matching ticket.
  6. Leave Generate exception if no results unchecked. It is valid for an online alert to arrive when no open ticket exists (the device may have already been manually resolved).
  7. In Store results in variable, enter existingTicket

Action 4: Add a note to the ticket​

Only run this step if a ticket was actually found.

  1. Click Add New Action, select API: Create an Object, click OK
  2. Name the step Add Resolved Note
  3. Set Entity Type to TicketNote
  4. Add the Only perform this action if expression: custom.existingTicket.id is not null
  5. Configure fields:
FieldValue
TicketID{{custom.existingTicket.id}} (unlock the field)
Title{{email.subject}}
Description{{email.body}}
NoteTypeTask Summary (or your preferred note type)
PublishAll Autotask Users

Action 5: Close the ticket​

  1. Click Add New Action, select API: Update an Object, click OK
  2. Name the step Close Ticket
  3. Set Entity Type to Ticket
  4. Add the Only perform this action if expression: custom.existingTicket.id is not null
  5. Configure fields. Only add the fields you want to change:
FieldValue
ID{{custom.existingTicket.id}} (unlock the field)
StatusComplete (or whichever status means resolved in your Autotask)
Why the API requires two steps for what Autotask shows as one

In the Autotask UI, adding a note and changing the ticket status look like a single action. Under the hood, they are two separate API calls: one to create the TicketNote and one to update the Ticket. This is why the workflow has separate steps for each.

Action 6: Stop​

  1. Click Add New Action, select Stop Processing This Message Completely, click OK

This stop fires regardless of whether a ticket was found. If no open ticket exists for this device, we still want to stop. There is nothing else to do with an online alert when no offline ticket was open.

Step 5: Order the Rules​

The rule order in the mailbox determines which runs first. The Close rule must be above the Create rule.

In the mailbox's rule list:

  1. Drag Close Existing Ticket to the top
  2. Drag Create New Ticket below it
  3. Click Save Order

With this order:

  • An online alert: Close rule expression matches → Close rule fires and stops → Create rule never runs
  • An offline alert: Close rule expression does not match → Close rule is skipped → Create rule fires and creates a ticket

Step 6: Test​

Test offline (ticket creation)​

  1. Send a test email to your mailbox address that matches the offline pattern (e.g., Status: offline in the body)
  2. Navigate to History and click Refresh until it appears
  3. Open the details log and verify:
    • The Close rule was skipped (expression did not match)
    • The Create rule fired
    • The regex extracted the correct hostname
    • The CI was found in Autotask
    • A new ticket was created with the correct Account and CI

Test online (ticket close)​

  1. Open the ticket that was just created in Autotask and note the ticket number
  2. Send a second test email that matches the online pattern (e.g., Status: online in the body, same device hostname)
  3. Navigate to History and click Refresh
  4. Open the details log and verify:
    • The Close rule fired (expression matched)
    • The regex extracted the correct hostname
    • The CI was found
    • The open ticket was located
    • A note was added
    • The ticket status was changed to Complete
Use Replay while iterating

If a step fails or produces unexpected output, fix the rule and click the Play button on the history entry to reprocess the same email. You do not need to send a new test email for each iteration.

Handling Edge Cases​

Online alert arrives with no open ticket​

This is expected and handled gracefully. The Find Open Alert Ticket step returns no result, custom.existingTicket.id is null, the note and close steps are skipped, and the Stop fires. Nothing bad happens.

Multiple open tickets for the same device​

If a device generates rapid repeated offline alerts before you process the first online alert, you may accumulate multiple open tickets. The query uses Sort: CreateDate descending so it finds the most recent one. Consider enabling the ticket filter to only match the most recently created open ticket, or use a Source field to make matching more precise.

Device not in Autotask as a CI​

If Find Config Item returns no result, the workflow exception fires and you receive an error notification. This is the right behavior: it tells you to add the CI to Autotask. Alternatively, remove the "generate exception if no results" flag and add a stop action that fires if custom.configItem.id is null, so the email is silently discarded for unknown devices.

Key Takeaways​

  • Dedicated mailbox per tool: keeps rules and history clean
  • Close rule above Create rule: order determines which fires; the expression on the Close rule gates it
  • Stop in every path: the Close rule stops whether or not a ticket was found, so the Create rule never runs for an online alert
  • Extract before querying: use an Extract Strings step to pull the device identifier out of the email first, then use it in the CI query
  • Guard update steps with an expression: add custom.existingTicket.id is not null to any step that uses the found ticket, so it gracefully skips when no ticket exists
  • Two API calls to add a note and close a ticket: Autotask requires separate calls; add a TicketNote first, then update the Ticket status