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.


List of items

1.  Introduction of Conditional fields in Incident workflows [Phase 2]

2. Enhancement to the signoff feature by introducing Sequential and Concurrent signoff

3. Introduce the snippet ‘[LinkedHierarchyNodes]’ to show when the Notification Type is ‘Risk’.

4. Remove Edit and Delete Buttons in custom tables based on permissions

5. Introduce Newly added Action Fields to Incident Action Register

6. Enhanced Incident Action widget in quick update

7. Archival Feature for Incident (Phase 1)

8. Solution to disabled fields getting overridden



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


Figure 1.1: Conditional Mode Settings in Field Configuration Details

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

 

Figure 1.2: Field Value Configuration area - Mandatory tab

 

 

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.


Figure 1.3: Mandatory Condition applied for Incident severity field


Before Condition is satisfied (Severity field shown not Mandatory)


Figure 1.4: Before value change on Priority field

 


After Condition is satisfied (Severity field shown Mandatory) 

Figure 1.5: After value change on Priority Field

 

 


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.

Figure 2.1: Concurrent and sequential Sign off options

  • 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’


Figure 2.2: Newly introduced 'sync selected values to Signoff Authority by Default' setting

  • Incident Administrators can give newly introduced standard permission ‘Standard Incident Signoff Delegated Approver permission’ to users via Incident Settings -> User Roles. 

Figure 2.3: Newly introduced 'Standard Incident Signoff Delegated Approver Permission'

  • Incident Administrators will be able to select both Type and Object when configuring notifications for 'Sign Off' type notifications via Incident Settings -> Notifications


Figure 2.4: Newly introduced Type and Object fields to notification configuration when Notification type is 'Sign Off'

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

Figure 2.5: Sign off authority defined

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


Figure 2.6: Sign off approval area in respective object



Figure 2.7: Sign off approval area in My Incident/Incident Sign Offs bubble in 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.


Figure 3.1: Notification Template with [LinkedHierarchyNodes] snippet


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


Figure 3.2: Notification received with linked hierarchy node snippet



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.


A screenshot of a computer 
Description automatically generated 

Figure 4.1: Edit Custom Table Record and Delete Custom Table Record permissions in User Roles

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.


Figure 4.2: Edit Custom Table Record button only displayed based on permission given

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

 


Figure 4.3: Both Edit Custom Table Record and Delete Custom Table Record permissions are given

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.


Figure 5.1: Newly added fields made visible and searchable


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.

Figure 5.2: Newly added fields in the Incident Action Register


Figure 5.3: Newly added fields in the filter of Incident Action Register



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

Figure 6.1: Show in My Quick Update setting in Field Configuration Details


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.


Figure 6.2: Newly introduced Incident Action Related fields and filter chips in the My Incident Actions Bubble in My Quick Update page


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

Note: Completed actions will be hidden for action responsible officer, Completed review actions will be hidden for action         reviewer and Completed effectiveness review actions will be hidden for action effectiveness reviewer although filters are         set to show completed items.



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


Figure 6.3: Newly introduced Incident Action Related fields in filter area of My Incident Actions Bubble in My Quick Update page.


Note: Enhanced Incident Action Bubble in My Quick Update is just around the corner and will be available from the Demo Release on May 10th, 2024.




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.

Figure 7.1:Visible and editable settings in 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.


Figure 7.2:Edit Archive permission in Close object

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


Figure 7.3:IncidentArchiveStatus field made searchable in register configurations

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


Figure 7.4:Archive Incident Records that are closed and older than (In Days, keep blank to turn off) setting


How does this work?

  • Incident Users can now Archive Incident records by ticking newly introduced ‘IncidentArchiveStatus’ checkbox field in standard and custom Close objects.

Figure 7.5:Archive field in Close object

 

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

Figure 7.6: IncidentArchiveStatus field in the filter area



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.