CAMMS is pleased to announce the April Feature Release for cammsincident.

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

    1. Trigger emails when incident actions are reassigned


You can now setup email notifications that are triggered when a responsible officer is assigned for an incident action, as well as each time that responsible officer is changed. 

  • A new trigger ‘Action assigned to user’ is available in the Email Notification area, which can be accessed via cammsrisk>Framework>Incident Settings when you select Action as the ‘Email Type’. 


 Image 1 : New email Trigger Criteria is introduced


Administrator users with access to this area will be able to set up this email trigger, upon making the rule active. This will trigger an email whenever the ‘Action Responsible Officer’ field in Action Object is changed. 


Note: This will trigger and send out emails at the first point of creating an incident action, when you assign and every subsequent time changes and updates are done within the system.

The rest of the functionalities will follow the same standard behaviour as any email trigger. 


2. Limit staff records populated in staff drop downs based on hierarchy linkages


Administrator users in cammsincident can now set up the staff lists to be limited in staff drop down fields, based on hierarchy linkages. 


You can limit the population of staff records in staff drop downs by choosing from the options below, which will help end-users further narrow down the list they search through when recording incidents and assigning staff.

  • All Staff
  • Staff linked to the incidents' linked organisation unit




Image 2 (a): Field configurations 


A new ‘Populate the staff list with’ configuration will be available for all incident administrator users for all staff fields within field configurations, which can be accessed via cammsrisk>Framework>Incident Settings>Object configurations for the staff fields below: 

  • cammsrisk>Framework>Incident settings>Object configurations>IncidentObject>IncidentResponsibleOfficer 
  • cammsrisk>Framework>Incident settings>Object configurations>ActionObject>ResponsibleOfficer 
  • cammsrisk>Framework>Incident settings>Object configurations>InvestigationObject>InvestigationPrimaryInvestigator 
  • cammsrisk>Framework>Incident settings>Object configurations>InvestigationObject>InvestigationSecondaryinvestigators 
  • cammsrisk>Framework>Incident settings>Object configurations>ResolutionObject>ResolvedBy
  • And any other custom staff fields configured with ‘field type’ selected as below,
  • Staff Dropdown   
  • Staff Dropdown with Details  
  • Staff Multi Select


The default value will be set as ‘All Staff’ for all fields and this will populate the entire staff list in the organisation, which is the currently existing behaviour.

If required, you can select ‘Staff linked to the incidents’ linked organisation hierarchy nodes’ and when the configuration is saved, this will filter the drop down list to populate staff linked to the same hierarchy node the incident is linked with. 


How do we determine the staff linkages to the organization hierarchy?

  • If your configuration is static hierarchy:

This will consider the staffs linkage with the organization hierarchy from cammsriks>Administration>Staff>Organisation Link area

  • If your configuration is flexible hierarchy:

This will consider the staffs linkage with the organization hierarchy from cammsriks>Administration>Staff>Assign Role area


How do we determine the incident’s linkage to the organization hierarchy?

  • All standard linkage creation options below are considered here, and any linkage created from the below options are considered.
  • From the linkage tab in the workflow 
  • From the linkage button (enabled via ‘Hierarchy Links’ field type in field configurations)
  • From the linkage button against a field (enabled via ‘Is Organizational link Enable’ tick box configuration in field configurations
  • From any of the standard drop down fields (enabled via below field types in field configuration area of the ‘Incident Details’ and other objects)
  • Incident Business Unit Grouping Dropdown 
  • Incident Business Unit Grouping multiselect  
  • Incident Business Unit Dropdown 
  • Incident Business Unit multi select  
  • Incident Service Profile Dropdown  
  • Incident Service Profile multi select  
  • Service Profile Dropdown  
  • Service Profile multi select  
  • Business Unit dropdown 
  • Business Unit grouping dropdown  
  • Business Unit grouping multi select 
  • Business Unit multi select  


  • With the above configuration, the staff list will be populated to show staff linked to the same node linked to the incident, providing you with a filtered staff list. 


Image 2 (b): A restricted staff list  



In the event an incident does not have a linkage with the organization hierarchy at the point of selecting a staff from a field configured as above, the staff list will show all staff following the default behavior. However, eventually when a linkage is created, the staff list will be filtered through based on the above logics. If prior to that a staff who does not belong to the filtered list has been selected, the system will retain that staff in the list linked to the incident record, until it is changed. Once it is changed and saved, the staff list will follow the filtered behavior. CAMMS recommendation is to always place the fields configured as above to be placed after the linkage creation field within the incident fo

When you enable this feature for an existing staff field, if the incident record does not have a hierarchy linkage at the point, the staff list will be filtered out only to show currently selected staff for the field, until a linkage is created. Once a linkage is available, the list will behave as above. 

If you are using the miscellaneous setting 'Default Incident Responsible Authority for Confidential Incidents' combined with the above feature, there is a known issue where the staff field reverts back to showing all staff (regardless of the restricted configuration) only at the moment you mark a confidential incident as non-confidential. This is a known issue and will be fixed in an upcoming sprint. 

Coming up soon:

We are hoping to provide more options to restrict the staff list as below, which will be announced in the future when they are released via sprints;

  1. Reporting officers of the hierarchy nodes the incident is linked with
  2. User Roles to populate only the staff assigned with the selected user roles
  3. Individual Staff names where you can select the names that show in the drop down

3. Improve Incident Category drop down field 

As communicated in the February sprint, we have progressively carried out improvements to the new feature introduced to have a hierarchical structure for the incident category and as a result have improved the Incident category field for the end user in the incident to reflect the same hierarchical tree sense when selecting the category. This will help the end user to have a sense of what they are searching for in the drop down with the ability to search through the tree structure through the parent category to other subsequent child categories at any level to find what they are looking for easily. 

This will be applied to the Incident category field in the incident workflow, register filter (if configured) and any standard report filter for incident category  as well. 

For users with multiple category levels, the Incident Category field will appear as below in the incident details page. 



 Image 3 (a): Incident Category drop down for hierarchical set up

For users with only one category level (as per the default standard behavior), the Incident category field in the details page and the filter in the registers will appear as below.

Image 3 (b): Incident Category drop down for non- hierarchical set up

Note: This feature will only be available after the Maintenance Release on 28th April 2020.