Alerts Server

User Manuals > Alerts Server

The Commit Alerts Server notifies technicians by email when they have new tasks they need to perform, and when any updates have taken place in the system which concern them. These email Alerts are triggered by various system events.

Using Commit Alerts helps automate many workflow-related tasks so that employees are constantly up-to-date on their tasks and responsibilities. Each user can define their own Alert settings and decide when they wish to receive Alerts. The Alerts they are eligible to receive are determined by their user role in each case.

Note that Commit Alerts runs as a part of the Commit Server, so the Server must be installed and running in order to use the Commit Alerts.

File:Commit email alerts chart.zoom55.png

Using Commit Alerts Server

Commit Alerts are sent when certain events happen in the system, like a new Ticket is created, new Appointments are scheduled, updates are made to existing records, and more.

Each user can defined their Alerts settings and decide in which cases they wish to receive Alerts. The ability to set up Alerts is determined by the role of the user in each case. Possible roles are: Account Manager, Ticket Manager, Appointment Manager, Task Manager and Receive Alerts for any Opened/Closed Ticket.

For each role you hold, you can decide whether you wish to receive Alerts for events related to every role or not. For example, if you select Account Manager Alerts, this means that when you are the Account Manager of an Account, you will receive Alerts for events which are related to this Account. Note that this includes related data Alerts, such as new Charges added to this Account, new Contracts created for this Account, etc.

Note that when you are the Account Manager and Ticket manager of a Ticket, you will receive a single Alert for all events which relate to this Ticket. You will receive the Alerts through your role as the Ticket Manager (Account Manager Alerts are eliminated to avoid duplicate Alerts).

Note: You will not receive Alerts for changes you have made.

The Commit Alerts Server setup includes Server Side setup and User Setup. Following is the user setting description.

Commit Alerts User Settings

In order to receive Alerts, each user should open the Tools > Options > Alerts window and define their own Alerts settings. The following window will appear:

File:Commit email alerts user settings.gif

In this window you should define your Alert settings as follows:

My Alert Status

You should use the ON setting (which is the default settings) when you wish to activate the Alerts mechanism for yourself. Note that only if you activate the Alerts setup below, you will be receiving alerts.

Alerts will be Sent to the Following Email Address

Here you define which of your Email addresses defined in your Employee Record in Commit will be used when sending the Alerts to you. You can define Email1, Email2 or Both.

Account Manager Alerts

The Account Manager of a specific Account is set by assigning an Account to a specific employee in the Account's "Acct Mgr." field.

The Account Manager can receive Alerts or any event in the system which relates to this Account, even when the specific event is not directly related to them, such as a new Appointment scheduled for a different employee that is linked to the Account.

Events which trigger Alerts for Account Managers:

1. Account assigned to you
2. Account Deleted
3. Account Updated - Name, Phone number, Address, etc.
4. Account related data updated - Tickets, Charges, Documents, Appointments, Tasks, Assets, Contracts

Ticket Manager Alerts

The Ticket Manager is set in the Ticket's "Manager" field. The Ticket Manager may be the assigned technician who is going to perform the actual work for this Ticket, or a manager who overseas the Ticket's completion, and assigns Tasks and Appointments to other employees.

The Ticket Manager can receive Alerts for any event in the system which relates to this Ticket, even when the specific event is not directly related to them (such as a new appointment scheduled that is linked to the Ticket that is assigned to a different employee).

Events which trigger Alerts for Ticket Managers:

1. Ticket is assigned to you
2. Ticket Deleted
3. Ticket Updated - Due Date, Status, Priority, Contract, etc.
4. Ticket related data updated - Charges, Documents, Appointments, Tasks, Assets

Note that when you are the Account Manager and the Ticket manager of a Ticket, you will receive a single alert for all events which relate to this Ticket. The Alerts will be received as the Ticket Manager (Account manager alerts are eliminated in this case to avoid duplicate alerts).

Tickets - Opened, Tickets - Closed

This is a special role that allows you to receive Alerts when ANY Ticket in the system is opened or closed. If you have this role, you do not need to be the actual manager of a Ticket or Account, or related to them in any way, in order to receive updates for it.

This is useful for employees who need to be aware of all new/closed Ticket activity. For example:

1. The "office dispatcher/helpdesk manager" needs to be aware of any new Tickets created in the system in order to dispatch them to the relevant technician.
2. The "office financing person/admin" needs to be aware of any Tickets that have closed and need to be billed to the customer.

These Alerts are sent for the following events:

1. Ticket - New
2. Ticket – Closed

Calendar - Appointment

An Appointment Manager is the Employee assigned to the Appointment in the "Emp." field of the Appointment. Only one Employee may be assigned to each Appointment.

The Appointment Owner can receive Alerts for any event related to the Appointment:

1. New Appointment assigned/unassigned to you
2. Appointment Updated - Date, Time, Linked Account, Linked Contracts, etc.
3. Appointment Completed
4. Appointment Deleted

Calendar - Tasks

A Task Manager is the Employee assigned to the Task in the "Emp." field of the Task. Only one Employee may be assigned to each Task.

The Task Owner can receive Alerts for any event related to the Task:

1. New Task assigned/unassigned to you
2. Task Updated - Date, Timer, Linked Account, Linked Contract, etc.
3. Task Done

Important Notes:

1. You will not receive an email Alert for changes you have made.
2. User Alert setup may take some time to take effect in the Commit Server. In order for it to take effect immediately, you should restart the Commit Server Service.

Commit Alert Format

The Email Alert Subject line is made up of the following parts:

File:Commit email alerts format1.zoom84.png

The Prefix can be one of the following:

• [acc-mgr] - when you receive Alerts as the Account Manager
• [tkt-mgr] - when you receive Alerts as the Ticket Manager
• [info] - when you receive Alerts for any Ticket opened/closed
• [ASSIGNED] - when you are assigned a Ticket/Account
• [assign-removed] - when you are removed from being a Ticket/Account manager

The following events can trigger an Alert: New, Updated, Deleted.

Setting up Commit Alerts Server

The Commit Alerts Server is part of the Commit Server.

Setting up the Commit Alerts Server includes server-side settings performed by a system administrator, and user-side settings, performed by each user in CommitCRM. The server-side setup includes setting up the Commit Server Outgoing email settings, setting up Commit Alerts Server settings and activating the Commit Server Service.

Once the Service is up and running and outgoing email settings are functioning properly, only then should you set up the Alerts Server.

To run the configuration application:

1. Log into the Server with a Windows Administrator user. Note that the setup program must run from the same server as the one where the CommitCRM installation sits and from where you plan to run the Email Connector.
2. Run <Installation_DIR>\Server\ServerConfig.exe

The following window will open:

File:Commit email alerts outgoing setup window.zoom67.png

The server configuration window consists of the following three tabs:

1. Outgoing Mail Server Settings - here you can define the settings for all outgoing emails sent by the Commit Server.
2. Email Connector Settings - here you can define all the settings for the Commit Email Connector.
3. Alerts Server Settings - here you can define all the settings for the Commit Alerts Server.

It is recommended to start with the Outgoing Mail Server settings.

Outgoing Email Settings

These settings are used for any outgoing emails sent from Commit Server, either by the Commit Email Connector emails or by the Commit Alerts Server.

Note that the Outgoing Email settings should be set only once for the Commit Server, so if you already defined this for the Email Connector, you can skip this step.

The settings should be configured in the Outgoing Mail Server tab.

File:Commit email alerts outgoing setup window with data.gif

To reduce errors and improve security it is strongly recommended to use SMTP authentication, using a user name and password for SMTP access.

• SMTP Host - your Outgoing SMTP Mail Server
• Port - the Outgoing SMTP port
• My outgoing server (SMTP) requires authentication - if checked, must fill in the authentication details below:
  • User Name - the User Name to be used for SMTP authentication
  • Password - the password related to the specified User Name

• Test SMTP Connection - click this to verify that your account is working. If there is missing or incorrect information, such as your password, you will be prompted to supply or correct it.
• Send Test Email - Use this option to send an outgoing email using the settings you defined. After clicking it you need to specify the From email address and the To email address that will be used for sending the Test Email message.

Commit Alerts System Settings

Setting up the Alerts System Settings should be performed after the outgoing email settings were set and tested. This is to make sure you actually receive Alerts once they are ready, and to avoid the unnecessary accumulation of Alerts that could not be sent due to wrong outgoing emails settings, etc.

To set up the Alerts Server, log-in to the server, open a command prompt and run: <Installation_DIR>\Server\ServerConfig.exe

The following window will appear:

File:Commit email alerts system settings.gif

Alerts Server Settings:

• Alerts Mode – The Alerts mode can be one of the following: On, Off or Pause.
  On - You should use the On setting when you wish to activate the Alerts mechanism. Note that if you activate the Alerts after they have been Paused (see below), you may wish to consider deleting some old Events from the queue in order to avoid Alerts for old Events from being sent once you reactivate the server. See more details on how to delete Events from the queue below in the Clearing the Activity Queue option.
  Off (default) - This mode should be used when you do not want the system to prepare or send Alerts at all. This means events in the system will not create any Alerts, and when you re-activate the Commit Alerts Server, no Alerts will be waiting to be sent. When installing the Commit Alerts Server, the system is OFF by default, and should be set to ON when you wish to activate the Alerts mechanism.
  Pause - This mode should be used when you want the system to create Alerts for events in the system, but avoid sending them until you switch the mode to On. This can be helpful when you have SMTP/mail server problems and you want to fix them before activating the Alerts. Note that in this Pause mode, the Alerts accumulate until you reactivate the Alerts system. Once you reactivate the system, you should consider deleting old Alerts from the queue, as they may already be irrelevant (see Delete Alerts option below).

Note that if you have SMTP/mail problems, it is advisable to use the Pause option, since it collects the Alerts before sending them to the outgoing email. This allows you to delete old Alerts later from the queue since they have not been sent. If you leave the system working, the Alerts will be accumulated as outgoing emails, and once the problem is fixed, they will all be sent, and you will not be able to clean up older Alerts.

• From Email Address, Email Sender Name - Here you define the Email From Address that will be used when sending the Alerts. You can define an Alias to be used which will reflect the source of this email (such as "CommitCRM Alert").
• Clearing the Activity Queue - This is an advanced option, which should be used carefully. You should use this option in cases where you wish to delete pending Events which haven't been sent as Alerts yet. For example, if you have SMTP/mail Server problems, and you paused the Commit Alerts system, you may wish to clean up the queue of Events and keep only the last day or two. This is to avoid sending a large number of Alerts at once when reactivating the system, and also to avoid sending Alerts for old events which are no longer relevant.

Important Notes:

1. Alerts will start to be sent only after each user defines their own Alert settings (and only when Commit Server service is running)
2. System Alert setup may take some time to take effect in the Commit Server. In order for it to take effect immediately, you should restart the Commit Server Service.

Running Commit Alerts Server

The Commit Alerts Server runs as part of the Commit Server. The Commit Server runs as a Windows Service on your server. You should first install the Service and run it, and then activate the Commit Alerts Server from the Alerts System Settings window (see below).

Note that running the Commit Server should be performed only once for the Commit Server, so if you already did this for the Email Connector in the section above titled "Outgoing Email Settings," and you made sure outgoing emails are being sent successfully, you can skip this step and move on to the Alerts Server Settings.

Before you install Commit Alerts Server Before you install, sure to allow the Commit Email Server Service in your DEP settings.

Install Service: This part of the installation should be performed on the server itself.

When logged in to the server with a Window's Administrator account, open a command prompt window and enter the following command:

<Installation_DIR>\Server\CommitServer.exe -install

Note: The <Insallation_Dir> must refer to a LOCAL server path (e.g. c:\ or D:\Software, etc.) and NOT to a shared network name/path.

A Window's service called CommitServer is now displayed in the system services management window (Control Panel > Administration Tools > Services).

Running Commit Alerts Server:

1. Once the Commit Server Service is installed, setup the Commit Alerts Server as explained in Commit Alerts System Settings.
2. You should also make sure all the users (employees) configure their own Email Alert settings so they will receive Alerts.
3. Using the Window's Services Management window start the service (right-click > Start). Make sure that it is set to start automatically (Startup type > Automatic) each time the server is restarted.

Uninstall Service:

To Uninstall Commit Server, stop the CommitServer service and then enter the following command in a command prompt window on the server:

<Installation_DIR>\Server\CommitServer.exe -uninstall

Tips & Tricks

Tips for filtering incoming Alerts in Outlook

In some cases, you may wish to filter the Alerts and move emails that don't interest you to a different Outlook folder so they don't clutter your Inbox.

You can create Outlook rules to filter incoming email according to the Sender (the Alias name you set in the Alerts Server System Settings) or the email's subject.

For example, you may wish to receive Ticket Manager Alerts, but not Alerts for each Document added to the Ticket. To accomplish this, create a rule in Outlook that moves email to another folder based on the subject's prefix. Here is an example of the subject line of a Ticket Manager Alert:

[tkt-mgr] CommitCRM Document - New [0500-0002, Completed, Natalie, Internet - Cafe, Inc.]

You can therefore create a rule that any email starting with: "[tkt-mgr] CommitCRM Document" will be moved to another folder.

Troubleshooting

I set my user to receive Alerts but I do not get any email alerts

Solution: You should check the following options:

1. It can take up to 10 minutes for new Alerts preferences to take effect. You can wait, or restart the Commit Server service in order for the settings to take effect immediately.
2. Make sure your system administrator has activated the system alerts (set the system to ON using the ServerConfig utility) and that the CommitServer Windows service is running).
3. When testing the alerts, note that you will not receive Alerts for changes you have made. You should perform the changes with a different Commit user.

I checked all of the settings, the alerts system is activated, and and I still don't get email alerts

Solution: In some cases, old settings already created wrong email alerts which are "stuck" in the outgoing queue and prevent the system from going on to the new alerts. In this case, you should first cleanup the outgoing queue:

1. Stop CommitServer service
2. Run <server>\Commit\Server\ServerConfig and make sure all settings are correct. Check that the "From Email Address" is correct. Save any changes you make.
3. To delete old pending alerts, delete all the files in the following folder: <server>\Commit\Server\QSysEDOutbox\
4. Restart CommitServer service and verify email alerts are being sent

For more Outgoing Emails troubleshooting, please refer to the Email Connector Troubleshooting section (both the Email Connector and the Alerts Server use the same Outgoing mechanism).

I made changes in Commit (i.e. added a new Ticket, etc.) and I am not getting any Alerts

Solution: You only receive Alerts for changes made by other people. When you make a change in the system on entities related to you (e.g. you assign yourself a new Ticket), you will not receive an Alert.

See Also

• Videos
• Email Connector
• Commit Alerts Server Troubleshooting
• Alerts Server FAQ