Introduction
We have long wanted to change the policy module, the review process and include a new workflow feature. This feature will in theory cover these three topics at once.
The current review process will change for an approval + review process.
- The “Approval Workflow” will control that any change on the policy or its attributes (title, etc) has to be approved to become “Published”. All new Policies will be on “Draft” by default. Internally we call it Versioning. This feature is very likely to be used on other modules.
- The “Review Workflow”, is simply a reminder to regularly trigger the previously mentioned “Approval Process”.
Approval Workflow (New)
The “Approval Workflow” process will be very simple and can apply to any module when an item is created and edited:
From a “Approval Process” perspective there are three possible status for an item:
- Draft (default)
- Pending Approval
- Approved
Workflows will be enabled on the following modules to start with: All Risk Modules, Assets and Policy, it can easily be expanded to almost any (parent) module in eramba later on.
Workflow UX/UI:
- Workflows “Statuses” will have a pre-defined status created to highlight them
- The entire “Workflow” process will be managed from the “View” button, there won’t be a “Review” tab for “Workflows”
- There are records for every step of the way, these will be shown on the “View” button and when “Exporting” the policy, there will be two options: Policy Alone + OR Policy + Records
- Workflow Notifications will be hard-coded as any other notification and enabled by default when the workflow feature is turned on
Workflow FAQ:
- Does the workflow status affect if the item is visible in other modules? No
- Does the workflow support multiple approvals if the approver is a group? No, a single group member approval is sufficient
- Can the workflow process be override in case the approver is away? Yes, by admin group members for now . (WE MISS UPDATING THE DIAGRAM ABOVE)
Workflow Settings:
We need some basic settings on every module for workflows, the basic settings will be:
- Workflows enabled / disabled: will be disabled for all modules except for Risk, Assets and Policies for which will also be disabled. Note, reviews DEPEND on workflows, for that reason this setting is tightly linked to Reviews.
- Timeout in days/hours (what happens if no-one approves or rejects a workflow for that period of time)
- Workflow Approver: this setting will come from what we currently have as “Review” Settings, this is part of the migration process.
Review Workflow (Upgraded)
The “Review Process” is optional, it just basically triggers the “Approval Workflow” process based on some frequency defined by the user.
If the “Review Process” is enabled, there are then two additional statuses:
- Expired Review (which also trigger the “Draft” status)
- Review Deadline Soon
Workflow UX/UI:
- The same as workflows, all reviews will be managed from the “View” button
- The review tab will be there, but items will no longer be editable
- Views will be there, nothing changes
- Customisations will not be possible, if you detect there was something customised we will simply leave it there but it won’t be any more editable the custom field. THIS IS THE ONE THING WE ARE TAKING AWAY FROM CURRENT USERS.
- Notifications will be left as they are, nothing changes.
- Status will be left there, nothing changes.
- We could perhaps simply hide this tab all-together at least for new installs or customers that have never used the module.
Review Settings:
We need some basic settings on every module for Reviews, the basic settings will be:
- Is very likely that these settings will be merged with workflow settings in one, it just makes sense.
- Reviews enabled / disabled: Reviews will be disabled by default on Assets, Risks and Policies. This setting can only be enabled if workflows are enabled.
- Review frequency, this can be pre-set for all documents with two variables: (Year|Month|Week) and a number, meaning 3 Years is every 3 years from the moment the policy is created. Changing this setting applies to new policies only. Another option is to disable these and set “Custom for every policy” (what we have today).
Migration Process:
The migration to this new system will be complicated for:
- Existing installs that HAVE created at least one item on every module (Risk, Assets, Policies)
- Existing installs with enabled notifications, customisations, custom statuses, custom views and if they currently use APIs
The concept is that both workflows and reviews will be managed the parent item. The migration process will take Review records and migrate them to the parent item “View” modal.
Stored Records:
During the workflow and review process there is a need to store specific records that will be then shown on the “View” button and review records. This is the list of what records we need to store for every step of the process:
Ref: https://docs.google.com/spreadsheets/d/1wFgK1HVEutO1Ev7T0_mOYs_Upyab3z41vrgvYvPcY4o/edit?gid=0#gid=0
Policy Module Form (Upgrades)
The policy module will be simpler unless the user customised something:
- General/Name*
- General/Description
- General/GRC Contact*
- General/Policy Reviewer Contact* (we might rename this to policy approver contact)
- General/Labels
- General/Type
- Content/Widget Editor
- The policy editor needs to be markdown as default
- We will leave “Backward” compatibility as a switch on-off only if they have policies written already there and the migration on Markdown shows something horrific.
- Portal/(Private|Public|Limited) - by default “Private”, if they switch to “Public or Limited” and the portal is disabled you need to show a warning.
Note on editors: TipTap ( Tiptap Rich Text Editor - the Headless WYSIWYG Editor ) or this too Introducing our new composer, making writing on Discourse easier than ever - Announcements - Discourse Meta
Policy Portal
TBD
