Skip to end of metadata
Go to start of metadata



This document is a draft (7-12-2011).


KEW relies on user interaction to fulfill generated action requests.  Be it an individual accessing their action list to approve or acknowledge an document, a delegate doing the same, or a super user taking action on behalf of an individual should the situation arise.   While this works for the majority of cases, there are times where documents are stuck waiting for action due to inactivity.  This slows down the flow of  the document and can interrupt necessary downstream processing.

An escalation is a tool for specifying what actions should be taken on a requests once it reaches a predefined point.

In KEW, this feature will offer the option for applications to dictate additional notification and/or the movement of documents through their workflows, limiting the amount of time a document can stay assigned to one action request, before escalation to another based on a set of parameters that make the most sense for that document type.

The requirement for this is driven by the Kuali Rice Roadmap, specifically Kuali Rice Roadmap JIRA KRRM-12.

Functional Design & Requirements



  • Escalation parameters should be definable
    • At the document type
      • Including the parent document type which the children could inherit
    • At the route node
      • This would execute regardless of the document type
  • Parameters that can be defined
    • Duration - in hours, how long the action will sit in a given action list
    • Time of the day -  a defined time of the day that the action must be taken
    • Day of the Week - day of the week that an action should be completed
    • Action to be taken - Auto-Route onto next request, Notification, Auto-Route to specified group, combination of the above.
    • Action Requested - different types of action based on the request type (approve, acknowledge, fyi)
    • Calendar - static, defined dates (ie 7/15/2011) for actions to be taken, or dynamic dates (the 15th of every month)
    • Combinations of the Above
  • Route Log
    • A specific Action should be recorded in the route log.



It may be out of scope for this initial release, but would there be benefit in having this hook to KRMS for finer business rules driven escalations in the future? TIME brought up the fact that they escalate documents, but if the standard hours recorded on the TIME sheet are not met they actually DISAPPROVE the document at the final route node instead of approve.

Setup & Maintenance 

In future versions of Rice, there is a desire to establish a full, graphically driven Kuali Enterprise Workflow Designer (KEWD). However, that initiative is still being decided upon. At this time, the setup and maintenance of escalations will need to be done by an applications development team (see Technical Design & Implementation below for more).



Provide a functional template with the escalation options listed in a plugin and submit format?

Use Cases

Case 1 (Inactivity):

A document is created and routes to an Approver who is on vacation for two weeks. Using this feature, the document type could be set to auto-escalate if no action has been taken within 3 business days. It would send them a reminder notification that a document is in their action list. If after 5 days no action has been taken, it would automatically-route to the next defined individual in the workflow.

Case 2 (Processing Deadlines):

In the TIME application, after an individual submits their timesheet, it will route to a designated TIME approver for review. The TIME approver (first route node) must approve the timesheet by Wednesday at 4am; if not approved by this time, it is automatically approved and routed onto the Payroll Processor (the second route node). The Payroll Processor has to approve the timesheet by 3pm on Wednesday.  If the timesheet is not approved on time and the document meets a predefined set of criteria, referred to as "ready to approve" criteria, it will automatically be approved.  However, if it does not meet the ready to approve criteria and is not approved on time, it will be automatically disapproved.

Case 3 (Clogged action lists):

FYIs and Acknowledgements are sent to individuals to notify them that something has happened. However, many times, these may be automatically generated due to the role a person has within their institution resulting in thousands of items in their action list. To keep an individual’s action list “clean” so that documents requiring action are easily viewed, an escalation would be established to auto-acknowledge the document after 21 days.



Solicit more cases from Application Groups

Technical Design & Implementation

  • Modeling Maps
  • Database Models
  • Services

Work Breakdown and Estimates

Related JIRA Issues

  • No labels