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.

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. 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. 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}}
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}} Note: This section will be displayed only if SMS notifications are set up for your organisation. Should you require to setup SMS notifications, please contact CAMMS Support.
API Body	Section to view and include API general details, parameters, authorisation, headers, request body syntax, and response body syntax. Note: This section will be displayed only if API notifications are set up for your organisation. Should you require to setup API notifications, please contact CAMMS Support.

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’. Note: For the hyperlink to work, it is important that the 'Disable hyperlinks in email snippets for all incident and compliance notifications' setting under Incident Settings > Miscellaneous Settings, is not active.
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	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. Note: The "Action List" works only for Consolidated Emails.
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
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. Note: Based on the selected notification type, the Trigger Criteria, Notification Template, and Notification Recipient options to select from will vary.
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. Note: If the user does not have permission to view the object, they will not be able to view the object, but will get an email notification.
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. Note: The ‘On Auto-Save’ option is not applicable for the following triggers: Incident: New incident creation, Password reset, Web account created, Incident Deleted, Incident Submitted, Incident Approved, Incident Rejected. Action: Action submitted, Action Approved, Action Rejected. Sign off: Phase submitted for sign off, Phase approved, Phase rejected. Submission. Notifications will not trigger if the incident is in ‘Draft’ state. 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.

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

Notes:

To trigger an email for an Incident Submission, configure the following as below:
- Notification Type = Incident
- Trigger Criteria = Incident Submitted
- Notification Recipients = Incident Submitter

Incident approved – Notification triggered when an incident is approved.

Notes:

For the above two triggers (Incident submitted and incident approved), if the incident submitter and the incident approver are the same, both submit and approval of the incident will effectively take place. This will then tag the incident as 'Approved'. Therefore, the 'Incident Submitted' trigger will not be sent out.
If the incident approver is different from the incident submitter, then once the incident is submitted, the 'Incident Submitted' trigger will be sent out.
To trigger an email for an Incident Approval, configure the following as below:
- Notification Type = Incident
- Trigger Criteria = Incident Approved
- Notification Recipients = Incident Submitter

Incident rejected – Notification triggered when an incident is rejected.

Notes:

To trigger an email for an Incident Rejection, configure the following as below:
- Notification Type = Incident
- Trigger Criteria = Incident Rejected
- Notification Recipients = Incident Submitter

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. 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)})` Note: It is important to NOT leave any spaces when building a custom function, except when referring to a value within a quotation mark (e.g. 'Not Started'). The trigger will not work if any spaces are used in the Custom Trigger function.

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

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.

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:

({BEFORE(CloseObject.CloseIncidentDueDate,0,HOUR)}) or
({BEFORE(CloseObject.CloseIncidentDueDate,0,DAY)}) or
({AFTER(CloseObject.CloseIncidentDueDate,0,DAY)})

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

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

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

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:

Success,object#data.<API response results need to refer relevant API documentation>

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

@@iif([success]='200','{BINDDROPDOWNLIST.<Object Name>.<Field Name>=[<Response Body Notation in Notification Template>]}','')

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.

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

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:

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: For an API delivery failure
iif([success] ='<error code>,'{SEND}','{RETRYANDSEND(<duration>,<retrycount>)}')
E.g. iif([success]= '500','{SEND}','{RETRYANDSEND(1,5)}')

For an SMS/Email delivery failure
iif([success] ='<error code>,'{SEND}','{RETRYANDSEND(<duration>,<retrycount>)}')
E.g. iif([success]= '-2','{SEND}','{RETRYANDSEND(1,5)}')

Notes:

The duration requires to be entered using integer numbers and the minimum value will be 0. The unit for the duration is hours. Once 0 has been entered as the duration, then the Retry Attempts will occur continuously.
If the user wants to send a failure notification if any failure occurs and would want to retry continuously 5 times before sending the notification, the notation should be configured as below:iif([success]>'-2','{RETRYANDSEND(0,5)}','')
If the user wants the retry attempts to occur in regular time intervals for any exception, the notation should be configures as below. The minimum time interval will be 1 hour.iif([success]='-2','{SEND}','{RETRYANDSEND(1,5)}')
If the user wants to configure delivery failure notifications for all exceptions to be sent out immediately then the notation is to be configured as below:iif([success]>'-2','{SEND}','')
If the user changes the number of retry attempts and the frequency during the process, then the system will consider the newly configured notation after the 2^nd retry attempt since after the 1^st attempt is made the 2^nd attempt will be queued. The number of retry attempts which the user enters the second time should exceed the already triggered number.
Example: If the user changes:
iif([success]>'-2','{RETRYANDSEND(1,5)}','') to
iif([success]>'-2','{RETRYANDSEND(24,4)}','') after the first retry attempt has been occurred, 2^nd retry attempt will occur 1 hour after the 1^st attempt and then only the system will change the retry attempts based on the change made. Therefore, the next retry attempt will occur 24 hours later to the 2^nd attempt. Even though the retry attempt mentions 4 it will trigger two attempts since 2 has been already being triggered due to the previous configuration.

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

Incident Settings – Notification Templates & Notifications

1. Notification Templates Settings

2. Notifications Settings

3. Trigger Criteria

3.1 Incident

3.2 Investigation

3.3 Action

3.4 Resolution

3.5 Close

3.6 Signoff

3.7 Risk

3.8 Submission

3.9 Custom

3.10 Incident Review

3.10.1 Notification Delivery Failure

3.10.2 Custom Trigger Criteria Configuration

4. Triggering Notifications based on Custom Date Fields

5. Notifying Parent Node Managers for an Incident Linked to a Hierarchy Node

5.1 Dropdown List based on API Calls

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