This article contains:

1 1. Notification Templates Settings
2 2. Notifications Settings
3 3. Trigger Criteria
- 3.1 3.1 Incident
- 3.2 3.2 Investigation
- 3.3 3.3 Action
- 3.4 3.4 Resolution
- 3.5 3.5 Close
- 3.6 3.6 Signoff
- 3.7 3.7 Risk
- 3.8 3.8 Submission
- 3.9 3.9 Custom
- 3.10 3.10 Incident Review
  - 3.10.1 3.10.1 Notification Delivery Failure
  - 3.10.2 3.10.2 Custom Trigger Criteria Configuration
4 4. Triggering Notifications based on Custom Date Fields
5 5. Notifying Parent Node Managers for an Incident Linked to a Hierarchy Node
- 5.1 5.1 Dropdown List based on API Calls
- 5.2 5.2 Notify Users via Email/SMS during Email/SMS/API Delivery Failures

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.

Figure 1.1

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

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. Notes: In addition to Email notifications, you are able to configure SMS and API notifications too, if these are set up. If not, you will only see the Email notification method. Should you require to setup SMS or API notifications, please contact CAMMS Support.
Subject	This will be the email subject of the notification. Note: Additionally, you can include snippets for custom fields that are added via 'Object Configuration Settings' using the following syntax: `{{ObjectName.FieldName}}` E.g. For a custom object named <Claim> you wish to include the <ClaimNumber> custom field in the email, include it as: {{Claim.ClaimNumber}}
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: `{{ObjectName.FieldName}}` E.g. For a custom object named <Claim> you wish to include the <ClaimNumber> custom field in the email, include it as: {{Claim.ClaimNumber}} Figure 1.2
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

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.
Incident Categories	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	Flexoff DBs: Refers to the responsible person of the Directorate linked to the Incident Record. If no Directorate is linked, it identifies the responsible person of the Business Unit. Flexon DBs: Refers to the responsible person of the hierarchy node linked to the Incident Record.
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 Status	Action	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

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: Incident – Incident creator, incident responsible officer, unit manager, director, business unit manager, service profile manager, incident submitter, incident approver, reporting officer of incident responsible officer, custom staff, unit manager of the linked hierarchy node of the notification and below, staff dropdown. Investigation – Primary investigator, secondary investigator, unit manager, incident creator, incident responsible officer, director, business unit manager, service profile manager, reporting officer of incident responsible officer. Action – Incident responsible officer, action responsible officer, unit manager, incident creator, director, business unit manager, service profile manager, action submitter, action approver, action creator, action reviewer, action effectiveness reviewer, reporting officer of incident responsible officer, reporting officer of action responsible officer. Resolution – Resolved by, unit manager, incident creator, incident responsible officer, director, business unit manager, service profile manager, reporting officer of incident responsible officer. Close – Closed by, incident creator, incident responsible officer, unit manager, director, business unit manager, service profile manager, reporting officer of incident responsible officer. Signoff – Incident responsible officer, signoff authority, signoff submitter, incident creator, unit manager, director, business unit manager, service profile manager, reporting officer of incident responsible officer. Risk – Evaluated by, unit manager, incident creator, incident responsible officer, director, business unit manager, service profile manager, reporting officer of incident responsible officer. Submission – Unit manager, incident creator, incident responsible officer, director, business unit manager, service profile manager, reporting officer of incident responsible officer. Custom – Unit manager, director, business unit manager, service profile manager, incident creator, incident responsible officer, reporting officer of incident responsible officer. Incident Review – Incident creator, incident responsible officer, reporting officer of incident responsible officer. Notification Delivery Failure – Unit manager, director, business unit manager, service profile manager, incident creator, incident responsible officer, reporting officer of incident responsible officer.
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: `{{ObjectName.FieldName}}` Example: `{{Action.CustomStaff}}` – this custom field will be created under the Action Notification Type, having a dropdown list of Custom Staff members to send out this notification to.
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: On Save – selecting this option will execute the trigger when the user makes a change and clicks the Save button. On Auto Save – selecting this option will execute the trigger when the 'Auto Save' setting (under Miscellaneous Settings) is turned ON. When the auto save cycle runs in the background, if there has been any new changes in an incident record which requires an email to trigger, it will execute. Open – selecting this option will execute the trigger for API based notifications; where an API based dropdown can be configured using API notifications. The system will send an API request when the dropdown is set to 'Open' and then receive an API notification with the data values to populate the dropdown. This has nothing to do with email or SMS notifications.

3. Trigger Criteria

The following trigger criteria will be available for each notification type.

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 submitted from an object with the Workflow Element Type ‘Incident Details’.

Incident approved – Notification triggered when an incident is approved.

Incident rejected – Notification triggered when an incident is rejected.

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 – This is a notification feature that alerts users when an action review is due.
Action Review Effectiveness Due Date – 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.
Custom Trigger Criteria – Refer Custom Trigger Criteria Configuration title below for more details.

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, action 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

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. Example: In the screenshot, in line 1, the object > Case Details + the field > Investigation Status has been selected in the first line. You may then use the operators as explained below, and build the function you wish, to create your customised trigger.
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. Example: In the screenshot, in line 1, the object > Case Details + the field > Investigation Status has been selected and the EQUAL operator has been selected, and the Value dropdown has been selected as 'Not Started'.
Operators	AND – Use this operator to denote that whatever follows this, will have to be fulfilled too, in order to trigger the notification. Example: `({IncidentObject.IncidentStatus}='Complete')AND` `({IncidentObject.IncidentStatus}='In Progress')` OR – Use this operator to denote that whatever criteria mentioned before this or after this requires to be fulfilled, in order to trigger the notification. Example: `({IncidentObject.IncidentStatus}='Complete')OR` `({IncidentObject.IncidentStatus}='In Progress')` EQUAL – Use this operator to add an = sign to trigger a notification if it equates the field to a selected value. Example: `({IncidentObject.IncidentStatus}='Complete')` NOT EQUAL – Use this operator to add a != sign to trigger a notification if it does not equate the field to a selected value. Example: `({IncidentObject.IncidentStatus}!='Complete')` ( ) – Use these bracket operators to group several functions when using multiple trigger criteria. Example: `(({IncidentObject.IncidentStatus}='Complete')AND` `({IncidentObject.IncidentStatus}='In Progress'))` `OR({IncidentObject.IncidentStatus}='N/A')` CHANGE – Use this operator when you want to trigger a notification whenever a field is changed to any value (unlike in EQUAL and NOT EQUAL, where it will trigger only when equal/not equal to a specified value). The 'Change' syntax should be written as follows: `({CHANGE.objectname.fieldname})` for this to function correctly. BEFORE / AFTER – Use these operators to trigger notifications based on custom date fields. See section Triggering Notifications based on Custom Date Fields below, for more details. Examples: Trigger notification 5 days before the incident close due date. `({BEFORE(CloseObject.CloseIncidentDueDate,5,DAY)})` Trigger notification after 5 days from the incident close due date. `({AFTER(CloseObject.CloseIncidentDueDate,5,DAY)})` To trigger the notification on the incident close due date you can use any of the below: `({BEFORE(CloseObject.CloseIncidentDueDate,0,HOUR)}) or` `({BEFORE(CloseObject.CloseIncidentDueDate,0,DAY)}) or` `({AFTER(CloseObject.CloseIncidentDueDate,0,DAY)})`

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])})

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.

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'.

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'.

STEP 5: Save the notification.

5.1 Dropdown List based on API Calls

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:

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

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.

5.2 Notify Users via Email/SMS during Email/SMS/API Delivery Failures

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:

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:

<< Back to main section
Incident Settings

Table of Contents

Camms.Support Documentation

Incident Settings – Notification Templates & Notifications

Analytics