Open

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 20 January 2024 and will be available in your Live environment on 10 February 2024.  

Open

This modification allows us to configure conditional fields within Incident workflows, enabling the ‘Show’ and ‘Hide’ functionality of fields based on conditions defined based on values defined in other fields.

How do you configure this?

• Incident Administrators can now mark a field as a conditional field through the newly introduced 'Is Conditional Field' setting 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 'Show Field,' and 'Hide Field'.

• If Visible Setting is ticked, then Conditional Mode setting will show the selectable option 'Hide Field' and if Visible setting is unticked, then Conditional Mode setting will show the selectable  'Show Field'.

• A new standard permission, 'Field Value Configuration Settings,' has been introduced to all Incident user roles. This permission, when enabled, grants users access to the 'Field Value Configuration' setting, allowing them to configure field values based on conditions.

• Incident Administrators can now utilize the new 'Field Value Configuration' setting, located in the Incident Settings area between 'Object Configuration' and 'Register Configuration.' This setting allows for the configuration of field values based on conditions.

• Incident Administrators can now leverage the Variable dropdown to select dropdown fields for conditions, and the Operations dropdown to choose operators like AND, OR , (,), EQUAL, and NOT EQUAL. The Values dropdown will dynamically show the relevant values for the selected field, and the dropdown’s functionality will adapt based on the chosen conditions.

• Users can easily alter conditions by adding a new condition or an operation to the right side by selecting a specific condition or operation. This logic applies to both 'Hide Field' and 'Show Field' conditions.

• The 'Save' button logic has been implemented in the 'Field Value Configuration' area. Upon clicking 'Save,' a success message will be displayed for correctly configured conditions, and a warning message will appear for incorrect sequences, preventing the incorrect condition from being saved.

• Conditions will be displayed in a box format as well as in a read-only format similar to custom trigger criteria notifications, providing flexibility in viewing conditions.

How does this work?

• Incident Users can now experience conditional field visibility based on given values in other fields. Fields will be shown or hidden '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.

• Users can now track the history of fields and conditions given in the selected object using the 'History' button in the 'Field Value Configuration' area. The history includes additions, edits, and removals of conditions from a conditional field, providing a comprehensive overview.

• A new 'Dependency' button has been introduced below each field in the 'Field Value Configuration' area. Once a condition is entered and saved, the 'Dependency' button is enabled. Clicking the 'Dependency' button opens a traceability popup, allowing administrators to track dependencies, conditional statuses, and mandatory/non-mandatory statuses for the selected field.

Google ReCAPTCHA version 3 will be implemented in the Incident portal for the following areas:

• Save Progress, Save, Submit, and Resubmit Buttons

• Field wise Documents, Action, Links and Hierarchy Links Buttons

• Next and Previous Buttons

How does this work?

• When a user enters Incident Details and save or submit using the above buttons, the Google ReCAPTCHA version 3 Algorithm will verify the saved or submitted request using an automated score using the action of the user in the context of the web page without any additional interaction with the user. 

• If the verification is successful, then the Google ReCAPTCHA version 3 Algorithm will submit the data to the server and the server will submit data to the database and the database will store the data.

• If the verification is unsuccessful, an error message will be displayed requesting the user to redo the user action as shown below.

This modification will allow users to add an action priority for an action, review a completed action and also review for effectiveness a completed action. 

How do you configure this?

• Users will be able to configure predefined Action Priorities using the newly introduced action priority details page. Administrators can configure new action priorities via the ‘New’ button, following a process similar to configuring incident priorities. The newly introduced ‘Mandate Action Review’ setting will allow users to mandate an ‘Action Review’ for an Action based on the selected Action Priority.

• New Standard roles ‘Incident Action Creator’, ‘Incident Action Reviewer’, Action Effectiveness Reviewer’ and ‘Incident Signoff Authority’ will be introduced based on user defined for Action Object and Signoff authority field in any object. These standard roles can be assigned with other user roles, workflows, Object and Field similar to other standard roles.

• The newly introduced miscellaneous setting called ‘Show action signoff only when action status is completed’ can be configured by users who has permission and if ticked, Signoff section in the Action Object will show only if ‘Enable Signoff’ setting is ticked for the Action Object and when the Action Status is ‘Completed’.

• The newly introduced ‘Action Review Due Date Notification’ and ‘Action Review Effectiveness Due Date Notification’ for notification type ‘Action’ can be configured as similar to ‘Action Due Date’ trigger criteria configuration in Incident Settings -> Notifications. These notifications will be based on the newly introduced ‘Action Review Due Date’ and ‘Action Review Effectiveness Due Date’ fields.

• These newly introduced notifications can be configured based on Action Review Status and Action Review Effectiveness Status respectively as well.

• A new setting called ‘Populate the signoff Authority with’ will be introduced to Action Object configuration which can be used to limit which users are shown to select as a Signoff Authority. This setting will also allow users to select specific user roles as Signoff Authority.

• The newly introduced ‘Action Creator’, ‘Action Reviewer’ and ‘Action Effectiveness Reviewer’ can be added as notification recipients when the notification type is ‘Action’.

• New trigger criteria ‘Custom Trigger Criteria’ introduced to notifications when the notification type is ‘Action’ and users will be able to select the Action Object and its fields in the variable dropdown for all the other notification types as well.

How does this work?

• As explained earlier, if the selected Action priority has ‘Mandate Action Review’ ticked in the Action Priority details page, then the Action Review Required field will be set to ‘Yes’

• The ‘Action Creator’, ‘Action Priority’, and ‘Action Review Required’ fields will be introduced to all standard and custom Action Objects.

• The newly introduced ‘Action Review’ section in the action object will be enabled if the user has selected ‘Yes’ as the value of ‘Action Review Required’ field. This ‘Action Review’ section will allow users to keep record of ‘Action Review Status’, ‘Action Review Owner’, ‘Action Review Due Date’, ‘Action Review Complexion Date’ and ‘Action Review for Effectiveness Required’.

• The newly introduced ‘Action Review Effectiveness’ section in the action object will be enabled if the user has selected ‘Yes’ as the value of ‘Action Review for Effectiveness Required’ field. This ‘Action Review Effectiveness’ section will allow users to keep record of ‘Action Review Effectiveness Status’, ‘Action Review Effectiveness Owner’, ‘Action Review Effectiveness Due Date’, ‘Action Review Effectiveness Complexion Date’, ‘Action Review Effectiveness Rating’ and ‘Action Review Effectiveness Comments’.

• The newly introduced ‘Action Review Due Date’ and ‘Action Review Effectiveness Due Date’ notifications will function similar to ‘Action Due Date’ notification.

• The new column called ‘User role’ will be introduced to the Action Grid in Incident Action Bubble in My Quick Update and newly added ‘Incident Action Reviewer’ and ‘Incident Action Effectiveness Reviewer’ user roles will be displayed under the ‘User Role’ column in Incident Action Grid along with the already available ‘Incident Action Responsible Officer’ user role.

• "Action Responsible Officer" will see Incident Action records in the My Incident Actions bubble when the Action Status is "Not Started" or "In Progress" only and "Action Reviewer" will see Incident Action records in the My Incident Actions bubble when the Action Review Status is "Not Started", "In Progress" or "Completed". Also "Action Effectiveness Reviewer" will see Incident Action records in the My Incident Actions bubble when the Action Effectiveness Review Status is "Not Started", "In Progress" or "Completed".

• The newly introduced ‘More details’ Popup in the Incident Action My Quick Update bubble will allow users to view Action Details, Action Review and Action Review Effectiveness related details for a selected Action.

• Two new tabs will be introduced called ‘Incident’ and ‘Action’ in My Quick Update "My Incident/Incident Action Sign Offs" bubble (Previously called "My Incident approvals" bubble). The new Action Tab will be introduced to show signoffs added from ‘Action’ Object.

At Camms, we are committed to enhancing the security of our application. After thorough assessment, we have identified an opportunity to improve authentication token security. This involves the introduction of one-time tokens, these unique tokens are designed to provide an additional layer of protection against potential unauthorised access and with reduced expiration periods of those tokens, serving as mandatory security enhancement. 

These measures represent a crucial and effective security enhancement, demonstrating our dedication to proactive security measures.

Benefits of secure tokens:

• Security: By encapsulating user identity and permissions, secure tokens reduce the need to transmit sensitive data with each request, minimising the risk of interception and unauthorised access.

• Statelessness: Secure tokens enable stateless authentication, meaning the server doesn't need to keep a record of tokens. This simplifies the architecture and scalability of applications.

• Flexibility: JSON Web Tokens (JWTs) are widely supported and can be used in a variety of applications, from web to mobile and even IoT devices.