Skip to main content

UniFi Online/Offline Emails with Autotask

This tutorial walks through building a workflow that processes device offline and device online alert emails from Ubiquity UniFi. When a device goes offline, a new Autotask ticket is created. When the device reconnects, Email2AT locates that original ticket, adds a note, and closes it.

Part 1 covers the core workflow. Part 2 covers how to associate tickets to the correct Autotask account based on the sender's email address.

Overview​

UniFi sends two types of alert emails:

AlertSubject lineWhat the workflow does
Device offlineDevice OfflineCreates a new Autotask ticket for the device
Device reconnectedDevice ReconnectedFinds the open offline ticket and closes it with a note

The key challenge is connecting these two separate emails to a single ticket. The workflow solves this by extracting the device name from each email and embedding it in the ticket description. When the online alert arrives, Email2AT queries Autotask for an open ticket containing that device name and updates it.

Related pages:

Part 1: Create and Close Tickets for Offline/Online Alerts​

Before You Start​

Create a dedicated mailbox for UniFi alerts. Do not use your general support mailbox.

  1. Navigate to Email2AT and click Hosted Mailboxes
  2. Create a new mailbox, for example: [email protected]
  3. Configure your UniFi system or controller to send alert emails to this address

Send a test offline and online alert through before building the rules. With no rules in the mailbox yet, the emails will be received and logged in History but not processed. You can then open those history entries to see exactly how Email2AT parsed each email, which makes writing the extraction logic much easier.

Rule 1: Process Offline Alerts​

This rule fires only when a device goes offline and creates a new ticket.

Add the rule​

  1. In your mailbox, click Add New Rule
  2. Name it Process UniFi Offline Alerts
  3. Set the Expression so the rule only fires for offline emails: subject equals Device Offline

Action 1: Extract the device name​

  1. Click Add New Action, select Render Text and Store as Variable, click OK
  2. Name the step Extract Device Name
  3. In the text field, enter:
{{after_string email.body "Device Name: " flags="tn"}}

This extracts everything after Device Name: in the email body. The t flag trims whitespace and the n flag stops at the next newline, so you get just the device name (for example, ACME-AP-01) and nothing else.

  1. In Store results in variable, enter device_name
  2. Set Only perform this action if to always run (no condition needed on this step)
Why use History first

Before building the extraction, open the offline email in History and look at the plain text body exactly as Email2AT received it. Find the Device Name: label and confirm the format. UniFi alert emails may vary slightly depending on your controller version.

Action 2: Create the ticket​

  1. Click Add New Action, select API: Create an Object, click OK
  2. Name the step Create New Ticket
  3. Set Entity Type to Ticket
  4. Set Only perform this action if: custom.device_name is not empty
  5. Configure the ticket fields:

Ticket fields:

FieldValue
AccountIDYour zero account (unlock the field and enter 0), or see Part 2 for account matching
StatusNew
PrioritySet as appropriate for alert severity
QueueIDYour monitoring alerts queue
Title{{email.subject}}
Description{{email.body}} followed by a blank line and [UniFi Device: {{custom.device_name}}]

The [UniFi Device: ACME-AP-01] tag at the end of the description is how the online rule will find this ticket later. When the online alert arrives, Email2AT searches for an open ticket whose description contains [UniFi Device: followed by the device name from the online email. This tag ensures the search is specific enough to find exactly the right ticket.

Action 3: Stop​

  1. Click Add New Action, select Stop Processing This Message Completely, click OK
  2. Name it Stop
  3. Set Only perform this action if: custom.device_name is not empty
What happens when device_name is empty

If the device name extraction returns empty (for example, the email format is unexpected), steps 2 and 3 are skipped. The email is not stopped, so any catch-all rule further down the mailbox's rule list will fire instead. This lets you handle unknown alert formats separately rather than silently discarding them.

Rule 2: Process Online Alerts​

This rule fires when a device reconnects, finds the original offline ticket, adds a note, and closes it.

Clone Rule 1 to use it as a starting point, then make the following changes.

Add the rule​

  1. Clone Rule 1 or create a new rule named Process UniFi Online Alerts
  2. Change the Expression to: subject equals Device Reconnected
  3. Delete the Create Ticket and Stop actions, keeping only the Extract Device Name step

Action 1: Extract the device name (same as Rule 1)​

Keep the same extraction step: {{after_string email.body "Device Name: " flags="tn"}} stored as device_name.

Action 2: Query Autotask for the open offline ticket​

  1. Click Add New Action, select API: Query for One Object, click OK
  2. Name the step Find Open Offline Ticket
  3. Set Entity Type to Ticket
  4. Set Only perform this action if: custom.device_name is not empty
  5. Add query conditions:
    • Status does not equal Complete
    • Description contains [UniFi Device: {{custom.device_name}}]
  6. Set Sort to CreateDate descending
  7. Leave Generate exception if no results unchecked (it is valid for an online alert to arrive with no matching open ticket)
  8. In Store results in variable, enter ticket

Action 3: Update the ticket status to Complete​

  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. Set Only perform this action if: custom.ticket.id is not empty
  5. Configure fields (only add the fields you want to change):
FieldValue
ID{{custom.ticket.id}} (unlock the field)
StatusComplete

Action 4: Add a note to the ticket​

  1. Click Add New Action, select API: Create an Object, click OK
  2. Name the step Add Reconnection Note
  3. Set Entity Type to TicketNote
  4. Set Only perform this action if: custom.ticket.id is not empty
  5. Configure fields:
FieldValue
TicketID{{custom.ticket.id}} (unlock the field)
Title{{email.subject}}
Description{{email.body}}
NoteTypeTask Summary
PublishAll Autotask Users
Why add the note after closing the ticket

In the Autotask UI, adding a note and changing status look like one step. The API requires two separate calls. Order them as: update status first, then create the note.

Action 5: Stop​

  1. Click Add New Action, select Stop Processing This Message Completely, click OK
  2. Name it Stop
  3. Set Only perform this action if: custom.ticket.id is not empty

When custom.ticket.id is empty (no open ticket was found for the device), the stop is skipped. A catch-all rule can then handle the unmatched online alert.

Rule Order​

Drag the rules into this order in the mailbox and save the order:

  1. Process UniFi Offline Alerts (expression: subject equals Device Offline)
  2. Process UniFi Online Alerts (expression: subject equals Device Reconnected)
  3. A catch-all rule with no expression (optional, recommended): handles any UniFi email that did not match the above two rules

Each rule has an expression, so only one rule fires per email. The catch-all at the bottom fires only if neither of the first two rules stopped the message.

Test the Workflow​

Test the offline alert:

  1. Replay the offline email from History (or send a new one)
  2. Open the processing log and verify:
    • The device name was extracted correctly
    • A ticket was created in Autotask with the [UniFi Device: ...] tag in the description
  3. Open the ticket in Autotask to confirm the description and title look correct

Test the online alert:

  1. Replay the online email from History (or send a new one)
  2. Open the processing log and verify:
    • The device name was extracted correctly
    • Autotask was queried and the correct open ticket was found
    • The ticket status was changed to Complete
    • A note was added to the ticket
Use Replay to iterate

The Play button on any History entry re-processes the same email through your current rules. You do not need to send new test emails each time you adjust a rule.

Part 2: Associate Tickets to the Correct Account​

By default, Part 1 creates every ticket on your zero account. If each of your customers has their own UniFi controller sending alerts from a customer-specific email address (for example, [email protected]), you can use that from address to look up the correct Autotask account and create the ticket there instead.

How It Works​

When an offline alert arrives:

  1. Extract the device name (same as before)
  2. Query Autotask for a Contact whose email address matches the alert's from address
  3. If a matching Contact is found: create the ticket on that Contact's account and optionally associate the Contact
  4. If no matching Contact is found: fall back to creating the ticket on the zero account

Setting Up Account Association​

Clone your offline alert rule and add a Contact lookup step between extraction and ticket creation. Disable the original rule once the new one is ready.

Action 2: Query Autotask for the contact​

  1. Click Add New Action, select API: Query for One Object, click OK
  2. Name the step Query Autotask for Contact
  3. Set Entity Type to Contact
  4. Set Only perform this action if: custom.device_name is not empty
  5. Add query conditions (use an OR group for all three):
    • Active equals 1
    • OR group:
      • EmailAddress equals {{email.from.address}}
      • EmailAddress2 equals {{email.from.address}}
      • EmailAddress3 equals {{email.from.address}}
  6. Leave Generate exception if no results unchecked (no contact found is a valid fallback)
  7. In Store results in variable, enter contact

Action 3: Create ticket (contact found)​

  1. Clone the existing Create Ticket step to get two versions
  2. Name this one Create Ticket (Contact Found)
  3. Set Only perform this action if: custom.contact.id is not empty
  4. Unlock both AccountID and ContactID fields:
    • AccountID: {{custom.contact.accountId}} (the account the contact belongs to)
    • ContactID: {{custom.contact.id}} (optional: associates the contact to the ticket)

Action 4: Create ticket (no contact found)​

  1. Name this version Create Ticket (No Contact)
  2. Set Only perform this action if: custom.contact.id is empty
  3. Set AccountID back to 0 (the zero account) and remove the ContactID field

Action 5: Stop​

Keep the same stop step, still conditioned on custom.device_name is not empty.

Alternative Approaches​

The Contact lookup is the most common approach, but it is not the only one. You can query for any Autotask entity that stores the UniFi controller's email address:

  • Account User-Defined Field: add a UDF to the Account called UniFi Alert Address and query Accounts where that UDF equals {{email.from.address}}
  • Configuration Item: store the controller's email address on a CI and query InstalledProducts
  • Custom mapping: use a Render Text step to hard-code account IDs for known from addresses

The query in step 2 is the only thing that changes between these approaches. Everything else stays the same.

Online Alert: Optional Account Filtering​

For most setups, the online alert rule does not need account-aware logic. The device name tag in the ticket description is specific enough to find the right ticket regardless of which account it is on.

If you have multiple customers with devices that share the same name (for example, AP-01 at every site), add an additional filter to the ticket query:

  • Query for Contact (same OR group as above), store as contact
  • In the Find Open Offline Ticket query, add: AccountID equals {{custom.contact.accountId}}

This ensures the ticket found belongs to the same account as the alert's sender.

Key Takeaways​

  • One mailbox for UniFi alerts: keep these rules isolated from your general support mailbox
  • The device name tag links the two emails: embedding [UniFi Device: name] in the ticket description is what allows the online alert to find and close the correct ticket
  • Guard every action with a condition: if the device name or ticket lookup returns empty, skipping dependent steps allows a catch-all rule to handle the edge case gracefully
  • Two API calls to add a note and change status: Autotask requires separate calls; update the ticket status first, then create the TicketNote
  • History is your best debugging tool: use Replay and the processing log to see exactly what was extracted and what Autotask returned at each step

What's Next​