The word ‘role’ is used in multiple contexts in KC, and this section aims to clarify those for you.
There are four primary kinds of roles involved with usage of the KC system:
• System: relate to e-doc routing status & actions (workflow)
• User Interface: relate to tabbed main menu screens (functional menus)
• Document: relate to e-doc preparation & completion (permissions)
• Proposal: relate to the proposed personnel (research project)
Roles determine which options are available to a KC user. Some roles are determined by the user’s relationship to a particular document. The role of Initiator is automatically assigned by the system to the user who creates a new e-doc. Other roles give additional permissions or options in addition to what normal KC users might possess. For example, a user could be an Approver for a specific e-doc or have the additional role of Administrator, which gives the user options that a normal Approver would not have. It is possible, and sometimes common, for a user to have multiple roles. The primary roles are Initiator, Approver, Delegate, Reviewer, Administrator, and Superuser.
Table 2 System Roles (Workflow) Definition
System Role |
Description |
Initiator |
As an Initiator you can create documents. Any Kuali user may initiate most of the document types, however, an Initiator may be required to belong to a Workgroup for certain restricted document types. |
Approver |
An Approver is someone who has been granted permission in the system to approve a proposal for submission to the sponsor. As an Approver you can approve the documents at any route level (including Ad Hoc routing). As a document moves through Workflow, it moves one route level at a time. An approver operates at a particular route level of the document. The screen view and available action options of a document may vary, depending on whether the document is at that approver’s route level, or at some other route level. |
Delegate |
As a Delegate you can approve documents at a particular level of routing, as if you yourself were at that level yourself. Fiscal Officers can delegate the approval authority to other users based on attributes of a specific transaction, such as document type and dollar amount. There are two kinds of delegates: Primary Delegates and Secondary Delegates. While documents route directly to Primary Delegates instead of routing to Fiscal Officers, they route to Secondary Delegates in addition to Fiscal Officers. The Secondary Delegates have a special filter option in their action list, which allows them to retrieve documents for which they have been given approval authority. |
Reviewer |
As a Reviewer, a document is ad-hoc routed to you for ‘Acknowledgement’, ‘Carbon copy (Cc)’ or ‘For Your Information (FYI).’ |
Administrator |
As an Administrator you can give blanket approval on most transactions you initiate or for which you are an Approver. Blanket approval is a special workflow option that allows the user to force a document into approved status without waiting for the normal routing process to be completed. |
Superuser |
As a Superuser you can fully approve any document in the ‘ENROUTE’ status, can approve or disapprove any document at its current route level, and can cancel any document that has not been fully approved. |
User Interface Roles (Functional Menus)
Figure 8 KC User Screen Menus
User Interface Roles, unlike System Roles or Document Roles, are identified on the main menu as tabs. They include Researcher, Unit, Central Admin., Maintenance and System Admin.. Admin. is an abbreviation for Administrator or Administration, depending on whether you’re referring to purpose of the tab or the user of the tab. The idea behind this user interface design is that your role in research administration work determines the menu tab you are likely to use most often, if not exclusively. Functionality commonly used by a Researcher, for example, appears on the Researcher screen when the Researcher tab is selected, and so on. This feature allows users of KC to quickly access the information they need based on their role in using the system, and eliminates functionality they are not concerned with. While not perfectly tailored to everyone’s needs, particularly when you consider individuals who wear many different hats within smaller organizations, the efficiency, convenience, and simplicity are all improved by providing a screen that has only what a particular user needs, and nothing more.
Table 3 - User Interface Menu Role Definition
Main Menu Tab |
Description |
This screen is designed for the individuals who create proposals and receive awards to conduct research. It allows them to get a proposal started that others complete, view all information related to the proposal they started at any time, view award information associated with proposals at any time, create and view protocols, disclosures, review financial entities, look up opportunities on Grants.gov, and view and modify personnel-related information such as degree, support, bio-sketches & training. Finally, as with all tabbed main menu screens, there is the ability to customize workflow preferences. | |
This screen is designed for the individuals who work in research administration at the unit level. This means they contribute to proposals started by Researchers and typically work in the same unit that the Researchers do. Unit users of KC might coordinate the completion of proposals; do post-award work such as entry of award information into KC, award tracking and reporting; work on ensuring proposals are compliant with various regulations and laws prior to being submitted; and similarly that after a proposal has been submitted the proper protocols are followed leading up to the award; and additional search and routing capabilities that the Researchers do not have. | |
This screen is designed for the individuals who work in the institution’s Central Administration office (also known as Contract & Grant Administration or Office of Sponsored Projects). It offers functions grouped and organized in a very similar manner as the Unit screen, but is meant for use by Central Administrators who may perform the same duties that Unit users would in the absence of personnel resources being available (for example, in a smaller unit in an institution with fewer staff members than other units). | |
This screen is designed for the individuals who need to maintain information that is referenced by e-docs within the KC system via maintenance documents. Maintenance documents are e-docs that provide a user interface for a database of stored information that is sometimes shared by more than one transactional e-doc, and are grouped together on the Maintenance screen accordingly. Similarly, functions related to specific functional modules are also grouped together. In this way, when a code changes for example, a functional user can update it in the system without the need for a technical software expert. | |
This screen is designed for administrators of the KC system by grouping functions those user types need to use frequently to be sure the software is functioning properly. It is for users who have more technical software expertise and work to continually update the behind-the-scenes functions to keep the system running smoothly and according to necessary functional changes. For example, when business rules change, the configuration of the system must also be changed to support them, which might include updates to system parameters, batch schedules, messaging or workflow services. |
Document-Specific Roles (with Corresponding Permissions)
Document roles are user roles for particular document types within the KC system. They allow different types of access for different types of users for a particular document type. This facilitates collaboration on the completion of an e-doc by multiple individuals, each of which take responsibility for portions of a document based on their area of expertise.
Figure 9 Document-Specific Role Examples (Proposal Development)
Figure 10 Document-Specific Role Permissions Examples
For more information about how roles
and permissions are tied together, see
Role in System Admin > Identity. |
Subtopics: