| Section | |||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| Excerpt |
|---|
The Kuali Enterprise Workflow (KEW) is a general-purpose, content-based electronic routing infrastructure or workflow engine. Its main purpose is to automate the routing of electronic documents (e-docs) to individuals and groups for approval, yet the KEW can also be used to orchestrate complex processes between business components and applications. Approval routing is based on institutional or departmental business rules and policies. A new routing option called PeopleFlow is also available from the KEW to provide a streamlined way to view and update routing actions. This section provides an overview of KEW as it relates to the OLE. |
...
Kuali OLE uses the KEW to handle the routing of electronic documents for actions such as approvals, acknowledgements and FYI notifications. Although much KEW functionality works behind the scenes, the action list and doc search buttons and the Workflow submenu (under Configuration) options on the OLE Administration Admin menu tabs are part of the KEW. These workflow options allow you to access, act on, and search for many types of e-docs from various functional areas from a single location. Additionally, the Route Log tab on OLE e-docs is a workflow feature that allows you to follow the progress of given documents through the approval process.
...
KFS Knowledge Transfer - KIM functions (roles permissions, responsibilities) was a video conference about roles and workflows. It also contains a visual demonstration about responsibilities.
...
PeopleFlow Overview
PeopleFlow is a new Kuali Rice feature that Kuali OLE is now using for License Requests and Electronic Resources. PeopleFlows are a prioritized list of people to send requests to. Essentially, it's like a mini people-based workflow that doesn't require you to specify a KEW node in the document type for each individual who might need to approve or be notified. You can define "Stops" in a PeopleFlow, where everything in the same stop proceeds in parallel, but all must be done within the stop before proceeding to the next stop.
You can call/execute a PeopleFlow from within a KEW workflow node directly, or you can invoke the Kuali Rules Management System (KRMS - a common rules engine for defining decision logic, commonly refereed to as business rules) engine from an application and any PeopleFlows that get selected during rule execution, defined in a KRMS agenda, will be called. In this way, you can integrate business rules across applications and workflows.
The same PeopleFlow that defines a routing order among a set of persons, groups or roles can be called by KRMS rules, with the KRMS rules defining which type of request to pass to the PeopleFlow (for example, an "approval" routing action or a "notification").
For information about creating and managing PeopleFlows in OLE, see in the Guide to OLE System Administration Functions.
| Anchor | ||||
|---|---|---|---|---|
|
Documents route by progressing through a series of route levels (also called 'route nodes'). All Many of the financial e-docs on the financial (FS) menus Select/Acquire menu, and other e-docs throughout OLE, support both pre-established workflow routing and ad hoc routing. There are several on the Rice 2 (LS) menu that also support routing. Here is an example of the approval route nodes that a typical financial processing document passes through:
...
An easier view for functional users is located in the Routing & IDM Doc Type Hierarchy (Routing and Identity Management Document Type Hierarchy) option in the Configuration submenu on the Administration menu tabs.
...
| Column | ||
|---|---|---|
| ||
On the Financial (FS) Administration menu |
...
submenu on the Admin menu.
The KEW arranges OLE document types in a hierarchical fashion, with some document types being 'parent' to the document types below them in the hierarchy. 'Child' document types inherit attributes from their parents. The Routing and Identity Management Document The Routing & IDM Doc Type Hierarchy screen displays documents in their respective positions in this hierarchy and also displays the route nodes associated with each document type. Nodes are listed in the order in which the document progresses through them.
The following example shows route nodes associated with the Transfer of Funds document type viewed through the Routing and Identity Management Document Routing & IDM Doc Type Hierarchy.
| Anchor | ||||
|---|---|---|---|---|
|
Routing and roles inherited from KFS will continue to be reviewed for the 1.0 5 release. Many of the route nodes remain listed but are passed over in OLE. These options remain available for institutions that wish to implement them.
Most, but not all, Kuali financial documents are able to progress through three route levels: account level, organization hierarchy, and special conditions.
...
Special condition routing is a blanket term for additional route levels that might be triggered by various attributes of a transaction. Special conditions often represent special administrative approvals that may be required. This routing may be based on the type of document, attributes of the accounts being used, or other attributes of the transaction.
Throughout the OLE Select and Acquire help documentation, we refer to route levels that are not fiscal officer or organization review routing as 'special conditions routing'. This term covers a variety of different types of routing that are explained in the help documentation sections about the various document types that use these route levels.
...
- Select an action requested from the Action Requested list. To route the document to an individual, select this option in the Person Requests section. To send the request to a group, select this option in the Ad Hoc Group Requests section.
- To ad hoc route the document to another person, type the principal name in the Person box in the Ad Hoc Recipients section or use the lookup icon
to search for the appropriate username.
- To ad hoc route the document to a group, in the Namespace Code field in the Ad Hoc Group Requests section, enter the group name or use the Lookup icon to search for the appropriate group name.
- Click
. The system verifies that the person ID or group namespace code and name that you have entered for routing is valid. - Click
on the document.
After you complete the Ad Hoc Recipient section and submit the document, the system changes the Node(s) value to 'Adhoc' and changes the Status value to 'ENROUTE'.
The Pending Action Requests tab shows the requested action and the user ID.
...
When you review the Route Log immediately after submitting a document, you may not see the Pending Action Requests tab. This is because OLE has not yet received the routing information from Workflow. In this case, wait for a few seconds and click the Refresh button at the top of the Route Log to refresh the screen. You may need to repeat this process a few times until the information appears in the Pending Action Requests tab.
On documents in the Rice 2 menu, the ad hoc tab looks different but functionally works the same way.
appears in the Pending Action Requests tab.
| Anchor | ||||
|---|---|---|---|---|
|
To see the route nodes associated with a particular document type:
- Click the
the 
menu tab. Select Select Routing & IDM Doc Type Hierarchy (Routing and Identity Management Document Type Hierarchy) from the Configuration submenu.
sectionColumn width 40% On the Financial (FS) Administration menu
Column On the Rice 2 Administration menu
The system displays document types in the hierarchy.- Locate the desired document type route levels.
For example, you might scroll down to Transfer of Funds to view the rules of the Transfer of Funds document route levels.
Beneath the document type, you see the nodes that the document routes through. The system lists these nodes in order from first to last. To view more detail about the KIM responsibilities associated with these route nodes, click the View Document Configuration link.
- Scroll down to the Workflow / Responsibilities tab.
In the Workflow / Responsibilities tab, the system displays the name of each route node along with the associated role(s) and other information. The first entry in the list defines the exception routing for this document type. This entry identifies the role that receives the document if Workflow encounters an error that prevents it from completing the document's normal routing.
...
Responsibilities are associated with roles in KIM. Roles have members or assignees who are represented in the system as persons, groups, or other roles. Users assigned to a role inherit the role's responsibilities, meaning that they receive action requests from Workflow when specified conditions are met.
To view responsibilities, select the Responsibility option from the System submenu on the administration menu. On the Rice 2 administration menu, the Responsibility link is located under the Identity submenu.
To view responsibilities, select the Responsibility option from the System submenu on the menu.
Each responsibility includes several attributes (that is, values and details) that determine when it is triggered.
Responsibilities lookup results definition
Title | Description |
|---|---|
Template Namespace Code | Display-only. The namespace for the responsibility template. Usually, the namespace identifies the application and module the applicable responsibility template pertains to. Because responsibilities pertain to workflow, most responsibility templates are associated with the KR-WKFLW (Kuali Rice-Workflow) namespace. |
Template Name | Display-only. The name of the template on which the responsibility is based. The template defines, in a broad sense, what the responsibilities based on it do. Since responsibilities usually generate action requests for user review, most responsibilities have a Template Name of 'Review'. |
Responsibility Namespace | Display-only. The namespace with which the responsibility is associated. This namespace usually corresponds to the namespace of the document type for which the responsibility generates action requests. |
Responsibility Name | Display-only. The name of this responsibility. In most cases, the responsibility name will be the same as the associated template name (Review). |
Responsibility Detail Values | Display-only. Additional detail that identifies the document this responsibility generates action requests for, when the requests are generated and how Workflow handles them. |
...
For more information about roles and responsibilities, see in the KFS Guide to Core Components and OLE System Administration Functions.
| Anchor | ||||
|---|---|---|---|---|
|
The Route Log tab displayed on all OLE e-docs shows workflow status details. The Route Log is broken into can have up to these four subtabs---Document ID, Actions Taken, Pending Action Requests, and Future Action Requests.
...
This tab lists each action taken, the name of the person who took this action, and the time and date the action was taken. The For Delegator field shows the name of a delegate that took action on someone else's behalf. For example, for account routing the fiscal officer's name is would be shown here if this person's delegate took action on the document.
...
When you open a document, you see various workflow action buttons at the bottom of the page. The buttons vary depending on the kind of action request you have received for the document and the KIM role(s) to which you belong.
Some additional buttons are available, depending on the the e-doc you are viewing. These buttons are described within their particular guide.
Workflow action buttons
Action | Description |
|---|---|
| Signifies that you have responded to the acknowledgement action request. This button is available only to users to whom a document has been routed for acknowledgement. See FYI below. |
| Signifies that in your judgment the document represents a valid business transaction in accordance with institutional needs and policies. A single document may require approval from several users, at multiple route levels, before it moves to 'Processed' status. |
| Bypasses all subsequent levels of approval and immediately moves a document to 'Processed' or 'Final' status. Anyone who would otherwise have received the document for approval receives an acknowledge request instead. This action may be taken only by roles associated with blanket approve document permission, such as the KFS-SYS Manager role. |
| Denotes that the document is void and should be disregarded. Canceled documents cannot be modified in any way and do not route for approval. |
| Allows you to exit the document. The system displays a message asking whether you want to save the document before closing. No changes to action requests, route logs or document status occur as a result of a close action. If you initiate a document and close it without saving, it is the same as canceling that document. |
| Allows you to create a new document based on the existing document. Not all document types can be copied. |
| Signifies that in your judgment the document does not represent a valid business transaction. A disapprove action from any single approver prevents a document from posting to the GL or updating a maintenance table. |
| Allows you to correct documents by creating a new document that reverses the original transaction. This feature can be used only on documents that have completed the routing process and have been fully approved. Not all document types are eligible for error correction. |
| Signifies that you have responded to the FYI action request. This action is available only to users to whom a document has been routed for FYI. The difference between acknowledgement and FYI is that FYI requests can be cleared directly from the action list without opening the document. FYI requests also have a different effect on the document status than acknowledgements. A document with no pending approval requests but with pending acknowledge requests is in 'Processed' status. A document with no pending approval requests but with pending FYI requests is in 'Final' status. |
| Refreshes the screen and displays the most recently saved information. Changes that are made but not saved prior to reloading a page are not maintained. |
| If you are the initiator of this document, allows you to save your work and close the document. The document may be retrieved from your action list for completion and routing at a later time. If your permissions allow you to edit enroute documents, you can also save changes to an enroute document in your action list. |
| Moves the document (through workflow) to the next level of approval. After a document is submitted, it remains in 'Enroute' status until all approvals have taken place. |
...
| Anchor | ||||
|---|---|---|---|---|
|
The In financial e-docs, the error correction action allows you to correct documents by creating a new document that reverses the original transaction that has been fully approved. A document created with the error correction action must route and be approved in the same manner as the e-doc it corrects.
...
- Click
.
The system creates a new document with a new document ID. The system also displays Corrects Document ID in both the document header and the Notes and Attachment tab of the document.
Amounts are in negative to reverse the original transaction.
The new document has an annotation that is an error correction.
- Click submit.
The header of the corrected document shows the corrected by document ID.
...
Color changes do not take place until the next time you log onto the system. The row colors change the next time you log on.
| Anchor | ||||
|---|---|---|---|---|
|
...