We will finish preparing the base ground for workflows in the coming months and therefore we’ll start preparing the functional design of the feature very soon.
1 Like
We had workflows but we never published them … and it was a good decision back then the code needed a cleanup (that is why we built 2.x)
Our goal here is:
- workflows must work exactly the same on any section in eramba
- admin defines workflow stages where items are located
- once stages are defined, items move in between these stages based on approvals
- there is always an initial and last stage , a bit like the beginning and end of a workflow
- there is optionally as many stages defined in between the initial and last
- On each stage admins define:
- title and objective of the stage
- what user, group or/and section custom role owns the stage (these people grant or deny access to the stage)
- next “hop” definition
- what is the next "hop"is in case of “approval”
- what the next “pass” is in case of “access denied” (this means the stage owners denied access to the stage) and
- what the next hop is in case “ignored” (this is in case stage owners never grant access or deny it and the stage times out)
- if the stage is initial , last or inbetween (we need a better name here)
- what triggers an item to fall into the _initial _ stage of a workflow (we assume items initially fall into a workflows initial stage only):
- all new items (when an item is created…)
- all edited items
- all deleted items
- change of status of an item (this links to Feature - Custom Defined Role Names and Dynamic Status)
- what notification gets sent when an item falls into or exits a stage:
- Subject, Body
- Recipients are section custom roles + a custom role for the stage owner
- all macros for the section must be active
- what portal will be shown to the user, this is defined on every stage and the objective is that stage owners can see the item that fell into the stage in detail (its attributes, name, description, etc). this is key as it must be very user friendly.
Simulation for a “new item”:
1- John creates a Risk … he is playing with it so at this point it shows on the “Initial Stage” of the workflow. Once he is happy with it, he manually pushes it to the next hop (he can not decide what the next hop is, that was configured and it is “Peer Review”)
2- Falls under the “Peer Review”
3- John and Stage Owners get two notifications: one triggered by the “Exit” notification of the stage “Initial Review” and another by “Access Request” of stage “Peer Review”.
4- Stage owners click on the link, they log in, they see the “Item Report” modal that allows them to visualise in two tabs
4a- Item Details tab: they see what the stage configured for the user to see, this is an “Item Report”
4b- Workflow Details tab: see the trails for the items workflow (what stage, enter, exit date/time, etc), comments, attachments, they can “Approve” or “Deny” the item access to the stage
QUESTION: what if anyone (the one who created it, the people on the item custom role or the stage custom role people) tries to delete or edit this object? Should a stage define what fields can be edited and by whom? … for example, if the owners of the stage dont like the title of the risk, does it need to go back or they can change it?
5- If they deny access, it goes back to the previous stage. If they grant access the process starts again from step #1 but no on the next hop
1 Like
It would make a good idea to define who can delete an object without permission. Maybe set it in the access list to define that, or in the workflow.
I am really looking forward to this feature! 
We will begin development of this feature after we complete the Cake migration project , always look for “Release” on the search bar and “Sort by date”, that will give you the latest update on what we are doing.
Latest release: https://discussions.eramba.org/search?q=Release%20order%3Alatest
1 Like
1 Like
Do you still have plans to implement the workflow feature? It would be useful to be able to validate audit results, risk assessments, security policies and other types of Eramba artefacts. Thanks.
yes, but not during 2023
you can use comments and attachments in every module, also you can match approved words. not exactly blocking workflows but still has done the job well for many years.
1 Like
Thank you that is what we have been doing so far. Kind regards.
I don’t think it does the job very well, to be honest. We have used it here for the past couple of years but my users find very confusing.
Can I ask if this ‘workflows’ feature is still on your roadmap?
Every summer, I get all my control owners to do a peer review exercise on all our controls.
If the new Eramba workflow feature isn’t available by then, I will probably just use a Jira Kanban board to do your peer review exercise. It’ll mean me manually creating 120-odd Jira tickets, and the results won’t be integrated with Eramba, but that will only be pain for me, not pain for all my control owners, so I will probably just have to bear it 
We are interested in knowing:
- what workflow use cases you need
- how tools handle this from a UX/UI perspective, screenshots would help more than words
The new UX/UI is being prepared to handle configurable workflows, this does not mean that they will be available when the new UI/UX is launched (after summer) but we are preparing the ground for this, perhaps later at the end of this year.
We would be very pleased if the topic of workflows were implemented. An approval process for risks and exceptions would be relevant for us. A requester submits a request to record an exception/risk. Cybersecurity then checks the available information and carries out an assessment. After a successful assessment, the process is forwarded to one or more people (depending on criticality) for approval.
2 Likes
We are working on the design of the new “User defined workflow” feature in eramba. This will allow users to control (approve or deny):
- Creation of items: an item does not become “Active” until it is approved
- Deletion of items: an item is not “Deleted” until is approved
- Edition of items: an item is not “Edited” until is approved
This feature will also replace the concept of “Reviews” used in Policies, Assets and Risks.
Workflow Settings:
The administrator of the software, must configure for each module, if workflows are “Enabled” or “Disabled”. By default they are “Disabled”, meaning the software works as it does today.
If enabled, the administrator must define for each type of change (Creation, Deletion and Edition) stages and for each one of them the following attributes: Stage name, owners, next stage, deny stage (where to go if the stage owner denies the change).
Active vs Draft Items
All items will now have two statuses: Draft and Active
When workflows are enabled in any given module and an item is created, edited or deleted, until the workflow is completed (approved) the item is in “Draft” mode. In this mode, these items do not count for filter, status, report, etc calculations.
When the workflow is completed, the “Draft” item:
- Updates the “Active” item (in the scenario of an Edition)
- Goes to the trash (in the scenario of a deletion)
- Is created (in the scenario of a creation)
Draft items are available to anyone that has access to the item (we follow the rules of visualisation and ACLs). When edited, an item in draft mode has three option buttons:
- Cancel
- Save Draft (used to make modifications without triggering workflow)
- Initiate Workflow (Step 1/3)
When an item is inside a running workflow, the “Edit” or “Delete” button should not be displayed, instead you can “Cancel Workflow”. This will be used to stop workflow approvals.
Sample Workflow for an “Edition”:
Note:
- Workflows wont be available on all modules, just in some so we need to setup a config file
- When an item falls into a stage where there are multiple “Owners”, the approval should come from at least one of these people, not all are required.
- Comments & Attachments are associated to the approval stage, not to the item … this is important so you can see what was discussed on each approval.
- When approving, there should be a clear distinction in between “Approve and pass to next stage” and “Final Approve” so people knows in which phase of the workflow you are, or perhaps a visual representation of what approvals are left until “Active” stage
- There should be a way to bulk edit approvals, imagine someone imported things over CSV
- Imagine the owner of a stage no longer exists in the system, then “Admin” group members should be allowed to “Approve” any workflow anytime even if they are not there.
From a visual perspective, the “View” modal will be used to display the activity of any item. this was discussed at length on this post: Feature - review process of risks, policies and assets - #9 by kisero
- the right panel of an item shows in a timeline:
- changes on the item
- reviews of the item (scheduled reviews)
- changes on the status of items
- comments & attachments
- workflows (only if enabled on the module)
- on that view users approve or deny workflow changes and also comment on the item if needed
1 Like
Workflow configuration first idea:
Questions:
- What actions can be performed in the first box? (Probably Create/Edit/Delete)
- Can we tie notifications to each individual block? (For example: Notify the CISO group when the first review is completed)
- How to show draft items in the views (probably column)
1 Like