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
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.
1 Like