Skip to end of metadata
Go to start of metadata



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


Exception is a type of routing used to handle error conditions that occur during the workflow of a document. A document goes into Exception Routing when the workflow engine encounters an error or a situation where it cannot proceed, such as a violation of a Document Type Policy or an error contacting external services. When this occurs, the document is routed to the parties responsible for handling these exception cases. This can be a group configured on the document or a responsibility configured in KIM. Once one of these responsible parties has reviewed the situation and approved the document, it will be resubmitted to the workflow engine to attempt the processing again.

Currently a document type or route node can have a single workgroup specified for exception routing. In cases where this has not been defined, KEW will default to a KIM role or group. In the cases where an exception workgroup has not been defined or a KIM role for exception has not been established, this could happen. As part of this custom Flow we need to compensate for cases where exception routing itself may fail. A document should never be enroute without an action request.

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

Functional Design & Requirements



  • Exception parameters should be definable...
    • By document type
      • Including the parent document type which the children could inherit
      • In general, different areas are managed by different functional & technical areas
    • By route node
      • This would execute regardless of the document type
    • By type of error
      • Based on the type of error, document or database/SQL error
      • A missing fiscal officer or something that can be fixed by a functional person goes one place, but a SQL/database error should probably go to the tech team
    • By document content
      • Different types of the same document may be supported by different functional areas, a defined set of content from the document should be allowable as determinants of the exception routing
    • A default, system workgroup or KIM ROLE should be mandatory and established to ensure this situation does not occur.

Setup and 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 exceptions will need to remain with an application’s development team (see Technical Design & Implementation below for more).

Use Cases

Case 1 (Type of error) :

A document that is being routed to a department that has not fiscal officer specified can be fixed by a functional group updating that assignment and routing the document on.  However a document that goes into exception due to an error in the underlying database or the code of the document will need to be fixed by a more technical group.  As such, the routing of the document that's in exception should be determinable by the type of error encountered.

Case 2 (Document content) :

Human Resource groups may be split into different responsibility groups based on the type of employees involved. In these cases, it would be desirable and more efficient to route documents, based on values in the document, that have gone into exception to the responsible groups. These groups would be more familiar with the data contained w/in the document, those in the workflow, and what may be causing the issue

Case 3 (Document type) :

In KFS when a Purchasing Card document (PCDO) goes into exception the PCard Administration group would be appropriate group to notify, however if it were an Effort Certification document (ECD) the Sponsored Projects group would be the correct group. This is an example of different child document types under the same Parent document type needing their own exception routing specification.

Case 4 (Route Node) :



Include more examples from Applications

Technical Design & implementation

  • superUserWorkgroupName, blanketApproveWorkgroupName, and exceptionWorkgroup: should be set to the administrative group at your institution. If you are using the default workgroup service, this can be left as WorkgroupAdmin
  • <defaultExceptionGroupName>YOUR_EXCEPTION_TEAM</defaultExceptionGroupName>
  • defaultExceptionWorkgroup determines to which workgroup to send an eDoc of this type if it goes into exception routing. This is an optional element. You can also define Exception Workgroups with a route node.
  • Define a custom process flow for exception cases (i.e. allow an exception document to go through two levels of review prior to be submitted back tot he workflow engine for a retry or allow for it to route to different exception responsibilities based on document data).
  • Modeling Maps
  • Database Model
  • Services

Work Breakdown and Estimates

  • No labels