Notification Scenarios

This introduction article will help users to understand how TeamDynamix processes notifications in a variety of scenarios. To edit notification settings user must have the Administrator access in TDAdmin.

Overview

There are various notification scenarios that are not completely straight forward. Use this article to learn about the how TeamDynamix processes some of these scenarios.

Who Is Notified When a Person Replies to a Feed Comment Post

When a user replies to a feed comment, either via email replies or within the system, 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 User Accounts When Interacting via Email

When Creating New Tickets from Email

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:

1. TeamDynamix Alert Email Address
2. TeamDynamix Primary Email Address
3. TeamDynamix 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 TeamDynamix 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 user's record by email address and post the response as if it was from that user.

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 TeamDynamix email will post that response on behalf of the person who sent it. It will post something like "[TeamDynamix 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 TeamDynamix at All

Replies to email notifications from an email address which is not on any user record in TeamDynamix will always be proxied. There is no TeamDynamix user record to match it to in this case. There are several ways this could happen, including:

1. Tickets created via email, the FROM email address was not found in TeamDynamix and no user 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.
2. 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 TeamDynamix record was created for the requestor with the email address from the ticket, any replies from the requestor would get proxied.
3. Notifying an email address using with the Other Email Address(es) free-text field which isn't in TeamDynamix. Replies from the notified email would be proxied, as in scenarios 1 and 2.
4. Using a Forward page to notify an email address which isn't in TeamDynamix. 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@school.edu, you receive a TeamDynamix email notification with a reply token in it and you reply from john.doe@school.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. TeamDynamix highly recommends always replying to email notifications from the same email address and that the one from which you primarily reply be set as the TDX Alert Email address value. If not, you will experience cases where your reply will be proxied instead of showing as from you.

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 TeamDynamix 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:

1. Resource A updates ticket X and notifies resources B, and C.
2. 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.
3. 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.
4. 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@university.edu will match against John.Doe@university.edu as well as john.doe@University.edu.

Who Is Notified When a Client’s Ticket Request Is Withdrawn? 

Withdrawing a ticket from Client Portal will attempt to notify using the rules below in a waterfall or fallout fashion:

1. If there is a responsible person defined on the ticket, that person will be notified.
2. If there is a responsible group defined on the ticket, that group will be notified.
3. If there is a ticket type reviewing user, that reviewing user will be notified.
4. 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 TeamDynamix and notifications are sent out, replies back to the ticket creation emails will go to:

1. The ticket creator or,
2. Depending on whether the ticket has a primary responsible user or group, the following people may be notified:
   1. If the ticket does have primary responsibility set, the responsible user or group will be notified.
   2. 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 user 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 TeamDynamix 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.