Table of Contents
Workflow is a very general term and means different things in different contexts. For example, it may mean the sequence of approvals needed for a Leave Request or it may refer to a complex scientific procedure.
In our context of enterprise applications within a higher education institution, we're usually talking about business process management when we discuss workflow. Usually, this revolves around business rules, authorizations, and routing for approval.
A simple example is a leave request system. It needs some workflow to get the necessary people (supervisor, etc.) to approve it. This is one example of the routing and approval side of a workflow.
You may also have business rules in workflow that dictate that some people get automatic approval for leave requests. This is a business rule detail that workflow executes by automatically routing these types of requests past the approval steps.
The Kuali Enterprise Workflow (KEW) product revolves around routing and approval of documents. It is a stand-alone workflow engine upon which you can integrate other enterprise applications to do routing and approvals.
In addition, KEW contains an eDocLite system. This is a mechanism to create simple data-entry forms directly in KEW. You can also create routing rules around eDocLite forms. eDocLite forms are the rough equivalent of the basic, one- or two-page forms that are commonly used to process business and get signature approvals.
The benefit of eDocLite in KEW is that it does not require a separate application. You can use eDocLite in KEW simply by setting up the forms that your institution or department needs.
Overall, KEW is based on documents. In KEW, each document has a collection of transactions or things to be done. Each transaction is approved or denied individually in KEW.
For example, John Doe may use a Leave Request document in KEW to ask for a week off in June. The KEW Leave Request document contains enough information for his supervisor to make a decision about John’s leave. (The document may use data keys to retrieve external information, such as John’s past Leave Requests and available hours.) Once John submits his Leave Request, KEW routes it to John's supervisor for approval. Depending on how John’s department has configured KEW for routing Leave Requests, after John’s supervisor approves or denies his request, KEW may route it to more people for further action to be taken.
Once John’s Leave Request document is processed, it triggers a PostProcessor, which can peform any desired additional processing. This is most commonly used to “finalize” the business transaction once all approvers have signed off on it. In this particular example, it might call another service that would update records in the Leave Request application’s database, indicating that the individual has successfully scheduled leave during that time period.
In addition, the KEW PostProcessor contains hooks for all the stages that a document goes through. For example, an external application may use a KEW workflow for routing and approval of documents, and that application may take action at each change in state of a routed document.
The primary benefit of KEW workflow is the correct routing for approval of documents. It enforces your business-specific rules about who needs to approve what documents, in which scenarios.
Simple Workflow Example
Leave Request: Each person has one other person (possibly more) who needs to approve his or her leave requests. In this context, KEW is the system that manages both the approval structure and the leave requests themselves (the actual approvals).
More Complex Workflow Example
Purchasing Desktop Computers: You may need several business rules in KEW for this, such as a rule to enforce:
A strategic alliance requires that you buy from one vendor unless there is a justification to not do so
General purchasing approval by the Purchasing Department is required when the cost of the purchase exceeds a certain limit
Approval by the account owners who fund the purchase is required
In this example, KEW requires an approval if:
The strategic alliance is not used
The cost limit for Purchasing Department approval is exceeded
The workflow also requires an approval by the signer (or delegate) for each spending account that you use for the purchase.
In KEW, Approval Types are set up such as account approver, supervisor, or organizational/department hierarchy approver. An Approval Type contains the applicable routing and approval rules. Once you create an approval type, those routing and approval rules are available for other workflow clients and scenarios. This creates a tipping point situation, in which the more applications and business processes you set up through workflow, the easier it gets to do new ones.
In addition, KEW can help you with distributed management of approval structures. Each group at your institution (each college, unit, division, etc.) can create their own approval and workflow structure for their group, and you can centrally manage the workflow above those groups. This allows groups to manage their own internal controls and structures, while still being subject to higher-level institutional controls.
KEW is not a general-purpose application builder. For complex applications, you need to develop applications separately and then integrate them with KEW. For simple forms or documents that need approval, you can use eDocLite, but this only works in simple cases, analogous to a one- or two-page paper form that requires signatures. It is important to note, however, that Kuali Rice does include a framework called the Kuali Nervous System (KNS) that can be used to facilitate the development of more complex applications and includes built-in integration with KEW.
KEW is not a general-purpose business rules engine. For example, it does not know that a continuation account must be specified when an account is closed. Those types of rules are the responsibility of the application itself to manage. However, this is not a clear-cut line, as KEW does manage business rules that directly affect routing and approval.
KEW is not an Organization Hierarchy manager. For example, it will not automatically manage your organizational hierarchies and internal structures. However, integration with these hierarchies and structures can be accomplished using KEW, and leveraging such hierarchies for routing and approval is a very common need for many applications.
Nearly anything, in theory. In the current version of KEW, any application can access KEW if it can:
Do Java method calls, or
Do remote method invocation, or
Do web-services calls, or
Communicate with the Kuali Service Bus (KSB)
(The recommended cross-platform integration method is over web services.)
Yes, absolutely!
KEW is an incredibly powerful platform for routing and approval for enterprise (i.e., large) applications. However, it also includes eDocLite, which makes it easy to develop simple business-process forms and run them through KEW. In this situation, in its most simple form, you can do all of your work within KEW, and most of that work is in developing your form configurations. If needed, the eDocLite process can also hook into a post-processor to take an action once a document's approvals are complete.