Boru Tickets Replacement Users’ Guide

  • Notifications

    Notification Events 

      • When one of these events occurs, a corresponding email notification will be sent if the following conditions are met:
        • 1. the event is set to “On”
        • 2. the notification within the event is set to “Enabled” (and saved)
        • 3. the enabled notification is properly configured, with a valid subject line and body
      • Ticket Created within vTiger
        • A ticket was manually created within the vTiger user interface
      • Ticket Created within Customer Portal
        • If the customer portal is installed and enabled, this notification is generated when a customer using the portal submits a ticket using the customer portal ticket-creation interface
      • Ticket Updated: Reassignment
        • A ticket’s assigned user or group was changed
      • Ticket Updated: Comment Added in vTiger
        • A comment was added manually by a user within the vTiger interface
      • Ticket Updated: Change in Solution
        • A ticket’s “Solution” field was modified (this is trigger by any change to the “Solution”, including when the first information is initially entered into the “Solution” field, as well as when an existing “Solution” value is modified
      • Ticket Updated: Change in Status
        • A ticket’s “Status” field was modified
      • Ticket Updated: Comment Added in Customer Portal
        • If the customer portal is installed and enabled, this notification is generated when a customer using the portal submits a comment using the customer portal’s ticket interface
    • For each email box that is created in the “Configure Mail Settings” page, two additional options are added to the notifications list:
      • Ticket Created from Email Sent to [name of email server]
        • A new ticket was created as a result of a new email being sent to the email address configured in the named email box
      • Ticket Updated: Email Reply Sent to [name of email server]
        • A ticket was updated as a result of an email being sent to the email address configured in the named email box, and a ticket number contained in the email subject line was matched against an existing vTiger ticket, so a new ticket was not created. When this happens, the ticket is updated by adding the contents of the email as a comment within the existing ticket. This is the notification event triggered in this case, not a “Ticket Updated: Comment Added in vTiger”

    Notifications

      • Notify Contact/Organization
        • This notification will be sent to the ticket’s Contact or Organization, which is stored in the “Related To” field. Note that for tickets generated as a result of an incoming email being scraped into the system, if the system cannot find an existing Contact or Organization matching the sender’s email address, a new placeholder Contact will be created with the sender’s email address and assigned to the ticket, so this notification can still be used to send a bounceback email to the sender
      • Notify Assigned User/Group
        • This notification will be sent to the ticket’s “Assigned To” user or group. If the “Assigned To” value is a group, a single email will be sent, which has each user who is a member of the group as a recipient
      • Notify User: [user-select dropdown]
        • This notification will always be sent to the specified user, regardless of whether that user is assigned to the ticket or not
      • Notify Group: [group-select dropdown]
        • This notification will always be sent to the specified group, regardless of whether that group is assigned to the ticket or not. A single email with multiple recipients will be sent, listing each user who is a member of the group as a recipient
      • Notify Assigned User/Group if Assigned User/Group [Does/Does Not Equal] [specified user or group]
        • This is a conditional notification that will only be sent to the assigned user or group if the assigned user or group is or is not a certain user or group. This is useful in situations in which, for example, you use placeholder users or groups that you assign some tickets to, and you don’t want a notification to be sent to the assigned user or group if the placeholder is still the “Assigned To” on the ticket. This is also useful where you don’t want to alert the assigned user or group unless that ticket has been assigned to a special user or group, such as an escalation group
      • Notify User [user-select dropdown] if Assigned User/Group [Does/Does Not Equal] [specified user or group]
        • This notification uses the same conditional as the notification above, but instead of notifying the assigned user or group, it always notifies a specified user if the condition is met
      • Notify Group: [group-select dropdown] if Assigned User/Group [Does/Does Not Equal] [specified user or group]
        • The same as above, except it always notifies a specified group, by sending a single email naming each user who is a group member as a recipient

    Public Vs. Private Notifications

    • When the “Public” checkbox is checked before submitting a comment, the comment, as well as any notifications it triggers, will be visible to the Contact or Organization linked to the ticket. If it is not checked, the notification will be “Private” and will not be visible to the linked Contact or Organization in the portal or in any email notifications.
    • Please note: Any comments that are added to the ticket by the email scraper are set to “Public”, since replies to notification emails are expected to be coming from the Contact or Organization. Although it is possible to configure an email notification to be sent to an internal User (or even a third party), who could then reply to the email and thereby create a comment, it is expected that if internal Users are working with a ticket, their work will be done directly in the CRM. Therefore, all comments generated by email replies are always “Public”. The only way to create a “Private” comment is to do so directly in the CRM. Similarly, any comment entered through the customer portal is set to “Public”, since these will have been left by the customer.
    • Notifications
      • When a new comment is entered in the CRM, this triggers the “Ticket Updated: Comment Added in vTiger” notification event. If the “Notify Contact/Organization” notification is enabled, it will only be sent if the “Public” checkbox is checked. Otherwise, this notification will not be sent at all, regardless of whether or not its contents contain the actual comment. Notifications to internal Users and Groups, however, will be sent, regardless of whether the comment is “Public” or “Private”.
      • If ANY notification email contains the contents of the most recent comment, either via the “[[TICKET::LATEST_COMMENT]]” merge field or the “[[TICKET::Add Comment]]” merge field, the contents of what is merged will depend on whom the email is being sent to, and whether the most recent comment is Public or Private. If the email is the “Notify Contact/Organization” email, then the most recent Public comment will be merged. If there are no Public comments, the field will be blank. If the email is any of the other notifications (to internal Users or Groups), then the most recent comment, regardless of whether it is Public or Private, will be merged.
    • Customer Portal
    • Reviewing Old Comments
      • The visibility (either “Public” or “Private”) of each comment can be seen beneath the comment in the “Comment Information” section of a Ticket in detail view.
    • Pre-existing Comments
      • If there were any comments that existed on your build prior to installing the Boru Tickets Replacement module, those comments will have neither a Public nor Private status. Please consult with Boru about retroactively setting the visibility of these pre-existing comments.
    • Uninstalling
      • Please note that if you uninstall the Boru Tickets Replacement module, the distinction between Public and Private comments will be lost. If you revert to the standard HelpDesk/TroubleTickets module, everything will effectively be treated as public, since the standard module does not have a visibility setting.
  • Email Settings

    Incoming Email Configuration Options

    • Name
      • A name used internally to identify this configuration (this is the name that will appear in the notifications page to identify notifications relating to this email scraper)
    • Host
      • The IP address or URL of the mail server
    • SSL?
      • Whether or not the account uses SSL encryption
    • Regex
      • A regular expression which is compared against the subject line of an incoming email to determine whether the ticket can be matched against an existing ticket. The “Ticket No” field value must be contained within the regular expression’s first sub-match (i.e., must be contained within parenthesis). The default value provided will look for a ticket number formatted with the word “Ticket” followed by a space and then the “Ticket No” value. For example, a subject line that contains “Ticket TT7” anywhere within the subject would be matched against existing ticket TT7. Make sure to configure outgoing email notifications so that the subject line contains this value, otherwise the system will not be able to identify an incoming email as relating to an existing ticket, and will instead create a new ticket based on the email
    • Type
      • For now, this value should always be set to “Incoming”. For information relating to the outgoing server which is used to send email notifications, see standard vTiger documentation regarding the “Outgoing Server” page within standard vTiger settings.
    • Port
      • The server port used to establish a connection (typically either 143 for non-SSL servers or 993 for servers using SSL encryption)
    • Password
      • The account password
    • IMAP?
      • Whether the account is an IMAP account (typically this should be “Yes”)
    • Assign New Tickets To
      • New tickets created as a result of emails sent to this email address will be assigned to the user or group specified here (in the “Assigned To” field of the ticket)

    Outgoing Email Settings 

    • The ticketing systems uses the standard vTiger “Outgoing Server” settings to send notification emails. These settings can be accessed by going to the main vTiger “Settings” page, and clicking the “Outgoing Server” icon under the “Other Settings” header. Please refer to vTiger documentation for help with configuring these settings.

 

Leave a Reply

Your email address will not be published.

top

Boru Inc. Dismiss