Camms.Risk Incident Management | October 2023
- amani imtiyas
Camms is pleased to bring you the Quarterly Product Update Notification for the Camms.Risk Incident Management.
This quarter we've got exciting enhancements to improve your user experience within the system, which will be available in your Test environment on 08th October 2023 and will be available in your Live environment on 29th October 2023.
1. Introduction of Audit trail for Document and Linkage Objects |
|---|
An audit trail has now been introduced within the Documents and Linkage Objects of the Incident Workflows, allowing to maintain a track of the history of changes made to the records.
How does this work?
All users with permission to the Document or the Linkage Object will be able to view the Audit trail via the History button newly introduced within the Documents and Linkage Object.
Upon clicking the History button, an initial popup will be loaded with the basic information such as the Username, Date/ Time stamp and summary of the activities that have taken place.
Upon clicking the hyperlinks within the History Summary Popup, another popup will be displayed with further tabs named Summary, Current Representation and Previous Representation which will provide detailed information on the activities taking place within the Objects.
The overall functionality is similar to the audit trail feature within the rest of the objects.
2. Addition of a 'Getting Started' Icon on the Left-Hand side Quick Access Menu |
|---|
Getting Started, page will be introduced as a new option within the Left-Hand Side Menu, allowing users to navigate into this page easily.
This provides easy access to the page without consistently navigating through the Mega Menu > Workspace.
3. Introduction of a Searchable and Expandable Hierarchy Tree Filter in Registers |
|---|
Hierarchy filter within the Incident Registers will now be introduced as a searchable Expandable Tree type filter allowing users to select multiple nodes in one go.
How do you configure this?
The' HierarchyID' field should be configured as Searchable in Incident Settings > Register Configuration.
How does this work?
An expandable tree-type filter will be displayed upon clicking on the Hierarchy filter in the Incident Register. This will initially display the Standard and Custom Hierarchy types configured within the application, which, when further expanded, will display the relevant parent nodes and child nodes.
Users can now search for the required parent/ child nodes and select multiple nodes within different hierarchy types to easily filter out the required records within the register.
Note: We regret to inform you that the introduction of a Searchable and Expandable Hierarchy Tree Filter in Registers will not be included in the Quarter 3 Live Feature release. This decision is driven by our commitment to ensuring a seamless user experience. In light of this, we are actively working on an alternative solution, and you can expect this feature to be part of our upcoming Feature Release.
Thank you for your understanding and patience as we continue to enhance our platform.
4. Eliminating the need to set a due date on the action if the Status is configured as 'Ongoing' and 'Deferred' |
|---|
With this modification, users will be able to create or edit an Action without having to mandatorily fill in an End Date if the status of the action is ‘Ongoing’ or ‘Deferred.’
I.e., Despite the field ‘End Date’ being configured as a mandatory field, users will be allowed to leave the field blank for these two statuses.
The status ‘Ongoing’ means that the Action is required to be always continued and the status ‘Deferred’ means the Action is no longer required/ applicable. Therefore, the end date is no longer a mandatory field for the two statuses and users can continue to fill them if required.
5. Return Button Enhancements |
|---|
A series of improvements have been made to the functionality of the 'Return' button within Incident records.
When the ‘Return’ button is clicked in an Incident record, the user will be navigated to the incident register which has the same incident type connected in the register configuration.
If there are multiple registers with the same incident type, then the user will be returned to the register which has the same 'Description’ as the incident type. This will be done only if the incident type with the same 'Description’ is linked to the register to be returned to. In other cases, the user will be returned to the first register found with the incident type connected in the register configuration.
If a user opens an incident record from a specific incident register, upon clicking ‘Return,’ the user will be returned to the specific incident register from which the incident record was opened.
Records opened via My Quick Update and Dashboard will be opened in a new tab. Therefore, if the ‘Return’ button is clicked within that record, the user will be returned to the register connected to the type of record as per the above explained functionality.
If the ‘Return’ button is clicked from a Portal record, the user will be returned to the portal register if a portal register exists.
Note: The above logic of returning to the correct incident register will only work if the miscellaneous setting ‘Default Incident Home Page’ is set to ‘Incident Register’. Otherwise, user should be returned to the page defined as the Default Incident Home Page.
6. Solution to disabled fields being Overridden |
|---|
Field types given below that are not Editable (Read-only) in Field Configuration (Incident Settings-> Object Configuration -> [Object] -> [Field]-> Field Configuration) will be excluded from getting updated upon clicking ‘Save’ by the end user.
Synchronized disabled fields.
Field Mapped disabled fields.
Disabled Fields which are getting updated from an API.
Note: Solution to disabled fields being Overridden is just around the corner and will be available from a Maintenance Release after the Live Release
Fields with the above field types will be excluded from the override warning message given below.
Thereby, disable fields which are updated from field mapping, auto synchronization or API will not be updated when a user clicks ‘Save’ from the respective object.
Disabled fields which are updated from field mapping, auto synchronization or API will not be reflected in the history as well when a user manually saves the corresponding object with the field.
Disabled fields which are updated from field mapping, auto synchronization or API will only be reflected in history when updated via field mapping, auto synchronization or API.
If a disabled field which receives values from other fields is added in Custom Trigger criteria in a Notification with Trigger Type ‘On Save’, then the notification will not trigger on manually saving of the object with the field by the end user and should only trigger from save done from field getting updated from auto synchronization, field mapping or API.
7. Introduction of the Calculated fields within Custom Tables |
|---|
This modification allows us to perform numeric calculations within Custom Tables. You will now be able to easily configure and perform calculations within Custom Tables.
How do you configure this?
A new section like custom email configurations will be available for field types ‘Numeric Text Box’ and ‘Integer Text Box’ within Custom Tables configuration accessed via Incident Settings.
There will be dropdowns called ‘Variables’ and ‘Operations’ in the calculation section. Variables dropdown will contain the columns added with the Field modes configured as ‘Numeric Filed’ or ‘Calculated Field’ while the Operators dropdown will contain the values that can be used to configure different calculation options.
This section will contain an important value addition where the users will not be required to type in the conditions for the calculations. It will be a simple method that requires users to select the field values and operators. However, the option like custom email configurations is also provided to have both views.
If any incorrect or partial configurations are made, a warning message will be displayed to the user, restricting them from saving the configuration.
Admin users can revise and update the conditions on the calculations as and when required.
A new button called ‘Recalculate’ will be shown in custom tables in Incident Settings -> Custom Tables if that custom table has at least one field with the Field mode ‘Calculated Field.’ This will help update all results within the Custom Tables if there are any revisions made to the condition of the calculations in the custom table.
How does this work?
Once the conditions for the calculations within the Custom Tables are configured via Incident Settings, users can visit the specific Custom Table within the Incident Workflow and view or perform the required calculations.
A new button called ‘Calculate’ has been introduced within the ‘Add’ and ‘Edit’ popup of the Custom Tables. Users can use this button to calculate and view the results prior to saving the details within the popup.
An ‘I’ icon will be displayed Infront of the fields configured as ‘Calculated Fields’ which include a condition for calculations. Upon hovering over it, users will be able to view the field names and the calculation leading to the value in the Calculated field.
8. Introduction of the Archival Feature in Incident |
|---|
With this modification, you will now be able to mark incident records as ‘Archived’ which will help segregate and maintain the most recent and required records within the registers. This modification also allows us to automatically archive Closed and older records as they surpass a specific defined period.
How do you configure this?
A new field named ‘IncidentArchivedStatus’ will be introduced within the Incident and Close Objects. This field needs to be ticked and enabled via Object Configuration > Incident Settings. This will allow us to manually mark an incident record as Archived. This configuration also works along with the below-mentioned permission.
A new standard field wise permission called ‘Edit Archive’ will be introduced to standard and custom Incident objects (Workflow element type ‘Close’) and close objects (Workflow element type ‘Incident Details’). This permission must be provided to the user to use the above-mentioned field.
By default, the ‘Edit Archive’ field wise permission will be unticked for all user roles.
When the ‘Edit Archive’ field wise permission is unticked, the ‘Archive’ field will be read-only and not editable in the corresponding object.
When the ‘Edit Archive’ field wise permission is ticked, the ‘Archive’ field will be editable in the corresponding object and user can archive the respective incident record.
A new field named ‘IncidentArchiveStatus’ will be introduced within the Register Configuration in Incident Settings. This field can be configured as ‘Visible’ and ‘Searchable’ to view the archival status as a column within the register and to filter out records easily.
The dropdown values within ‘IncidentArchiveStatus’ will be provided as ‘True’ and ‘False’ by default. However, these can be customised and configured via Custom List Configurations > Incident Settings.
A new Miscellaneous setting named ‘Automatically Archive Incident Records that are closed and older than’ with a numeric field followed by the word ‘days’ will be introduced. Admin users will be able to define a value within this field which will be used to automatically archive incident records that are closed and older than the define number of days. Example: If the user defines this value as ‘30,’ all closed incident records that reach the duration of 30 days after closure will be automatically archived by the system
How does this work?
The main output of this modification is to help easily segregate the most recent records within the registers and Dashboard. Once the above configurations are completed:
Users with permission can manually mark an incident record as ‘Archived’ via the Incident Object or the Close Object.
The Archival status will be captured within the History popup with the details.
Users can filter the Incident records using the new ‘IncidentArchivedStatus’ field.
The auto-archival feature will work independently and regularly archive the older records based on the defined configurations.
Below are some of the key value additions of this modification:
Only the records not marked as Archived (IncidentArchiveStatus = False) will be filtered and listed within the Incident Registers by default. Users must manually apply the Filter ‘IncidentArchivedStatus = True’ to filter and view the Archived records if required.
Only the records not marked as Archived (IncidentArchiveStatus = False) will be filtered and listed within the Linkage dropdowns when linking other records to Incident records.
Only the records not marked as Archived (IncidentArchiveStatus = False) will be displayed within the Dashboard.