Table of contents
Octopus User
Each Octopus user can define his own notification preferences. There are two ways to access it:
- Go to the File > My notification preferences menu.
- Open the user file with the File > Modify my profile menu, and click the Modify my notification preferences action from the Action menu.
You can also modify the notification preferences of another user, but you must have the Administer Octopus permission to do so:
- Access the Users module and click on the Octopus Users list.
- Select the Octopus user and click the Modify notification preferences action in the left side menu. This action can only be done one user at a time.
- Note that these preferences can be changed again by the Octopus user if he has the rights to modify his profile.
Notification Types
There are four notification types:
- Popup
- List
- No notification
- SMS (text)
Octopus users can choose, according to their taste, how to be notified for each basic Octopus event. Only one notification choice is possible per event.
How to choose the notifications options
From Octopus, go to File > My notification preferences.
Choose the situation that will trigger a notification in the Event field. Each event from the list is a potential notification. By default, Octopus has already made notification choices based on best practices.
Go through the list and select the desired notification types. It is not required to do OK each time, choose the type for a notification and go back to the Event field to do the next until the list has been reviewed.
Example of an email
Example of a popup
Example of a list
SMS (text) Notification - For more details click here
My pending notifications
This option, accessible from File > My pending notifications will bring up the notifications by list window. It can also be accessed with CRTL+F12.
One of the advantages of this notification type is that you can open a request from the list by double-clicking it. It will also remove the notification from the list.
The list can be closed to get back to it later on. The rest of the notifications will remain available in the list until the element is accessed from the list or marked as read.
Mark a notification as read
Here are the different ways to mark a notification as read:
- Double-click a notification.
- Select a notification and click on the Mark as read button.
- Use CRTL+click to select multiple notifications and click on the Mark as read button.
- Use MAJ+click to select multiple subsequent notifications and click on the Mark as read button.
- Use CRTL+A to select all notifications and click on the Mark as read button.
Notification Description
Event | Description | Scope |
---|---|---|
Requests | ||
Assignment or activity sent to an unavailable person |
Sent to all the members of a group when a request is assigned to an unavailable person, or when an activity is added to a request assigned to an unavailable person. The system will use the proper template according to the notification to be sent. |
Group |
Incidents/SR | ||
New incident |
Sent to all members of the incident's groups when an incident is created or when it is transferred to the group. |
Group |
Assignment of an incident/SR |
Sent to the assignee when the incident is assigned to him. |
Individual |
High priority incident/SR |
Sent to a manager when a high priority incident/SR is created or when the priority of an existing incident is modified to high. It is possible to specify from which priority the notification applies. |
Individual |
Incident resolved or closed by another user |
If an incident/SR has been resolved or closed by another user than the assignee, the assignee will be informed. |
Individual |
Problems | ||
New problem |
Sent to all members of the problem's groups when a problem is created or when it is transferred to the group. Will not be sent if the problem is assigned to an individual. |
Group |
Assignment of problem | Sent to the assignee when he is assigned to a problem. | Individual |
New known error | This notification is sent when the Known error field of a specific problem is documented. | All |
Problem closed |
This notification is sent when a problem is resolved and closed. This notification is sent to everyone, regardless of the assigned group. |
.All |
Changes | ||
Assignment of a change |
Sent to the assignee when he is assigned to a change. | Individual |
Tasks | ||
New task |
Sent to all members of the task's group when a task is created and activated or when it is transferred to the group. Will not be sent if the task is assigned to an individual or if it is not activated. |
Group |
Assignment of task |
Sent to the assignee when he is assigned to an active task. | Individual |
Approval task refused on a request in process |
Sent to the assignee when an approval task is refused in an ongoing service request. This notification allows the assignee to intervene following an approval rejection when it is not for an initial approval task. |
Individual |
Activities | ||
New activity added to all requests/tasks |
Sent when an activity is added to a request part of any group the assignee is a member of. Adding this notification should be used in precise situations as it will create lots of notifications, therefore it is not recommended to activate it by default. |
Group |
New activity added to an unassigned request/task | Sent to all members of a group of a request or task assigned to them when an activity is added. The notification will not be sent if the request or task is assigned to an assignee. |
Group |
New activity added to a request/task assigned to me | Sent to the assignee of a request or a task when an activity is added. | Individual |
Events | ||
New event |
Sent to all members of the event's group when an event is created or when it is transferred to the group. Will not be sent if the event is assigned to an individual. |
Group |
Assignment of event | Sent to the assignee when he is assigned to an event. | Individual |
Error notification |
The system has detected a error: of a Required to operate Cyclic Relationship. |
Group |
Contract | ||
Service contract expiration |
This notification is sent X months before the expiration of a service contract. You can configure the number of months from the Tools > Options > Emails to technicians menu. |
All |
Lease contract expiration | This notification is sent X months before the expiration of a lease contract. You can configure the number of months from the Tools > Options > Emails to technicians menu. |
All |
Meetings | ||
Meeting invitation |
This notification is sent when you are invited to a meeting. | Individual |
Meeting modification | This notification is sent when a meeting is modified. | Individual |
Reminder Meeting |
This notification is sent as a reminder of a meeting. | Individual |
Reminders | ||
Reminder |
This notification is sent at the time set for a reminder. | Individual |
SLA | ||
Octopus can inform you when incidents and SR are almost due or are late. You can manage the warning level of SLAs from the Tools > Options menu > Service Level Agreement (SLA) section. |
||
SLA - 1st warning reached |
This notification is sent when the delay for the first level specified in the Service Level Agreement of a request is reached. By default, the percentage of elapsed time notification is 50%. |
Special: See additional options below |
SLA 2nd warning reached | This notification is sent when the delay for the second level specified in the Service Level Agreement of a request is reached. By default, the percentage of elapsed time notification is 75%. |
|
SLA breach | This notification is sent when the maximum delay specified by the Service Level Agreement is reached. | |
Response SLA – Breach | This notification is sent once the response delay is breached for the service level agreement (SLA). | |
Octopus update | ||
Octopus update |
When the database is updated, specifies the database name and the new version. It is recommended to add this notification to both test and production DBs. |
Individual |
New Octopus version available soon |
When the Release Notes Wiki page is updated with a new version to come. It is recommended to add this notification in only one place to avoid duplicate notifications. |
Individual |
Additional options on the scope of SLA
It is possible to control to whom SLA notifications will be sent to. You can configure these options from the menu Tools > Options > Scope of SLA notifications.
When an incident/SR is assigned to an Octopus user, the notification may be sent to all members of the affected group or sent only to the Octopus user and group managers.
When an incident/SR is not assigned to an Octopus user, the notification may be sent to all members of the affected group or only to group managers.
- Octopus update.
- When a test DB is refreshed with a copy of the production DB, email notifications will be lost.
- It is suggested to make a list in the test DB that will grab the list of users whose email field Is not empty and note them down to add them later.
- The email addresses that must receive this notification must be added again.
- New Octopus version available soon.
- This notification only works for hosted customers.
Regular User
Emails to users can be enabled and configured from the Tools menu > Options, Email to users section.
Event | Description | Scope |
---|---|---|
Incident creation |
Sent to the Requestor/User when an incident is created (by Web, email, or in the appliation). | Requestor/User |
Beginning of work |
Send to the Requestor/User when an incident is marked In Process (status is changed to Take assignment). | |
Activity by email |
Send to the Requestor/User when an activity is sent by email. Note that the Octopus user can select who will receive the email. |
|
Incident resolution | Send to the Requestor/User when the incident is resolved. |
Notifications for Approvers
The use of the approval tasks and the notifications related to this process are described in the Automated Approvals - Reference Document article.
Thank you, your message has been sent.