Allow variables in "Default Account if no match" field

[brsm]

I’m wondering if I can put in a request for a change to the “Create Autotask Ticket” workflow that would allow variables in the “Default Account if no match” field.

Our use-case is that we have separate support email addresses for each of our clients, so we already know the right account when we receive an email. I can leverage the “Create Autotask Ticket” pre-defined rule by filtering to the specific account based on the recipient address. However, in the edge case where we receive an email at a client’s support address that is not from an address on the client’s domain, we would like it to create a ticket under that client without a contact. But because this situation reverts to the static “default account” it instead uses that for all clients.

For example, let’s suppose we have a company named Test Co with email domain testco.com and their support address is [email protected]. If you were to send an email to that address, the following would happen:

1. Code identifies that based on the recipient [email protected], this ticket should be opened under Test Co.
2. Code calls “Create Autotask Ticket” workflow with the filter scoped only to the Test Co account.
3. The code does not find you as a contact on Test Co, nor does your domain match their domain of testco.com.
4. The code defaults to the default account.
5. Ticket is created under the default account instead of Test Co.

Ideally, if I could instead use a variable for the “Default Account if no match” field, I could set that field to the same value as the account I identified in the first step and everything would work as intended.

Thanks!

[travis]

Hey @brsm ,

Thanks for posting here! I have a few thoughts.

First off, you can use a variable in that field. You just need to check the box to enable that field to be unlocked:

At the bottom of the action step, check this:

Once you do that, the Default Account field will allow a variable:

That said, I wouldn’t recommend you do this. It will work, but it’s a bit of trying to force the action step to do something it’s not intended to do. That action is designed to choose the contact and account based on the sender address. Yes, you can make it work, but I would recommend hard-coding the following workflow:

1. Query for account based on the destination email address (not the sender)
2. Query for a contact on that account with a matching email addres for the sender
3. Create a ticket (the contact may be blank if not found, and that’s okay)

Also, I know you were recently asking about Remote Mailboxes. This is a very good use-case for a Hosted Mailbox with a regular expression prefix. Are you planning to use a Remote Mailbox or a Hosted Mailbox for this workflow?