Multi-Level Request Action

From wooqpedia
Jump to: navigation, search

MULTI-LEVEL REQUEST ACTION(MLRA)


Multi Level Request Action(MLRA) is a Wooqer use case which is used when a process has dependencies and requires more than one user’s inputs to complete the process. Here user requests an action from another user who in turn may request to another higher level user and this can be further scaled up to # levels.

Use Cases:

  • Simple scenario for a MLRA process can be of that where a user is requesting for a Leave approval to his immediate senior.
  • Another scenario can be of that where a user is requesting his/her Expense reimbursement.
  1.Such a user who is termed as L0 user can attach all the required documents related to his/her expenses and assign it to his/her manager.
  2.The manager who can be termed as L1 user may review the documents and other evidences attached by the L0 user in the request form. 
  3.If he/she finds them satisfactory then the process can be further assigned to the Finance team for further actions.
  4.Now the finance lead who can be termed as L2 user can either approve or reject the request according to his/her call.
  5.Once the set “Closure Question” is answered the process is said to be completed.


Closure condition setting :

Question Based Closure. In this case the closure condition is set on one specific question. Answering this question, the process will be completed. Only non-mandatory questions will be displayed under this setting. Based on which level the question belongs the process can be set as Floating or Non-floating.


Option Based Closure Under this setting multiple questions can be set as closure. Answering any of the question the process will end. Under this the answer option can also be defined on which the closure can be set.



Alternatives in MLRA:

  • Do Not Require Due Date: This option will be available for processes which have only a single level. i.e L0 and L1.This does not require a due date for the process to be completed. When the L1 user answers closure the process gets submitted.
  • User Requesting Action : In this alternative the L0 user can set the due date for the next level user. The L0 user needs to select the respective assignee and the give the due date for the level 1 user. In this the L0 user will be setting the due date.
  • User Required to take Action : In this case L0 user will only be able to select the next level assignee. The Level 1 user after answering his relevant questions will then set the due date and the assignee.
  • Platform Generated :This will give a system generated due date. User can set the due date as submission date plus ‘n’ number of days. Here the due date will be the date on which L0 submitted plus the defined number of days. This cannot be edited the user filling the form.
  • Coverage Filter and Self Select:
 1.Coverage Filter ON – This filter if kept ON, will filter out the users as per the coverage being filled. i.e If the process has coverage A,B,C and 
 the set RA Rules has users belonging to all the 3 coverage. Now when user is making a submission for coverage A, this filter will list out users 
 only belonging to A in the Select Assignee drop down  and not B and C.
 2.Self Selector ON – This filter if kept on, will not display the name of the user in the Select Assignee drop down.