RAS Route Path Config

Basic Route Path Definition

The Route Path within RAS controls which users are required to approve proposals in the PD module, and in what order.

The basic Tufts route path for PD is:

1. Local Admin
2. Manager
3. Department Reviewer (optional escalation)
4. School Financial Reviewer (optional escalation)
5. Central Portfolio Manager
6. Central Administrator (aka Signing Official)

Escalation Factors

Stops # 3 and 4 will only be included if one of five predetermined "escalation factors" are present on the proposal. The factors are defined in JIRA ticket RAS-434, but the basic conditions are:

1. Special Capital Planning Considerations are present on the Proposal Questions questionnaire
2. A Course Release is required, as noted on the Proposal Questions questionnaire
3. The proposal budget contains any amount of cost sharing
4. The proposal budget contains any amount of unrecovered F&A
5. The user has marked that the proposal has "additional considerations that require special review" on the Proposal Questions questionnaire

If ANY of these five conditions are met on the proposal, stops 3 & 4 will be included on the route path. If none of the conditions are met, those stops will be skipped and the route path will go directly from stop #2 to #5.

Short Routing Path

There is a flag in PD named the 'Short Routing Path' flag. This flag can be set by the Central Administrator when rejecting a proposal; when set, the route path will skip ALL of stops 1-5 on subsequent routings, going directly to the Central Administrator. This option is available so that last-minute revisions to the proposal can be processed without requiring every approver to re-approve the record.

Route Path Assignments

Route paths are configured on a per-department basis, so each department ID will have a unique route path. The configuration is done via the RAS 'Unit Administrator' maintenance table. This table contains roles which correspond to each route path stop, and users can be assigned to these roles to configure the route path for a given department. The resulting assignments in the Unit Administrator table will look like this:

Not every role needs to have an assigned approver – only the 'Tufts Central Admin' role is required for each department. The other roles can be populated based on the specific department's needs. Any roles left empty will simply be skipped over in the route path.

Delegates

Each route path role has a corresponding 'Delegate' role. Users assigned to a delegate role will NOT get notifications related to approvals for that role, but will have the ability to approve on behalf of the "regular" approver.

Delegates are assigned the the Unit Administrator table exactly like regular approvers.

Route Path Configuration

The stops on the route path are configured using two Kuali Coeus features: Agenda and PeopleFlow. 

A "PeopleFlow" is simply an ordered collection of people, groups, or roles. These PeopleFlows are used to define the order and definition of the route path stops.

An "Agenda" is a document containing rules which which PeopleFlows are called. 

Tufts Agenda

The Tufts agenda used for routing is named 'TuftsRoutingAgenda'. It can be found by going to the Central Admin → Agenda page and executing a search. (There are only a handful of Agendas in our system, so it shouldn't be hard to find.)

The Agenda contains a number of preset rules, which are executed in sequence. Each rule will result in the proposal either being routed to the linked PeopleFlow (if the rule matches) or passed to the next rule (if the rule does not match). The PeopleFlows for each step can be found and edited via the Central Admin → PeopleFlow menu.

The rules within the TuftsRoutingAgenda are displayed and explained below.

TuftsRoutingStage1

Stage 1 will match all proposals that do NOT have the Short Routing Path flag set. The PeopleFlow for stage 1 will route the proposal to the Tufts Local Admin (stop 1) followed by the Tufts Manager (stop 2).

As seen in the PeopleFlow image below, the 'Tufts Delegate' roles are also set up here as delegate approvers for each stop.

TuftsRoutingStage2

Stage 2 will match proposals that do not have the Short Routing Path flag set, AND have met one of the five Escalation Factors, as discussed above. Each of these five factors has a custom KRMS rule (Kuali Rules Management System) which contains the logic for checking the underlying field on the proposal. Details about creating a KRMS rule can be obtained from Kuali, but you can look up RAS-434 in both the kc-custom and kc-scripts git repos to see how these rules were created. Both custom java code and database configuration are required.

The PeopleFlow for this step will route the proposal to stops 3 and 4 (Department Reviewer and School Financial Reviewer) if the conditions are met.

TuftsRoutingStage3

Stage 3 will match all proposals that do not have the short routing path set. This stage routes the proposal to stop 5, the Central Portfolio Manager.

TuftsRoutingStage4

Stage 4 matches all proposals, and routes the proposal to the Central Administrator for final approval.