A number of customers have recently asked for help building logic that creates new Autotask tickets associated to a contact with a matching email address, but they wanted to limit the Autotask accounts that were queried when searching for a matching contact. These customers needed to build logic to lookup a contact but always for a particular account or small set of accounts.
To facilitate this use case, we added a new Account Filter option in the Autotask Create New Ticket action step, and we are pleased to report this new logic is live and ready for use.
You can now apply a filter to limit the accounts that MSPIntegrations will search when creating a ticket in the Autotask Create New Ticket step. The filter will ensure that only certain accounts are retrieved when matching the sender’s address or domain name.
For example, you could apply a filter to ensure that MSPIntegrations only searches for accounts that are ‘Leads’.
This is causing me a problem because if the answer is more than 100 accounts it only uses the first 100 so quite often doesn’t find the appropriate record. It looks like it’s trying to pull the list of accounts first, rather than finding all matching contacts and then filtering them
We’d love to use your use-case to refine this workflow. Can you provide a few example history URLs we can review? Seeing the actual results will help us implement the changes in a way that correctly resolve the issue for your use.
The use case was that I’d set a filter to ignore our answering service company record on searching for emails so it would fall back to catchall. Unfortuately that meant the allowed account list was over 100 records. Only the first 100 are fetched so the company in this example was not found.
Thanks for providing the URL example and for sharing about your use-case.
Since you are trying to exclude one particular account, I wouldn’t use the Account Filter option in the rule. The Account Filter is designed to include only a small subset of accounts, not to exclude one. Instead, I would add a new rule in your mailbox that intercepts messages from your answering service in its own rule. When the answering service sends you an email notification, this new rule would process their message and the default rule would never fire. Over time, as you have more edge-cases to exclude from the primary ticket creation, you can add more rules above the default rule.
For the rule to process the answering service messages, I recommend using the Autotask API: Create an object (docs) action and not the Create Autotask Ticket for Email Address (docs) action. Configure the action to create a ticket directly on your internal (“zero”) account or on the answering service account. This way, the system never tries to match the sender email (the answering service) to an account.
If the answering service message includes an email address for the caller, you could extract that email address and then use that to match the contact. Or, if the message has their phone number, you could extract that to find the contact.
A few other things I noticed in your rules:
In your “Create Ticket” step, I recommend you uncheck the “Suppress Autotask API exceptions” checkbox. This way, if the ticket can’t be created, the system will stop and alert you. If you do that, you can also delete the subsequent step to email you if the ticket failed (because the system will do that for you).
You imported a rule from our library that finds merged tickets. The “Update Existing Autotask Ticket” rule will do that for you with the checkbox to “Follow trail of merged tickets”:
