Camms is pleased to bring you the Quarterly Product Release Notification for Camms.Risk Incident Management.

This quarter we've got a number of exciting new features and enhancements to improve your user experience within the system, which will be available in your Test environment on 19th June 2021 and will be available in your Live instance on 3rd July 2021.


Quick Tip: If any pages don't appear properly on the first load, try pressing Ctrl + F5 on your keyboard to refresh the page and clear your cache.

1. Revamped user interface and experience

Our newest version of Camms.Risk v4.0, will feature a completely revamped and modernised user interface designed with simplicity and clarity in mind. Camms.Risk v4.0 delivers a new user experience and refines many aspects of a user’s day-to-day interaction with the solution. It provides clarity on what your users should be doing, where they can go next and makes it easier to locate items within the user interface. As we continue to build out this next-generation platform, this redesign also sets the stage for further improvements in our upcoming releases.

Sycle Note: The revamped user interface changes will apply only to standalone customers that use Camms.Risk Incident. Customers that use SYCLE will get all of these updates at a later stage. 

The revamped items that will be available for our SYCLE customers will be noted within each of the items.

Some of the user interface improvements include:

1.1 Updated user interface theme

We have introduced a modernised colour palette, new fonts, refined icons, table/grid colour, and formatting options.

What has changed?

  • Change in Camms product logo
  • New clearer fonts and icons
  • Clearer blue and white background
  • Button changes with both icon and text, making it easier to identify

Figure 1.1: New login screen


1.2 Page header

The page header section has been simplified, reducing the space taken up by Camms.Risk logo and providing more prominence to your organisation’s title or logo.

What has changed?

  • Change in Camms product logo, making it shorter, providing more prominence to your organisation name/logo
  • Removed Home icon, and the homepage can instead be accessed by clicking on the product logo
  • Name and Designation text moved to a dedicated panel accessed by clicking on your profile image 
  • Profile menu with a clearer white background and icons




Figure 1.2.1: Staff card and menu

Figure 1.2.2: Page header

1.3 Quick access navigation panel

The quick access left-hand navigation panel has a revamped new look, along with completely new icons that make it easier to distinguish different registers at a glance.

Sycle Note: The revamped quick access navigation panel will be available for our SYCLE customers as well.

What has changed?

  • Change in navigation icons, designed to provide more clarity on its function and making them more distinct from each other, making it easier to identify the different registers
  • Background colour of left-hand navigation panel
  • Directly access a specific register through a new panel (replacing the menu that appeared previously)

Figure 1.3:  Quick access navigation panel 


1.4 Page tab improvements

Page tabs will now be frozen when scrolling down, making it easy for you to know where you are and to navigate to other tabs.

What has changed?

  • Background colour of tabs to a clearer white
  • Prominent blue underline below tabs clearly indicating which tab you are on
    Sycle Note: SYCLE customers will observe this revamp in the Dashboard page.
  • Tabs stay frozen on top while scrolling down the page

1.5 Page layout improvements

Placement of fields and field labels have been adjusted to reduce gaps and optimise layout to provide an improved visual flow on each page.

What has changed?

  • Gap between fields and field labels reduced
    Sycle Note: SYCLE customers will observe this revamp.
  • Multi-selections changed to a blue square instead of a circular shape

1.6 Clarity for function buttons

Common function icon buttons at the top of a page are now converted into buttons with text and an icon, providing users with instant clarity on the purpose of each button.

Sycle Note: SYCLE customers will observe this revamp in the Dashboard page.

What has changed?

  • Icons made small and converted into buttons with a combination of text and an icon

Figure 1.4: Navigation, page layout, function buttons

1.7 Improved next/previous navigation

The next/previous buttons at the bottom of pages, especially in our Incident and Compliance workflows, are now equipped with better visual cues (including the name of the next tab) and they are anchored visually as a footer.

Sycle Note: The revamped next/previous navigation feature will be available for our SYCLE customers as well.

What has changed?

  • Next/Previous buttons changed to text in a footer section
  • The Next/Previous tab page name listed below the Next/Previous text with an < or > arrow as a link

Figure 1.5: Improved next/previous navigation 

1.8 Brief description on each settings page

A short description has been provided at the top of each Incident Setting page to give an idea of what each setting page does.

Sycle Note: Descriptions in the Setting pages will be available for our SYCLE customers as well, under the Framework menu.


1.9 Group header field as a collapsible panel

When a Group Header field is included in an incident workflow, in a standard or custom object (except for Actions, Linkage, Document), it will behave as a collapsible panel when clicked upon. By default the panel will be expanded.

Sycle Note: The group header field revamp will be available for our SYCLE customers as well.

Figure 1.6: Group header field as a collapsible panel

1.10 Change in custom tables

When adding records to a custom table, a popup will be displayed now. This is in response to customer feedback that the previous behaviour (where it opens as a panel at the bottom of the table), was at times confusing. Now both adding a new record or editing an existing record will both open in a popup window. The 'Add New' button's placement has been updated to make it clearer that it is part of the relevant custom table.

Sycle Note: This change in custom tables will be available for our SYCLE customers as well.

Figure 1.7.1: Custom table

Figure 1.7.2: Popup to add a record to a custom table

1.11 Improved pagination

An improvement to Incident and Action Registers have been introduced where you can select the number of items to be displayed per page, navigate to a page by clicking on a page number, arrows to move to first/next/previous/last pages, and key-in a page number to directly navigate to.

Sycle Note: This improvement in pagination will be available for our SYCLE customers as well.

The default number of records displayed can be changed via Camms.Risk Incident > Menu > Incident Settings > Miscellaneous Settings > [Records per page in incident register].

Figure 1.8: Pagination

1.12 Field configuration popup label changes

Under Object Configuration Settings, the labels in the Field Configuration Details popup has been updated to provide more clarity and convey its function.

Sycle Note: This improvement in Field Configuration Details popup will be available for our SYCLE customers as well.


1.13 Removal of the spell checker functionality in creation pages

The spell checker functionality in the incident type creation pages has now been removed.

Sycle Note: This change will be updated for our SYCLE customers as well.



2. Adding the incident code/title to the header area of an incident record

This feature will introduce a change in the header of an open incident record to display the Incident Code and Incident Title,

making it easier for you to follow which incident record is open when navigating the tabs.

Sycle Note: This modification will be available for our SYCLE customers as well.

Figure 2.1: Incident title in header 

How do you configure this?

  • An administrator can configure the Incident details page title by navigating to 'Camms.Risk Incident > Menu > Framework > Incident Settings > Incident Type > [Name of the Incident type]'.
  • The administrator may select either the ‘StandardIncidentText’ option or Incident Code and/or Incident Title options.
  • If the ‘StandardIncidentText’ option is selected, the display text configured for ‘StandardIncidentText’ in 'Camms.Risk Incident > Menu > Framework > Incident Settings > Display text >[Label Reference: StandardIncidentText]' will be displayed in the header area when any incident record is opened.
  • Alternatively, the administrator may select the Incident Code and Incident Title which will populate the relevant code snippets in the adjoining text box. These code snippets will populate the relevant records’ code and title respectively, in the incident record’s header area.
  • The administrator can configure the order in which the Incident Code and Incident Title should appear, add characters such as ‘-‘ or ‘ /’ or spaces, which will directly reflect in the Incident record’s title.

    Example:

    If the configuration for ‘Record details page title’ is [IncidentCode] – [IncidentTitle] in 'Camms.Risk Incident > Menu > Framework > Incident Settings > Incident Type > [Name of the Incident type]'.
    An Incident with an Incident code ‘INC32’ and Incident title ‘Complaint on Fraud’, will display 'INC32 – Complaint on Fraud’ in the header area of the incident record.

  • By default, the application will display the StandardIncidentText.

    Note: The Incident Code and Incident Title will appear in the Incident details page title dropdown, only if the visibility for the Incident Code and/or Incident Title has been set to ‘true’ in 'Camms.Risk Incident > Menu > Framework > Incident Settings > Object Configuration > Incident Object > [Field name: IncidentCode /IncidentTitle]'.

Figure 2.2: Incident title setup


3. Enhanced separation of incident types in the dashboard

With the enhanced separation of incident types, when multiple incident types (e.g. issues, opportunities, inspections) exists, this enhancement would ensure that dashboard widgets can be separated into individual incident register tabs, and not display all incidents types in one dashboard.

In the dashboard, previously you were able to view consolidated information of incidents in the Incident tab of the Dashboard, relating to all Incident types. However, this modification will let you view information of incident types linked to the incident registers, displayed as separate tabs within the Dashboard page.

Sycle Note: This modification will be available for our SYCLE customers as well.

How do you configure this?

  • An administrator can enable register-wise dashboards by ticking the introduced option ‘Show in Dashboard’ in each Register (except for the ActionObject register) (accessed via Camms.Risk Incident > Menu > Framework > Incident Settings > Register Configuration > [Register type]).

Figure 3.1: Show in dashboard setting for incident registers


Figure 3.2: Dashboard displaying incident registers

How does this work?

  • The template and behaviour of the displayed dashboards for the incident registers (where configured) will be identical to the previous Incident Dashboard template and behaviour.
    • All Filters – All existing filters will be displayed as is in the new segregated tabs.
      • The ‘Incident type’ filter will populate the incident types linked to the relevant register for filtering.
    • All 16 Charts/Widgets will be displayed for the respective incident register.
    • The Export option will function as it did previously.
    • The Refresh option will function as it did previously.
    • Settings – This area will display settings for each of the enabled Incident Register tabs in the dashboard.
  • If you want to hide the consolidated Incident Dashboard view, disable the setting ‘Show Incident Consolidate Dashboard’ checkbox (accessed via Camms.Risk Incident > Menu > Framework > Incident Settings > Miscellaneous Settings). This setting will be enabled by default, for all clients.

Figure 3.3: Show consolidated incident dashboard


4. Notifying users during Email/SMS delivery failures

You will now have the option to be notified when an Email/SMS is facing a delivery failure. This way, your IT teams can investigate the root cause of the failure and rectify where necessary. This includes the ability to specify the number of retry attempts as well as the duration between retries.

The following instances will trigger a failed notification:

  • When a user has entered an invalid email ID in the staff page
  • An issue in the Camms.Risk Incident Email Server
  • An SMTP server failure
  • SMS Gateway failed responses

Sycle Note: This modification will be available for our SYCLE customers as well.

How do you configure this?

4.1 Template Creation

  • A Notification Type named ‘Notification Delivery Failure’ will be available under Notification Templates (accessed via Camms.Risk Incident > Menu > Incident Settings > Notification Templates).
  • Select ‘NotificationDeliveryFailure’ from the Notification Type dropdown and tick the Notification Methods as ‘Email’ and ‘SMS’. The ‘Error Log’ snippet will be available to be selected from the Variables dropdown in the Email/SMS Body, when drafting the Email/SMS template.
  • The Error Log snippet will include the Error Log which was produced when the exception occurred.

4.2 Notification Creation

  • When ‘NotificationDeliveryFailure’ is selected as the Notification Type, when creating a notification (accessed via Camms.Risk Incident > Menu > Framework > Incident Settings), a new trigger criteria ‘Notify Upon Delivery Failure’ will be available.
  • When ‘Notify Upon Delivery Failure’ is selected as the trigger criteria, the ‘Custom Trigger Criteria Configurations’ editor will be displayed.
  • Notation for the retry attempts should be entered in the editor in the below form:

iif([success] ='<error code>,'{SEND}','{RETRY(<duration>,<retrycount>)}')

  • You can add external parties as recipients using the Additional Recipient/s field.
Notes: 
  • The <error code> for Email or SMS failed notifications will ONLY use the value -2 to identify a delivery failure.
  • The duration requires to be entered using integer numbers and the minimum value will be 0. The unit for the duration is hours. Once 0 has been entered as the duration, then the Retry Attempts will occur continuously.
  • If the user wants to send a failure notification if any failure occurs and would want to retry continuously 5 times before sending the notification, the notation should be configured as below:
    iif([success]>'-2','{RETRYANDSEND(0,5)}','') 

  • If the user wants the retry attempts to occur in regular time intervals for any exception, the notation should be configures as below. The minimum time interval will be 1 hour.
    iif([success]='-2','{SEND}','{RETRYANDSEND(1,5)}')If the user wants to configure delivery failure notifications for all exceptions to be sent out immediately then the notation is to be configured as below:
    iif([success]>'-2','{SEND}','')

  • If the user changes the number of retry attempts and the frequency during the process, then the system will consider the newly configured notation after the 2nd retry attempt since after the 1st attempt is made the 2nd attempt will be queued. The number of retry attempts which the user enters the second time should exceed the already triggered number.
    Example: If the user changes:
    iif([success]>'-2','{RETRYANDSEND(1,5)}','') to 
    iif([success]>'-2','{RETRYANDSEND(24,4)}','') after the first retry attempt has been occurred, 2nd retry attempt will occur 1 hour after the 1st attempt and then only the system will change the retry attempts based on the change made. Therefore, the next retry attempt will occur 24 hours later to the 2nd attempt. Even though the retry attempt mentions 4 it will trigger two attempts since 2 has been already being triggered due to the previous configuration.

Figure 4.1: Creating failure notifications


4.3 Linking the Failure Notification to an Email/SMS

  • A dropdown named ‘Failure Notification’ will be introduced in the created Email/SMS notifications.
  • You can link the failure notification using this dropdown.

Figure 4.2: Linking failure notifications


5. Improved navigation after an incident submission

With this improved navigation feature, you will now be redirected to the Register of the created Incident type, once an Incident Record is closed or submitted.

Sycle Note: This modification will be available for our SYCLE customers as well.

How does this work?

  • An incident record (accessed via Camms.Risk Incident > Menu > Incident Management > [click on required register type]), when closed or submitted, will be directed back to the respective register of the incident type.
  • For this modification to function as indicated above, the 'Configurable redirect for submit' dropdown value under Camms.Risk Incident > Menu > Incident Settings > Miscellaneous Settings, will be required to be set to '-- Please Select --', without any page selected under this dropdown.

Note: This improvement will be applied to both the Camms.Risk Incident and Camms.Risk Compliance modules.



6. An incident register will by default filter incidents for only configured incident types

With this update, the behaviour of the Incident Type filter within the Incident Register, is improved to limit the list of values in the filter, to only those incident types that are configured for the underlying register.

Sycle Note: This modification will be available for our SYCLE customers as well.

How do you configure this?

  •  Configure the default incident types to be displayed for an incident register via  Menu > Framework > Incident Settings > Register Configuration > [select Incident Register] > [under  Incident Types field add all relevant incident types to filter details from].

How does this work?

  • Within an Incident Register, you will see incident records filtered ONLY based on the configured incident types by default.
  • You can remove an added incident type and filter further. However, you cannot add any new incident types outside of the configured ones.
  • If you clear the Incident Register filter, it will still filter incidents ONLY based on the configured Incident Types, and not display all incident types in the register.