Skip to end of metadata
Go to start of metadata


Indicate the necessity for this enhancement. What does it accomplish?
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.

Detailed Description

Give a detailed description for the enhancement. Clearly describe all concerns, eliminating ambiguities.

Usage Scenarios

Include at least one usage scenario, from the user's task perspective, that might be helpful in understanding the issue:

  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.
  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.
  3. Clogged Action List - 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.

Mocks and Diagrams

Include any mocks (for UI enhancements) or diagrams that might be helpful in understanding the issue:


If applicable, list expectations for performance (optimal and worst cases would be fine, give time in seconds):


Include links to other confluence pages or external resources that might be helpful for this issue:

Requirements Listing

List all requirements (individual verifiable statements) that indicate whether the work for this item has been complete. If there are requirements that are not essential to the functionality but would be nice to have if time allows, enter those under 'Non-Essential':

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


List any functional or technical work that must be completed before work on this item can begin:

  1. item


List any issues that need to be resolved before work on this item can begin:

  1. item
  2. item
  1. item
  2. item

QA or Regression Testing Plan

List steps needed to test the basic functionality of this update, enhancement, bug fix

  1. test/steps
  2. test/steps


Functional Analysis Complete? No (completed by BA)

Needs Review by KAI? Yes (completed by BA)

Technical Analysis Complete? No (completed by DM)

Needs Review by KTI? Yes (completed by DM)

Estimate: 200 hours (completed by DM)

Technical Design: Link Here (completed by DM)

Jira: KRRM-12 - Data cannot be retrieved due to an unexpected error (completed by BA)

Final Documentation: Link Here (completed by DM)

Added to QA: No (completed by QA)

  • No labels