Skip to main content

Turn UniFi Offline and Reconnected Emails into One Autotask Ticket

UniFi sends one email when a device goes offline and a separate email when it reconnects. Autotask cannot tell that the two messages belong together. The sender also may not identify the customer, so each email can become a separate ticket on the wrong account.

This tutorial builds an automation that connects the two messages:

  1. A Device Offline email creates a ticket.
  2. A Device Reconnected email finds that ticket by device name, adds the recovery email as a note, and closes the ticket.
  3. An optional account lookup puts the ticket on the customer associated with the sender's email address.
Building blocks, not a fixed recipe

Email Processing gives you building blocks such as extract, look up, create, update, and branch. This tutorial arranges them for UniFi's offline and reconnected emails. You can change the account lookup, ticket fields, fallback, or closing behavior to fit your process.

Decide What Should Happen​

UniFi naturally fits an auto-close design because it sends a clear recovery message:

ApproachHow it behaves
Create on offline and close on reconnect (this tutorial)Device Offline creates a ticket. Device Reconnected adds a note and closes that ticket.
Keep one ticket open until a tech closes itThe first alert creates a ticket. Later alerts become notes while the ticket remains open. See Monitoring Alerts to the Right Autotask Account and Ticket.
Create a separate ticket for every emailEvery offline and reconnected message creates its own ticket.

All three designs work. Choose the one that matches how your team responds to UniFi alerts.

Before You Start​

Create a Hosted Mailbox for UniFi​

  1. Open Email2AT, then click Hosted Mailboxes.
  2. Create a Hosted Mailbox, for example [email protected].
  3. Configure UniFi to send alerts to that address.

We recommend a dedicated address for each monitoring tool because it keeps its rules and History separate. There is no technical requirement to do this. You can use a shared support mailbox if you add conditions that identify UniFi messages reliably.

Send examples before you build​

Send one offline alert and one reconnected alert to the Hosted Mailbox before adding rules. Both emails appear in History, but nothing processes them yet.

Open each email in History and inspect the plain text body. Confirm that your messages contain:

  • The subject Device Offline or Device Reconnected
  • A line such as Device Name: ACME-AP-01

UniFi versions may format alerts differently. Building from the text in History shows you exactly what the automation receives.

Part 1: Create the Offline Ticket and Close It on Reconnection​

Start with the smallest useful version. It extracts the device name, creates an offline ticket on your zero account, then finds and closes that ticket when UniFi reports the reconnection.

The video uses a different layout

The video builds the same result with two rules, one for each subject, and uses Stop actions to keep later rules from processing the email. The written steps below use one rule with a Match action, which works like an if/then/else and keeps the decision in one place. The written layout is the current recommendation.

Create one rule for both UniFi subjects​

  1. In the Hosted Mailbox, click Add New Rule.
  2. Name it Process UniFi Offline and Reconnected Alerts.
  3. Set the rule condition to an Any of these (OR) group:
    • email.subject equals Device Offline
    • email.subject equals Device Reconnected

The exact subject conditions keep unrelated messages out of this rule.

Step 1: Extract the device name​

  1. Click Add Action, select Extract Strings, then click OK.
  2. Name the step Extract Device Name.
  3. Add this definition:
VariableExtraction TypeTextIf Empty
device_nameText Expression{{after_string email.body "Device Name: " flags="tn"}}Continue processing
  1. In Store results in variable, enter extracted.

The after_string helper takes the text after Device Name: . The n flag stops at the next line, and the t flag trims surrounding spaces. For an alert that contains Device Name: ACME-AP-01, the result appears as {{custom.extracted.device_name}}.

The remaining steps check that this value exists before they run. If UniFi changes its email format, the rule skips ticket changes and lets a later catch-all rule handle the email.

Step 2: Look for the open offline ticket​

  1. Click Add Action, select API: Query for One Object, then click OK.
  2. Name the step Find Open Offline Ticket.
  3. Set Entity Type to Ticket.
  4. Set Only perform this action if to both conditions:
    • custom.extracted.device_name is not empty
    • email.subject equals Device Reconnected
  5. Add these query conditions:
    • Status does not equal Complete
    • Description contains [UniFi Device: {{custom.extracted.device_name}}]
  6. Leave Generate an exception if no results unchecked. A reconnected email can arrive when no matching open ticket exists.
  7. Enable Generate an exception if more than one result so the automation does not guess between duplicate open tickets.
  8. In Store results in variable, enter ticket.

This step runs only for a reconnected alert. The offline path does not need to look for a ticket.

Step 3: Choose whether to close or create​

The Match action checks branches from top to bottom and runs the first true branch. If no branch matches, it runs Default.

  1. Click Add Action, select Match, then click OK.
  2. Name the step Close or Create Ticket.
  3. Add the following branches in this order.

Branch 1: Close the matching ticket​

Set the branch condition to both:

  • email.subject equals Device Reconnected
  • custom.ticket.id is not empty

Add these two actions inside the branch in this order.

Add a reconnection note

  1. Add API: Create an Object and name it Add Reconnection Note.
  2. Set Entity Type to TicketNote.
  3. Configure these fields:
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

Close the ticket

  1. Add API: Update an Object and name it Close Ticket.
  2. Set Entity Type to Ticket.
  3. Configure these fields:
FieldValue
ID{{custom.ticket.id}} (unlock the field to enter this)
StatusComplete

Autotask requires separate actions for the note and status change. Unlocking TicketID and ID changes each picklist into a field where you can enter the ticket ID found in Step 2. Type { to choose that variable from the available data.

Branch 2: Ignore an unmatched reconnection​

Add a branch with this condition and leave its action list empty:

  • email.subject equals Device Reconnected

An empty matching branch counts as the selected branch. It prevents a reconnected email with no open ticket from reaching Default and creating a new ticket. Because no ticket changed, a later catch-all rule can still handle this email.

Default: Create the offline ticket​

Add API: Create an Object to the Default branch:

  1. Name the action Create Offline Ticket.
  2. Set Entity Type to Ticket.
  3. Set Only perform this action if to custom.extracted.device_name is not empty.
  4. Configure the ticket fields:
FieldValue
AccountIDYour zero account (unlock the field and enter 0)
StatusNew
PriorityChoose the priority that fits these alerts
QueueIDYour monitoring alerts queue
Title{{email.subject}}
DescriptionSee below

End the description with a device marker:

{{email.body}}

[UniFi Device: {{custom.extracted.device_name}}]

The marker gives both emails a shared value. For example, the offline ticket contains [UniFi Device: ACME-AP-01], and the reconnected email searches for that exact marker. Including the brackets keeps a shorter name from matching part of a longer one.

Step 4: Stop after a successful result​

  1. Add Stop processing this message completely after Match.
  2. Name it Stop After Successful Processing.
  3. Set Only perform this action if to either condition group:
    • email.subject equals Device Offline AND custom.extracted.device_name is not empty
    • email.subject equals Device Reconnected AND custom.ticket.id is not empty

The Stop action runs only after the automation creates or closes a ticket. If the device name is missing or a reconnected email has no open ticket, the message continues to a later catch-all rule instead.

What you have so far​

For an offline and recovery pair from ACME-AP-01:

  1. The offline email provides the device name.
  2. Match reaches Default and creates a ticket with [UniFi Device: ACME-AP-01] in its description.
  3. The reconnected email provides the same device name.
  4. The ticket query finds the open ticket with that marker.
  5. Match runs Branch 1, which adds the recovery email as a note and changes the ticket status to Complete.

At this point, the two UniFi emails produce one ticket. Part 2 changes only where the offline ticket gets created.

Part 2: Put the Ticket on the Correct Account​

Part 1 uses your zero account. If each customer's UniFi controller sends from a customer-specific address such as [email protected], you can match that address to an Autotask Contact and use the Contact's account for the ticket.

The video uses two guarded create actions

The video clones the ticket action, then guards one copy with "contact found" and the other with "contact not found." The written steps use a nested Match action for the same choice. The written layout is the current recommendation. The video also shows the zero account fallback; you can choose an exception instead.

Decide what no match should do​

Choose your fallback before adding the lookup:

ChoiceResult
Stop and notifyEnable Generate an exception if no results on the Contact query. No ticket gets created until you add or correct the Contact and replay the email from History.
Use the zero accountLeave that option unchecked. The nested Match action creates unmatched tickets on account 0, where a tech can move them.

Neither choice fits every MSP. An exception avoids putting a ticket on the wrong account, but someone must fix and replay the alert. The zero account keeps every alert visible, but a tech may need to move the ticket. See The Autotask Zero Account for details.

Step 1: Find the Contact by sender address​

Add this action between Extract Device Name and Find Open Offline Ticket:

  1. Add API: Query for One Object and name it Find Contact by Sender Address.
  2. Set Entity Type to Contact.
  3. Set Only perform this action if to both:
    • custom.extracted.device_name is not empty
    • email.subject equals Device Offline
  4. Add Active equals 1 to an All of these (AND) group.
  5. Inside that group, add an Any of these (OR) group:
    • EmailAddress equals {{email.from.address}}
    • EmailAddress2 equals {{email.from.address}}
    • EmailAddress3 equals {{email.from.address}}
  6. Enable Generate an exception if more than one result so the automation does not choose between duplicate Contacts.
  7. Set Generate an exception if no results according to the fallback you chose above.
  8. In Store results in variable, enter contact.

After this step, {{custom.contact.accountId}} identifies the Contact's account. You may also use {{custom.contact.id}} to associate the Contact with the ticket, but a monitoring system address often does not represent a person, so leaving ContactID off the ticket can make more sense.

Step 2: Choose the account in the Default branch​

In the Close or Create Ticket Match action, replace the Create Offline Ticket action in Default with another Match action named Choose Ticket Account.

Contact found branch​

  1. Add a branch where custom.contact.id is not empty.
  2. Add API: Create an Object with Entity Type Ticket.
  3. Name it Create Ticket on Contact Account.
  4. Keep the same status, priority, queue, title, description, device marker, and device-name guard from Part 1.
  5. Unlock AccountID and enter {{custom.contact.accountId}}.
  6. Optional: add ContactID, unlock it, and enter {{custom.contact.id}}.

Default branch for no Contact​

If you chose the zero account fallback:

  1. Add API: Create an Object to the nested Default branch.
  2. Name it Create Ticket on Zero Account.
  3. Keep the same fields and conditions from Part 1.
  4. Unlock AccountID and enter 0.
  5. Leave ContactID off the ticket.

If you chose Stop and notify, leave the nested Default branch empty. The Contact lookup stops with an exception before the automation reaches it.

Other ways to identify the customer​

The sender-to-Contact lookup works well when every controller uses a unique email address that already belongs to an Autotask Contact. You can also create an Account UDF such as UniFi Alert Address, enter each controller's sender address on its customer account, and query that UDF instead.

A UDF gives you a value that you control specifically for this integration. It also avoids creating a Contact for an automated system. For approaches based on a customer name, an Account UDF, or both, plus the choices when no account matches, see Identify the Customer.

Optional: include the account when finding the open ticket​

The device marker usually identifies the open ticket. If customers reuse names such as AP-01, also identify the account before querying for a ticket on reconnected emails, then add this ticket query condition:

  • AccountID equals the account ID found for the sender

This makes the customer plus device marker the shared identifier. Apply the sender lookup to both subjects when you use this option, not only to Device Offline.

What happens now​

  • Known sender goes offline: the Contact lookup finds [email protected], and the Default path creates the ticket on that Contact's account.
  • Known device reconnects: the automation finds the open ticket by its device marker, adds a note, and closes it.
  • Unknown sender goes offline: the automation either stops with an exception or creates the ticket on the zero account, according to your choice.
  • Unexpected email format: the guarded actions skip ticket changes, so a later catch-all rule can handle the email.

Test the Automation​

  1. Replay the offline email from History. Confirm that the extraction produced the device name and the ticket description ends with the exact [UniFi Device: ...] marker.
  2. If you completed Part 2, confirm that the ticket uses the expected customer account or your chosen fallback.
  3. Replay the reconnected email. Confirm that the automation found the same ticket, added a note, and changed its status to Complete.
  4. Replay the reconnected email again. Confirm that it did not create a new ticket because no open matching ticket remains.
  5. Test an email without Device Name:. Confirm that the guarded actions skip and your catch-all rule handles it.
Use Replay while iterating

After you change a rule, click the Play button on a History entry to process the same email again. You do not need to send a new test message after every change.

Key Takeaways​

  • Decide the ticket lifecycle first: this tutorial creates on offline and closes on reconnection, while the general monitoring tutorial shows the alternative where notes continue until a tech closes the ticket.
  • Use one predictable device marker: put [UniFi Device: name] in the ticket description and search for the same complete marker.
  • Guard dependent actions: only query when the device exists, and only add a note or close when the ticket exists.
  • Treat account fallback as a design choice: stop with an exception when accuracy matters most, or use the zero account when every alert must create a visible ticket.
  • Use sender-to-Contact matching when it fits your data: an Account UDF provides another reliable option that does not require an automated Contact.