Page Comparison

...

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.

Adding New Roles for Additional Stops

Based on the information above, you probably have a decent idea of how to add a new route path stop – simply update the appropriate PeopleFlow to call the desired role at the desired point in the route path. For example, to add a new stop between the Central Portfolio Manager (stop 5) and Central Admin (stop 6), you would add the new stop to either the end of Stage3 or the start of Stage4 (depending on which rule you wanted it to be tied to).

However, the roles themselves are custom "Derived" roles. Unlike regular roles, which are assigned directly to users, Derived Roles instead contain logic which dynamically determines which users are members of the role at any given time. The Dervied Role can also be given parameters when it is called, to be used in determining the result.

Our Tufts derived roles are passed the proposal's department ID as a parameter, and contain logic to look up the appropriate Unit Administrator assignments for that department. Each derived role is a custom Java class with a matching database entry. Examples of how the roles were created can be found in the git repo at the following commits:

Custom java classes for each role: https://gitlab.it.tufts.edu/ras/kc-custom/commit/38b9e814c57972378c1b5213eaff26c4d9ee29d2

Database configuration: https://gitlab.it.tufts.edu/ras/kc-scripts/commit/dc190af86e6d2b6d81fa9accef0ad8e0152b0ef7

To create a completely new role, you would need to:

• Create the new UNIT_ADMINISTRATOR_TYPE entry which represents the new role
• Create the new Java class which extends the AbstractUnitAdministratorDerivedRoleTypeService and implements the Unit Admin lookup for that role
• Create KRIM_TYP_T and KRIM_ROLE_T entries to define the dynamic role within KC

Once complete, you will be able to look up the new KC-WKFLW dynamic role from within the PeopleFlow and add it to the route path. When called, the role will use the given parameters and inbuilt logic to determine the role members.