Using same mailbox for app-level email and replies?

So far, we have always configured a separate email reply monitor from the email monitor(s). As we move to app-specific email configurations - ticketins apps will have their own from address, email monitors, and reply address. Is it possible to use the same account for the email monitor and the reply monitor? What are the downsides of doing so? It seems like we could eliminate an account from the mix if we could use one of the email monitors as the reply monitor and avoid situations where people contact the reply monitor director (which then is missing a token) and generating errors.

Asked by Bob Black on Tue 2/8/22 11:30 AM
Sign In to leave feedback or contribute an answer

Answer (1)

This answer has been marked as the accepted answer
Mark Sayers Tue 2/8/22 12:41 PM

Hello Bob,

You can certainly connect them all to the same email account, as long as you're not attempting to connect each monitor to the same "Inbox" folder within that email account.

I would personally recommend you make the Creation ticket monitor connect to the Inbox of the email account, and make a separate folder for the Replies monitor to connect to, so you can build an email account-level mail rule to route things with the reply token down to the other folder for processing.

Sincerely,
Mark Sayers
Sr Support Consultant, CS

1 of 1 users found this helpful.
Thanks. We will experiment. I appreciate the recommendation as that is the detail I was hunting for. If I recall, there are hopes to remove the token from the body of the message and get into the header or something at some future point. Any sense if that will help or hinder this approach? - Bob Black Tue 2/8/22 12:48 PM
So we *already* have implemented the addition of the reply token into the outbound notification headers of areas of the tool that support reply-by-email. We still have notification tokens in the body of the emails though as a backup method of recognizing when an email is able to be replied to via email. - Mark Sayers Tue 2/8/22 1:05 PM
that's great. Is there any way to suppress them in the message body yet that I have missed? We have a few offices that really dislike them because they ruin the "conversational tone" of exchanges and interactions through those emails. - Bob Black Tue 2/8/22 1:29 PM
None that are officially supported at this time, no. We've seen folks do things like tailor their notification templates so anything following the main notification body is either super small or is a font color that blends to the background color of the notification email itself. - Mark Sayers Tue 2/8/22 1:40 PM
@Mark - I have tried to customize our notifications so that anything following our main body is super small and I cannot seem to find a trick that works. I asked in the Service Management community and didn't get a reply there. Any chance you know the specific trick people are using?

We have tried (SIC that I needed to use square brackets because the forums don't want me to inject html):
[p style="font-size: 4px;"] and a table with a style on the td element as [td style="font-size: 4px;"] as the last line of the notification template

Neither seem to effect the formatting of the reply code that follows
- Bob Black Wed 2/23/22 11:32 AM
Thank you for following up and making additional attempts to successfully hide the reply token. Unfortunately since this isn't something we currently officially support within the tool, I'm unable to recommend a solution. We could open a Support ticket if you wanted to discuss further or submit for an enhancement to add a supported method for hiding the reply token in the body of outbound notifications. - Mark Sayers Wed 2/23/22 4:43 PM
Please convert to enhancement suggestion. As we work with more and more offices, this is becoming a stinking point and having a fully supported option is preferred anyway. I'd rather not hack our way through this one. - Bob Black Wed 2/23/22 4:48 PM
Sure thing, I've created ticket 19807141 for this enhancement and you should have been notified that it was created. - Mark Sayers Thu 2/24/22 10:17 AM