Feature Release Note | cammsincident, March 2020
CAMMS is pleased to announce the March Feature Release for cammsincident.
This was released on 21st March 2020 and includes the following new features and enhancements to improve your user experience within the system.Â
1. Enhanced usability in Documents uploading, custom tables and custom list configuration |
We have taken your suggestions into consideration and improved the user journey in the following areas of the application to give you a better experience when entering incident data.
Document uploading;
Improved UI for the document upload area within the 'Documents' object and the 'Documents' pop-up indicating 'No documents are available' when the uploads are empty.
Improvements to the UI of the Save and Download buttons to be more prominent in the ‘Document’ object and pop-up.
Improvements to the UI of the Save and Back to documents buttons to be more prominent when users click on Add New. When the document is uploaded, prior to saving, a message is prompted to the user notifying that the upload was successful.
You now have an inline Delete button on the document grid to delete unnecessary documents in an instant.
Custom Tables;
Improved UI of the custom table to show a placeholder message indicating no data is added when no information is entered in the table.Â
Improvements to the UI of the Add New Row, Save and Close buttons to be more prominent when adding a new row.
An updated message to notify users attempting to leave a record, that their data will be lost if not saved;
Custom List configuration; Â
Terminology changes in Incident settings area accessed via Cammsrisk > Framework > Incident Settings > List Items where the previous screen which was titled ‘List Items’ is now changed to be ‘Lists’ and few labels are updated to provide more meaning for the configuration screen.
The changes are highlighted in the Before and After screens below.
Before;
After;
2. Pre-populate child fields to function across objects |
A quick recap of what was released last sprintÂ
You can create parent child relationships between fields within the object and define the relationships between field values.
This way, child fields will be populated based on the selections made from the parent fields.Â
Once the list items and other fields are created, and the linkage between parent child fields are also done, matching parent and child fields should be configured in the object configuration area of the object the fields are required to be appeared in.
There will be a field mapping area which lets to map the list fields with the respective field in the objects.Â
So far this had been always possible to be done within the same object where both parent and child fields must be within the same object.Â
What is available now?
Ability is now provided to configure the parent and child fields to be on different objects within the same workflow. Provided that the fields are individually created in the different objects, Field mapping area accessed via Cammsrisk > Â Framework > Incident Settings > Object Configuration > Field Configuration Details (for the parent field) > Field mapping can be used to map the child fields (which are configured as properties within the parent field, already populated in this area) to the fields within objects in the workflow which needs to show the child fields.Â
The configuration area for field mapping is improved as below, where 'Mapped Fields in the Object' area will now show all fields coming from all objects in the workflow.Â
This is arranged to be grouped by the object and all fields within the object will be grouped under that. Multiple fields can be selected from here where the same child field can be mapped with multiple fields.
How will this work for the end user?
Based on the mapped fields, the child fields will inherent the configured data based on the parent field selections.Â
When one property is mapped with multiple child fields, all of the fields will be updated based on the parent selections in the workflow. However, these auto populated information can be manually edited by the end users and saved if required as well. Â
When the child fields are manually updated, this will not subsequently update the parent field. However, if the parent field is updated, the child fields will be overwritten by the auto populated values once again.Â
Note:Â
This feature only works across objects in the same workflow and not across workflows.
For the users using the mobile application, please note that when the above feature is enabled, any changes done from the web application will be reflected in the mobile application as well for the parent and child fields. However, if a parent field is updated from the mobile app, the subsequent auto population of data will not function at the moment. CAMMS will extend this ability for the mobile application in a future sprint.
Â