Overview
There are various notification scenarios that are not completely straight forward. Use this article to learn about the how Enterprise Service Management (ESM) system processes some of these scenarios.
In this article:
Who Is Notified When a Person Replies to a Feed Comment Post
When an individual replies to a feed comment, either via email replies, the Service Portal (aka TDClient), or within the Ticketing App (aka TDNext), the reply will be added under the original feed comment. When this happens, the system will notify all the relevant people for that feed comment.
A reply will notify:
- The original person who sent out the notification on the item.
- Anyone in the reply chain, meaning anyone who has previously replied to the original comment.
- Anyone who was notified in the initial notification.
A reply will not notify:
- The person who posts the reply. You will not be notified about your own comments.
How the System Matches Email Addresses to People When Interacting via Email
When Creating New Tickets from Email
For departments electing to enable email to ticket creation, when tickets are created from emails utilizing the Email Monitors feature of a ticketing application, the ticket creator will show as the account set to run the creation monitor. The ticket requestor will be set by matching the incoming email address to the first match found against the following user record fields. This is done waterfall style, in the following order:
- ESM Alert Email Address
- ESM Primary Email Address
- ESM Alternate Email Address
If no match is found, the ticket requestor is set via text-only fields with as much information as can be pulled from the email FROM address. In this case, display name maps to First and Last name if possible and address maps to email address. Tickets in this state will not show a value selected in the Requestor lookup when editing a ticket. They will instead show labels with the text information from the original email FROM display and address.
When Utilizing the Reply-by-Email Functionality
Most notifications that are sent out from ESM have a reply token in them, if your organization has enabled reply-by-email. These tokens contain the specific email address that they were sent to when the notification was generated for validation during reply processing. In this way, the email reply monitor can know whether a reply to that notification originated from the same email address to which the notification was sent. If the email reply is from the same email address that the token was generated for, the system will find the person's record by email address and post the response as if it was from that person.
The simplest way to think about this is that there is a 1:1 relationship between an email token and who can reply to it. If any other email address other than the original address the notification was sent to replies, the system will proxy the reply.
A proxied reply means that the account that monitors the ESM email will post that response on behalf of the person who sent it. It will post something like "[ESM user from reply-by-email settings] posted a comment: [comment text] for [email address]." When a reply is proxied, the reply is saved in the system under the TeamDynamix account which runs the reply monitor, not the actual person replying in. Due to this, the original person replying via email may no longer be notified of future replies, because those replies might now be in a chain where all replies were proxied, and the responses now go to the reply monitor account.
When the Email Address Being Interacted with Is Not in ESM at All
Replies to email notifications from an email address which is not on any person record in ESM will always be proxied. There is no ESM user record to match it to in this case. There are several ways this could happen, including:
- Tickets created via email, the FROM email address was not found in ESM and no person record was created for the requestor. In this case the ticket would show requestor information as read-only text and no actual record selected, so interacting solely via email would result in proxied messages from the requestor.
- Tickets created from a public form which does not find a match on email and allows the ticket through with read-only requestor information. If the ticket was worked in this state and no ESM record was created for the requestor with the email address from the ticket, any replies from the requestor would get proxied.
- Notifying an email address using with the Other Email Address(es) free-text field which isn't in ESM. Replies from the notified email would be proxied, as in scenarios 1 and 2.
- Using a Forward page to notify an email address which isn't in ESM. Replies from the notified email would be proxied like scenarios 1 and 2.
Replying from a Different Email than the One a Notification was Sent To
If your email is set as jdoe@alaska.edu, you receive a ESM email notification with a reply token in it and you reply from john.doe@alaska.edu, your reply will be proxied. This is because the address from which you reply from must match the address contained in the token for validation. When the values do not match, the reply is proxied. The University of Alaska highly recommends always replying to email notifications from the same email address that the message was sent to. If not, you will experience cases where your reply will be proxied instead of showing as from you.
Tip
All individuals affiliated with the University of Alaska system (student, staff, and faculty) have their account's email addresses provisioned within the ESM as follows:
- Primary & Alert/Notification Email: Set to your <UA Username>@alaska.edu (i.e. jdoe@alaska.edu)
- Alternate Email: Students who have set a preferred email address to a non-UA email address will have this value set to their preferred email address.
Replying to Another Person’s Token
It is very easy to pass along a reply-by-email token by CC’ing other people in your organization from your mail client outside of the ESM system. If those people reply and include the original reply token in their email, the system will proxy their reply in.
The ramifications for this build upon those stated in the Who Is Notified When a Person Replies to a Feed Comment Post section of this article. When a response gets added in proxy by the email monitoring account, further responses from other users may not be sent back to the user whose response was proxied.
The following is a contextual example, in which Ticket X exists and Resources A, B, and C are working ticket X:
- Resource A updates ticket X and notifies resources B, and C.
- Resource B replies to the notification from Step 1 and copies resource C on the reply. Resource A is notified of the reply. Resource C is only copied via email.
- Resource C replies to the copied email from Resource B. Resources A and B are notified. A is notified because they are the original sender. B is notified because they are now in the reply chain from step 2. C's reply was posted by the email system on their behalf since they used B's reply token.
- Resource B replies to the notification from Step 3. Resource A is notified. A is notified because they are the original sender. C is not notified because their reply was added by proxy. The reply that would have gone to C is sent to the alert email address of the TeamDynamix user account which runs the reply-by-email monitor.
The above scenario happens frequently in many organizations and people get concerned because the person whose reply was proxied may not receive further notifications in that comment thread. This is an expected behavior of the system. It is highly recommended at this point to start a new comment thread so Resource C can reply to their own notification and token, have their response posted correctly, and be updated on any additional posts that come in after their response.
Case-Sensitivity of Email Matching
When email address matching is attempted, all matching is performed in a case-insensitive manner. This means that differences in casing only of the email addresses will not cause matching to fail. For instance, john.doe@alaska.edu will match against John.Doe@alaska.edu as well as john.doe@Alaska.edu.
Who Is Notified When a Client’s Ticket Request Is Withdrawn?
Departments can choose to allow customers to cancel/withdraw a ticket once its been submitted. Withdrawing a ticket from Client Portal will attempt to notify using the rules below in a waterfall or fallout fashion:
- If there is a responsible person defined on the ticket, that person will be notified.
- If there is a responsible group defined on the ticket, that group will be notified.
- If there is a ticket type reviewing user, that reviewing user will be notified.
- If there is a ticket type reviewing group, that reviewing group will be notified.
The first rule that applies will be used, but it is entirely possible for no rules to apply. Note that if the person withdrawing the request has an email address which matches an address from the rule being applied, the withdrawer will not be notified. The system tries not to notify the person taking the action.
People Notified When a Person Replies by Email to a Ticket Creation Email
When a ticket is created in ESM and notifications are sent out, replies back to the ticket creation emails will go to:
- The ticket creator or,
- Depending on whether the ticket has a primary responsible user or group, the following people may be notified:
- If the ticket does have primary responsibility set, the responsible user or group will be notified.
- If the ticket does not have primary responsibility set, the ticket type's primary reviewer and Other Email Addresses list will be notified, but only if the ticket type is set to notify the reviewer of new tickets.
These rules are used no matter the ticket creation vector, i.e. through the web application, from the email service, from a scheduled ticket, etc.
Group Notifications
When group notifications are sent, whether to a primary responsible group or a group reviewer for the ticket type, only members in the group set to be notified are emailed. If a member of the group is replying and that notification will notify the group again, the member will not be notified of their own reply. The system tries to shield the person from receiving both a notification to a group and their own replies which should notify the group.
Email Service
The SaaS email service uses email rules to assign default responsibility. Therefore, for tickets created by the email service, the ticket type's default responsibility setting determines who will be notified when replying to creation emails.
If the ticket type has a default responsible user or group, items 1 and 2.1 above are applicable.
If the ticket type has no default responsible user or group, items 1 and 2.2 above are applicable.
In the case of the Email Service, item 1 above is the user configured as the ESM username in the ticket template settings.
Who Notifications Go to if Primary Responsibility and/or Ticket Type Information Has Changed
The information on who should be notified in 2 above is stored in the reply token at the bottom of the ticket creation email. This information is based on ticket settings at the time of ticket creation. If a requestor replies to their ticket notification email, but before they do so the ticket Type and/or Primary Responsible person or group is set or changed, the notification of their reply will go to whoever would have been the original responsible user, group or reviewer and other emails if no responsible user or group was originally set on the ticket.
Need additional help or have issues
For support, requests may be submitted anytime using the appropriate Enterprise Service Management form. Requests generate a Ticket which will be worked in order received and urgency by IT Employees with the knowledge and permissions to assist with the request.
For immediate assistance please review the Contact Us page for the appropriate support group.