Camms.Risk Incident Management - May 2024
Camms is pleased to bring you the Quarterly Product Update Notification for the Camms.Risk Incident Capability
This quarter we've got exciting enhancements to improve your user experience within the system, which will be available in your Test environment on 29 April 2024 and will be available in your Live environment on 20th May 2024.
1. Introduction of Conditional fields in Incident workflows [Phase 2] |
---|
This enhancement will provide users with the ability to make fields mandatory or non-mandatory in selected workflows based on specified conditions. These conditions can be based on values of other fields, both during and after incident creation.
How do you configure this?
Incident Administrators can now mark a field as a conditional mandatory or Non-Mandatory field through the 'Is Conditional Field' > Mandatory/ Non-Mandatory checkbox in Incident Settings -> Object Configuration -> [Object] -> Field Configuration Details.
Fields will be displayed in the 'Field Value Configuration' area based on the Conditional Mode setting options 'Mandatory,' and 'Non-Mandatory’.
Incident Administrators can define conditions to make mandatory or non-mandatory a field based on values of other fields during incident creation as well as after the incident creation from field value configuration area in Incident Settings -> Field Value Configuration.
How does this work?
Incident Users can experience conditional Mandatory and Non-Mandatory fields based on given values in other fields. Fields will become Mandatory or Non-mandatory 'on change' in the same object as well as after the relevant object is successfully saved if it is in different objects when the given condition is satisfied. Conditions can be altered, and fields can be filled based on the sequence and conditions.
Before Condition is satisfied (Severity field shown not Mandatory)
After Condition is satisfied (Severity field shown Mandatory)
Note: Incident Users can now experience conditional Show/Hide and Mandatory/Non-Mandatory fields in Incident Action Object as well. But conditional fields in the Action object will work only for conditions defined based on fields in the same object.
2. Enhancement to the signoff feature by introducing Sequential and Concurrent signoff (Phase 1) |
---|
This enhancement will introduce concurrent and sequential sign-off processes to the Camms Incident workflows.
How do you configure this?
Incident administrators can now enable newly introduced 'Concurrent' and 'Sequential' signoff options via Incident Settings -> Object Configuration -> [Sign off Enabled Object] -> Object Configuration Details.
Incident administrators can now chose either ‘At least one approval needed’ or ‘All approvals needed’ for Concurrent Sign off option.
By default ‘Concurrent’ and ‘At least one approval needed’ will show selected and user can change the configurations as required.
Incident administrators can now enable newly introduced ‘Sync Selected Values to Signoff Authority by Default’ setting via Incident Settings -> Object Configuration -> [Object] -> Field Configuration settings to all fields with field type ‘Staff Dropdown’ and ‘Staff Multi Select’
Incident Administrators can give newly introduced standard permission ‘Standard Incident Signoff Delegated Approver permission’ to users via Incident Settings -> User Roles.
Incident Administrators will be able to select both Type and Object when configuring notifications for 'Sign Off' type notifications via Incident Settings -> Notifications
Incident administrators will be able to utilize reassign staff responsibilities page to reassign ‘Incident Signoff Authority’ related responsibilities.
How does this work?
When ‘Enable Sign Off’ is ticked for an object, it will expose new options for Sequential and Concurrent Sign Offs as radio button selection option.
It is quite flexible to configure a sign off type per object. If Sequential sign off is selected, then the sign-offs will follow a sequential approach, alternatively, if Concurrent sign off is selected the system will expose two new options for concurrent sign off as ‘At least one approval needed’ or ‘All approvals needed’.
If the ‘Sync Selected Values to Signoff Authority by Default’ setting is enabled for a ‘Staff Dropdown’ or ‘Staff Multi Select’ type field, then selected values of that field will be synced to Sign off Authority field as shown below.
Once the Sign Off is submitted, users will be able to approve, reject or reverse the Sign off from both the respective object where the sign off is configured and My quick update.
Incident users will be able to receive email notifications when a signoff is submitted, rejected and approved.
Note: MOC Signoff Enhancement (Phase 1) is just around the corner and will be available from the Demo Release on May 10th, 2024. Please note that there is an identified issue when Signoff is submitted for existing incidents, the record is shown to be submitted again. This will be fixed by next week before the live release.
3. Introduce the snippet ‘[LinkedHierarchyNodes]’ to show when the Notification Type is ‘Risk’. |
---|
This enhancement will Introduce the '[LinkedHierarchyNodes]' snippet to notification templates in Camms Incident to show when the Notification Type is 'Risk.
How do you configure this?
Incident Administrators will be able to utilize newly introduced [LinkedHierarchyNodes] snippet from the variable dropdown in Incident Settings -> Notification Templates when the notification type is ‘Risk’ as shown below.
How does this work?
Incident Users will be able to receive notifications configured with the newly introduced [LinkedHierarchyNodes] snippet for notification type “Risk”, based on the notification criteria and notification template. Behavior of the above snippet will be the same as the snippets with the same name when the notification type is ‘Incident’.
4. Remove Edit and Delete Buttons in custom tables based on permissions |
---|
This enhancement will allow users to edit and delete custom table records in Camms Incident based on two separate permissions.
How do you configure this?
Incident Administrators can allow users to edit and delete custom table records in Incident workflows now for any object except document, linkage, and Task objects through the newly introduced ‘Edit Custom Table Record’ and ‘Delete Custom Table Record’ Permissions in Incident Settings -> User Roles -> [User Role] -> [Objects] as shown below.
How does this work?
Incident Users will be able to see the “Edit” button against custom table records and will be able to edit custom table records in a particular object, if the ‘Edit Custom Table Record’ permission and 'Edit' permission are given to that user for the selected object.
Incident Users will be able to see the “Delete” button against custom table records and will be able to delete custom table records in a particular object, if the ‘Delete Custom Table Record’ permission and 'Edit' permission are given to that user for the selected object.
Incident Users will be able to see both "Delete" and "Edit" buttons in custom tables and will be able to delete and edit custom table records in a particular object, if both permissions are given to that user for the selected object.
5. Introduce Newly added Action Fields to Incident Action Register |
---|
This enhancement will introduce newly added Action review and Action effectiveness related fields to the Incident Action Register and enable users to filter action records by these newly added fields.
How do you configure this?
Incident Administrators will be able to make visible all the newly introduced Action Details, Action Review and Action Review Effectiveness related fields via Incident Settings -> Register Configuration -> ActionObject (All Standard and Custom Action Objects) > Visible as shown below.
Newly Introduced Action Details, Action Review and Action Review Effectiveness related fields can be made searchable via Incident Settings -> Register Configuration -> ActionObject (All Standard and Custom Action Objects) -> Searchable as shown below.
How does this work?
Incident Users will be able to see newly introduced Action Details, Action Review and Action Review Effectiveness related fields in the Incident Action Register if the relevant fields are made visible.
Incident Users will be able to filter Incident Action Records by newly introduced Action Details, Action Review and Action Review Effectiveness related fields in the Incident Action Register if the relevant fields are made searchable.
6. Enhanced Incident Action Bubble in My Quick Update |
---|
This enhancement introduces significant improvements to both user experience and system performance, enriched with more comprehensive information and filtering options for more refined updates in the Incident Action bubble in My Quick Update.
How do you configure this?
Incident Administrators will be able to display newly introduced Incident Action related fields in the My Quick Update page via Incident Settings -> Object Configuration -> Action Object -> Field Configuration Details -> [Show in My Quick Update].
How does this work?
Incident Action owners, reviewers and effectiveness reviewers will be able to see and update their records within the Incident Action widget in quick update. The new Incident action widget features a number of additions.
What’s new?
Enhanced Grid Layout
The grid now includes additional columns, providing a more comprehensive view of information. Below are the newly added columns that can be configured to show in the grid within Incident Action widget.
Incident Name
Incident Type
Action Priority
Action End Date
Action Review Due Date
Action Review Effectiveness Due Date
Action Review Status
Action Effectiveness Review Status
Note: Incident Name and Type columns are configured by default to show in the grid; these columns cannot be configured to hide from the grid.
The first column (Incident Action Name) and the last column (More Details button) are frozen to remain in view as you scroll, facilitating easier updates.
A new slider control is introduced to update the progress allowing swift adjustments. The color of the slider changes based on the performance as the progress is updated.
Graphical indicators highlight overdue items for immediate attention.
Mandatory field and End Date validations are shown below the fields as the user updates each record.
Advanced Grouping Options
Users have the flexibility to group records by any column by dragging and dropping the column header to the topmost row of the grid.
Upon grouping by a column, the records will rearrange with the new grouping and the column will be hidden from grid; a chip will be shown with the column name in the topmost row of the grid. You can remove any grouping by clicking on the “x” icon in each chip in the topmost row of the grid.
The grid is grouped by Incident Type and Incident Name respectively by default.
Sorting Options
Users have the flexibility to sort records by any column in both ascending and descending order.
By default records are sorted by Incident Type and Incident Name.
Filters
13 filters, a filter for each column have been introduced as listed below. For each column configured to show in the grid, the respective filter associated with the column appears in the filter panel.
Filter name | Field Type | How does the filter work? |
Incident Name | Textbox | You can filter by keywords of the incident tittle or incident ID. |
Incident Type | Multi-select Dropdown | All the incident types will be listed in the dropdown and you can filter by multiple incident types. |
User Role | Multi-select Dropdown | Incident action responsible officer, Incident action reviewer and Incident action effectiveness reviewer will be listed in the dropdown and you can filter by multiple user roles. |
Action Name Filter | Textbox | You can filter by keywords of the incident action tittle. |
Action Status Filter | Multi-select Dropdown | All the incident action statuses will be listed in the dropdown, and you can filter by multiple statuses. |
Percent Completed Filter | Numeric stepper | You can filter by the percentage completed. |
Comment Filter | Textbox | You can filter by keywords of the incident action comment. |
Action Priority Filter | Multi-select Dropdown | All the incident action priorities will be listed in the dropdown, and you can filter by multiple priorities. |
Action Due Date (End Date) Filter | Date Filter | You can filter by a date range. Incident actions will be shown in the search results if the end date falls between the selected date range. (Start and End dates in the filter are inclusive) |
Action Review Status Filter | Multi-select Dropdown | All the incident action review statuses will be listed in the dropdown, and you can filter by multiple statuses. |
Action Review Due Date Filter | Date Filter | You can filter by a date range. Incident actions will be shown in the search results if the Action Review Due Date falls between the selected date range. (Start and End dates in the filter are inclusive) |
Action Effectiveness Review Status Filter | Multi-select Dropdown | All the incident action effectiveness review statuses will be listed in the dropdown, and you can filter by multiple statuses. |
Action Review Effectiveness Due Date Filter | Date Filter | You can filter by a date range. Incident actions will be shown in the search results if the Action Review Effectiveness Due Date falls between the selected date range. (Start and End dates in the filter are inclusive) |
Incident action grid is filtered by all the action statuses (Not Started, In Progress, Differed, Ongoing and Completed) By default.
All the active filters are shown in the “Filtered by:” panel as; chips which provides more visibility of the filters set at a glance. Users can easily remove any applied filter by clicking on 'x' icon on the chip. Incident action status filter chips will be shown in the “Filtered by:” panel by default.
7. Archival Feature for Incident (Phase 1) |
---|
This enhancement will introduce the ability of Archiving closed incident records.
How do you configure this?
Incident Administrators can now make newly introduced ‘IncidentArchiveStatus’ standard field visible and editable in all standard and custom Close Objects via Incident Settings -> Object Configuration -> [Close Object] -> [IncidentArchiveStatus field] -> Field Configuration Details.
Incident Administrators can now allow users to archive Incident records by giving newly introduced ‘Edit Archive’ permission in all standard and custom close objects via Incident Settings -> User roles.
Newly Introduced ‘Archive’ field can be made searchable via Incident Settings -> Register Configuration -> Close Object (All Standard and Custom Close Objects) -> Searchable as shown below.
Incident Administrators can now turn on automatic archival feature for incident records by defining number of days which will be used to automatically archive incident records that are closed and older than the defined number of days for ‘Automatically Archive Incident Records thar are closed and older than in days’ field in Incident Settings -> Miscellaneous settings.
How does this work?
Incident Users can now Archive Incident records by ticking newly introduced ‘IncidentArchiveStatus’ checkbox field in standard and custom Close objects.
Incident Users will be able to filter Archived Incident Records using ‘IncidentArchiveStatus ‘ field in the filter area of Incident registers. By Default, Incident Registers will show Archive 'False' records.
8. Solution to disabled fields getting overridden |
---|
This enhancement will avoid disabled fields which receive values from other fields from getting overridden by user manually saving the object with the disabled fields.
How does this work?
Below type of fields that are not Editable will be excluded from getting updated upon clicking “Save” by the Incident user.
Synchronized disabled fields.
Field Mapped disabled fields.
Disabled Fields which are getting updated from an API.