Route Direct Customer Emails to Autotask
Customers sometimes email a technician directly instead of sending to your shared support address. When that happens, you need those emails to become properly attributed Autotask tickets with the correct Account and Contact, without asking customers to change their habits.
This tutorial covers three approaches for handling this with MSPintegrations. Each varies in how much manual effort is required per email and how much automation you get out of the box.
Prerequisites
- An Email2AT account with Autotask connected
- Microsoft 365 connected as a Remote Mailbox connection (How to Connect to Microsoft 365)
- The technician's personal mailbox accessible to the MSPintegrations service account (the O365 user you created must have full mailbox rights)
If you have not yet connected Microsoft 365, complete the connection steps before proceeding.
Which Option to Choose
| Option 1: Subfolder | Option 2: Forward to Hosted Mailbox | Option 3: Monitor Personal Inbox | |
|---|---|---|---|
| Setup effort | Low | Medium | Medium |
| Per-email effort | Drag email to folder | Forward email | None (fully automatic) |
| Sender accuracy | Exact (original sender preserved) | Approximate (extracted from forwarded body) | Exact (original sender preserved) |
| Risk of false positives | None (only emails you move) | None (only emails you forward) | Low (only fires for known Autotask contacts) |
| Best for | Technicians who want control over which emails become tickets | Teams already using forwarding workflows | Technicians who want hands-off automation |
Read all three options below, then pick the one that fits your team's workflow.
Option 1: Create a "Move to Autotask" Folder (Recommended)
This is the simplest and most reliable approach. Create a subfolder in the technician's personal mailbox, point MSPintegrations at that folder, and drag customer emails into it. MSPintegrations picks up the email, reads the original sender, and creates a ticket with correct attribution.
No forwarding is involved, so the sender information is always accurate.
Step 1: Create the Folder in Office 365
- Open the technician's mailbox in Outlook (desktop or web)
- Right-click on Inbox and select New Folder
- Name the folder
Move to Autotask
The folder name is up to you. Use whatever is clear and memorable for the technician.
Step 2: Add a Remote Mailbox in MSPintegrations
- Navigate to Email2AT in the console and click Remote Mailboxes
- Under your Microsoft 365 connection, click Add Remote Mailbox
- Set the Mailbox Address to the technician's email address (e.g.,
[email protected]) - Set the Folder to
Inbox/Move to Autotask(or whatever path matches the subfolder you created) - Click Save
MSPintegrations will now poll this folder for new messages.
If multiple technicians need this workflow, create a "Move to Autotask" folder in each of their mailboxes and add a separate Remote Mailbox entry for each one. All of them can share the same rules.
Step 3: Create the Rule
Add a rule to this Remote Mailbox using the same Update-then-Create pattern described in Create Your First Mailbox:
- Click Add New Rule and name it
Create or Update Autotask Ticket - Leave the Expression empty so it fires for every email in the folder
Action 1: Update Existing Autotask Ticket
- Click Add New Action, select Update Existing Autotask Ticket, click OK
- Configure it the same way as a standard support mailbox (search subject for ticket number, enable Reply-All Storm Catcher)
- Set Action When Complete to Stop processing the actions on this rule and all other rules
Action 2: Create Autotask Ticket
- Click Add New Action, select Create Autotask Ticket, click OK
- Configure contact matching to use From Address (the default)
- Set a Default Account for senders not found in Autotask (your zero Account or a dedicated "Unknown Senders" Account)
- Set the Queue to your support queue
- Set Action When Complete to Stop processing the actions on this rule and all other rules
Ensure the Update action is above the Create action. Drag to reorder if needed.
Full action reference: Create Autotask Ticket | Update Existing Autotask Ticket
Step 4: Test
- Move a real or test customer email into the "Move to Autotask" folder
- Wait for MSPintegrations to poll the folder
- Navigate to History and click Refresh until the email appears
- Open the processing log and verify:
- The sender was identified as the original customer (not the technician)
- The correct Account and Contact were matched in Autotask
- A ticket was created with the right attribution
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 without moving another message into the folder.
Daily Workflow
When a customer emails the technician directly:
- Open the email in Outlook
- Drag it into the "Move to Autotask" folder
- MSPintegrations creates the ticket automatically with the correct customer and contact
No forwarding, no manual ticket editing, no asking the customer to resend.
Option 2: Forward to a Hosted Mailbox with Sender Extraction
This approach uses a Hosted Mailbox as the destination. The technician forwards the customer's email to that address, and MSPintegrations extracts the original sender from the forwarded message body.
This method works, but sender extraction from forwarded email bodies is less reliable than reading the original sender directly. Formatting differences across email clients can affect extraction accuracy.
Step 1: Create a Hosted Mailbox
- Navigate to Email2AT in the console and click Hosted Mailboxes
- Create a new mailbox, for example:
[email protected] - Click Save
Step 2: Create the Rule with Sender Extraction
- Click Add New Rule and name it
Process Forwarded Customer Email - Leave the Expression empty
Action 1: Extract Original Sender
When an email is forwarded, the "From" address becomes the technician's address. The original sender typically appears in the forwarded body as a line like From: Jane Customer <[email protected]>.
- Click Add New Action, select Extract Strings, click OK
- Name the step
Extract Original Sender - Add a definition:
| Field | Value |
|---|---|
| Extraction Type | Regular Expression |
| Pattern | /From:\s*.*?<([^>]+)>/ |
| Input | {{email.body}} |
| Variable | originalSender |
| If Empty | Generate an exception and stop processing |
- In Store results in variable, enter
extracted
After this step, {{custom.extracted.originalSender}} contains the original customer's email address.
Forwarded email formats vary by email client. The pattern above works for most Outlook-style forwards. If your technicians use a different client, examine a sample forwarded email and adjust the regex. You can test patterns at regex101.com (PCRE2 flavor), or contact support with a sample and we will help you build the right pattern.
Action 2: Create Autotask Ticket
- Click Add New Action, select Create Autotask Ticket, click OK
- Set Locate contact by to the extracted sender: change the field value to
{{custom.extracted.originalSender}} - Set a Default Account for unmatched senders
- Configure ticket fields (Title, Description, Queue, Status) as you would for a standard support mailbox
- Set Action When Complete to Stop processing the actions on this rule and all other rules
Step 3: Test
- Forward a customer email to
[email protected] - Navigate to History and verify the extraction pulled the correct original sender address
- Confirm the ticket was created under the correct Account and Contact
If the extraction fails, check the forwarded email body in the processing log to see what format your email client uses, and adjust the regex pattern.
Daily Workflow
When a customer emails the technician directly:
- Forward the email to
[email protected] - MSPintegrations extracts the original sender and creates the ticket
This method depends on the forwarded email body containing the original sender in a parseable format. If the email client strips or reformats that information, the extraction may fail. Option 1 (subfolder) is more reliable because it reads the original sender directly from the email headers.
Option 3: Monitor the Personal Inbox Automatically
This approach connects MSPintegrations directly to the technician's root Inbox. A rule evaluates every incoming message and only creates tickets for senders who exist as Contacts in Autotask. All other emails (vendor messages, order confirmations, internal mail) are left untouched.
This is the most automated option: the technician does not need to drag or forward anything. The trade-off is that MSPintegrations reads every email in the inbox, so the rule must be carefully configured to avoid creating tickets from non-customer messages.
Step 1: Add a Remote Mailbox for the Inbox
- Navigate to Email2AT in the console and click Remote Mailboxes
- Under your Microsoft 365 connection, click Add Remote Mailbox
- Set the Mailbox Address to the technician's email address
- Set the Folder to
Inbox(the root inbox, not a subfolder) - Click Save
Step 2: Create the Rule
- Click Add New Rule and name it
Auto-Create Ticket for Known Customers - Leave the Expression empty (filtering happens via a lookup step and an action-level expression)
Action 1: Update Existing Autotask Ticket
Add this first to handle replies to existing tickets:
- Click Add New Action, select Update Existing Autotask Ticket, click OK
- Configure as standard (search subject for ticket number, enable Reply-All Storm Catcher)
- Set Action When Complete to Stop processing the actions on this rule and all other rules
Action 2: Look Up the Sender as an Autotask Contact
The Create Autotask Ticket action always creates a ticket if it can resolve an account (falling back to the zero account when no match is found). To prevent tickets from being created for non-customer emails, add a lookup step first and gate the Create action with an expression.
- Click Add New Action, select API: Query for One Object, click OK
- Name the step
Find Contact - Set Entity Type to
Contact - Add a query condition:
EmailAddressequals{{email.from.address}} - Leave Generate an exception if no results unchecked
- In Store results in variable, enter
senderContact
After this step, {{custom.senderContact.id}} contains the Contact ID if the sender exists in Autotask, or is null if they do not.
Action 3: Create Autotask Ticket (only if Contact was found)
- Click Add New Action, select Create Autotask Ticket, click OK
- Set the Only perform this action if expression so that this step only runs when a Contact was found:
custom.senderContact.idis not null - Set Locate contact by to From Address
- Leave Create new account if unmatched unchecked
- Configure ticket fields (Title, Description, Queue, Status) as you would for a standard support mailbox
- Set Action When Complete to Stop processing the actions on this rule and all other rules
The expression on the Create action is the key to this approach. When the sender is not an Autotask Contact, custom.senderContact.id is null, the expression is false, and the Create action is skipped entirely. Emails from vendors, newsletters, and internal colleagues pass through without generating tickets.
For finer control over which customers trigger ticket creation, add a User Defined Field (UDF) in Autotask on the Account entity (for example, a checkbox called "Auto-Create from Direct Email"). Modify the Find Contact step to also query for the Account and check the UDF value. Update the expression on the Create action to require both a matching Contact and the UDF flag.
This lets you enable the workflow for specific high-priority customers while leaving it off for others, even if those others have Contacts in Autotask.
Step 3: Test
- Send a test email from a known Autotask Contact's address to the technician's inbox
- Navigate to History and verify:
- The
Find Contactstep returned a result - The Create action fired and created a ticket with the correct Account and Contact
- The
- Send a test email from a non-Autotask address (e.g., your personal email)
- Verify in History that:
- The
Find Contactstep returned no result - The Create action was skipped (expression was false)
- No ticket was created
- The
Daily Workflow
No action required from the technician. Emails from known customers automatically become tickets. Everything else stays in the inbox as normal.
Because this option monitors every email in the technician's inbox, review the types of email that arrive there. If the technician receives automated messages from systems that happen to use an email address matching an Autotask Contact, those messages will also create tickets. Add a suppression rule above the Create rule to filter out known automated senders if needed.
Key Takeaways
- Option 1 (subfolder) gives you the best balance of accuracy and control: the original sender is always preserved, and you choose which emails become tickets
- Option 2 (forward to hosted mailbox) works but depends on parsing the forwarded email body, which can be fragile
- Option 3 (monitor inbox) is fully automatic but requires careful filtering to avoid false positives
- All three options preserve proper Account and Contact attribution in Autotask, which eliminates the manual step of editing the ticket after forwarding to
support@ - Start with Option 1 if you are unsure. It is the easiest to set up, the most reliable, and can be extended later
Related Documentation
- Core Concepts: the domain/mailbox/rule/action hierarchy
- Create Your First Mailbox: the foundational Update-then-Create pattern
- Connect to Microsoft 365: connecting Remote Mailboxes
- Expression Builder: filter which emails trigger each rule
- Create Autotask Ticket: full action reference
- Update Existing Autotask Ticket: full action reference
- Email Processing Best Practices: routing and testing guidelines