Email2AT support for Problem Management features?

With the new release of Autotask’s Problem Management features, a number of Email2AT users have asked if we’ll be supporting the new “Ticket Type” field in Email2AT.

Basically, they want to know if they can have Email2AT create “Problem” or “Incident” tickets for their users.

The short answer is that we do not have plans to support this new pull-down. This is partly because Autotask’s API doesn’t make that field available to us. But, more importantly, you probably don’t want your customers creating Problem tickets at all (these should be created by your team after identifying a root systemic issue that needs remediation). Each of your customer’s tickets will likely be “Incident” tickets, but Email2AT doesn’t have a way to know what Problem they’re associated to. Unfortunately, this has to be a manual, human process, because it involves intellect and understanding how the tickets relate to one another.

If I’m missing something in my thoughts here, do let me know in the comments below.

Route Messages Based on Reply-To Address Instead of From Address

Several users have asked that we add the ability to route an inbound email based on the “Reply-To” address of the message instead of the “From” address. This is now available:

An Update to Client Portal Ticket Notes

A few months ago, we released a very cool feature which used the client access portal to add notes to tickets. We also introduced a couple bugs in the process. I am thrilled to announce that these bugs have since been fixed.

New Contacts Created when “Auto Create Contacts” is Disabled

A number of users reported that they were seeing new contacts created in their Autotask accounts even if Email2AT was set to not create new contacts. Email2AT was incorrectly creating new contacts when customers replied because Email2AT needed a client portal user account in order to add the note.

We’ve now updated Email2AT to be more intelligent on these replies. When an email is received to update an existing ticket, Email2AT will attempt to locate an existing contact in Autotask for the sender. If Auto Create Contacts is disabled, and a contact is not found, then Email2AT will add the reply via the API (not the client portal). If a contact is found, then Email2AT will add the note via the portal for that user (and Email2AT will activate the portal if needed, too).

Internal Resources Created as Contacts

When an internal resource (an Autotask user) sends a ticket update to a customer’s ticket, Email2AT was creating a contact and a portal account for that Autotask user. This meant that Autotask users had a bunch of contacts on all sorts of accounts in their own Autotask.

Email2AT will no longer use the portal to add notes to tickets if the note is being sent in by an Autotask resource. Email2AT will always use the API for these notes.

Thanks for your patience as we worked through these fixes.

Major Enhancement to Ticket Replies via Email

Email2at is built atop the technologies provided by Autotask’s WebServices API. This API allows Email2AT to create new tickets, update tickets, add notes to tickets, and even lookup Accounts and Contacts from an Autotask database.

Like any technology, the Autotask API has a few quirks, some of which directly affect Email2AT. In particular, the API acts “on behalf of” a particular Autotask Resource, so all actions performed by the API actually appear to have been done by the user who originally setup Email2AT for the Autotask company.

This behavior is perfect for interactive applications such as dashboards or other interfaces to Autotask since the user is indeed the person performing the action.

In automated systems such as Email2AT, though, this behavior can be troublesome. For example, when a customer replies to an Autotask email notification, Email2AT adds the reply as a note to the existing ticket. The ticket history will show that the person who added the note was the Autotask Resource who setup Email2AT, when, in actuality, the person adding the note was the customer who sent the email.

Today, we’re thrilled to announce that we have overcome this quirky behavior in Autotask’s API.

Here’s the skinny.

Email2AT now has the ability to add notes via Autotask’s Client Access Portal interface instead of just using the WebServices API. This means that notes added via a reply email can now be displayed in the ticket history as being added by the actual person who sent the email. This makes the ticket history much easier to read and follow, and helps to drastically reduce confusion among Autotask users and customers alike.

This change also fixes another quirky behavior: dual workflow notifications.

Previously, Email2AT had to call the API twice when a customer replied to a notification: once to edit the ticket status to something like “Customer Added Note”, and then again to actually add the reply as a note to the ticket. This would cause Autotask to fire any pertinent workflow rules twice which would generate redundant notifications from Autotask.

Now, Email2AT can add a note via the Portal interface instead of the API, and the Portal can change the ticket status. This means that Email2AT doesn’t make any API calls, and that the workflow rules fire only one time. Autotask users who receive these notifications will be much happer as they will have much fewer emails from Autotask.

This new feature is enabled by default on all new Email2AT inbound addresses. To enable this on your existing addresses, simply edit the Email2AT inbound address and change the pull-down “Create notes via” to “Client Access Portal”.

Email2AT: API Order When Adding Notes

When a customer replies to an Autotask notification, Email2AT can add that reply as a ticket note to an existing ticket. Email2AT can also modify the status of that ticket.

Many users configure a workflow rule to send a notification to the ticket’s assigned resource when that ticket status is changed, but that used to mean two notifications would fire: one when the ticket status was changed, and one when the ticket note was added.

We’ve now added the option to configure Email2AT to add the note before the ticket is edited, resulting in a single notification.

(Note: if your Autotask workflow notification includes the description of the note, then you will need to keep this set to edit the ticket first, and you will continue to receive two notifications from Autotask)

Transfer an Email to Autotask with ONE Click!

We just added a feature that we’re VERY excited about!

When you receive an email in your Microsoft Outlook inbox that belongs in Autotask, you can now move it to Autotask with ONE click and NO pop-up windows.

Here’s how to set it up.

In Microsoft Outlook 2010, navigate to the “Home” tab of the ribbon, then create a new Quick Step

Give the Quick Step a unique name (such as “Send to Autotask” or even simply “support@mydomain.com”)

Configure 3 steps:

  1. Step one should be “Forward message as an attachment”
    1. Set the “to” address to an Email2AT-bound email address
    2. Click the “Show Options” button (the screenshot shows “Hide Options”)
    3. Select “Automatically send after 1 minute delay”.
  2. Step two should be “Mark as Read” (optional)
  3. Step three should be “Move to folder” (optional)

Now, when you receive an email in your inbox that needs to go to Autotask, simply click this “Quick Action” button, and it will sent to Email2AT to be converted to a ticket. Since it’s forwarded as an attachment, we’ll parse the email as if the person had sent it directly to your Email2AT address (it will show as “from” the original sender, and will be assigned to their account, etc).

As always – questions? Ask us at support@mspintegrations.com.

List Additional Domains and Email Addresses

Email2AT uses specific logic to determine which Contact and Account a new Ticket should be assigned to. This logic relies on the “Email Address” field of Contacts, as well as the “Web Site” field of Accounts.

Email2AT will now also include a user-defined field called “Email2AT Addresses” for Contacts, and “Email2AT Domains” for Accounts.

Here’s why this is such a cool thing: Previously, if your customer had a professional email address (suzyq@coolcustomer.com) as well as a personal email address (suzylovesbananas@gmail.com), Email2AT would only correctly handle inbound email from the customer’s professional address (or whichever address was listed in Autotask for that Contact). Now, you can add the customer’s alternative email addresses to the “Email2AT Addresses” field in the Contact, and Email2AT will correctly handle email sent from the professional address as well as the personal address.

Similarly with Account, some companies use many email domains. Instead of only recognizing a single domain, Email2AT can now support as many inbound email domains as an Account may need. If Acme Corp uses @acme.com, @acmecorp.com, and @mycoolacmewidget.com, Email2AT can handle all three of these. Simple set the “Email2AT Domains” field for this Account to be “@acme.com, @acmecorp.com, @mycoolacmewidget.com”.

During the Email2AT activation process, two new User Defined Fields will be added to your Autotask instance automatically. Accounts will have a new field called “Email2AT Domains” and Contacts will have a new field called “Email2AT Addresses”.

Instead of a single domain-per-Account and a single email-per-Contact, simply list additional domains and email addresses in each of these fields.

More Helpful Question Marks

We’ve added a few more blue (?) to the interface. Check them out, specifically when creating new Email2AT filters.

New Search for Email History Screen

No more wading through page after page of email history! There is a new search box at the top of all history screens to make it much easier to find a particular message. Searching is available based on the email sender’s address, the filter they sent to, the email subject, and the Autotask Ticket Number.

There is also a new link from the Email2AT Filters List screen to link directly to a search of messages for that particular filter.