Feature Release Note | Camms.Risk Incident Management, September 2020
- amani imtiyas
Camms is pleased to announce the September Feature Release for Camms.Risk Incident Management.
This was released on 19th September and includes the following new features and enhancements to improve your user experience within the system.
1. Introducing auto-save for your data |
You now have an auto-save feature, where incident data will be saved in a pre-defined frequency to prevent data loss due to interruptions. This prevents the end-user from the need to manually save information, in the expectation of an event of an application crash or due to human errors such as accidentally closing the browser window.
How to do the configurations?
A new ‘Auto Save Frequency setting has been introduced within ‘Miscellaneous Settings’ (accessed via Camms.Incident > Mega Menu > Incident Settings > Miscellaneous Settings).
To activate the auto-save feature a numeric value needs to be inserted within the numeric box which will determine the frequency in minutes.
The minimum auto-save frequency is 5 minutes. Keeping it blank would turn off the auto save feature.
Decimals, alphabets and characters cannot be entered.
How will it work?
The auto-save will run in the background for the object the user is currently in, and will display a message as ‘Saving’ when it happens. The user can continue to work on the application without any disruption to on-going work. The data will be saved up to the point the auto-save happened.
The mandatory validations will not be validated at the time of auto-save.
The user will not be able to do a manual save at the time the auto-save is happening, but could do so at any other given time.
At the time of an incident creation, if the auto-save happens the incident will get saved as a ‘Draft’ and will appear in the register as a ‘Draft’ for the incident creator only.
Note: The incident will be created and saved as a ‘Draft’ irrespective of the miscellaneous setting ‘Disable draft functionality in Incident Details’ being ticked.
At the time of an incident action creation, the action will get saved as a ‘Draft’ and will appear in the action register for the action creator only.
Note: The incident will be created and saved as a ‘Draft’ irrespective of the ‘Enable Approval’ setting being ticked.
The auto-save will run and save information only if the user has done any changes to the record between the frequency cycles.
The auto-saved information will be updated in incident history.
Where will it not work?
The feature will not work in the below mentioned objects
Linkage object
Document object
My Quick Update
Incident Portal
Will emails get triggered on auto-save?
Emails can be configured to trigger on auto-save when the trigger criteria is fulfilled. A new dropdown named as ‘Trigger Type’ has been introduced in the Notification configuration screen for most notification types and its trigger criteria
This will include the options of ‘On Save’ and ‘On Auto-Save’ as the trigger types
The ‘On Save’ option will be the default, and will trigger emails only on the manual save of incident details. The ‘On Auto-Save’ option will trigger emails when changes are saved on Auto-Save
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. This is also applicable for actions which are in ‘Draft’ state
2. Filter staff lists based on user role |
As an extension to the feature for staff list fields released in our April 2020 sprint, administrator users in Camms.Incident now have the ability to set up staff lists in staff dropdown fields to be limited, based on the assigned user roles.
You can already 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 to staff.
All Internal Staff
Staff linked to the incidents' linked organisation hierarchy nodes
Restrict to internal staff within parent node of the Incident Creator’s link
Portal Staff
The existing configuration ‘Populate the staff list with’, available for all incident administrator users on all staff fields within field configurations, which can be accessed via Camms.Service>Framework>Incident Settings>Object Configurations, will now have an added feature as below.
User Roles: When selected another drop down will appear beneath the field listing all user roles available in Camms.Risk>Framework>Incident Settings>User Roles area.
The user will be able to select one/many user roles from the list and any staff who is directly or indirectly assigned with one or all of these user roles will be listed in the staff drop downs within the incident form.
This new configuration can be used in combination with other options available above for the staff list population feature as well and a union of all combinations will filter out the staff to be shown in the staff lists.
Rest of the feature behaviour is as it is at the moment.
Important Note:
When this feature is used for the Standard Incident Responsible Officer field and if the below settings are used in the database for the client from under Camms.Risk>Framework>Incident Settings>Miscellaneous Settings, the below behaviours can be observed. Hence it is important to have consistent configurations for the staff fields.
If the above setting is enabled and used along with the feature above, the selections made from the new feature ‘Populate the staff list with’ configuration will be taken in to consideration.
If the above setting is enabled and used along with the feature above, the selections made from the new feature ‘Populate the staff list with’ configuration will be NOT taken in to consideration and the final staff list will be picked from the setting above.
3. Ability to send out email notifications based on hierarchy linkages |
The email notifications are improved this sprint to give you ability to send out email notifications based on the hierarchy linkages the incidents has to help the records get the attention from it requires immediately based on the impact it may have.
Two new triggers are introduced as below with the mentioned functionality for the Notification type: ‘Incident’ accessed via Camms.Risk>Framework>Incident Settings>Notifications
i) Linking to Hierarchy nodes
When this trigger is selected, notifications can be configured to be triggered based on the linkage’s incident records have with different hierarchy nodes.
The specific nodes for which the linkage should be considered and matched with to trigger the emails, can be selected and saved for the notification using the hierarchy search and type areas below;
The hierarchy search will give an option to carry out a text-based search for a particular hierarchy node, similar to the hierarchy search filter in your incident registers at the moment. If you wish to have a more hierarchical view for the node selection process, you can do so by selecting the hierarchy type and the linkages from the respective options above. Once the selections are made, you can save by selecting the recipients and other attributes to the notification following the existing behavior.
How does the trigger work?
Once your set up is done, the trigger will be satisfied, when an incident record linked to a hierarchy matching the exact hierarchy nodes you selected for the notification are found. The linkages can be made to the incident by the end user via the linkage tab or pop up or using the standard drop down options as well. The linkages selected for the notification should be the same selected for the incident as well here as the direct linkage to the linked node itself is considered here for the trigger.
What recipients can you use with this?
All snippets available at the notification set up area can be used as applicable for this trigger as well.
What snippets can you use with this?
All snippets available at ‘Notification Template’ area accessed via Camms.Service>Framework>Incident Settings>Notification Templates for the Notification type: Incident, can be used for this trigger.
Additionally, a new snippet [LinkedHierarchyNodes] available under the same area can be used together with this trigger, which when used will list all linkages the incident has with hierarchy nodes - grouped by the hierarchy type
ii) Linking to a hierarchy node considering rolled up linkages
When this trigger is selected, notifications can be configured to be triggered based on the linkage’s incident records has with different hierarchy nodes, but with the added feature of considering the rolled-up linkages.
The specific nodes for which the linkage should be considered and matched with to trigger the emails, can be selected and saved for the notification using the hierarchy search and type areas below:
The hierarchy search will provide an option to carry out a text-based search for a particular hierarchy node similar to the hierarchy search filter in your incident registers at the moment. If you wish to have a more hierarchical view for the node selection process, you can do so by selecting the hierarchy type and the linkages from the respective options above. Once the selections are made, you can save by selecting the recipients and other attributes to the notification following the existing behavior.
How does the trigger work?
Once your set up is done, the trigger will be satisfied when an incident record linked to a hierarchy matching the exact hierarchy nodes you selected or rolling up to that level for the notification are found. The linkages can be made to the incident by the end user via the linkage tab or pop up or using the standard dropdown options as well. The linkages selected for the notification should be either same selected for the incident or rolling up to the level selected for the notification as both the direct linkage and rolled up to the linked node area considered here for the trigger.
For Example: Consider a hierarchy path (top to bottom as below):
Let’s assume Incident A is linked to the level 3 node in the hierarchy which is ‘Libraries’ and Incident B is linked to the level 2 node ‘Community Facilities’
If for the notification, from the hierarchy field, a level 1 node (Community and Culture) is selected, this trigger will consider both Incident A and B for the notification because both those incidents roll up to the level 1 which was selected for the trigger.
Therefore, If an Incident C was linked to the node ‘Chapel Off Chapel’ it will also be considered but an Incident D linked to ‘EAT Economic Development…’ will NOT be considered
What recipients can you use with this?
All snippets available at the notification set up area can be used as applicable for this trigger as well.
Additionally, a new recipient ‘Unit Manager of the linked hierarchy node of the notification and below’ is also introduced for this trigger which when used will send out emails to all unit managers for the hierarchy node the notification is linked with and below.
To explain more using the above example,
In a scenario where the notification was linked to level 1 node ‘Community and Culture’ with a new incident created linked to level 3 node ‘Libraries’, if there are responsible officers/unit managers assigned to the respective hierarchy nodes, the notifications will be sent out to the managers of units ‘Level 1 node – Community and culture’, ‘Level 2 node -Community Facilities’ and ‘Level 3 node – Libraries’. If there are mode child nodes below ‘Libraries’, they will be sent out for them as well.
What snippets can you use with this?
All snippets available at ‘Notification Template’ area accessed via Camms.Service>Framework>Incident Settings>Notification Templates for the Notification type: Incident can be used for this trigger.
Additionally, a new snippet [LinkedHierarchyNodes] available under the same area can be used together with this trigger which when used will list all linkages the incident has with hierarchy nodes - grouped by the hierarchy type.
4. Review process for incidents |
A new review process is now introduced which can be used to carry out scheduled reviews for incidents
How to do the configurations?
A new standard object ‘Review’ is introduced to the ‘Object Configurations’ area accessed via Camms.Service>Framework>incident Settings area which can be enabled for this purpose.
There will be the below standard fields available with the mentioned functionality but rest of the behavior would follow the standard object behavior providing similar capabilities such as adding/editing and deleting custom and standard fields, determining the field labels/positions and whether/not they are mandatory etc.
Review Frequency: will show all frequency options created under ‘Frequency’ area accessed via Camms.Service>Framework>Incident Settings in the order. This will determine the next review date for the incident based on the below logics. More details below.
Last Reviewed By: The name and the position of the staff who completed a review last.
Last reviewed Date: The data on which the above staff completed a review.
Next Review Date: The next review date for the incident. This would be set up based on a calculation [Last Review Date + Period of days defined by the Frequency].
Review Comment: Any comments added while doing and completing the review
Review Status: The status of the review. This will be shown as Overdue or Upcoming based on the below logics.
Overdue – If the next review date has passed the current system date and the review is not still ‘Complete’ this will be shown as Overdue
Upcoming – If the next review date is either falling before or on the same date as the current system date, this will be shown as ‘Upcoming’
Complete Review: The review details above can be updated many times as required and saved using the save icon for the page, but a review is considered as completed only when the ‘Complete Review’ button is clicked. Only doing so will update the Last review date/Last reviewed By and Next review date fields as per the above logics and the incident will be considered as reviewed, changing the status to ‘Upcoming’ .
How to set up the frequency values?
For a user with the necessary permissions given for a user role from User Roles are accessed via Camms.Service>Framework>Incident Settings>User Roles>Standard, an extra configuration ‘Review Frequency’ will be available on the left menu under Incident Setting