the functionality is then composed of the following elements:
- user defined “Status” , examples are “Failed”, “Pass”, “Open”, “Closed”, etc. these are the drop downs you see in most sections. the immediate gain is that you can now group items as you wish (risks no longer applicable, audits that are not failed or pass … but are more less ok, etc). this means new reports can be created immediately too as you can group items based on this status you define.
- user defined “Dynamic Status” , which trigger based on the “status” and sometimes a date. The user will be able to define their own dynamic statuses (name, colour and conditions). Reports, filters and notification macros will then reflect these settings
These dynamic status are composed of:
- a name (like we have now, Last audit expired, etc)
- one or more condition (as defined above on the table) connected to each other by a set of conditions, a bit like we have today on Zendesk
The modal for defining them could be a bit like this:
And the “Rules” must be defined on a light-modal that could use the following UX:
The table below shows the sample conditions we can apply on each section, these settings would allow users to make far more detailed and customised statuses:
spreadsheet link: https://docs.google.com/spreadsheets/d/1t2HSXpcKm7766CKge19MCLH-9YIfF-9_YqOaUIsafkA/edit#gid=0
Rules are defined with the following fields:
Drop down with the list of functions (see the list of functions on the spreadsheet). Functions return: date, string and integer…when a function is selected its description is shown below to make sure the user understand what the function does
Operator (depends on the function selected)
- integer: ><=!
- string: = ! contains
- date: on, before, etc same as filters
Value (depends on the function selected)
- integer: the user provides an integer value
- string: the user provides a string or regex
- date: the user provides a static date OR a reference (+14, -7, etc)
How does this work for a system admin?
- the user can define their own “status” on top of the ones eramba ships with - these status can be enabled or disabled (if they are disabled they stop showing on the form, users can not disable a status that is being used on a dynamic status)
- the user can then define dynamic status, these definitions use operators, hardcoded functions and in between the rules “Ands” and “or”
- every time a dynamic status is “saved”, the entire section (and all its related sections) must be re-calculated. since this can take a while we need a warning (a bit like on the login page) to be shown until the recalculation is completed.
Reports must be updated on the sections that support dynamic status, i would suggest we re-use the existing charts but update the group by and colour based on the definitions of the setting.
Notifications remain the same except for those that trigger when a specific status is identified, see the spreadsheet for details.
Macros must be reviewed to understand where this is affecting them, they will need to become dynamic too.
I would suggest we start this feature on:
- Internal controls
- Compliance Analysis