Camms is pleased to announce the August Feature Release for Incident Capabilities in Camms.Risk.

This was released on 15th August 2020 and includes the following new features and enhancements to improve your user experience within the system. 

1. Notification log for Incident 

An email notification log is now introduced within each incident, showing all notifications sent out for it, along with details such as time, subject and recipients.

How do you configure this?

Image 1: New configuration is available   

• When the you access the ‘IncidentDetails’ object for your workflow via Cammsrisk>Framework>Incident Settings>Object Configuration, a new tick box configuration ‘Show Notifications Log’ is now available.  
• This will be un-ticked by default but can be ticked and enabled upon saving the object configurations. 
• When this is enabled, within each incident, all notifications sent out for that particular record will be shown.

The end user view:

• For any user with view/edit permissions for incident records, a notification icon will be shown when accessing the record.

Image 2: Notification icon  

• Upon clicking in the icon, a pop up will display all notifications which has been sent out for the record with the below details. 

1. Notification Method: The type of the notification whether that is an Email/SMS or both.
2. Notification Type: The type of the notification based on the ‘Notification’ set up via Cammsrisk>Framework>Incident settings. 
3. Trigger Criteria: The trigger criteria of the notification based on the ‘Notification’ set up via Cammsrisk>Framework>Incident settings.
4. Subject: The subject of the ‘Notification Template’ selected for the notification which was sent out.
5. Notification Recipient: The recipients to whom the notification was sent out to. When there are multiple users, they will be shown separated by commas. 
6. Body: The content of the ‘Notification Template’ selected for the notification which was sent out. This will be accessible via the downward arrow icon available against each record on the log.
7. Timestamp: The date and time displaying when the notification was sent out. 

2. Usability Improvements

Improvements to the 'category hierarchy' feature

• You can now restrict allowing the full hierarchy of categories to be selectable in the end user view and show only the lowest child nodes if that is what is preferred in your organisation. This can be used in a business setting where incidents are linked to the very bottom categories in the hierarchy. 
• As an admin user, a new setting ‘Hide parent level node tick boxes in category drop down’ is available in ‘Miscellaneous Settings’ area accessed via Cammsrisk>Framework>Incident Settings 
• This will be un-ticked by default to have the current behavior as the standard but when enabled and saved, the parent levels will not be selectable. 

The standard way of showing this:

Image 3: Standard view

How this will be shown with the setting (note that the parent level check boxes are not shown and only the check boxes for child nodes are shown): 

Image 4: View with the setting on  

3. Improvements to the ‘timer’ in the Task feature

• Released on a previous sprint, we have further improved the task feature to have the automatic timer to start from the moment the task is added to the incident (either via the category/from within the incident) without it having the incident record is saved. This will be a standard behavior and hence will be applicable to clients who has the feature enabled.

Image 5: Time frame feature in the task grid  

4. Options for setting up confidential incidents’ emails

Incidents email notifications can now be withheld from any of the intended recipients, if the incident is tagged as 'confidential' and the recipient doesn't have confidential permission.

• As an administrator user, you are now able to restrict any user (whether they are assigned to records or not) from being able to view confidential records if they do not have permission assigned to view them. (For this feature explanation, any user who has been assigned to a record via any standard role will be referred to as the ‘Assigned user’)
• The standard behavior of the Incident Capability so far allowed any user with direct responsibility to a record via a standard role (Incident Responsible Officer, Incident Action Responsible Officer, Investigation Responsible Officer, Incident Creator and Incident Root Cause Analysis Responsible Officer) to view any records assigned to them even if they were marked as confidential. 
• This behavior has now been improved to provide further flexibility for you to determine who should have view access to confidential records within the application and hence emails across the solution regardless of their standard roles. 
• The existing permission ‘Display confidential records in registers’ available in User Roles accessed via cammsrisk>Framework>Incident Settings under standard permissions will now be applied for any user role governing the standard roles. 

Image 6: Permission to view confidential incidents   

• For any standard role available in the application (Incident Responsible Officer, Incident Action Responsible Officer, Investigation Responsible Officer, Incident Creator and Incident Root Cause Analysis Responsible Officer), the permissions are assigned via user roles linked to them (accessed via Cammsrisk>Framework>Incident Settings>User roles).
• With this feature release, the permissions for even the standard roles to view confidential incidents will be governed by the permissions given within the user roles and not via a standard business logic as previously existed for assigned users.

Image 7: Standard User Roles  

• As a default feature, for any user role linked under a standard role, the permission ‘Display confidential records in registers’ will be ticked and enabled thereby giving the permission to view confidential records assigned to them. However, ability is now available to un-tick the permission from the user roles to restrict even the assigned users being able to view records if marked confidential 
• Our recommended approach is to have a separate custom user role to govern permissions to view confidential records.

Impact to existing clients using the confidential feature:

• For the user roles which are added under the Standard User Roles are assigned to other users (who do not inherit the standard user role permissions), Camms. will be removing those user roles and replacing them with a custom user role with the exact same permissions.
• The new custom roles created will be named after the existing user role name follow by a prefix "-custom" (i.e. User Role Name - Custom")
  
• As per the above example in Image 3(b), the Incident Responsible Officer standard user role has two user roles, namely 'Compliance Breach Responsible Officer' and 'Incident Responsible Officer'. Both these user roles post release will have the 'Display confidential records in registers' automatically ticked. If the user role 'Compliance Breach Responsible Officer' is assigned to another user directly, that will be removed and be replaced with newly created role which will be named 'Compliance Breach Responsible Officer - Custom', which will include all its existing permissions.
• Therefore, for the clients who are using the current set up will have no impact for the behavior for the assigned users. The permission for all linked user roles for the standard roles will be ticked by default hence causing no impact to the BAU process. 

Note: If you wish to not let any direct assigned responsibilities to see records marked as confidential, the individual user roles under the standard role governing the behavior should be updated to have the permission disabled. 

Impact on emails:

• System emails at the point of trigger will cross check the incident record for which the email is being sent against the recipients to whom its being sent and will only be fired if the recipient has the necessary permissions to view that record in the application 
• The permission structure would follow the same explained above to govern this behavior 
• If the recipient has no permissions , even though they are selected, they will still not receive any emails from the system
   

5. Options for Auto-populating the severity and priority based on category

When an incident category is selected, you can now have the severity and priority for the incident to be automatically selected as per the pre-set configurations of your preference.

• As an administrator, options to select a Severity/Priority against each incident category will be available in the ‘Category’ area accessed via Cammsrisk>Framework>Incident Settings. 
• These options will only be available if the Severity/Priority fields are enabled for any workflow via the ‘Object configurations’ in Cammsrisk>Framework>Incident Settings area 

Image 8: Severity/Priority selection for Categories    

• For each category, there will be 2 drop down fields for Severity/Priority listing the configured list values and appropriate values can be selected for the category and saved. 
• When this is done, for the end user, when assigning a category to an incident record, the Severity/Priority values will b auto populated based on what was configured for that category.
• However, this can be changed for the incident and saved as well. 

6. Customize action objects for different workflows

You can now create custom action objects, to be customized with unique fields to be specific to each workflow. 

• As an administrator, you will now be able to have customized action objects based on the standard ‘ActionObject’ accessed through the ‘Object configurations’ via Cammsrisk>Framework>Incident Settings. 
• When you are creating a new object via the ‘Add’ option, you will be able to choose the Workflow Element Type as ‘Action’ to make the new object be based on  the standard action object.

Image 9: Custom Action object creation    

Upon saving after entering the other required details, a standard template of the existing actions object with the standard fields will be populated in the field configuration area but with the ability to add new/edit existing or delete fields and customize as needed. 

• In this manner, any number of duplicate but custom action objects can be created with unique fields for the object and hence can be used in different workflows.
• The rest of the object behavior would be similar to the standard action object and actions created from these custom versions will be available in the quick update, incident actions register, reports, dashboard and all other areas following the standard behavior 
• This will enable to have different and unique action objects with unique configurations per workflow as opposed to having one common standard action object with common fields across all workflows.

Note: The action object, both standard or custom can only be used once within one workflow 

7. Option for staff lists to include external portal users

A new staff field configuration is available now with the option to show 'portal staff'. 

• As an administrator user, via the field configurations for any field type listing staff names, a new option ‘Portal Staff' is now available under the ‘Populate the staff list with’ configuration accessed via Cammsrisk>Framework>Incident Settings>Object configurations>Field configurations.

Image 10: ‘Portal Staff’ option  

• This option would refer to all users who are tagged as ‘Portal Users’ which represents staff created through the Incident portal. When this option is selected, it will list all portal user staff in the staff drop down for which it was configured for. 
• In addition to the above, the existing options are renamed as below to help users distinguish between internal and external users as well.
  • All internal staff 
  • Internal staff linked to the incidents’ linked organisation hierarchy nodes 
  • Restrict to internal staff within parent node of the Incident Creator's link