This article contains:
|
1. Notification Templates Settings |
This settings page will let you setup and configure various notification templates to be available when triggering notifications. Select the notification name, type, description, notification method, subject and body (for email notifications), SMS body (for SMS notifications), and API body (for API notifications). You can specify under which conditions these templates are to be used in the Notifications page of this Settings area.
| Info |
|---|
Note: The filters within the Incident Settings pages accessed via Mega Menu > Framework > Incident Settings > Notification Template Configuration will be simplified to only have the ‘Contains’ search filter. This will allow you to easily filter the required details. |
To create a new notification template:
STEP 1: Click the New button at the top-right corner of the page.
STEP 2: Enter the following fields.
Field | Description | ||
|---|---|---|---|
Name | Define a name for the template. Name should be unique. | ||
Notification Type | A dropdown including types; incident, investigation, action, resolution, close, sign off, risk, submission, custom, incident review, notification delivery failure. Selecting a type will determine the snippets and trigger criteria of the notification. | ||
Description | A textbox to include a brief description of the notification template. | ||
Notification Method | Select the method of the notification to be sent.
| ||
Subject | This will be the email subject of the notification.
| ||
Email Body | Text area to include an email notification body. Few common formatting functionality will be included here such as bold, italic, underline, strike through text, align text to right, left, centre, justify, remove alignment, font size, spell check, and snippets.
| ||
SMS Body | Text area to include an SMS notification body. Snippets will be able to be added in this section too. Additionally, you can include snippets for custom fields that are added via 'Object Configuration Settings' using the following syntax: E.g. For a custom object named <Claim> you wish to include the <ClaimNumber> custom field in the email, include it as: {{Claim.ClaimNumber}} 
| ||
API Body | Section to view and include API general details, parameters, authorisation, headers, request body syntax, and response body syntax. 
|
STEP 3: Click on the Save button at the top-right corner of the page to save and add details.
Notification snippets are available to be included in the e-mail body. The snippets are categorised by the e-mail type, therefore, only the snippets that belong to the type selected will be visible in the list.
All snippets are described below:
Field | Types | Description | ||
|---|---|---|---|---|
Incident Title | Incident Investigation Action Resolution Closure Signoff | Title of the relevant incident. | ||
Incident Responsible person | Incident Investigation Resolution Closure Signoff | Name of the staff selected as incident responsible person. | ||
Incident Code | Incident Investigation Resolution Closure Signoff | The code of the relevant incident will be included as a hyperlink. This will apply to all notification types, except ‘Risk’.
| ||
Incident type | Incident | Type that the relevant incident belongs to. |
Action Responsible officer
Action
Name of the staff selected as action responsible officer.
Action Start Date
Action
Action start date
Action end date
Action
Action end date
Action Status
Action
Current status of the action
Action % complete
Action
Current action % complete
Resolution Status
Resolution
Resolved or not
Close Status
Close
Close/ Open
Signoff Status
Signoff
Approved / denied
Incident type
Incident
Incident Categories |
Investigation
Investigation due date
Primary investigator
Investigation
Name of the staff selected as incident primary investigator.
Secondary investigator
Investigation
Name/s of staff selected as incident secondary investigator/s.
Action Title
Action
Action title
Incident | Incident category of the action | |
Previous Incident Category | Incident | Previously saved Incident category |
Incident Description | Incident | Incident description |
Incident Location | Incident | Incident location |
Incident Reported By | Incident | Incident reported person |
Incident Reported Date | Incident | Incident reported date |
Reporting Officer of Incident Responsible person | Incident | Reporting officer of the Incident responsible officer |
Unit Manager | Incident | Responsible Person of the Directorate linked to the Incident Record. (Works only in Flexoff DBs) |
Investigation due | Investigation | Investigation due date |
Primary investigator | Investigation | Name of the staff selected as incident primary investigator. |
Secondary investigator | Investigation | Name/s of staff selected as incident secondary |
investigator/s. | ||||
Action Title | Action | Action title | ||
Action Responsible officer | Action | Name of the staff selected as action responsible officer. | ||
Action Start Date | Action | Action start date | ||
Action end date | Action | Action end date | ||
Action Status | Action | Current status of the action | ||
Action % complete | Action | Completed Percentage of the Action | ||
Action Actual Completion Date | Action | Actual completion date of the action | ||
Action Description | Action | Action description | ||
Action List | Action | List of actions in the consolidate email along with their Incident title, Action name, Responsible officer, start date, Previous action status, Status, Percent Completed, Overdue days.
| ||
Action Priority | Action | Action |
priority |
Action Responsible |
Officer | Action |
Responsible officer of the |
action |
Previous Action |
Action end date
Action
Action end date
Action Status
Action
Current status of the action
Action % complete
Action
Current action % complete
Status | Action |
Action start date
Previously saved action status | ||
Reporting Officer of Action Responsible Officer | Action | Reporting officer of the Action responsible officer |
Resolution Status | Resolution | Resolved or not |
Close Status | Close | Close/ Open |
Signoff Status | Signoff | Approved / |
Denied |
2. Notifications Settings |
This settings page lets you configure notifications to be sent out as email, SMS, or APIs upon various trigger criteria, according to a selected notification template, to various recipients, users, user roles, or additional recipients. Notifications can be based on a trigger type. Further, create custom notifications for incident objects, with custom trigger criteria, using custom trigger criteria configuration equations.
To create a new email notification:
STEP 1: Click on the New button.
STEP 2: Enter relevant details to trigger notifications. The following fields will be available.
Field | Description | ||
|---|---|---|---|
Notification Name | Define a name for the notification. Name should be unique. | ||
Notification Type | A dropdown including the notification types: incident, investigation, action, resolution, close, signoff, risk, submission, custom, and incident review, notification delivery failure.
| ||
Type | This dropdown will be displayed only for the notification types: Submission and Custom. | ||
Object | This dropdown will be displayed only for the notification types: Submission and Custom. And based on the selected submission or custom type, the object list will vary. | ||
Trigger Criteria | List of all trigger criteria available for the selected notification type. Refer Trigger Criteria title below for more information. | ||
Notification Template | Lists all notification templates created via Incident Settings > Notification Templates filtered by the notification type. | ||
Notification Recipient | Select multiple recipients via their role within the incident to receive a notification. Recipient list will differ according to the notification type selected. Options available will be:
| ||
Users | Select multiple users from the list of staff members that don't fall into any recipient or role category. This will allow to select a set of users to receive notifications when the criteria triggers.
| ||
User Role | Select multiple user roles created via Incident Settings > User Roles, to send a notification to all users assigned under that user role; | ||
Custom Fields | If any user does not fall under the standard set of notification recipients, users, or user role category, and want to create a new staff category, the custom fields can be used to add this field/responsible person(s) here. This will be written as follows: Example:
| ||
Active | Tick this checkbox to mark this notification as active, and deselect to mark it as inactive. | ||
Trigger Type | Select when the trigger will be executed from the following options:
|
3. Trigger Criteria |
The following trigger criteria will be available for each notification type.
| Info |
|---|
Note: Service based email notifications will be triggered, only if one of the below trigger criteria is met and if the Incident is still in an 'Open' state. If not, email notifications will not be sent out to recipients. |
3.1 Incident
Incident due date – Notification triggered on the incident due date. If you select this trigger, you may add details to continue this trigger for a specified number or times, on a recurring (daily, weekly, monthly, quarterly, yearly) basis, for a specified number of days before/after the incident due date, and/or for a selected incident status.
New incident created – When a new incident is created a notification is triggered.
Incident assigned a workflow – When an incident is assigned a type and saved a notification is triggered.
Incident assigned to user – When an incident is assigned to a user as a responsible person a notification is triggered.
According to incident priority – Notification triggered according to the incident priority. Priorities to trigger this notification can be specified.
According to incident severity – Notification triggered according to the incident severity. Severities to trigger this notification can be specified.
Incident deleted – Notification triggered when incident is deleted.
According to incident type – Notification triggered according to the incident type. Types to trigger this notification can be specified.
According to incident location – Notification triggered according to the incident location. Locations to trigger this notification can be specified.
Custom trigger criteria – Refer Custom Trigger Criteria Configuration title below for more details.
Incident submitted – Notification triggered when an incident is submittedan incident is submitted from an object with the Workflow Element Type ‘Incident Details’.
| Info |
|---|
Notes:
|
Incident approved – Notification triggered when an incident is approved.
| Info |
|---|
Notes:
|
Incident rejected – Notification triggered when an incident is rejected.
| Info |
|---|
Notes:
|
Web account created – Notification triggered when a web account is created.
Reset password – Notification triggered when a password is reset.
Linking to hierarchy node – Notification triggered when linked to a hierarchy node. Type and category can be specified to trigger this notification.
Category change – Notification triggered when there is a category change. Type and category can be specified to trigger this notification. Additionally,this notification is triggered initially when the empty category field is given a value and saved.
Linking to hierarchy node considering rolled up linkages – This trigger will consider all and any linkages done at underlying child level nodes for the selected hierarchy branch. Type, category, hierarchy search, and hierarchy type can be specified to trigger this notification.
3.2 Investigation
Investigation due date – Notification triggered on the investigation due date. If you select this trigger, you may add details to continue this trigger for a specified number or times, on a recurring (daily, weekly, monthly, quarterly, yearly) basis, for a specified number of days before/after the investigation due date, and/or for a selected investigation status.
Investigation assigned to user – When an incident is assigned to primary/ secondary investigators and saved an notification is triggered.
Investigation pending – On the day specified as investigation due, a notification is triggered.
Investigation started – When the investigation status is changed to in-progress and saved a notification is triggered.
Investigation completed – When the investigation status is changed completed and saved a notification is triggered.
Custom trigger criteria – Refer Custom Trigger Criteria Configuration title below for more details.
3.3 Action
Action due date – Notification triggered on the action due date. If you select this trigger, you may add details to continue this trigger for a specified number or times, on a recurring (daily, weekly, monthly, quarterly, yearly) basis, for a specified number of days before/after the action due date, and/or for a selected action status.
Action Review Due Date Notification – This is a notification feature that alerts users when an action review is due.
Action Review Effectiveness Due Date Notification – Alerts users when the effectiveness review of an action is due.
Action review – Notification triggered on the action review due date. If you select this trigger, you may add details to continue this trigger for a specified number or times, on a recurring (daily, weekly, monthly, quarterly, yearly) basis, for a specified number of days before/after the action review due date.
Action status changed – Notification triggered when an action status is changed and consolidated notifications can be sent out when triggered.
Action created – When an action is created and saved a notification is triggered.
Action submitted – Notification triggered when an action is submitted.
Action approved – Notification triggered when actions submitted for approvals are approved by a user. If the approval process type is set up as ‘Sequential’ this will only be triggered if when all approvers approve the record.
Action rejected – Notification triggered when actions submitted for approvals are rejected by a user. If the approval process type is set up as ‘Concurrent’ this will only be triggered if the last standing approver also rejects the record and there are no more pending approvals.
Action assigned to user – Notification triggered when an action is assigned to a user.
According to action status – Notification triggered according to the action status. Action status can be specified to trigger this notification and consolidated notifications can be sent out when triggered.
3.4 Resolution
Incident resolved – A notification triggered when an incident is marked as resolved and saved.
Custom trigger criteria – Refer Custom Trigger Criteria Configuration title below for more details.
3.5 Close
According to incident close status – A notification triggered when an incident is marked as closed.
Custom trigger criteria – Refer Custom Trigger Criteria Configuration title below for more details.
3.6 Signoff
Phase submitted for signoff – When an incident object is submitted for signoff a notification is triggered.
Phase approved – When an incident object is approved a notification is triggered.
Phase declined – When an incident object is declined a notification is triggered.
3.7 Risk
According to risk analysis status – Notification triggered according to the risk analysis status. Risk analysis status can be specified to trigger this notification.
Custom trigger criteria – Refer Custom Trigger Criteria Configuration title below for more details.
3.8 Submission
Submitted – Notification triggered for a submission type notification for various items submitted. The submission Type and Object can be specified to trigger this email notification.
Custom trigger criteria – Although this option is available, this is not functional yet.
Submission failed – Notification trigged for a submission type notification when the submitted.
3.9 Custom
Custom trigger criteria – Refer Custom Trigger Criteria Configuration title below for more details.
3.10 Incident Review
Next review date – Notification triggered on the next review date. If you select this trigger, you may add details to continue this trigger for a specified number or times, on a recurring (daily, weekly, monthly, quarterly, yearly) basis, for a specified number of days before/after the next review date.
3.10.1 Notification Delivery Failure
Notify Upon Delivery Failure.
3.10.2 Custom Trigger Criteria Configuration
A custom trigger criteria can be set for notifications to be triggered using this 'Trigger Criteria Type' for the following Notification Types: incident, investigation, resolution, close, risk, and submission. Custom trigger criteria for all these notification types will be set in the same manner.
The following configurations will be available to be set using the above custom trigger criteria builder.
Field | Description | ||
|---|---|---|---|
Select field | Select the object from the dropdown to which you wish to set the custom trigger for. Expand the object by clicking on the + icon to list all its fields under each object. Once you select the field, it will add it on to the criteria builder area. | ||
Values | If the above selected field has several values assigned to it (e.g. in a dropdown), this will list under the values dropdown. These values can be used with the EQUAL or NOT EQUAL operators to use in your customised function. | ||
Operators |
|
STEP 3: Click on the Save button at the top-right corner of the window to save your settings.
4. Triggering Notifications based on Custom Date Fields |
You can trigger notifications based on custom date fields and combine date fields with other fields to setup a more advanced logic as the trigger criteria (e.g. triggering a notification 5 days before a certain date, if the incident is still open).
The operators BEFORE and AFTER can be used when incorporating custom date fields to custom trigger criteria.
To incorporate custom date fields within the custom trigger criteria of your notification, you will need the ‘Custom Trigger Criteria Configurations’ editor. To do this, select any of the below notification types along with the ‘Trigger Criteria’ as 'Custom Trigger Criteria':
Incident
Investigation
Resolution
Close
Risk
Submission
Custom
Build your custom date related trigger criteria in the ‘Custom Trigger Criteria Configuration’ editor using the following format. You can use the 'Variables' and 'Operators' dropdowns in the ‘Custom Trigger Criteria Configuration’ editor.
({[Operator]([Date field],[Timeframe],[Timeframe unit])})
| Tip |
|---|
Example: ({BEFORE(IncidentObject.DateTimeofIncident,5,DAY)}) |
Operator – Allowed operators for Date and Time fields are 'BEFORE' and 'AFTER' only. You can use the 'Operators' dropdown in the ‘Custom Trigger Criteria Configuration’ editor.
Date field – You can use the 'Variables' dropdown in the ‘Custom Trigger Criteria Configuration’ editor to select the required date field.
Timeframe – This is the interval within which the notification will be triggered. The timeframe value must be 0 or a positive integer.
Timeframe unit – Will specify the unit of measure of the given timeframe. Permitted values are: HOUR, DAY, MONTH, YEAR.
| Info |
|---|
Note: Have the timeframe value as ‘0’ when you require the trigger on the same day of the selected date-time field. In essence, when the timeframe is '0', the use of any valid date-time Operator and compatible Timeframe Unit, will provide the same result. Example: To trigger the notification on the incident close due date you can use any of the below:
|
5. Notifying Parent Node Managers for an Incident Linked to a Hierarchy Node |
This feature lets incident admins configure to have notifications sent to all parent node managers. Configure this following the below steps:
STEP 1: Go to Menu > Incident Settings > Notifications, and create a new notification by entering a 'Notification Name', and select the 'Notification Type' as 'Incident'.
STEP 2: Select the Trigger Criteria as 'Linking to a hierarchy node considering rolled up linkages'.
| Info |
|---|
Note: This trigger will consider all and any linkage done at underlying child level nodes for the selected hierarchy branch. |
STEP 3: Select the respective 'Notification Template'.
STEP 4: Select the Notification Recipient as 'Unit Manager of the linked hierarchy node of the notification and below'.
| Info |
|---|
Note: This would send out notifications to all responsible officers/unit managers at all levels from the hierarchy node level linked to the notification until the node level the Incident is linked with. |
STEP 5: Save the notification.
5.1 Dropdown List based on API Calls
| Info |
|---|
Note: To utilise this feature, you will need to have the API functionality enabled, and a suitable API available. Please contact CAMMS Support to set this up for you. |
This feature lets you populate list values based on the response of an API call, depending on specific conditions, with the options list being populated via an API. The field type can be assigned to a custom field within any object.
Set this up following the below steps:
STEP 1: Under Menu > Framework > Incident Settings > Object Configuration, under the Object you wish to set the API dropdown to, under the 'Field Type' dropdown, select 'API based dropdown' and under 'Select List Name', select the list name you wish to apply this API dropdown to.
STEP 2: Under Menu > Framework > Incident Settings > Notification Templates, set up a custom API notification template with the below setup:
Notification Type: Custom
Notification Method: API
The API body requires to be configured within the template. The API body consists of General API information, such as the request type and the API URL. For this feature, the request type would be ‘Get’. The API URL of your external application must be included.
The API body will further include a Parameters section, where the parameters required to be passed in the API can to be configured. The parameters for this feature would be the parent list field values, and/or other fields by which the list value requires to be filtered by.
The API response body requires to be configured to include the response result. For this feature, within the ‘Response Body’, the response should define the notation type that the response result must be received. The following syntax requires to be included for ALL API-based dropdowns:
| Tip |
|---|
|
| Info |
|---|
Note: Separate notification templates and notification triggers must be configured for each API-based dropdown. |
STEP 3: Under Menu > Framework > Incident Settings > Notifications, set up a custom API notification template with the below setup:
Notification Type: 'Custom' field within any Object.
Type: [Applies to ALL types]
Object: Select the object for which the API dropdown is configured.
Trigger Criteria: Custom Trigger Criteria.
Notification Template: Select the Notification Template created in STEP 2. In the event there aren’t any notification templates created, the 'Active' tick box will remain disabled.
Trigger Type: Open (This is because the API call will trigger a request when clicked to open the dropdown to select a value.)
Fields: Select the fields for which the dropdown is configured.
Response Trigger Criteria Configurations (include the below syntax for each API-based dropdown):
| Tip |
|---|
|
STEP 4: When you open an API dropdown to select a value, an API call will be triggered (based on the API notification configured), which will then populate a list of values into the dropdown.
| Info |
|---|
Note: Dropdown values will be populated based on the selection of one or more parent dropdown value selection. This filtration will be developed into the API Get request. If the response of the API calls has no values, the dropdown will display ‘No data found’. |
5.2 Notify Users via Email/SMS during Email/SMS/API Delivery Failures
| Info |
|---|
Note: To utilise the API delivery failure feature, you will need to have the API functionality enabled. Please contact CAMMS Support to set this up for you. |
This feature lets you notify pre-defined users about delivery failures via SMS or Email. This includes the ability to specify the number of retry attempts as well as the duration between retries.
The following instances will trigger a failed notification:
When a user has entered an invalid email ID in the staff page
An issue in the Camms.Risk Incident Email Server
An SMTP server failure
SMS Gateway failed responses
Set this up following the below steps:
STEP 1: Under Menu > Framework > Incident Settings > Notification Templates, create a template for an error log with the below setup:
Notification Type: NotificationDeliveryFailure
Notification Method: Email and SMS
Email/SMS Body: Select [ErrorLog] from variables snippet
STEP 2: Under Menu > Framework > Incident Settings > Notification, create a notification delivery configuration with the below setup:
Notification Type: NotificationDeliveryFailure
Trigger Criteria: Notify Upon Delivery Failure
Notification Template: Select the Notification Template created in STEP 1.
Additional Recipients: If additional recipients are required to be added, add using the following syntax template – {{IncidentObject.BusOperatorName}},+64713489166,Test@cammsgroup.com
Active: Tick both Email and SMS
Custom Trigger Criteria Configuration: Notation for the retry attempts should be entered in the editor using the following syntax:
| Info |
|---|
Note: It is important that this notification is saved with one of the below syntax for a failed notification. Although the system will let you save without this syntax, the failed notification will not be sent without this important step. |
| Tip |
|---|
Tip: For an API delivery failure |
| Info |
|---|
Notes:
|
For API-based delivery failures:
STEP 3: Link the failure notification to an API request with the below setup:
Under Menu > Framework > Incident Settings > Notification, open an API notification created.
Under the 'Failure Notification' dropdown, select the notification delivery failure name created in STEP 2.
STEP 4: An error log format will be as the below log file.
View other articles under this section: |
