We got feedback on an email from a Dutch customer that the review process is somewhat annoying and since is pretty important and is used in three modules (policies, risks and assets) is time for us to review (pun intended) it.
This post will be worked out later when we have some more time to think about it, but we will defintely try to simplify the user experience and try to amend some things that do not make much sense.
see how it looks now (like a report of how it looks what you are reviewing now)
do the above with a friendly interface
Our review process does not really track any of the ones above automatically (you can do it, but you need to look at the parent risk: history and item report) so we want to put all that on the review record so hopefully it becomes easier.
Phase #1 Changes on the Review Module: Basic Review Settings
we need a setting on the Asset/Risks (all three) and Policy module under Settings/Review where people can choose on a multiple select dropdown that lists all roles in the module (there could be custom roles too) which ones inherit by default review records.
the field is called “Review Inherit Role” (Select one or more custom roles that will inherit by default review records created for items in this module. Modifications to this setting will trigger updates to all existing, incomplete reviews to reflect your changes).
Note: if the user creates. a custom role, it should be displayed as part of the drop down menu mentioned above.
Exception #1: currently on the risk modules, the “GRC Contact” inherits reviews, this needs to be changed to “Risk Originator Contact” role. This applies to new installs only. Past installs will have the “GRC Contact” as reviewer (same as today).
Exception #2: currently on the asset module, we miss a mandatory role for the “GRC Contact”, when we create this field it needs to be automatically populated with the “Admin” user on the migration. The default reviewer for Assets will be the “Asset Reviewer” (please rename this to new and existing installs to “Asset Reviewer Contact”).
Default value for NEW INSTALLS are listed below. Existing installs keep the settings we have today.
Assets: Asset Reviewer Contact (this is a change from what we have now
Risks: Risk Originator Contact (this is a change from what we have now)
Policy: Policy Reviewer Contact (this is a change from what we have now
When you edit the parent item (all three types of reviews) and modify the selections on the dropdown of a custom role, this should trigger an update on the reviewer field on all incomplete, future reviews.
make sure the status “Current” review is applied to the one that has the latest “Actual Date” and is “Completed”. You could easily have more than one review with the same “Actual Date” so always assign the current to the latest of those records (i guess the id of the item?). Every time a review is edited, deleted or added this status should be re-calculated. The same every time the daily cron runs.
Remove the “Completed” option, no-one is using this and is very confusing. Assume all reviews are “Completed” when “Saved”.
the form today is a bit different, depending if you are editing an existing review or creating an “Ad-hoc” review (when someone clicks on “Actions/Add”). The following changes are needed when editing an existing review:
when we edit an EXISTING review, we just need to get rid of the completed option, assume is “Completed” always.
The following changes are needed when an Ad-hoc review is created (Actions/Add)
We should not let people create add-hoc reviews (this are created when they click on action/add or click on the option below) if there is an existing “Expired” review. “Expired” means that there is at least one (could be more) review that has a “planned date” in the past AND is “incomplete”. The message should say: “You currently have expired reviews, please complete those before creating new review records”
when we create a new review (Actions / Add), the “planned” and “actual date” fields should show todays date by default and should be disabled, the user can no longer modify these dates. you can still show these fields to the user (read only)
the “completed” option should go away as discussed before, by default is “enabled”
when you add a review (Actions/Add), the “next review date” TAB should disappear if there is an already EXISTING incomplete review with a “planned date” in the future for this item. If there isnt one, then you show it.
TO REVIEW: you should be able to bulk edit reviews (all three types), i understand that when you edit a review some fields are automatically completed so when you bulk edit you need to have the logic to ensure all required fields to save a review (indiferent of which one you are editing) are mandatory. the question is, does bulk edit feature today have the form logic embedded? i think not.
Phase #3 Changes on the Review Module: Activity Log Records (NOT YET DECIDED)
when you start the review of a risk as a stakeholder, you see this … how can i see what the risk is if i just see a row? we need an “Item Report” to be available to the user on those review records. Today the “Item Report” applies to the item, but in some cases these items have a “Parent Item”, so we need to be able to display those as well for the user, a little like we do with Activity Log.
The parent item report should include a “Table” widget that can lists all activity logs on the item. If i try today to create a table with that information on the “Parent” item i get the following options only, we need here to be able to include Activity Log records. This feature should apply to all modules where activity logs are available.
when you create a warning notification or comments & attachment notification or an awareness notification, because they always trigger in relation to an item, you could include to “Attach item Report” (The email will include a PDF with the report of the item that triggered this notification) of the item that triggered the notification, the user here would select from the list of available “Item Reports”. that option is ONLY available when they choose “Email Notification” (not webhooks). Of course, item reports can not be deleted if they are used in any notification, we need to block those actions.
when you have items that have “parent” / “child relationships” , on the parent item, a new activity log record should be created when an child item is created.
These changes are coming to reviews in the coming months. We will also update Comments / Attachments and the what people sees when they work with them so they are more user friendly. This is likely to be part of the new UX.
We are planning to remove the “Review” concept from Risks, Assets and Policies all together and simplify this process. In the end, all items in eramba will have the same method of being created, modified, reviewed, etc.
The approach will be to use a right panel on all items, including Risks, Assets and Policies that show what changes happened on the item.
We need different panel templates on the right, these panels include the attributes mentioned above plus specific attributes that each template requires:
New item created
Changes on an item field
Notification triggered for this item
Status activated / deactivated for this item
Review (planned / completed / incomplete) → this only applies to Risks, Policies and Assets
For every stage of the lifecycle of a policy or an item we need to understand what needs to be displayed on the right panel.
Item Created
View the Item
Change Fields on the Item
Review the Item (before or after Review Date)
Notification (email/api) Triggered
Status Changed
Item Created
The right panel needs to describe on a single “item” all fields and their values
Note Policy module: the document version should be specified on this right panel item
The right panel needs to show in one entry what statuses changed and when
A direct link to the right panel should be able in case you want to share this with someone
View the Item
A button should show the item as it is “Now”
A direct link should display the “View” modal (for example when is embedded on notifications)
Note for Policy module: the view modal needs to show the policy directly, maybe this requires a special view button for the policy module. is very important that if you give a link to someone they open the link and they see the document directly.
Change Fields (Review)
The right panel needs to describe on a single entry all fields that changed, their old and new values.
Note for Policy module: we need to know what the latest version of the policy is (to be able to “View”) and we need to clearly show previous versions. We need a special “Item” on the right panel that shows “Reviews”, every time content changes it triggers a review with whatever version the user set. If the user wants to see previous versions they just need to search on the right panel for “Review” type of items.
Review the Item (Scheduled)
The right panel shows a special “item” where you are offered to complete a “scheduled” review your options are to “keep the document as it is” or “make modifications”
if the user chooses to “keep document” then we need to let the user specify the “next review date”
if the user chooses to “make modifications” then the user makes modifications (we enabled the edit fields) and saves triggering a standard “Change Fields (Review)” type of review. we could one day implement a way for this process to be “standby” so modifications to the document do not need to be done all at once when the review is done
Today you can delete reviews, so we have the “Action” buttons
How notification tie to all this?
Deadline notifications URL should point to the right side menu to the item for “Review” (as explained before)
