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