Skip to main content

Monitoring Alerts to the Right Autotask Account and Ticket

Monitoring tools such as Meraki, SentinelOne, Sophos, Webroot, PRTG, and Auvik send alerts from a no-reply address. When those emails reach Autotask's built-in email processor, it cannot tell which customer the alert is about, so the tickets land on a catch-all account. Every alert also becomes its own ticket, so one flapping device can bury your techs in tickets they have to move, merge, and close by hand.

This tutorial builds an automation that fixes both problems:

  1. Every alert lands on the right account. The automation reads the customer from the alert itself, not from the sender address.
  2. Related alerts stay together. While a device has an open ticket, new alerts for it are added to that ticket as notes instead of creating new tickets.

The ticket is created on the right account from the start. Nothing creates it in the wrong place and fixes it afterward, so a tech who grabs it right away sees correct information.

Building blocks, not a fixed recipe

Email Processing is not a Meraki solution or a SentinelOne solution. It gives you building blocks (extract, look up, create, update, branch) that you arrange to fit your process. This tutorial shows one common arrangement. Once you see how the pieces fit, change any part of it: create a ticket for every alert, close tickets automatically, create a sales opportunity instead of a ticket, or ignore certain alerts entirely.

Decide What Should Happen​

Before building anything, decide how you want alerts laid out in Autotask. Picture a device that goes down, comes back up, and goes down again. Do you want one ticket with several notes, or several tickets? Should the ticket close itself when the device recovers, or should a tech close it?

Here are the common choices:

ApproachHow it behaves
One ticket until a tech closes it (this tutorial)The first alert creates a ticket. Every later alert for that device is added to the ticket as a note while it stays open. When a tech closes the ticket, the next alert starts a new one.
Also close automatically on recoverySame as above, but a "device is back up" alert closes the ticket. See Optional: close the ticket automatically.
A separate ticket for every alertStop after Part 1.

All three are valid designs. Choose the one that fits how your team works.

Before You Start​

Prerequisites​

  • An Email2AT account with Autotask connected
  • A monitoring tool that can send alert emails to an email address you choose

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

Create a dedicated Hosted Mailbox​

  1. Navigate to Email2AT in the console and click Hosted Mailboxes
  2. Create a new mailbox, for example: [email protected]
  3. Click Save
  4. In your monitoring tool, set this address as the alert recipient

The mailbox is live as soon as you save it. Until you add rules, emails sent to it appear in History but nothing else happens.

One address per tool

We recommend giving every third-party system its own address. It keeps each tool's logic and History separate and tidy. There is no technical requirement to do this; you can also route alerts through your support mailbox and filter them with rule conditions.

Look at your alert emails​

Open a few real alerts from your tool and find:

  • The customer: a company name, organization or network name, site name, or other value that tells you which customer the alert is about
  • The device: a device name, serial number, or other value that identifies the device
  • The state, if you plan to auto-close: a word or phrase that tells a problem apart from a recovery, such as down and up

This tutorial uses this simplified alert:

Subject: [Alert] Device SW-01 is down
Body: Company: Acme Corp
      Device: SW-01
      Status: down

Your tool's labels will be different. Adjust the extraction steps to match the labels in your emails.

Part 1: Create the Ticket on the Right Account​

The first version takes three steps:

  1. Extract the company and device from the email
  2. Find the company in Autotask
  3. Create a ticket on that company

This alone puts every alert on the right account. Part 2 then adds the logic that keeps related alerts in one ticket.

Create the rule​

  1. In your new mailbox, click Add New Rule
  2. Name it Create or Update Alert Ticket
  3. Leave the condition empty, so the rule runs for every email in this mailbox. You can add conditions later if some alerts need different handling.

Step 1: Extract the company and device​

  1. Click Add Action, select Extract Strings, click OK
  2. Name the step Extract Data from Email
  3. Add two definitions:
VariableExtraction TypeTextIf Empty
company_nameText Expression{{after_string email.body "Company:" flags="tn"}}Generate an exception and stop processing
device_idText Expression{{after_string email.body "Device:" flags="tn"}}Generate an exception and stop processing
  1. In Store results in variable, enter extracted

The after_string helper finds Company: in the email body and takes everything after it, up to the end of that line (n flag), with surrounding spaces trimmed (t flag). After this step, {{custom.extracted.company_name}} contains Acme Corp and {{custom.extracted.device_id}} contains SW-01.

If an email does not contain one of these labels, the automation stops and emails you an exception notice. You can then open the email in History and see what was different about it. That is safer than guessing at a customer.

Need a regular expression instead?

Set Extraction Type to Regular Expression when the value is harder to pinpoint than "everything after this label." The pattern must have one capture group, for example /Company:\s*([^\n]+)/. See Extract Strings for details.

Step 2: Find the company in Autotask​

  1. Click Add Action, select API: Query for One Object, click OK
  2. Name the step Find Account
  3. Set Entity Type to Account
  4. Add query conditions. Type { in a value field to pick from the variables available, including the values you extracted in Step 1:
    • AccountName equals {{custom.extracted.company_name}}
    • Active equals true
  5. Enable Generate an exception if more than one result, so two similarly named accounts stop the automation instead of picking one at random
  6. In Store results in variable, enter account

After this step, {{custom.account}} holds the whole account record, and {{custom.account.id}} is the ID Autotask uses for it.

Matching on the account name is the simplest approach. It works only when the name in the alert exactly matches the name in Autotask. See Identify the Customer for more reliable matching and for what to do when no account matches.

Step 3: Create the ticket​

  1. Click Add Action, select API: Create an Object, click OK
  2. Name the step Create Alert Ticket
  3. Set Entity Type to Ticket
  4. Configure the fields:
FieldValue
AccountID{{custom.account.id}} (unlock the field to enter this)
Title{{email.subject}}
DescriptionSee below
StatusNew
PriorityMedium, or whatever fits your alerts
QueueIDYour monitoring alerts queue
  1. In Store results in variable, enter ticket

Why unlock AccountID? When the field is locked, it is a picklist: you choose one account by name, and every ticket goes to that account. Behind the picklist, Autotask only receives the account's ID number. Unlocking the field lets you type a variable instead, so each alert sends the ID of the account found in Step 2.

Description. Build the description from any parts of the email or extracted values. End it with a bracketed device marker:

{{email.body}}

[Device ID: {{custom.extracted.device_id}}]

The marker ensures the device ID is on the ticket in a predictable format. Part 2 searches for it.

What you have so far​

Step through what happens when an alert arrives:

  1. Step 1 pulls Acme Corp and SW-01 out of the email.
  2. Step 2 finds the Acme Corp account in Autotask.
  3. Step 3 creates a ticket on Acme Corp, with [Device ID: SW-01] at the end of the description.

Every alert now lands on the right account. If you want a separate ticket for every alert, you are done.

Now make repeat alerts for the same device go to the ticket that is already open.

To do that, each new alert has to tell the automation which ticket it belongs to. In this tutorial, that is the combination of the customer and the device: an open ticket on Acme Corp whose description contains [Device ID: SW-01]. We will refer to this tie between an email and its ticket as the correlation key. It is the value that is the same in every email about one problem and that the automation can also find on the ticket.

Step 4: Look for an open ticket​

  1. Click Add Action, select API: Query for One Object, click OK
  2. Name the step Find Open Ticket
  3. Set Entity Type to Ticket
  4. Add these conditions to an All of these (AND) group:
    • AccountID equals {{custom.account.id}}
    • Status does not equal Complete (or whatever your closed status is)
    • Description contains [Device ID: {{custom.extracted.device_id}}]
  5. Leave Generate an exception if no results unchecked. Finding no ticket is normal; it means this is a new problem.
  6. Enable Generate an exception if more than one result. If two open tickets match, the automation stops so you can review them, instead of guessing which one to update.
  7. In Store results in variable, enter ticket

Including the brackets in the search keeps SW-1 from matching a ticket for SW-10.

Step 5: Add a note or create the ticket​

The Match action works like an if/then/else: it checks each branch's condition from top to bottom, runs the first branch that is true, and runs Default if none are.

  1. Click Add Action, select Match, click OK
  2. Name the step Update or Create Ticket
  3. Move the Create Alert Ticket step from Step 3 into the Default branch: select it, click Copy selected, click Paste in the Default branch's action list, then delete the original step
  4. Click Add Branch and set its condition to custom.ticket.id is not empty
  5. In that branch, add API: Create an Object with Entity Type TicketNote, named Add Alert Note:
FieldValue
TicketID{{custom.ticket.id}} (unlock the field to enter this)
Title{{email.subject}}
Description{{email.body}}
NoteTypeTask Summary, or your preferred note type
PublishAll Autotask Users or Internal Only

The finished rule looks like this:

StepActionWhat it does
1Extract StringsPulls the company and device out of the email
2API: Query for One ObjectFinds the company's account
3API: Query for One ObjectLooks for an open ticket on that account for that device
4Match, branch: custom.ticket.id is not emptyAdds the email to the open ticket as a note
Match, DefaultCreates a new ticket

What happens now​

  • First alert for SW-01: no open ticket is found, so Match runs Default and creates a ticket.
  • More alerts for SW-01 while the ticket is open: the open ticket is found, so each alert becomes a note on it. No new tickets are created.
  • A tech closes the ticket: the next alert for SW-01 finds no open ticket and starts a new one.
  • An alert for a different device: it has a different device ID, so it gets its own ticket.

Optional: close the ticket automatically​

To close the ticket when the device recovers, add two branches to the Match action, above the note branch. Branch order matters, because Match runs only the first branch that is true.

OrderConditionActions
1custom.ticket.id is not empty AND email.body contains Status: upAdd the note, then API: Update an Object to set the ticket's Status to Complete
2email.body contains Status: upNo actions. A recovery with no open ticket has nothing to close, and an empty branch keeps Default from creating a ticket.
3custom.ticket.id is not emptyAdd the note (from Step 5)
DefaultCreate the ticket (from Step 3)

Adding a note and closing the ticket take two separate actions because the Autotask API handles notes and status changes as separate calls. Use whatever text your tool uses for a recovery in place of Status: up.

Identify the Customer​

Step 2 matched the account by name. That is the quickest way to get started, but it depends on the alert and Autotask using exactly the same name. Choose the approach that fits your data, then decide what happens when no account matches.

Option 1: Match the account name​

This is the approach used in Step 2: AccountName equals the extracted company name. It works out of the box, but it breaks when the names differ even slightly (Acme Corp. in the alert versus Acme Corp in Autotask), or when someone later renames the account in Autotask.

Create an account User-Defined Field (UDF) named after the monitoring tool, such as Meraki Organization Name. For each customer, enter the exact name your monitoring tool uses for them. Then change the Step 2 condition to:

  • UDF: Meraki Organization Name equals {{custom.extracted.company_name}}

Now the two systems are linked by a value you control. Renaming an account in Autotask cannot break the automation, and the names do not have to match.

Option 3: Try both​

To use the UDF where you have filled it in and fall back to the account name everywhere else, put both conditions in an Any of these (OR) group, inside the All of these (AND) group that checks Active:

  • UDF: Meraki Organization Name equals {{custom.extracted.company_name}}
  • AccountName equals {{custom.extracted.company_name}}

This lets you start right away and fill in the UDF over time, only for customers whose names differ.

When no account matches​

You choose how the automation handles an alert for a customer it cannot find:

ChoiceSetupResult
Stop and notifyOn the Find Account step, enable Generate an exception if no resultsThe automation stops and emails you an exception notice. No ticket is created until you fix the match and replay the email from History.
Use a default accountLeave Generate an exception if no results unchecked. Add a second API: Query for One Object right after it that finds your catch-all account (for example, AccountName equals Unknown Customer), stores its result in account, and has Only perform this action if set to custom.account.id is empty.Every alert still becomes a ticket. Unmatched alerts land on your catch-all account, where a tech can move them.

With Stop and notify, no alert is placed on the wrong account, but someone has to act on the exception. With Use a default account, no alert is held up, but some tickets need to be moved by hand. Consider adding the extracted company name to the ticket description, so the tech can see what the alert called the customer.

Instead of a dedicated catch-all account, you can use your zero account: skip the second lookup and enter {{#if custom.account.id}}{{custom.account.id}}{{else}}0{{/if}} in the unlocked AccountID field. It sends the found account's ID, or 0 when no account was found. Use the same expression for the AccountID condition in Step 4, so repeat alerts for an unmatched customer still find their ticket on the zero account.

Refinements​

Use an alert ID instead of the device​

Some tools include an ID that stays the same for every email about one alert, for example:

Alert ID: 9ca47b57-4c3f-8691-25e4-df3457b414d7

An alert ID is more specific than a device. If one device can have several problems at once, such as a disk alert and a CPU alert, the device marker groups them into one ticket. An alert ID gives each problem its own ticket.

To use it, extract the ID in Step 1, store it in the description marker in Step 3 ([Alert ID: {{custom.extracted.alert_id}}]), and search for that marker in Step 4. Set the extraction's If Empty to Generate an exception and stop processing, so an alert without an ID is not matched by guesswork. You can keep the device marker in the description too; it helps techs even though the automation no longer searches on it.

Make sure the recovery email repeats the original alert's ID. Some tools assign a new ID to the recovery event, which will not match the ticket.

You can store the marker in the ticket Title or in a dedicated ticket UDF instead of the description. Whichever field you choose, Step 4 must search that same field. Do not store it only in a note; the search looks at the ticket itself, not its notes.

If you track devices as Configuration Items (CIs) in Autotask, you can look up the CI by device name (Entity Type InstalledProduct) and use it in two ways:

  • To identify the customer: the CI's AccountID tells you the account, so you do not need a company name in the alert.
  • To link the ticket: set the ticket's InstalledProductID to the CI's ID, so techs see the device and its history.

Linking the CI is worthwhile even if you keep matching on the description marker. The Create Autotask Ticket (by Configuration Item) workflow action combines the CI lookup and ticket creation in one step.

Split the logic across rules​

This tutorial keeps everything in one rule. You can split it, for example into an Extract Data rule followed by a Create or Update Ticket rule. If you do, store values that later rules need in global instead of custom. Email Processing resets custom when each rule finishes; global carries over to later rules for the same email. To switch, double-click the custom. prefix in the Store results in variable field. See Variables for details.

Test​

  1. Send a test alert for a device. In History, open the details log and confirm that both values were extracted, the account was found, no open ticket was found, and a ticket was created on the right account with the device marker.
  2. Send a second alert for the same device. Confirm that it was added to the first ticket as a note and that no new ticket was created.
  3. Send an alert for a different device. Confirm that it created its own ticket.
  4. Close the first ticket in Autotask, then send another alert for that device. Confirm that a new ticket was created.
  5. Send an alert with a company name that does not exist in Autotask. Confirm that it follows the choice you made in When no account matches.
  6. If you set up auto-close, send a recovery alert. Confirm that the ticket received a note and closed. Send the recovery alert again and confirm that nothing changed and no ticket was created.
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​

An alert is missing a value​

If the company or device label is missing, the automation stops with an exception and emails you. Open the email in History, check whether your tool changed its format, and update the extraction.

Two open tickets match​

The automation stops with an exception and changes neither ticket. Review the tickets in Autotask and merge or close the duplicate. If this happens often, the correlation key is not specific enough. For example, one device may have several separate problems open at once; consider using an alert ID.

Two accounts match​

The automation stops with an exception. Use a UDF that you control to make the match exact.

Key Takeaways​

  • Read the customer from the alert, not the sender: extract it, find the account, and create the ticket on that account from the start
  • Start simple: three steps (extract, find, create) put every alert on the right account
  • Look for an open ticket first: the correlation key (here, account plus device marker) tells the automation which ticket an alert belongs to
  • Use Match as an if/then/else: add a note when an open ticket exists; otherwise create one
  • Match on a field you control: an account UDF is more reliable than an exact name match
  • Decide what happens when no account matches: stop and notify, or use a default account
  • Stop on ambiguity: enable the more-than-one-result exception instead of guessing