C 25x25.jpg                                                                                                                                                                                  K 25x25.jpg








User Manual


For Researchers, Unit Staff, Central Administration Staff, and System Administrators






Edition :  Release Version 3.1                                                                                                                   Date :  July, 2011

Abstract :

To serve as a basis for the training of new system users, this manual provides descriptions of how Kuali Coeus software interacts and performs with manual procedures to respond to research administration events.  It is designed to assist you with using the “out-of-box” functionality to accomplish common research administration tasks.  This content may be modified by your institution based on its unique implementation, customization, configuration, roles, business rules, and processes.  It covers functionality for Proposals, Grants.gov, Protocols, Awards, Budgeting, Compliance, and Workflow; including Coeus 4.5 functional equivalency within the Award, Budget, Proposal Development and Institutional Review Board core modules;  and key Kuali Financial System integration features.






Creative Commons License

Kuali Coeus User Documentation by Kuali Foundation, Inc. is licensed under a Creative Commons Attribution-ShareAlike 3.0 United States License .  Based on a work at testdrive.kc.kuali.org .  Permissions beyond the scope of this license may be available at http://www.kuali.org/download-form .









Introduction               1

About This Documentation               1

Prerequisites               2

Purpose and Audience               2

Organization and Conventions               3

Screen Images and Test Data               4

Institutional Business Processes and KC Implementation               4

Configurable Values               4

User Support Information               5

Using the User Documentation               5

Getting Help with Help               5

Supplemental Online Resources               7

Copyright and Licensing               8

Trademarks               8

Intellectual Property Management               8

Software Licensing               8

Contributor Licensing               9

Documentation Licensing               10

Overview               12

About Kuali Foundation, Inc.               13

About Kuali Coeus               14

Project Vision, History and Partners               14

Key Software Components               15

Functional Modules Overview               17

What’s New In This Release?               19

Downloading, Installing, and Configuring               20

Installation Basics and High-Level Overview               20

Technical Requirements               21

Distribution Download               22

Quickstart Setup               23

Embedded Mode               25

Running the Unit Test Suite               27

Where To Find More KC Technical Documentation               27

Access               29

Identity Management               30

Authorization               30

Authentication               31

Roles and Permissions Overview               32

Logging In and Out               39

Usage Basics               43

Screen Layout & Navigation               43

Selection, Entry & Action Tools               50

Action List               67

Doc Search               73

Searching With Wildcards               79

E-Doc Fundamentals               81

Common E-Doc Sections               88

Workflow Action Buttons               98

Common E-Doc Procedures               100

Initiating a Document               100

Copying a Document               101

Saving a Document               102

Reloading               103

Closing a Document               104

Canceling a Document               105

Routing a Document               106

Searching for a Document               107

Using the Action List               109

Common Line Item Operations               111

Summary               111

Common Maintenance E-Doc Procedures               112

Overview               112

Searching for a Maintenance Document               115

Initiating a Maintenance Document               116

Editing a Maintenance Document               117

Copying a Maintenance Document               119

Submitting a Maintenance Document               120

Saving a Maintenance Document               121

Closing a Maintenance Document               121

Canceling a Maintenance Document               122

Maintenance Document Rules & Routing               123

Summary               123

Main Menus               125

Researcher               128

Unit               135

Central Admin               141

Maintenance               143

System Admin               145

Quicklinks Group               146

Pessimistic Lock Lookup               146

Current & Pending Support               151

Grants.gov Opportunity Lookup               152

Rolodex Lookup               153

Sponsor Lookup               155

Change Password               159

Keyword Lookup               160

Workflow Group               161

Preferences               161

Routing Report               167

Rules               169

Rule Quicklinks               173

Proposal Development               175

Proposal               178

Document Overview               179

Required Fields for Saving Document               180

Sponsor & Program Information               182

Organization/Location               184

Delivery Info               188

Keywords               188

Grants.gov               191

Opportunity Search               193

Submitting to Sponsor via s2s               200

Submission Details               202

Forms               203

Submission History               209

Key Personnel               210

Add Key Personnel               211

Person Attributes               211

Combined Credit Split               216

Special Review               217

Special Review               218

Custom Data               220

Abstracts and Attachments               222

Proposal Attachments               223

Personnel Attachments               226

Internal Attachments               227

Abstracts               228

Notes               229

Questions               229

Grants.gov/Agency Specific Questions               232

Proposal Questions               233

Budget Versions               234

Budget Versions               235

Permissions               237

Assigned Roles               237

Users               238

Proposal Hierarchy               240

Proposal Actions               241

Data Validation               241

Proposal Hierarchy               244

Print               245

Copy to New Document               247

Proposal Data Override               248

Route Log               249

Ad Hoc Recipients               250

Medusa               251

Medusa               251

Budget               254

Budget Versions               257

Parameters               259

Budget Overview               260

Budget Periods & Totals               261

Rates               263

Research F & A               264

Fringe Benefits               266

Inflation               267

Vacation               268

Lab Allocation - Salaries               269

Lab Allocation - Other               270

Other               270

Summary               271

Summary               272

Personnel               274

Select Budget Period               276

Project Personnel               276

Budget Overview               278

Personnel Detail               279

Non-Personnel               280

Select Budget Period               282

Budget Overview               282

Equipment               284

Travel               284

Participant Support               286

Other Direct               286

Distribution & Income               289

Select Budget Period               289

Cost Sharing               290

Unrecovered F&A               291

Project Income               292

Modular Budget               294

Select Modular Budget Period               295

Modular Budget Overview               296

Direct Cost               296

F&A               297

Budget Actions               297

Print Forms               298

Budget Justification               300

Sub Award Budget               301

Proposal & Budget Development Process               302

Institutional Proposal               308

Institutional Proposal               310

Document Overview               311

Institutional Proposal               312

Sponsor & Program Information               314

Financial               317

Graduate Students               318

Notes and Attachments               319

Delivery Info               319

Keywords               320

Contacts               321

Project Personnel               321

Unit Contacts               323

Central Administration Contacts               324

Custom Data               325

Personnel Items for Review               325

Project Details               325

Custom Data               326

Special Review               326

Intellectual Property Review               328

Review Data               329

Activities               330

Distribution               334

Cost Sharing               334

Unrecovered F&A               335

Institutional Proposal Actions               336

Funded Awards               337

Medusa               340

Intellectual Property Review               341

Document Overview               343

Review Data               344

Review Activities               345

Notes and Attachments               346

Ad Hoc Recipients               347

Route Log               347

Proposal Log               348

Edit Proposal Log               351

Protocol               357

Protocol               365

Document Overview               366

Required Fields for Saving Document               367

Status & Dates               368

Risk Levels               369

Additional Information               370

Organizations               373

Funding Sources               374

Participant Types               375

Personnel               376

Add Personnel               377

Questionnaire               380

Custom Data               383

Course Related               383

Special Review               384

Permissions               385

Assigned Roles               386

Users               387

Notes & Attachments               389

Protocol Attachments               389

Personnel Attachments               391

Notes               392

Protocol Actions               393

Request an Action               394

Data Validation               428

Print               428

Summary & History               431

Copy to New Document               434

Route Log               435

Ad Hoc Recipients               436

Online Review               438

Detailed Process Flows               440

Committee               446

Committee               447

Document Overview               449

Committee               450

Area of Research               451

Members               452

Member Details Section               454

Schedule               458

Schedule               459

Meeting               463

Meeting Information               464

Meeting Actions Page               470

Actions               473

Batch Correspondence               474

Print               477

Detailed Process Flows               478

Award               480

Award               486

Document Overview               486

Funding Proposals               487

Details & Dates               493

Subawards               500

Sponsor Template               502

Keywords               505

Contacts               506

Key Personnel and Credit Split               507

Unit Contacts               509

Sponsor Contacts               510

Central Administration Contacts               511

Commitments               512

Cost Sharing               512

Rates               514

Preaward Authorizations               518

Budget Versions               520

Budget Overview               520

Budget Versions               522

Budget Limits               523

Payment, Reports & Terms               524

Payments & Invoices               525

Reports               532

Terms               536

Special Approval               539

Closeout               543

Special Review               545

Custom Data               546

Comments, Notes & Attachments               547

Comments               548

Notes               550

Attachments               551

Award Actions               553

Data Validation               554

Hierarchy Actions               556

Print               562

Ad Hoc Recipients               564

Route Log               565

Medusa               566

Time And Money               570

Document Overview               573

Award Hierarchy               574

Transactions               576

Direct/F&A Funds Distribution               577

Summary               578

Action Summary               581

History               581

Ad Hoc Recipients               582

Route Log               583

Award Budget               584

Budget Versions               586

Parameters               587

Budget Overview               588

Budget Periods & Totals               590

Rates               592

Public Service F & A               593

Fringe Benefits               594

Inflation               595

Vacation               596

Lab Allocation – Salaries               597

Lab Allocation – Other               598

Other               598

Summary               599

Personnel               602

Select Budget Period               604

Project Personnel               605

Budget Overview               607

Personnel Detail               608

Non-Personnel               610

Select Budget Period               612

Budget Overview               612

Equipment               614

Travel               617

Participant Support               620

Other Direct               623

Distribution & Income               626

Cost Sharing               626

Unrecovered F&A               627

Project Income               627

Modular Budget               630

Select Modular Budget Period               630

Modular Budget Overview               631

Direct Cost               631

F&A               632

Budget Actions               633

Print Forms               633

Budget Justification               635

Data Validation               636

Ad Hoc Recipients               636

Route Log               637

KEW Overview               640

Route Levels               642

Workflow Routing               642

Ad Hoc Routing               643

Viewing Route Levels               645

Routing Rules               648

Route Log               648

Route Status               653

Rule Templates and Attributes               654

Maintenance Documents               655

Shared               658

Miscellaneous               780

Proposals               828

Awards               900

Compliance - Conflict of Interest               953

Compliance               955

System Administration               1059

System               1062

Batch               1084

Configuration               1085

Identity               1102

Identity               1106

Locations               1138

Reference               1149

Workflow               1169

Notification               1188

Service Bus               1196

Appendix A:  Configuration Parameters               1213

Appendix B:  Grants.gov Form-Specific Instructions & Mapping Information               1221

Attachments V1.1               1221

Budget V1.1 (Budget Attachments)               1223

CD-511 V1.1 (aka US Dept. of Commerce Certification Regarding Lobbying)               1224

ED Abstract V1.1 (Dept. of Education)               1225

ED Certification Debarment V1.1 (Dept. of Education)               1226

ED GEPA 427 V1.1 (Dept. of Education General Education Provisions Act Notice)               1228

ED SF424 Supplement V1.1               1229

ED524 Budget V1.1 (Dept. of Education Non-Construction Programs)               1230

FaithBased Survey on EEO V1.2 (ensuring equal opportunity for applicants)               1232

GG Lobbying Form V1.1               1233

NASA Other Project Information V1.0               1235

NASA PI and AOR Supplemental Data Sheet V1.0               1237

NASA Senior/Key Person Supplemental Data Sheet V1.0               1239

NSF CoverPage V1.3               1242

NSF DeviationAuthorization V1.1               1244

NSF SuggestedReviewers V1.1               1246

Other Attachments V1.1               1248

PHS Cover Letter V1.2               1249

PHS Fellowship Supplemental V1.2               1250

PHS 398 Checklist V1.3               1265

PHS 398 Career Development Award Supplement form V1.2               1268

PHS 398 Cover Page Supplement V1.4               1273

PHS 398 Modular Budget V1.1               1275

PHS 398 Research Plan V1.3               1277

PHS 398 Research Training Program Plan V1.0               1281

PHS 398 Training Budget V1.0               1284

PHS 398 Training Subaward Budget V1.0               1292

Performance Site V1.4               1294

Project V1.1               1297

RR Budget V1.1 (5 yr) & (10 yr)               1298

RR FedNonFed Budget V1.1 (5 yr) & (10 yr)               1301

RR Key Person V1.1               1303

RR Key Person Expanded V1.2               1304

RR Other Project Information V1.3               1307

RR Personal Data V1.2               1311

RR SF 424 V1.2               1312

RR SF 424-B V1.1 (aka Assurances for non-construction)               1317

RR Subaward Budget Attachment(s) Forms – Detailed & Federal/Non-Federal forms               1318

SF 424A V1.0 (Budget Information – Non-Construction Projects)               1321

SF 424B V1.1 (aka Assurances – Non-Construction Programs)               1324

SF 424 Short V1.0               1325

SF 424 V2.0 (not R&R)               1330

SFLLL V1.1 (aka Disclosure of Lobbying Activities)               1334

Glossary of Terms               1337

Table Of Tables               1407

Table Of Figures               1424

Index               1447



The Kuali Coeus (KC) project is building a comprehensive system to manage the complexities of research administration that fully addresses the needs from the faculty researcher through grants administration to federal funding agencies. KC is using MIT’s proven COEUS system as its baseline design, filling in missing functionality from COEUS, and updating its technical architecture for vendor independence and easier integration with other administration systems.

About This Documentation


KC User Documentation, whether printed or in the form of in-application help, provides high-quality descriptions of how the software system interacts and performs with manual procedures in order to appropriately respond to business events. These user assistance materials are aimed at not only providing a user manual and online help for implementing institutions, but also at providing a basis for the training of new system users .  They also contain descriptions of the detailed functionality of each component of the application, and may thus serve as a reference for users who are already quite familiar with research administration and web-based software.

Types of Documentation Included


Interspersed throughout you will find the following three basic types of user documentation (typically appearing in this general-to-specific order):

        Conceptual documentation includes introductory, summary, overview and reference information that is used to support user understanding. It documents guidelines that: 1) enhance the completion of a task and 2) are best maintained independently so as not to interrupt the flow of learning. It does not provide how-to instruction, is not sequential, and is often in the form of a table. It often appears as a paragraph or two at the very beginning of a topic, or sometimes at the end of a printed user guide in the form of appendices.

        Process documentation contains high-level overviews of process steps and flow charts. It is necessary only if the activity 1) is complex, 2) involves risk, or 3) must be performed in a consistent manner. It details sequential actions written as a series of tasks; and may involve multiple departments and/or users.  This type of content usually contains overview information and business rules.

        Task documentation contains specific, detailed instructions with notes and action results that guide you through screen navigation to accomplish tasks. These often appear as numbered (ordered) lists of steps.  It is necessary only when the use of the system involves a task that: 1) involves user input action (data entry) by a single performer, 2) is complex, 3) involves risk, 4) must be performed in a consistent manner, 5) is best documented as a separate, stand-alone topic, and/or 6) when the task detail is referenced in multiple procedures or is subject to frequent change.

About Role-Based User Documentation :  This comprehensive documentation set is meant to cover basic usage of all functionality that is accessible via the user interface.  It is meant to serve as a source from which smaller, customized, role-based user documents and quick reference guides may be created by the implementing institution.



There are no specific prerequisites for reading this documentation.  However, it will be helpful if you have the following qualifications:

        Basic familiarity with your institution’s research administration business rules and practices

        Working experience with Web-based software application systems

We recommend that you visit http://www.kuali.org for a general orientation, and strongly encourage you to take a “test drive” of the demonstration version of KC that is accessible from this site.  It not only allows you to preview the KC functionality, but more importantly, it gives you the opportunity to practice using the software, which helps to reinforce the concepts and skills introduced in this documentation.


Tip :  KC User Documentation and In-Application Help is not meant to take the place of on-the-job training on your institution’s research administration policies, procedures and tasks.  KC is a tool you will use to accomplish a portion of those tasks, but this documentation is not intended to train you how research administration activities happen at your institution.  Although it covers enough of the very general principles of online research administration to instruct you how to use the software, it does not take into account which users with which job duties use which screens to perform which tasks – this is the responsibility of your unit or department within the organization.  KC’s flexibility for configuration and customization dictates that it is the responsibility of your institution to educate you about its unique implementation of KC.

Purpose and Audience

The purpose of this documentation is to assist you with efficient usage of the KC system by describing its features, tools and processes, including a walkthrough of:

        Screen navigation

        Action options

        Using the software to accomplish tasks

        Electronic document usage and routing

All KC documentation, whether printed or within the application, is meant to demonstrate how the system works and thus serves as a helpful desk reference during day-to-day system usage. Once familiar with the basic functionality of the KC, you can use this guide as a valuable tool for less common tasks, and as an excellent source of information should you experience any difficulties.

The audience of this documentation is any user of the system, however, the focus is on the typical end user involved in research administration activities as opposed to those involved in installation, implementation, technical configuration, maintenance, and system administration.

The term end user is meant to differentiate software developers from the users of the programs they write, and similarly, for information technology professionals to distinguish the system administrator from the users of computer systems for which the administrator is responsible.


Technical Documentation Reference :  For more technical KC documentation aimed at an IT audience, see the online Rice project’s support documentation at https://test.kuali.org/confluence/display/KRDOC which includes global user guides, installation guides, database diagrams, and technical reference guides for notification, workflow, identity management, nervous system and service bus modules.

Organization and Conventions


This documentation employs an information architecture design and set of typographic conventions to make it simple to use.  Having an understanding of the way it is organized and the conventions it uses are important to using it most efficiently.

Information Architecture and Software Design


KC user documentation is generally organized according to the design of the user interface.  Main menu tabs at the top of every screen are designed for user types, and the functionality links displayed on each are grouped according to functional subject matter areas.

The table of contents is organized according to the screens and action options in the software, allowing you to efficiently locate specific information.  Typically, you will find that topics appear as they do in the user interface of the software system in a top-to-bottom, left-to-right fashion, as you would read a website or newspaper.

User Alerts


The following graphical icon symbols are used throughout this user documentation to call your attention to pieces of textual information and statements that can generally be categorized as described:

Table 1 User Alerts


Caution :  Alerts you to important supplementary information that is essential to the completion of a task; or that failure to take or avoid a specific action could potentially result in data loss or security breach.


Note :  Alerts you to supplementary information that is useful to the completion of a task.


Reference :  Alerts you to hyperlinked references to related or supplementary information either located internally in this documentation set or externally on another site.


Tip :  Alerts you to supplementary information that is not essential to the completion of the task at hand, but offers a helpful hint, conceptual idea, or suggestion.

Task :  Alerts you to an activity, typically in the form of process task steps in an ordered list which provide step-by-step instructions for data entry and selection in electronic form fields on software and e-doc screens.

Typographic Conventions


Clickable Icons, Buttons, Options, and Links :  This document adheres to simple documentation standards and style conventions to optimize readability. The formatting of text used to name “things you click on” are typically bold to enhance visual comprehension and improve usability. 

Numbering and Indentation :  Sequential tasks are numbered, while integrated notes and action results are indented in procedures.

User Interface Element Name References :  First initials of each word are generally capitalized when referencing names of documents, pages, sections, and subsections, as is consistent with the user interface element naming convention.

Options and Examples Courier New font is used to format list options and input examples.

Graphics and Screen Shot Images :  Mouse pointer icons and callouts are used frequently on graphics to show you what to click on at each process step.  Where possible, fields in portions of screens are populated with example data to demonstrate acceptable or expected input.

Screen Images and Test Data



Screen images (and data displayed therein) may not be technically identical to what can be viewed in the actual application, and are provided for demonstration purposes only.

Institutional Business Processes and KC Implementation


Various components of KC modules contain functions that are configurable prior to implementation, based on individual institutional business processes. KC is delivered with a set of data elements; some of which come with pre-populated (hard-coded) values, while others are configurable by institution. These may include, but are not limited to, administrative, maintenance and control data such as restrictions, names, types, groups and codes that can be modified, removed or added to, based on your institution's unique business rules.

Configurable Values


Many values referenced in this user documentation are in fact configurable and an institution implementing KC could choose to customize them. Wherever possible an effort has been made to make key values configurable as parameters -as opposed to "hard coding" values into the application. Therefore some of the references in the user documentation to specific values for fields or attributes may in fact be different at your institution depending on the particular configuration decisions.


Refer to “ Appendix A:  Configuration Parameters ” on page Error! Bookmark not defined. within this documentation set for supplementary information that will prove helpful by providing default values and handy tips for both KC-specific and customized Rice parameters.

User Support Information


The following subsections provide information and links to additional online resources where you can find supplemental support for your use of Kuali Coeus software.

Using the User Documentation


The user documentation you are reading is a part of a comprehensive set that delivers three primary output formats that use the same source content.

        PDF :  This documentation set is available in printable PDF format which requires the use of a portable document reader application such as Adobe Acrobat or equivalent. 

        WORD :  It is also available in MS Word (.docx) format so that you may customize it for your institution. 

        HTML :  Lastly, the same content is published as in-application help (HTML) which you may customize using any editor such as Amaya or Dreamweaver.

Getting Help with Help


Although this documentation set is delivered by The Kuali Foundation, Inc., it is meant to serve as a starting point from which to customize for your institution based on your unique implementation of the out-of-box product. 

While you may provide feedback on this documentation to the Foundation directly from within the help itself as noted in the Documentation Feedback subtopic below, you may edit the help using any HTML editor such as Amaya or Dreamweaver. 

The Foundation used the Doc-To-Help help authoring tool to produce the delivered online help.  It uses Word source documents to compile help in their proprietary NetHelp target help format, however, this output is in the form of html pages. 

It is not necessary to use this product in order to customize the help, however, your institution may elect to purchase and install this product from Component One and use the Word source document version of this documentation as the starting point.

Using the online help

Click the question mark icon to access the help system, which provides document, page, or section-level help from anywhere in the application.

Figure 1   Kuali Coeus Context-Sensitive In-Application Help System - E-Doc Help Example

Customizing the online help

Refer to the separate publication entitled “Customizing Kuali Coeus Online Help.pdf” available on the Kuali Public Wiki ( https://wiki.kuali.org/display/KRADOC/Home ), a direct link to which is provided hereyou’re your convenience:  https://wiki.kuali.org/download/attachments/12222528/Customizing+Kuali+Coeus+Online+Help.pdf?version=1&modificationDate=1292518307000

Documentation Feedback

E-mail kc.doc.collab@kuali.org to contact us with comments or suggestions for future documentation editions.  As we write, revise, and evaluate our documentation, your feedback is the most valuable input we receive.

Click the E-Mail icon on the help menu bar from any screen, document or page to immediately provide feedback on a particular help topic.

Figure 2 Topic-Specific In-Application Help E-Mail Feedback

Your default e-mail application is launched with the 'To' and 'Subject' fields automatically populated, along with the help URL in the body of the e-mail. Just add your comments and click Send .

Supplemental Online Resources


Visit http://www.kuali.org/support for information about Kuali Commercial Affiliates.

Visit http://www.kuali.org/kc for general information about the Kuali Coeus project.

Visit http://www.kuali.org for links to FAQs, resource guides, conference information, workshops, feeds, newsletters, test drives, downloads and tutorials.


Test Drive


About KC

       Project Proposal

       Philosophical Principles



       Investing Partners

       Organization Charts



       Project Documentation

       System Requirements

       Resources for Evaluation and Adoption

       Join Collaboration Lists

       Contact Commercial Affiliate


Get Involved

       KC Announcements

       Attend Kuali Days

       Join Collaboration Lists

       Become a Partner

       Become a Commercial Affiliate




Technical Documentation Reference :  For a listing of links to online reference information that goes beyond the scope of end-user documentation, see “ Where To Find More KC Technical Documentation ” on page Error! Bookmark not defined. within this documentation set.

Copyright and Licensing


All Kuali Foundation Licensing information is located online at:  https://test.kuali.org/confluence/display/KULFOUND/Licensing



Kuali ® is a registered trademark of the Trustees of Indiana University.  Other company and product names from contributor organizations may be trademarks of the respective companies with which they are associated.

Intellectual Property Management


The Kuali Foundation has established a set of intellectual property management practices to protect the foundation, its members, and the extended Kuali community.

The Kuali Foundation uses various licenses to distribute software and documentation, to accept regular contributions from individuals and organizations, and to accept large grants of existing software products.

The sections that follow explain Kuali copyright information as it pertains to the following three licensing areas:

        Software Licensing

        Contributor Licensing

        Documentation Licensing

Intellectual Property Contact Information :  If you have any questions about Kuali Intellectual property, please contact The Kuali Foundation at licensing@kuali.org .

Software Licensing




Copyright © 2007-2011 The Kuali Foundation. All rights reserved. Kuali Coeus is licensed for use pursuant to the Educational Community License, Version 2.0 ( http://www.opensource.org/licenses/ecl2.php ). Portions of Kuali Coeus copyrighted by other parties, including the parties listed below, and you should see the licenses directory for complete copyright and licensing information. Questions about licensing should be directed to license@kuali.org .

Contributor Licensing


Copyright 2007-2011 The Kuali Foundation. All rights reserved. Kuali Coeus is licensed for use pursuant to the Educational Community License, Version 2.0. Portions of Kuali Coeus copyrighted by other parties, including the parties listed below, and you should see the licenses directory for complete copyright and licensing information. Questions about licensing should be directed to license@kuali.org .

Third Party Contributions

Portions of Kuali Coeus were developed by Indiana University, Cornell University, Michigan State University, University of Arizona, Massachusetts Institute of Technology, Colorado State University, Iowa State University, University of California - Berkeley, University of California - Davis, West Virginia University, Coeus Consortium, and Huron Consulting. ( http://www.kuali.org/kc ).

This product includes software developed by the Apache Software Foundation ( http://www.apache.org ).

This product includes software developed by ANTLR ( http://www.antlr.org/ ).

This product includes software developed by the JAX-RPC Project part of Project GlassFish ( https://jax-rpc.dev.java.net/ ).

This product includes software developed by the SAAJ Project part of Project GlassFish ( https://saaj.dev.java.net/ ).

This product includes software developed by Displaytag ( http://displaytag.sourceforge.net/11/ ).

This product includes software developed by the JDOM Project ( http://www.jdom.org/ ).

This product includes software developed by the University Corporation for Advanced Internet Development Internet2 Project ( http://www.ucaid.edu ).

This product includes software developed by the Open Symphony Group ( http://www.opensymphony.com/ ).

This product includes software developed by the Indiana University Extreme! Lab ( http://www.extreme.indiana.edu/ ).

This product includes software developed by the SAXPath Project ( http://www.saxpath.org/ ).

This product includes software developed by the JA-SIG Collaborative ( http://www.ja-sig.org/ ).

This product includes software licensed under GNU Lesser General Public License ( http://www.opensource.org/licenses/lgpl-license.php ).

This product includes software licensed under Common Development and Distribution License ( http://www.opensource.org/licenses/cddl1.php ).

This product includes software licensed under Common Public License ( http://www.opensource.org/licenses/cpl1.0.php ).

This product includes software licensed under the Mozilla Public License ( http://www.mozilla.org/MPL/ ).

This product includes the Kuali Rice module licensed under the Kuali Foundation ECL 2.0.

Portions Copyright (c) 2000-2006 The Legion of the Bouncy Castle. All Rights Reserved. ( http://www.bouncycastle.org )

Portions Copyright (c) 2000-2005 INRIA, France Telecom. All Rights Reserved.

Portions Copyright (c) 2001-2006 Sun Microsystems, Inc. All Rights Reserved.

Portions Copyright (c) 2003-2006 The Werken Company. All Rights Reserved. ( http://jaxen.codehaus.org/ )

Portions Copyright (c) 2001-2005 MetaStuff, Ltd. All Rights Reserved. ( http://www.dom4j.org/

Documentation Licensing



  Copyright 2011 by The Kuali Foundation.  Some rights reserved.  

Kuali Coeus User Documentation by the Kuali Foundation is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License .   Permissions beyond the scope of this license may be available at http://www.kuali.org .


Creative Commons License Deed


Attribution-Share Alike 3.0 United States


You are free:

to Share – to copy, distribute, and display the work

to Remix – to make derivative works


Under the following conditions:

Attribution .  You must attribute this work to the Kuali Foundation .

Share Alike .  If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license.

Permissions beyond the scope of this public license are available at http://www.kuali.org .

        For any reuse or distribution, you must make clear to others the license terms of this work.  The best way to do this is with a link to http://www.kuali.org .

        Any of the above conditions can be waived if you get permission from the Kuali Foundation , the copyright holder.

        Apart from the remix rights granted under this license, nothing in this license impairs or restricts the author’s moral rights.



Your fair use and other rights are in no way affected by the above.

The Commons Deed is not a license. It is simply a summary and handy reference for understanding the Legal Code (the full license) — it is a human-readable expression of some of its key terms. Think of it as the user-friendly interface to the Legal Code beneath. This Deed itself has no legal value, and its contents do not appear in the actual license. Creative Commons is not a law firm and does not provide legal services. Distributing of, displaying of, or linking to this Commons Deed does not create an attorney-client relationship.

The information in this document is subject to change without notice. It has been obtained from sources believed to be reliable. Although the authors and the Kuali Foundation have made every effort to ensure the accuracy of this document, neither the authors nor the publisher assumes any liability or responsibility for any inaccuracy or omissions contained therein, or for any loss or damage arising from the information presented.

If you discover any issues with the documentation, please report your findings, in writing, to The Kuali Foundation. The Kuali Foundation does not warrant that this document is error-free.

All other products or company names represented in this document are not to be viewed as endorsements by either the authors or The Kuali Foundation, and may be trademarks for their respective owners.



The focus of this documentation is usage of the Kuali Coeus software application to accomplish research administration tasks.

From a high level, Kuali Coeus consists of four main modules covering the following four functional subject matter areas:  Proposal Preparation and Submission; Proposal Tracking and Negotiation; Awards, Subawards, Report Tracking and Close-Out; and Research Compliance that interact with each other.  Shared amongst them all are Database, Infrastructure, Rice, Reporting and Workflow-related components.

KC Functionality Overview.jpg

Figure 3 KC Functionality Overview Diagram

To maximize what you get out of reading this documentation, it is important that your understanding include two key points about Kuali Coeus software:

        Kuali Coeus is also an ongoing software project , and therefore it is helpful to know a little bit about the project itself that produces the software you will be using.

        The Kuali Foundation is the organization that is responsible for coordinating the software project, so similarly it is helpful for you to know a little bit about this organization as well. 

The next two subsections provide a brief summary of the Foundation and the Project.

About Kuali Foundation, Inc.


The Kuali Foundation is a non-profit, 501(c)(3) corporation that coordinates the development of free / open source administrative software under the Educational Community License . The name "Kuali" came from the Malaysian word for wok . At a time when many colleges and universities are paying tens of millions of dollars for administrative systems, the notion of a wok -- a humble, but essential dish -- seemed appropriate.

The Foundation is incorporated in the United States. Its members are colleges, universities, commercial firms, and interested organizations that share a common vision of open, modular, and distributed software systems.

Figure 4 Kuali Foundation Project Organization and Governance


About Kuali Coeus


The Kuali Coeus (KC) project calls for higher education institutions to collaborate as partners in the design and development of the Research Administration system. As with other Kuali projects, the partner institutions bring resources to the project and a KC Board of senior representatives oversees their deployment in accordance with the model.

Project Vision, History and Partners


Vision :  As the vision statement from its successful proposal to the Andrew W. Mellon Foundation asks,

    "What if any and every college and university could use, without fee, an outstanding research administration system that embodies the 'best of' techniques and processes for research administration, while maintaining the flexibility to fit disparate institutional structures and needs?”

    "This is entirely possible via a community source partnership to pool resources, requirements, and execution of an efficient development process. The software and community developed through this process could meet college and university needs while providing an economically sustainable path for the future."

History :  KC development began in July, 2007 following practices in-line with the Kuali Architecture and Development Standards. In particular, KC follows the modular design and phased releases that the Standards promote. The KC system includes the key modules from Coeus functionality and approved enhancements. Each module is developed during its designated Phase by both a functional committee and a development team working in concert.

Functionality By Release :

        1.0 in July 2008 :  Proposal Development, Budget, Grants.gov System-to-System (S2S) submission

        2.0 in May 2010 :  Proposal Hierarchy, Institutional Proposal/Proposal Log, Awards

        3.0 in October 2010 :  Institutional Review Board (IRB) / Human Participants

        3.1 in Q2 2011 :  Coeus 4.5 functional equivalency in Proposal, Award, Budget & IRB core modules, and KFS integration features.

        Planned for Fall 2011 :  Conflict of Interest, Subawards, Negotiations, Report Tracking, Workflow/Business Rules UI, IACUC, ARRA Reporting, BIRT Integration

        Under Consideration for 2012 :  New functionality may include modules for Bio-Safety Management, Export Controls / ITAR Management, and Chemical Tracking.

Partners :  Founding partners contributing resources and staff to coordinated project teams are: 

        The University of Arizona

        Cornell University and the Weill Medical College

        Indiana University

        Iowa State University

        Massachusetts Institute of Technology

        Michigan State University

        Colorado State University

        University of California, Berkeley

        University of California, Davis

        Coeus Consortium

        Huron Consulting Group

        West Virginia University

Key Software Components


There are many components that work together to make the KC system work, and they are too numerous and often too technical in nature to mention here.  However, this topic aims to briefly summarize the major ones to give you a basic level of understanding that will allow you to use the KC software to accomplish tasks with confidence and success.

Currently falling under the Kuali umbrella is a core system known as Kuali Rice (KR), which is comprised of several technical modules, including Kuali Nervous System (KNS), which encompasses infrastructure components, and  Kuali Enterprise Workflow (KEW), which automates routing of e-docs (electronic documents) for approval according to specified business rules.  These are considered "core" modules because they depend on one another, and non-core modules and their components depend on the core, since they are necessary for other functional modules to operate. The specifications are available for institutions to develop their own interfaces to the core system modules, since any dependency of one non-core component on another non-core component is flexible to allow implementation of unique combinations of subsets via parameterization and service interface definition to meet an institution’s unique needs.

Figure 5   Kuali Rice (KR) Components and Synergy



Kuali Rice (KR) is an enterprise-class middleware suite of integrated products that make up a business application development framework for Kuali and non-Kuali applications using a modular, Service Oriented Architecture (SOA) approach with components such as workflow, notification, and user interface configuration.



Kuali Nervous System (KNS) is the underlying infrastructure code that any KC module may employ to perform its functions. KNS is functionality common to many modules. Examples include creating custom attributes, attaching electronic images, uploading data from desktop applications, lookup/search routines, and database interaction. KNS is a core technical module composed of reusable code components that provide common pieces of functionality. The KNS is a technical framework that enforces consistency in the applications that use it. It promotes adherence to the architectural principles and development standards defined by the Kuali architects. KNS also provides a stable core of development tools providing a more efficient development paradigm.



Kuali Service Bus (KSB) is a simple service bus geared towards easy service integration in an SOA architecture. In a world of difficult-to-use service bus products, KSB focuses on ease of use and integration.

KSB features Message-Driven Service Execution, Transactional Asynchronous Messaging, Synchronous Messaging, Queue Style Messaging, Topic Style Messaging, Quality of Service, Service Discovery, Reliability, Persisted Callback,       Primitive Business Activity Monitoring, Spring Based Integration, and  Programmatic Based Integration.



Kuali Enterprise Workflow (KEW) is the Kuali infrastructure service that electronically routes an e-doc to its approvers in a prescribed sequence, according to established business rules based on the e-doc content. It is considered a general-purpose electronic routing infrastructure or “workflow engine.” Client applications use KEW to automate and regulate the routing and approval processes for the transactions/documents they create. It starts with an e-doc that users compose in a client application such as the KC or some other Web application that requires routing and approval of documents.

KEW then routes the e-doc electronically to the attention of designated individuals, based on institutional or departmental business rules and policies. Via this centralized routing system, users can access and search for many types of e-docs from various client applications.  This is accomplished from a single location, the Action List and Doc Search. The Route Log for a given document allows users to follow its progress. KEW streamlines mediated business processes across the enterprise.



Kuali Identity Management (KIM) provides central identity and access management services. It also provides management features for Identity, Groups, Roles, Permissions, and their relationships with each other.  All integration with KIM is through a simple and consistent service API (Java or Web Services). The services are implemented as a general-purpose solution that could be leveraged by both Kuali and non-Kuali applications alike.

KIM services are architected in such a way as to allow for the reference implementations to be swapped out for custom implementations that integrate with other 3rd party Identity and Access Management solutions. The various services can be swapped out independently of each other. For example, many institutions may have a directory solution for identity, but may not have a central group or permission system. In cases like this, the Identity Service implementation can be replaced while the reference implementations for the other services can remain intact.



Kuali Enterprise Notification (KEN) acts as a broker for all university business-related communications by allowing end-users and other systems to push informative messages to the campus community in a secure and consistent manner. All notifications are processed asynchronously and are delivered to a single list where other messages such as workflow related items (KEW action items) also reside. In addition, end-users can configure their profile to have certain types of messages delivered to other end points such as email, mobile phones, etc.



E-doc is short for electronic document.  The two terms are used interchangeably to refer to KC’s online forms that allow for the entry and selection of information.  That information can then be saved for future modification by one or more designated users, each of whom may have different assigned roles in e-doc completion.  E-docs can be routed to collaborators, reviewers and approvers electronically.  Routing status is tracked.  Records of performed actions are preserved for reference.  In KC, a user initiates a “transaction” from their desktop Web browser by creating a new e-doc.

Upon saving or navigating between the various pages that make up the new e-doc (each with a separate screen), the initiator or collaborator receives immediate feedback on the validity of the document both in light of the appropriateness of data and the compliance with business rules via red error messages right on the document screen.  Valid documents are routed by KEW to one or more designated Reviewers and Approvers based on the type of transaction and content of the e-doc. Fully approved transactional e-docs are sent for final disposition actions.  One of those actions is to format and submit the approved document electronically to external organizations, such as Grants.gov.

Anyone who initiates, reviews or approves research administration transactions may be a user of an e-doc, including: Principal Investigators; Co-Investigators; Departmental Administrators; Departmental support staff, professional staff, and faculty; Fiscal Officers and Delegates; Deans, Directors, and Department Chairs; Institutional Review Board members; Office of Sponsored Projects Reviewers; Preparers; Aggregators; Budget Creators; Narrative Writers; FYI Viewers, etc.

Functional Modules Overview


In addition to the technical system modules, workflow and search-related capabilities, Kuali Coeus has various functional e-docs that are used to accomplish research administration work.  They rely on maintenance e-docs for searchable/selectable reference information used to fill them out prior to being submitted.  These functional e-docs are designed and built according to groups of related pieces of functionality which correspond to business tasks and events in the various phases of research administration work.  As of release 3.1, these modules include:



Proposal Preparation and Submission :  Also known as the Proposal Development module, included are e-docs for the following functions:

        Proposal Development


        Institutional Proposal

        Intellectual Property Review

        Proposal Log


Included in Proposal Development is Grants.gov Submission.

Institutional Proposal (a.k.a. Institute Proposal) also falls under the Proposal Tracking and Negotiation module.

Pre-Submission Compliance


Research Compliance :  Along with Post-Submission Compliance, this is also referred to as the Institutional Review Board (IRB) / Human Subjects module, included is an e-doc for the following function:


Post-Submission Compliance


Research Compliance :  Along with Pre-Submission Compliance, this is also referred to as the Institutional Review Board (IRB) / Human Subjects module, included is an e-doc for the following function:



Future research compliance modules will include IACUC, COI, Bio Safety, Radiation Safety, and more.



Awards, Subawards, Report Tracking and Close-Out :  Also known as the Award module, included are e-docs for the following functions:


        Time & Money

        Award Budget


Future award-related functionality will include Subawards, Report Tracking and ARRA Reporting.



Modules & The User Interface Design :  The KC User Interface (UI) has been thoughtfully designed to organize access to modular functionality by way of menu groups on user-specific screens.  This modular layout follows the logical progression of the various stages of research administration work.  Where possible, this documentation also follows the same general organization principles.

Modules that are technically established in the KC 3.1 system to correspond to Coeus project module codes are:

Figure 6   KC Module Names By Code

What’s New In This Release?


A brief summary of what you’ll find in KC 3.1:

        Kuali Coeus "catch up" release providing Coeus 4.5 functional equivalency within the Award, Budget, Proposal Development, and IRB modules.  This release is a significant milestone for Kuali Coeus in that we will be equivalent with Coeus functionality on the core modules of research administration systems.  This release will also include key integration features with the Kuali Financial System including the ability to automatically create an account upon receiving an award.

        Miscellaneous enhancements to previously-released functionality

Significant effort has been made to ensure this documentation has been updated accordingly to reflect the aforementioned functionality changes and additions.  However, it has been prepared in advance of the official release, and therefore is subject to further modification.  In the event portions of this documentation are incomplete at the time of publishing, every effort has been made to notify you within the corresponding topic heading with an appropriate alert to that effect, which serves as a placeholder for future editions.


For more detail, see the official “ Release Notes ” on the kuali.org site (also included in the software download package).


Downloading, Installing, and Configuring


The primary focus of this documentation set is on using the software after it has been downloaded, installed, and customized as part of your institution’s implementation.

It covers in detail how to use the customization and configuration functionality that is accessible via the user interface .


For more information about technical configuration and monitoring options available from the user interface, see “

System Administration ” on page 1057 within this documentation set.

However, this topic provides some basic technical information that will serve as a good reference for those involved in setting up KC.


Why are installation instructions in the online help?   Typically, this type of information would NOT be included in the online help, since accessing the help from the application means you’ve already installed the application.  However, it is provided here as an online reference due to the fact that many use the online help as a comprehensive, standalone documentation resource.  In addition to being included with the out-of-the-box code, the online help is also integrated into the public test drive, development and testing environments.  Lastly, all documentation within the online help is printable, and many prefer to save direct links for future reference and print topics on demand.  For these reasons, the installation information is included in the online help as well as in the PDF manual.

Installation Basics and High-Level Overview


This topic describes how to install Kuali Coeus on a single server.  The Kuali Coeus application binaries and source code are included as part of the installation distribution.

The Kuali Coeus application assists in the accessibility, administration and support of research information. There are many components that are working together to configure and install Kuali Coeus. The core system is known as Kuali Rice (KR), which is a set of integrated middleware products that allows Kuali Coeus to interface with technical modules running from a web server. Kuali Rice facilitates enterprise workflow functionality and provides customizable and configurable user interfaces that have a clean and universal look and feel. Kuali Rice contains five core modules of which two are actively used in Kuali Coeus. Kuali Enterprise Workflow (KEW) monitors document routing and approval while automating electronic processes and transactions across the enterprise. The Kuali Nervous System (KNS) alternately handles functionality common to many modules and can be thought of as a framework of reusable components providing an abstraction layer for developers to easily integrate with other Kuali Rice components.

Kuali Coeus scales depending upon your environment needs and therefore allows for various architectural choices to be implemented during installation.  This topic covers the essential architectural components that are vital to the overall operation of the system.  Kuali Coeus handles data storage using a database to maintain records. Care must be taken to ensure that the database remains accessible during times when Kuali Coeus is active.  The Kuali Coeus application server manages data for presentation through a web browser.


Technical Requirements


Kuali Coeus is versatile in its ability to deploy on numerous platforms but has only been tested on a select set of platforms. This section describes specific requirements to install Kuali Coeus.

System Server


This section outlines the minimum server requirements for Kuali Coeus.

        Hardware :  Recommended minimum hardware for the web application is 2 cores of a recent CPU architecture along with 2 gig of reserved RAM. Minimum hardware and settings for the database should be based on vendor recommendations, but there should be high bandwidth with low latency between the web application and database as this is a database intensive application.

        Operating Systems :  Any OS which supports either MySQL or Oracle databases should work, including Solaris, but it has been run on Windows, Linux (Ubuntu and RedHat distributions), and MacOSX.

        Web Application Platform :  The Web application platform can be any fully compliant modern J2EE container. Testing has been done with Jetty 6.1, Tomcat 5.5, and Tomcat 6 (still has some minor issues which will be dealt with after release).

        Heap Space :  The Webapp generally required 1 gig of heap space (-Xmx1g) and 256 meg of perm gen space (-XX:MaxPermSize=256m) to start and run. For production use, at least 2 gig of heap and 512 meg of perm gen space are recommended.

        Other Recommended Settings :  Other recommended settings are -server (to improve resource utilization for long-running tasks) and -XX:+UseConcMarkSweepGC (to improve garbage collection performance).

Supporting Application Software


This section outlines the minimum software requirements for Kuali Coeus.

        Sun Microsystems Java Development Kit (JDK 1.5.x)

        Web Application Server (Apache 2.x)

        Servlet container (Apache Tomcat 5.5.x)

        Web Browser (Firefox 1.5.x, Internet Explorer 6.x or Safari 2.0.4.x)

        Apache Ant 1.7.x

        Maven 2.0.x

        Oracle Database 10g Release 2 (10.2.0.x)

        Oracle Database 10g Release 2 (10.2.0.x) JDBC Driver

        MySQL 5.x

        MySQL Connector/J



This section outlines the minimum database requirements for Kuali Coeus. 

KC has been tested against Oracle and MySQL.  Supported versions of database products that Kuali Coeus has been tested with are as follows:

        Oracle10g:  JDBC drivers for Oracle can be obtained from http://www.oracle.com/index.html

        MySQL:  JDBC drivers for MySQL can be obtained from www.mysql.com

KC requires a User Account with access permissions to the database to perform the following:

        Connect to the database

        Create, Alter and Drop Tables, Triggers, Views, Procedures and Sequences

        Insert, Update and Delete data in the database tables

KC recommends the following database settings :

        For MySQL running on a case-sensitive OS (i.e., Linux) it is recommended to use settings to force all table names to lowercase (see other MySQL recommended settings in the Rice documentation).

Distribution Download


To download Kuali Coeus, navigate to the following site and fill out the download form appropriately:


The Kuali Coeus distribution is available from the Kuali Foundation at


The Kuali Coeus download contains:

        Kuali Coeus source code

        Database scripts – Full install and 3.0 to 3.1 upgrade, and 3.0.1 to 3.1 upgrade

        Binary distribution

        Quickstart Startup Guide

        Project licenses

        Kuali Coeus User Manual (PDF)

        Integrated Application Help (HTML)

        Release Notes

        List of known bugs

Extract the ZIP file that you downloaded to the folder of your choice.

Quickstart Setup


Use the following installation instructions to guide you through the baseline out-of-the-box setup.


Information on more advanced configuration and customization can be found in the public documentation .

caution.png Before You Begin - The following are required:

        Java 1.5

        Servlet 2.4 / JSP 2.0 Compatible Servlet Container such as Apache Tomcat 5.5

        Oracle database instance or MySQL database instance

To set up KC:


Run the database scripts using the instructions provided in db_scripts/ReadMe.txt.


Place binary/kc-config.xml in one of the configured default locations: {Userhome}/kuali/main/ptd/kc-config.xml OR /opt/sa_forms/java/ptd/kra/kc-config.xml.

note.png   If you are upgrading and have an existing kc-config.xml in this location, please replace it, as new parameters are often added

       On Windows with Tomcat running as a service, the best location is usually c:\kuali\main\ptd

       To use a different location, open kc-ptd.war and create an "alt.config.location" parameter in /WEB-INF/classes/META-INF/kc-config-build.xml.

       You SHOULD also be able to pass a java parameter of alt.config.location to your j2ee container (not guaranteed to work)

note.png   This file also contains the "build.environment" parameter referenced in the external kc-config.xml file as "environment"


Edit parameters in the external kc-config.xml (that you just placed in step #2) as desired.

       You will at least need to fill in the following parameters with your database connection information: datasource.url, datasource.username, datasource.password.

       You will also need to change application.host to your server's host name (i.e. kuali.yourinstitution.edu).

       Other commonly changed parameters are: application.http.scheme, http.port and app.context.name (be sure app.context.name matches your deployed webapp -- normally the name of your war file)

       If you are using SSL, be sure that application.http.scheme and http.port reflect this.

       If you are using MySQL, see the MySQL changes at the end of this guide.

link.png   For embedded mode or further configuration, please consult “ Embedded Mode ” on page 27 .


For Oracle :   Obtain ojdbc14.jar from an oracle client install ({OracleHome}/jdbc/lib) or the Oracle website (http://www.oracle.com).

For MySQL :   Obtain the jar file for the appropriate MySQL jdbc driver from mysql.com.

   Copy the jdbc jar file into the common jar file library.

   Example:  For Tomcat 5.5, copy ojdbc14.jar into {tomcat install dir}/common/lib.


Deploy kc-ptd.war to your servlet container (see user guide for your particular servlet container).


The KC application should now be accessible at: {application.host}/{app.context.name} (as specified in the external kc-config.xml -- app.context.name is kc-ptd, if not overridden).


Login as 'admin' (click on a tab or option and the login screen will appear).


Ingest the KEW documents.

       Click the System Admin tab and then select XML Ingester from the Workflow pane.

       Find the KEW zip files in the distribution package  (they are located in subdirectories under db_scripts)

       If you did a NEW install, you should ingest the Full-KC-KEW .zip file

       If you upgraded a 2.0 version of KC then only ingest the 3.0 KEW zip file

       Ingestion can take several minutes per zip file, so it is recommended to only do one at a time

       MySQL changes to external kc-config.xml file -- adjust datasource.url as needed to fit your install:

        <param name="datasource.url">jdbc:mysql://localhost:3306/kcdev</param>

        <param name="datasource.ojb.platform">MySQL</param>

End of activity.


Configuration Parameters



Tip :  Refer to “” Appendix A:  Configuration Parameters ” on page Error! Bookmark not defined. ” within this documentation set for supplementary information that will prove helpful by providing default values and handy tips for both KC-specific and Rice parameters.

Embedded Mode


Embedded mode allows you to run KC with a central Rice server.  This has the benefit of a central Doc Search, Action List, and KIM maintenance.

It also allows some processing to be offloaded to the rice server, which provides different scaling characteristics.  Embedded mode is currently the preferred deployment model. 


For a more detailed description of embedded mode, see the Rice documentation [ https://test.kuali.org/confluence/display/KULRICE/Documentation ].

Standalone Rice


1) Create/Configure Rice Server Database

2) Configure Stanalone Rice Server (see example-config/rice-config.xml in the rice project)

3) Startup Rice server

Running KC Client Application In Embedded Mode

Before you begin:


1) Create/Configure KC Database (This will include the Rice Client tables and KC's tables).

2) Setup KC database in Embedded Mode.

        Run the Database setup script

        Select EMBED for your Rice mode

        For Install/Upgrade Embedded Rice Server Side

o          Select Y if you need to cleanly install a new Rice database along with KC data

o          Select N if you need to upgrade an existing Rice database with KC data

2) Configure KC.

To run KC in Embedded Mode:

        Point KC to the client & server databases

        Configure the Rice URL

        Turn off dev-mode

        Set the run modes to embedded for the Rice modules

        Configure a valid keystore for secure communication with Rice

Keystore Example

              <!-- KC Client DB -->

              <param name="datasource.url">jdbc:oracle:thin:@</param>

              <param name="datasource.username">KCDEV</param>

              <param name="datasource.password">secret</param>

              <param name="datasource.ojb.platform">Oracle9i</param>


              <!-- For Embedded Mode -->

              <param name="rice.app.url"></param>


              <param name="kim.runmode">embedded</param>

              <param name="kcb.runmode">embedded</param>

              <param name="kew.runmode">embedded</param>

              <param name="ken.runmode">embedded</param>


              <param name="dev.mode">false</param>


              <!-- Rice Server DB -->

              <param name="server.datasource.url">jdbc:oracle:thin:@</param>

              <param name="server.datasource.username">RICEDEV</param>

              <param name="server.datasource.password">secret</param>

              <param name="server.datasource.ojb.platform">Oracle9i</param>


              <!-- Keystore Configuration -->

              <param name="keystore.file">${user.home}/kuali/main/${environment}/rice.keystore</param>

              <param name="keystore.alias">rice</param>

              <param name="keystore.password">r1c3pw</param>


3) Startup KC.

4) Verify the configuration. 

To verify the configuration, try the following :

        Create a proposal document.  Save it. Close it.  From the main portal page click on Action List -> Find the Proposal -> Log -> Future Action Requests

        Go to System Admin Tab.  Try Person Maintenance or Parameter Maintenance.  These pages should work correctly and they should link to the central rice server.

End of activity.

Running the Unit Test Suite

Running the unit tests helps verify that your install is working properly.  However, it needs special test data loaded in order to run properly.  This data is for testing and demonstration purposes only;  it is not meant for a production environment.

To load the demonstration data:


Set up a fresh unit test database using the schema provided by KC.











Go to db_scripts/demo-data and run the following three scripts in order against your database:

For Oracle :




For MySQL :


       KRC-RELEASE-3_1-Demo- MYSQL.sql

       KC-RELEASE-3_1-Demo- MYSQL.sql

End of activity.


To run the unit test suite:


Set up a unit test database using the schema provided by KC.

Note :  The schema should not contain any data.


Create a configuration file (see /kc_project/src/main/config/userhome/kuali/test/dev/kc-test-config.xml.template).


Place a configuration file in <userhome>//kuali/test/dev/kc-test-config.xml.


Run the junit suite org.kuali.kra.triage.suite.PassSuite.

Note :  This can be done either through maven or with the eclipse launch file (KC - PassSuite.launch).

End of activity.

Where To Find More KC Technical Documentation


The following is a list of links to other sources of information related to Kuali Coeus installation, and references to additional online resources where you can find more information that may prove to be helpful for installation activities:

Kuali Resources


        KC Technical Documentation https://test.kuali.org/confluence/display/KRACOEUS/KC+Technical+Documentation

        Kuali Rice Documentation https://test.kuali.org/confluence/display/KULRICE/Documentation

        KC Implementation Collaboration Group https://test.kuali.org/confluence/display/KRADOC/Collaboration

        KC System Requirements https://test.kuali.org/confluence/display/KRADOC/System+Requirements

        Grants.gov Server Configuration https://test.kuali.org/confluence/display/KRADOC/Grants.gov+Server+Configuration

        Kuali Coeus Implementation SIG https://test.kuali.org/confluence/display/KRADOC/Kuali+Coeus+Implementation+SIG

        KC Technical Toolset https://test.kuali.org/confluence/display/KRADOC/KC+Technical+Toolset

        Kuali Coeus Research Administration SIG wiki page https://test.kuali.org/confluence/display/KRACOEUS/Collaboration

        Kuali Architecture and Development Standards http://kuali.org/files/pdf/KualiStandards.pdf

        KC Test Drive http://kra.testdrive.kuali.org/kra-ptd/portal.jsp

Tomcat Resources


        The Apache Tomcat 5.5 Servlet/JSP Container http://tomcat.apache.org/tomcat-5.5-doc/index.html

        The Apache Jakarta Project http://jakarta.apache.org/

Eclipse Resources


        Eclipse Documentation http://www.eclipse.org/documentation/

Oracle Resources


        Oracle Database Express Edition Getting Started Guide http://download.oracle.com/docs/cd/B25329_01/doc/admin.102/b25610/toc.htm

        Oracle Express Edition Tutorial http://st-curriculum.oracle.com/tutorial/DBXETutorial/index.htm



KC access is primarily determined by workgroups and document types. Depending on institutional requirements and implementation, different access rules can be constructed and associated with specific document types or groups of documents and with specific users or groups of users.



A Workgroup is a collection of users who share a similar responsibility and business function. When a document routes to a workgroup, all members of the workgroup can see that document in their action lists. After any single member of the workgroup takes an action on that document, it is removed from the action lists of all other workgroup members. Access to particular document types can also be controlled by workgroups.

Document Type


Document Type is used to distinguish between the different types of transactions that are possible. A document type generally allows users to perform a set of functions and contains business rules particular to those functions.


While most document types in KC are available for anyone to initiate, there are some that may be restricted to users who are members of particular workgroups.  For information on specific restrictions available for particular document types, see the respective individual document type topics.

Workflow Restrictions


Workflow is used to route a document by matching attributes of a transaction or document with existing rules that indicate where a transaction or document with those particular attributes should go. Most commonly, Workflow is used to collect document approvals. The path of approval can be influenced by the type of action and the content of the document itself.  In this way, workflow can restrict the access to portions of the system and/or portions of data for a particular user based on the underlying, configurable business rules.


For more information about workflow as it applies to types of application access by role, see “

KEW Overview ” on page 642 .

Impediments to Access


Locking Considerations :  When more than one user has accessed and is editing the same document at the same time, there are document locking rules that can be quite complex to a new KC user regarding this that, when not followed, could result in loss of data entry work.


For more information about document locking, see “ Document Locking ” on page 89 in E-Doc Fundamentals.

Browser Navigation Button Usage :  As a general rule, we strongly suggest that you never use your Web browser’s navigation tools (for example, the Back button) while using the KC system.


For more information about Web browser functionality as it relates to usage of the KC Web application, see “ Screen Layout & Navigation ” on page 45 in KC Overview.

System Timeout :  The timing out of your user session in the KC system also has an effect on your application access.


For more information about access duration limits, see “ System Timeout ” on page 43 in Logging In and Out.

Identity Management

Kuali Identity Management (KIM) is a Kuali module that provides a means for authorization and definition of user permissions.  It is one of many modules that comprise Kuali Rice.  Customizable and configurable by implementing institutions, KIM uses namespaces to restrict who has access to what.  Examples include restricting available user interface options based on a user’s identity.  This flexibility allows the KC system to be presented to the user in such a way as to limit them to only what they need to use to accomplish their particular job. 


For more information about Kuali’s identity management module, see “ http://rice.kuali.org/kim/ ” in the Kuali Rice Web site.



See also:  “ Basic KIM Concepts ” on page 1100 in System Admin > Identity.



Authorization in KC works based on the permissions users have for viewing, creating and modifying documents.  It functions as a behind-the-scenes service that gets the user name, document name, and task the user was attempting and then asks “is this user authorized to perform this particular task for this document?.”  The user is either authorized to continue with the permitted task, or a violation error message is displayed.


For more technical information about KC Authorization, see “ https://test.kuali.org/confluence/display/KCDOC/Technical+Documentation ” in the Kuali wiki.

Most documents in KC include a Permissions Page with tabs for Assigned Roles and Users.


For example, for more information on assigned roles and users for Proposal Development documents, see “ Permissions ” on page 239 in Proposal Development.



KIM itself does not implement authentication services. It's assumed that an implementer will use existing services (such as CAS or Shiboleth) for this. However, KIM provides a service abstraction which allows for integrating with the authentication systems to help extract information about who has authenticated to the application.

Central Authentication Service


The default implementation of the authentication module shipped with KC uses the Central Authentication Service (CAS) authentication system.  CAS is the authentication system used by Yale University and Indiana University, and is the standard system at those institutions by which Web applications authenticate users. 

Figure 7 Generic, Default KC Login Screen

KC authenticates users based on the prevailing institutional practice.


Your institution may have opted to extend KC to use a different authentication service instead of the CAS framework.

Roles and Permissions Overview


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)

System Roles (Workflow)


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



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.


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.


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.


As a Reviewer, a document is ad-hoc routed to you for ‘Acknowledgement’, ‘Carbon copy (Cc)’ or ‘For Your Information (FYI).’


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.


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



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.

Central Admin

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.

System Admin

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 ” on page 1119 in System Admin > Identity.

User Roles for Document Development


Document-specific roles and associated permissions exist for each e-doc within KC.  These are related to the roles of those users involved in completing the preparation of the document, and submitting the document for review and approval.  Only after documents are prepared and approved are they then submitted elsewhere – to an external system (for example, Grants.gov) or to another group of users (for example, an IRB Committee).  When performing a custom document search on a specific document type that supports user role bound searches in KC, you will be given the option to select the roles that you want to constrain your search by.  These roles are always relative to the currently-logged-in user.  Roles to ensure that only specified users can view or change all or parts of an electronic document.


Table 4 :  Role Descriptions > Proposal Development Document Example

Prop. Dev. Role



The Aggregator is an assigned role in KC that allows the user to make changes to any part of the proposal.  In the paper world, this is the person who puts the parts of the proposal together and submits the proposal to the Office of Sponsored Projects (OSP).  Additionally, this person assigns roles for completing the proposal.  While the OSP may have the system role of Initiator for a Proposal Development Document, the Aggregator may also edit it electronically.  Typically, this Initiator is a member of the staff that is associated with the faculty department or college who assembles the proposal.

Budget Creator

Creates the Budget Document that is associated with the Proposal document.  Typically, this is a member of the institution’s administrative staff (as opposed to faculty) who is a department or business office manager who might confer with Office of Sponsored Projects.  However, some Principal Investigators (faculty members) create their own budgets.

Narrative Writer

Creates the proposal narrative.  Typically, faculty or students write proposal narratives and enter them within KC, but they may also have administrative staff enter it on their behalf.


Reads Proposal documents (cannot create new or edit existing).


Approves Proposal documents. Typically individuals with this role work at Dean, Dept. Chair, Research Office or Business Manager levels, but some might also be Fiscal Officers, depending on institutional needs.





Figure 11 Rights (Permissions) By User Role > Proposal Development Document Example


For more information on document-specific permissions, assigned roles and user types, see the corresponding topic for each individual e-doc.

Proposal Roles (Research Project)


Yet another type of role associated with use of KC is a role within the Proposal document that a user (with Aggregator rights that allow for Proposal document access maintenance) is able to assign to other users.  These role names exist for the purpose of identification of the individual institution employees (or in some cases, third-party contributors) that will be involved in conducting the research, carrying out the work stipulated in contracts, and ensuring the award conditions are met.

There are three such roles.  They are:

Figure 12 :  Proposal Personnel Role Selection

Table 5 :  Research Project Proposal Role Definition

Research Role


Principal Investigator

Faculty members who are requesting money from sponsor agencies to use to conduct research.  The individual bearing primary responsibility for all essential aspects of the project or protocol, including programmatic work, compliance with government, sponsor and university policies and regulations, fiscal stewardship of sponsored funds, and all administrative requirements of the project. The Principal Investigator/Project Director/Program Director (PI/PD) is the individual designated by the grantee, and approved by the sponsoring agency, who will be responsible for the scientific or technical direction of the project.  If more than one, the first one listed will have primary responsibility for the project and the submission of reports.  All others listed are considered co-PI/PD, and share in the responsibility of the scientific or technical direction of the project.  The term "Principal Investigator" generally is used in research projects, while the term "Project Director/Program Director" generally is used in education, and service projects. 

pencil-small The federal government is making the switch to the term “PD/PI” for all projects.


May be another faculty member from the same institution, a student (usually a graduate student), a faculty member from another institution, or an employee of an organization other than the PI’s institution.  Investigators who share responsibility for the scientific or technical direction of the sponsored project.

Key Person

An individual (faculty, student or non-employee) who will play a prominent role in the research activities associated with a proposal.  The role in which each Key Person will be assigned for the proposed sponsored project.  A named contributor (other than the PI) who is integral to the proposed sponsored project, or who makes a significant contribution to the scientific development or execution of the project, including Consultants (if applicable) and mentors on Career awards.  This includes Key Personnel and Other Significant Contributors as defined by NIH and Grants.gov.  All individuals who contribute in a substantive, measurable way to the scientific development or execution of the project or protocol, whether or not salaries are requested (NIH definition). 



Related Information



Identity Management :  For more information about document-specific roles and permissions, see “

Identity ” on page 1100   in System Admin.

Logging In and Out

Starting KC


Since KC is a Web-based system, it is accessed via conventional means using a Web browser.  Contact your System Administrator for the exact Uniform Resource Locator (URL) link.


You may want to bookmark this in your browser, or add it as a shortcut to your desktop if it is not integrated into another existing Web application portal.

        Enter the URL for KC (for example, https://test.kuali.org/KC-reg/portal.jsp ) into your browser’s Address box (a.k.a Location Bar) and click Go (or press your keyboard’s Enter key).

The Main Menu appears:

The default start screen (Main Menu) displays a message in the notification area of the menu bar that ‘ You are not logged in.

Logging In


When selecting an item on the Main Menu tab (or another tab) for the first time in a session, KC prompts you to enter a User ID and Password.  KC performs user authentication and authorization to restrict access to business transactions, according to the prevailing practices at your institution.


If your institution opts to integrate the user authentication to a different campus authentication system, the login sequence might vary.

Figure 13   JASIG CAS Demo Login

Enter your UserID and Password as appropriate and click Login .

        The notification area of the menu bar displays your user ID.

        You are able to navigate the system and perform actions according to your role.

Figure 14 Logged In User display


After you have logged in, you are not asked to log in again until you log out from the system by closing the browser.



Typical of demonstration and training environments, your implementation of KC may include the ability to impersonate other users after logging in.  This is particularly useful when showing how screens, documents and action options may differ depending on the workgroup or permissions associated with certain users.  If so, you will see a login box with button in the upper right corner of any screen.  When used, the notification area displays both your ID and the one you are impersonating.

Figure 15 Login To Impersonate

Figure 16 On-Screen Impersonation Notification

Figure 17 On-Document Reminder:  ‘Backdoor Id “…” is in use’

Logging Out


To log out from KC, simply close the Web browser by clicking the standard Close button window-close located in the upper right corner of your browser.


Depending on your institution’s implementation of Single Sign-On (SSO), this may remove automatic logins to other Web applications or systems.  Consult your System Administrator to be certain.

System Timeout


Figure 18 Session Expiration Message


The system may “time out” after a period of inactivity which could result in lost work and require logging in again.  Consult your System Administrator for specific duration and consequences.  The KC default is 60 minutes.  Upon a session expiration, document locks will be released .  Each time you click the save button (or navigate to a new page), the timer is reset.

Changing Your Password

Changing your password is done by clicking the Change Password link on the main menu.  Your institution may have chosen to disable this functionality and use a different means to accomplish this.  If so, you will not see this option, and should instead consult your system administrator for instructions.


  To change your password:

1.  Click the Change Password link.

     The Change Password tab appears:

Figure 19 Change Password Tab

2.  Enter your current password, new password, and confirmation of new password in the corresponding fields as desired.

     Asterisks appear in place of the characters of your entries.

3.  Click the save button.

End of activity.

Usage Basics


To help you navigate and use KC’s user interface successfully and without confusion, the following subtopics outline the various menus and functions that are common throughout the system.  They demonstrate how the system is organized so that you will become familiar with where in the application to find certain types of information and pieces of functionality, with element terms that are used consistently throughout this documentation.

Screen Layout & Navigation


Most KC screens have design constants such as a header, body, and footer.  The header displays the KC logo on the left, menu tabs in the center, and a feedback e-mail link on the top, right. 

A horizontal toolbar separates the header from the body with workflow action buttons on the left, a display of your user name, and a login tool that allows for impersonation of other user roles (used for system diagnosis and training demonstration). 

While the header and footer remain static, the body area is dynamic depending on which piece of functionality has been selected.  When e-docs accessed from a menu screen and are currently displayed, the body contains e-doc page and e-doc section tabs.  Lastly, the footer displays copyright information and the small “k” logo.

The following topics briefly describe the purpose and function of each of the major screen elements in KC:

Menu Access


Horizontally laid out across the top of any KC screen (header area, to the right of the KC logo) are tabs that have the look of file folder tabs. 

The KC user interface is organized at the highest level by five menus that appear as having the look of file folder tabs at the top center of the screen (header area, to the right of the KC logo) – Researcher, Unit, Central Admin, Maintenance and System Admin.  They are laid out horizontally across the top of any system screen.

Figure 20 KC Menu Tabs

The menu that is currently displayed is highlighted in red background with white letters, while the hidden menu tabs have black label text and tan backgrounds.

Figure 21 Menu Tab Navigation Example:  Navigating to a different menu

When you hover your mouse cursor over a hidden screen tab, you will see that your arrow icon is changed to a pointing hand,  the label text becomes underlined, and tip text pops up to indicate that you are able to click to select and display the menu.


Menus contain Groups.

Figure 22 KC Central Admin Menu Example


Groups are boxes that contain lists of functionality that can be accessed via icons or links.  The boxes have red heading text and occasionally black, bolded subheading sections that group functionally-related features.


Figure 23   KC Group Box Example

Group Icons

Lists of e-docs displayed in Groups contain icons for creating new and searching for existing document.

Figure 24   KC User Interface Icon Buttons for Create New and Look Up E-Docs




Group Links

Some Groups display bullet lists of underlined text that function as links to other areas of KC (usually to either e-docs or lookup screens).  Clicking an underlined link causes a new screen to appear (which dynamically changes the body portion of the web screen).


Figure 25 Group Link Example:  Create Proposal Link in Proposals Group

Figure 26 Menu Link Example:  The Sponsor link in the General section of the Inquiries and Lookups menu group

Group Sections


Black, bold headings within each menu group further divide and categorize functionally-related features.

Figure 27 Menu Section Examples:  The Conflict of Interest and Institutional Review Board sections of the Compliance group

Browser Navigation Warning

Whether attempting to navigate from screen to screen, menu to menu, or page to page, it is strongly recommended that you never use your Web browser’s navigation tools (for example, the Back, Forward, and Refresh buttons).   The tools on the horizontal toolbar near the top of the Web browser you use to access and use the KC software application with are not intended to be used for navigation (or for any other function) within the KC screens and pages.  KC is designed for compatibility with most popular browsers, but is not designed to use their functionality for anything other than viewing the display of the user interface. 

Figure 28 Just Say No To Using Browser Buttons


Clicking one of your Web browser’s navigation buttons (for example, the [ Back] button to go to a previous screen or page) while using KC could possibly result in :

        Loss of entry/selection work

        System-generated error messages

        Automatic refresh

        Disabled functionality

        A need to delete a document lock

        Loss of a document lock


If you do click Back by accident , it might not have a negative impact at all.  However, it is recommended that you log out completely, close your Web browser, and open a new browser window to log in again, rather than simply reloading the page with a KC action button or browser refresh button, both of which may not be reliable mitigating options.

Default Start Menu

Figure 29 Startup screen tab in forefront along menu

After successful authentication and login, the screen that is actively displayed by default has its menu tab appear with white text against a red background.  This may also be referred to as the “main menu”, “dashboard” or “portal”, but it is the screen that is displayed after you log in, and theoretically, the one that you will use the most based on your typical job duties as they relate to use of KC.


The initial screen default may be different depending on your implementation and role.  For example, if you primarily work with maintenance documents and/or system administration, your Administrator system role might dictate that the Administration menu is displayed by default after successful login instead of Main.

Selection, Entry & Action Tools


This topic covers basic user interface element tools that appear on various screens and e-docs throughout the KC system which allow for selection of options, entry of information, navigation, display customization, and action command initiation.



(also known as drop-down menu, combo box or list box) Arrow associated with a combo or list box indicating a list that drops (expands) downward for viewing. Click the down arrow icon to list menu options, and then click the text to highlight and select an option (may expand upward to take advantage of available screen real estate).

Check Box


(also known as selection box) Square box that is selected or cleared to turn on or off an option. More than one check box can be selected. Use a mouse to click within the box to place a check mark symbol to indicate the option is selected.




(also known as radio button, option button) Round button used to select one of a group of mutually exclusive options. Use a mouse to click within the circle to place a dot symbol to indicate the option is selected.



text box

(also known as edit box, text box or entry field) Rectangular box in which you can type text. If the box already contains text, you can select that default text or delete it and type new text. Use a keyboard to type or clipboard to paste text and numbers into the field. 

Autocomplete Functionality :  Recent entries will appear as autocomplete options when a portion is entered.  If desired, click the text you are presented with to populate the remainder of the box without having to type it and complete your field entry.


Accessibility Note :  You must click your mouse cursor within the box (essentially selecting that field for entry) in order to enable the entering of text into it, however, an alternative method is to use the [tab] key on your keyboard until the blinking cursor appears on the left of the box.  Many KC screens allow for tabbed field/option/button navigation to make keyboard entry more efficient.

Default Tabbing Sequence


  On all screens, the default tabbing sequence is top-to-bottom (down the first column, on to the second column and down, and so on) unless otherwise specified by instructions appearing on the relevant portion of the screen.  Alternatively, the standard of left-to-right (across the first row, on to the second row and across, and so on) is used.

All editable fields for a given (expanded) tabbed e-doc section are navigated to first, then all “local” buttons (buttons or links that do not take you to another screen), even if a strict top-to-bottom or left-to-right order is violated between fields and buttons.

The following widgets will not gain focus by tabbing: “non-local” buttons (buttons or links that change screen focus) and icon buttons such as Lookup or Inquiry.

Enter Key


Default Enter Behavior :  On all screens, pressing your keyboard’s [Enter] key will by default refresh the screen unless another button or link has focus, in which case that button or link will be activated as though clicked. Alternate behaviors may be specified on a page-by-page or section-by-section basis.



(also known as add document or create new e-doc) Round, green button with plus symbol that appears to the right of the e-doc name on the Main menu.  Clicking it initiates an e-doc with a unique system-assigned document number.

Figure 30 Add Button Example:  Clicking the Add button to create a new Proposal Development document

        Click the add button to the right of the e-doc name (for example, Proposal Development).

        A new, blank Proposal Development Document appears with a new Doc Nbr :

Figure 31 New, Blank Proposal Development Document With Unique Document Number Displayed In Document Header Area



Lookup screens are accessed either by clicking menu links or by clicking the Lookup icon (round magnifying glass) located to the right of fields on various screens and documents throughout the KC system.  This function (sometimes referred to as “search” or “inquiry and maintenance” ) allows you to look up reference table information from maintenance documents and display a list of valid values from which to select and return to populate the field.  This enables you to find what you need when all or a portion of the valid value is unknown, and prevents you from making data entry errors.  Usage of functionality associated with Lookups is covered here according to the following subtopics:

        Search Criteria Entry/Selection

        Search Results

        Maintenance Links

        Export Functionality

        Field Lookup

        Multiple Value Lookup

Search Criteria Entry/Selection

        Required Fields :  Some fields in the search criteria section of Lookup screens are required to conduct the search, and are marked with an asterisk (*) to the left of the field label, as with e-doc screens.

        Lookup Fields :  Search criteria section fields marked with the Lookup icon (round magnifying glass) on the right of the entry box allow you to look up the reference table information to select from in order to specify search criteria and avoid data entry errors.  Click the icon to display a list of valid values from which to select and return to populate the box.

        Direct Inquiry Fields :  Search criteria section fields that also have the Direct Inquiry icon (open book) appearing to the right enable you to…


        Selection Tools :  Standard selection tools are provided for some criteria section fields.  Use the drop-down menus and radio buttons to select options to specify search criteria as appropriate.

        Date Fields :  Dates should be specified as mm/dd/yyyy format.  Click the date selector icon where available to select a date from a calendar to populate date fields.

        Action Buttons :  Click search to initiate your search, clear to return search criteria fields you previously populated to a blank state, or cancel to return to the main menu.

        Create New and Main :  Click the create new button on the upper-right corner of the Lookup screen to navigate to a new, blank document for creating a new record for the lookup document type that is displayed when clicked.  Click the Main link to return to the default start screen (main menu).

        Wildcard Use :  Wildcard (%) and truncation (*) symbols are allowed on strings when a portion of search criteria is known.  Use the wildcard and truncation symbols to create searches where there are unknown characters, multiple spellings or various beginnings/endings.  Enter the prefix, suffix, or root of a search term and replace the missing portion with an asterisk to find all forms of that word.  Use the wildcard within your search criteria entry to replace each unknown character within a term to find all citations of that word with the percent symbol replaced by a letter.


For more detailed instructions about how to use wildcards for searching, see “ Searching With Wildcards ” on page 81 .

        Range Operators :  Range operators allowed on numerics and dates are >,<,>=,<=, or ‘..’.  All operators except .. should be before date value. Operator ‘..’ should separate date values.

        Direct Inquiry :  Find records based on parameters entered for a particular section.



For more information about using the direct inquiry feature, see “ Direct Inquiry ” on page Error! Bookmark not defined. .

Search Results

        Column Headings :  Each result field has link on header for sorting. Click once to sort ascending, and click again to sort descending.

        Result Text Case :  Most search result content is displayed in uppercase.

        Inquiry Drilldowns :  Some row fields have links to inquiry. The inquiry will be presented in a new window.

        Return value :  Click the return value link to select a row and return the key value to the previous page. 

        Return with no value :  Click return with no value or click the cancel button if you wish to return to the lookup screen without returning a value.

Maintenance Links

        Actions Column :  For each result row the action column displays edit and copy links.

        Edit Link :  Click edit to navigate to a maintenance document for editing the current record.

        Copy Link :  Click copy to navigate to a new maintenance document but copy over attributes to replace the current record.

Export Functionality

        Export Option Links :  At the end of each result set, there are links for exporting the data to a different format.  If you wish to export the result of the table lookup to your local computer, either in the CSV, Excel, or XML format, simply click CSV to export the data as a comma delimited file (comma separated value), spreadsheet to export the data as a spreadsheet, or XML to export the data as xml (extensible markup language).

        Open With/Save Options :  Depending on your settings, your computer’s default Web download manager application will prompt you to either open the file with the default application, choose another to open it with, or save the exported file to a default location on your computer’s hard drive.

Field Lookup

When the Lookup icon appears to the right of a field, clicking it takes you to a lookup screen which allows you to enter search criteria and return a list of valid values from which to select and return in order to populate the field.

To look up valid values:


Fill in one or more search criteria boxes to get a list of valid values in the field lookup (or leave all the search criteria blank to retrieve all).


Click buttonsmall_search search.

A results table appears below the search criteria section of the screen, displaying the list of applicable values that you have requested.


Available Actions From Field Lookup Results

After KC retrieves valid values in the field lookup and displays the list, you may take the following actions by clicking the hyperlinks available in the results table.

        Click the name of the column to sort the retrieved values by that column (alphanumeric ascending/descending toggle).

        Click return value to select the code.

        Click return with no value to cancel the search (or click cancel).

Multiple Value Lookup

Some documents that require a list of values come with a special multiple value lookup screen where you may select multiple values from the search list.

You will find the Look Up / Add Multiple xxx Lines searchicon   (where xxx is the name of the attributes you are updating) in the applicable section of the tab where this feature is available.

  To look up, select and return multiple values:

        Click the Look Up / Add Multiple xxx Lines searchicon   icon to navigate to a special search screen where you are given an opportunity to build a list of values from which you may choose one or more values by selecting the check boxes in the right most column.

        Then click either:

o          buttonsmall_selectall to select all values in the list

o          buttonsmall_unselall   to clear the check boxes for all values in the list

o          buttonsmall_retselected   to populate the tab you came from with multiple values

o          buttonsmall_retnovalue   to return to the tab you came from without populating the tab

Route Log Icon



The Route Log icon (magnifying glass over a piece of paper) appears in search result tables that, when clicked, causes Route Log information to display in a new browser window in the forefront of the KC application.  It displays the same document status and routing information that can be accessed and viewed from the Route Log tab that is common to many e-docs (for example, in the Proposal Development document, this tab appears on the Proposal Actions page).


For more detailed information about the Route Log tab, see the “ Route Log ” on page Error! Bookmark not defined. .

Expand Text Area


The Expand Text Area icon displays a larger text entry box in a separate pop-up window that allows you to view/edit text with more “screen real estate.”

Figure 32 Enter Text and Click Return

View Previously-Entered Text :  When accessing an existing, saved document where text has already been entered into a text box field, you will see that the “add note” icon (pencil with plus + symbol) has been replaced by the green arrow icon.  Clicking it causes a new browser (or tab, depending on your browser settings) popup window to appear containing the note text and a close button that allows you to close the expanded text area window and return to the document after viewing the note.

Direct Inquiry


The Direct Inquiry feature appears as an open book icon.  It usually appears to the right of the lookup icon for most editable fields.  Its purpose is to display an inquiry screen when the field contains a valid value and the icon is clicked.

It allows you to populate the field quickly and differs from the lookup icon by automatically returning a valid table value from the database.

        Enter known information into the box (for example, Sponsor ID field).

        Click the Direct Inquiry icon.

A pop-up window appears in the forefront, displaying identifying information available for the code you entered:

Figure 33 Direct Inquiry Result Popup Window Example:  Sponsor Tab Identifying Information

To retain the information in this window for future reference in populating your currently-accessed e-doc, you can either click on the e-doc screen again to cause this popup to be in the background, or you can minimize it by clicking the minimize browser button to keep it handy and readily available.

To close the information displayed when no longer needed, click the browser close button to close the popup window and return to e-doc screen.

Successful Inquiry Results

When the information to populate a field is known and entered, clicking the Direct Inquiry icon will cause the related text to be displayed beneath the field:

Figure 34 This display of the name serves as confirmation that the field value you entered is valid

Inquiry Errors

Otherwise, a red error message is displayed:

When you click the close button on the popup error message window, the ‘ not found ’ message is displayed under the field:



The Calendar (also known as date selector) icon enables you to populate date entry form fields by selecting dates from a navigable calendar.

About the Calendar icon

Date Selection Help Within the Tool

Click on the Calendar icon to display the calendar

Use Navigation buttons as necessary to locate

Figure 35 Date Selector (Calendar icon) Click on the numbered date to select it

The calendar closes and your selection appears in the box

Error Icon


The large, yellow asterisk icon marks document areas that contain errors after validation.

Figure 36 Error Icon on a Tab

Figure 37 Error Icon on a Field

Sort Column



The column sort toggle button (a down arrow on the left with an up arrow on the right) allows you to sort the display of a search result table by that column.  Unlike other table headings where the column heading text is underlined and can be clicked on directly to sort, table column heading text that contains sort column buttons is not underlined, and has the buttons appearing one row below the heading, centered under each column heading.

Figure 38 Column Sort Function

Clicking the column once will sort the columns contents in an ascending fashion (whether alphabetical or numeric), and then clicking it a second time will sort the data in descending order.  Column sort buttons are typically used on Multiple Value Lookup screens.


For more information on searching for multiple values, see “Multiple Value Lookup” on page Error! Bookmark not defined. .

Expand/Collapse All


You may expand or collapse all tabs by clicking expand all or collapse all .  These two buttons are located at the top, right of e-doc pages.

Clicking the collapse all button on an e-doc page

For example, when you click the button (shown above) while one or more sections have their content displayed, all of the sections of the page that contain the form fields become hidden from view and only the tab labels are displayed (as shown below):

Figure 39 An e-doc page with all sections collapsed



Use the show or hide buttons (located on the tabs to the right of the section labels) to expand or collapse an individual page section.

The tab button displays ‘ show ’ when the page section is closed

The tab button displays ‘ hide ’ when the page section is open

Site Index


Site Index is a blue button appearing at the top, right of e-doc screens and to the left of the “expand/collapse all” buttons.  The word “site” refers to the Web site that is synonymous with the KC system, specifically its web-based user interface.  Click it to view an index of the KC system.

Required Fields


All of the required fields are denoted with an asterisk * appearing to the left of the field label text. 

They serve as an indication that you must complete the particular field before you are able to perform one of the following actions:

        add a line (to create a new item in a table row by clicking an add button)

        save the document (either when new or to save changes made to existing)

        navigate to a different page (which forces an implicit save)


Some fields may not be marked as required and are indeed not required to perform these three actions, however, they may be required for successful validation (for example, Custom Fields in the Proposal document).

Figure 40 Required field asterisk appears to the left of the field label text

Figure 41 Field-level help includes a Yes/No Required? Display



Some selections for particular required fields cause other fields to become required, even though they are not marked as such.  For example, on the Proposal document, when your selection for the Proposal Type field on the Required Fields for Saving Document tab is “Renewal”, “Revision” or “Continuation”, the Sponsor Proposal ID field on the Sponsor & Program Information tab becomes required.  You are notified of this via red error messages upon validation or save.

Drilldown Links and Icons


Since the KC system is a web-based application, hyperlinks and icons are used both for navigation and for information display.  Many of them allow you to drill down into the document detail or to obtain additional information.

Drilldown Links


Figure 42 Three Types of Drilldown Links within a search result table

Field-Level Help


Field-level help functions as drill-down links by labels that can be clicked to display more information about the field.

To access field-level help:

        Click any field label text that is underlined (for example, Description on the Document Overview section).

A new browser window pops up in the forefront that displays the help information:

Typically, the Kuali Help information that is displayed comes from a data dictionary that includes the field label name, text describing the purpose and function of the field, an indication of whether the field is required or not, the maximum length of the possible input, the type of input that is accepted (for example, alphanumeric), and a close button that closes the popup browser window and returns you to the KC screen that was displayed when help was accessed.

Popup Text Tips


Figure 43 Nonstandard Functionality Is Reflected in Popup Tool Tip Text Upon Mouse-Over

Many buttons, icons, and links throughout KC have popup tips that appear when the mouse cursor hovers above them.  While these usually display the same text as the related label or common name, some may have different functions (for example, the lookup icon for adding keywords on a Proposal document displays ‘Multiple Value Search on’ instead of Search as it does most commonly elsewhere).

Action Buttons


Page and Screen Action Buttons are generally located at the bottom, center of KC software screens, and typically appear as rectangular keys with rounded corners, white backgrounds and red text.  Some may be unique to particular pages of particular documents.

Tab and Section Action Buttons typically are clicked to command system actions whose results are evident within the tabbed sections themselves.  These are usually associated with line items (lists displayed as table rows).

Action List


The Action List screen is where you receive action requests for e-docs.  It provides summary information about each document that requires your attention.  It displays columns of information in a table format that provides a quick view of the type of document, its title, status, the type of action that is being requested of you, who initiated the document, and a way to view its route information.  It also indicates whether you’ve received a request because you are delegate or a member of a group.  From this screen, you are able to

Figure 44 Action List Button Location

The Action List is accessible from the header area of most KC screens by click the action list button.

Figure 45 Action List Screen Layout Example

The Action List screen displays a table with 10 columns of information.  It also displays buttons at the top, right that allow for customization of the screen.  Additionally, page navigation tools are provided when the number of action requests exceeds the single page display limit.


For detailed, step-by-step instructions on how to use the Action List screen, see “Using the Action List” on page Error! Bookmark not defined. in Common E-Doc Operations.


When you receive action requests for KC actions through your Action List, summary information about the documents in your Action List is provided, such as document type, title, route status, the type of action requested of you, who initiated the document, when it was created and whether or not you’ve received this request because you are a Delegate or a member of a workgroup.

  To use the action list:



Click the action list button from the toolbar on any KC screen.



The workflow system retrieves all of the documents that you have initiated and saved, and any documents that are routed to you to approve, acknowledge or FYI:

Figure - Documents in the Action List that are pending action.


Click the Document ID link to open the document (for example, 4073 ).



A different set of buttons appears in the bottom of the document depending on your roles and the requested action:

Figure – Workflow action buttons

pencil-small   In the case of multi-page documents (like Proposal, for example), these only appear at the bottom of an “…Actions” page (for example, Proposal Actions).

End of activity.


Click one of the workflow action buttons (for example, approve ) to complete your usage of the action list by taking action on a particular document.

Show/Hide Button

  Click the show button in the left column to display action quicklinks (for example, to Copy Proposal)

Action List Filter


Setting a filter allows you to display a subset of the Action List. Click the filter button to go to the Action List Filter dialog box.

Figure 46 Click Action List Filter button to go to the Action Filter dialog box.

Figure 47 You may limit the e-docs displayed in your Action List by setting a filter.

Table 6 Action List Filter Definition



Document Title

Enter a partial or full character string that you are looking for in the document description. For example, when you enter 'Test' in the Document Title field, the Action List displays all documents that contain 'Test' in the document description. This field is case sensitive.

Document Route Status

Select a route status in the Document Route Status list. The list contains the choices All, Approved, Disapproved, Enroute, Exception, Processed and Saved. Select the Exclude? check box to exclude documents with the selected status from the list.

Action Requested

Select an action in the Actions Requested list. The list contains Acknowledge, Approve, Disapprove, and FYI. Select the Exclude? check box to exclude documents with the selected action from the list.

Action Requested Workgroup

Enter the name of the Workgroup that is requested to take an action.

Document Type

Select a document type from the Document Type lookup searchicon .

Date Created

Enter a date range or select dates from the calendar by clicking the Calendar cal to limit the documents based on the date they were created. Select the Exclude? check box to exclude documents that were created during this given time range.

Date Last Assigned

Enter a date range or select dates from the calendar by clicking the Calendar cal   to limit the documents based on the date that this action item was generated for you. Select the Exclude? check box to exclude documents that entered your action list during this given time range. The acceptable format is mm/dd/yyyy.


  To filter your Action List:


Click the filter button from the Action List header area.




The Action List Filter screen appears:



Specify the filtering criteria in the Action List Filter dialog box by making entries and selections as desired, and then click filter .








End of activity.










A system message appears in the notification area (upper left corner) of the Action List:

Changes you made to filter settings are summarized on the Action List screen

  To clear your filter:





        Click the clear filter button to remove the filter.

pencil-small   Note that the clear filter button is visible only when you have previously created the filter.

  To refresh the list:




        Click the refresh button to display the complete Action List.

  To use the Outbox:






        Click the Outbox link to view documents for which you’ve completed requested actions.

The Action List result table is refreshed to display your Outbox items:

  To remove an item:




        Check the Delete Item column for any document you want to remove and click the delete selected items button.

Doc Search


The Doc Search button is a “static” button that always appears in the header area just under the main menu bar.  It takes you to the Document Lookup screen, which provides selection and entry fields that allow you to refine criteria to search for existing e-docs.

Figure 48 Doc Search Button Location

The initial display of the Document Lookup screen shows three buttons and a menu in the header area;  and a search criteria entry/selection area, which displays several fields and three basic buttons.  After a search action has been commanded, an additional area of the screen appears below the search criteria selection/entry area with the search results.  The search result table displays items retrieved in rows.  Columns display key information about each document.  Within some column cells, text is underlined to indicate it is an active link that allows you to view additional information (such as Initiator, which allows you to view Person details), or to view the document itself (Document/Notification Id).  The Route Log column displays an icon that, when clicked, allows you to view routing action information about the document.

Figure 49 Document Lookup Screen (doc search) Layout


For detailed, step-by-step instructions on how to use the Document Lookup screen, see “ Searching for a Document ” on page Error! Bookmark not defined. in Common E-Doc Operations.

Basic vs. Detailed Search


The search screen initially defaults to a basic search. You may switch between the basic search and detailed search by clicking the Basic Search or Detailed Search   buttons on the horizontal Document Search screen header bar. The detailed search screen gives you more options for search criteria.


The detailed search button acts as a toggle between detailed search and basic search .  Clicking the button causes its text label to change accordingly.

Figure 50 Basic Search

Figure 51 Detailed Search

Superuser Search vs. Non Superuser-Search


The search screen initially defaults to a Non-Superuser search mode. If you have the Superuser role, you may switch between the Non Superuser search and Superuser search mode by clicking the Superuser Search or Non Superuser buttons.


The superuser search button acts as a toggle between detailed search and non-superuser search .  Clicking the button causes its text label to change accordingly.

Figure 52 The Superuser Search mode gives you more search options.

The superuser search mode gives you more search options and allows you to access documents you want to take Superuser actions on, such as bypassing an approval or sending a document to another route level. Anyone can search for documents using superuser search, but only Superusers can actually take special actions on the documents retrieved from the superuser search button.

Named Search


When you name a set of search criteria, the system saves your search as a named search.

Figure 53 Naming a Search

When you later click search, the system displays a list of all named searches you have created in the Searches drop-down list.

Figure 54 You may access your named search in the Searches list.

Clearing Searches

Click the clear saved searches button to clear the named searches from the list.


Click clear to clear your previous search criteria.

Document-Specific Searches


The document-specific searches are designed to assist you with additional search criteria for particular transactional e-docs. In addition to the standard search criteria available in the basic or advanced search, these searches include unique fields such as document status, and document-specific reference numbers.


The All My Proposals link from the Proposals menu group on the Researcher menu is a document-specific search for only Proposal documents that you have initiated.

All My Proposals Link from Researcher menu > Proposals menu group

Columns Displayed In Results Table for Proposal Document Search Using All My Proposals Link

Searching With Wildcards

What is a wildcard?   A wildcard is a character that can be used as a substitute for any of a class of characters in a search, thereby greatly increasing the flexibility and efficiency of searches.  The term wildcard or wild card was originally used in card games to describe a card that can be assigned any value that its holder desires. However, its usage has spread so that it is now used to describe an unknown or unpredictable factor in a variety of fields.

General Recommendations :  You may use the asterisk ‘*’ and the percent symbol ‘%’ as wildcards in searches.  Range operators allowed on numbers and dates in searches: >, <, >=, <=, or ‘..’.   All operators except ‘..’ should be before a date.   Use operators to separate dates.

Available Operators

Table 7 Available Wildcards For Lookups



Compatible Data Types














Not Equal to



If used repeatedly, e.g. !1031490!1031491 , an && is assumed, leading to !1031490&&!1031491

?, *




? will match any one character and * will match any number of characters.   These will still be used if ! has been used, but not if any of the range criteria below have been used.


Greater Than

String, Number, Date




Less Than

String, Number, Date




Greater Than or Equal to

String, Number, Date




Less Than or Equal to

String, Number, Date




Greater Than or Equal to and Less Than or Equal to

String, Number, Date



Account Number Examples

Table 8 Account Number (String) Wildcard Usage Examples




Accounts with an account number greater than or equal to 1031490


Accounts with an account number greater than 1031490 and less than 1111500


Accounts with an account number greater or equal to 1031490 and less than or equal to 1111500


Accounts with an account number greater than or equal to 1031490 and less than or equal to 1111500


Accounts with an account number starting with 103


Accounts with an account number 1031490, 1032490, 1033490…   The ? will match any one character with 103 before it and 490 after it


Accounts with an account number greater than or equal to 1031490 and less than or equal to 1111500 and accounts with account number like 1123400


Accounts with an account number that starts with 103149 or 105167


Accounts with an account number that starts with 103149 or 105167


Accounts with an account number with 1111 somewhere in it


Accounts except those with account numbers 1031490 and 1031491


Accounts except those with account numbers 1031490 and 1031491

Proposal Number Examples

Table 9 Proposal Number (Number) Wildcard Usage Examples




Proposals with a proposal number between 1031490 and 111500


Will not parse as a number, so it will not be included in criteria

Create Date Examples

Table 10 Create Date (Date) Wildcard Usage Examples




Accounts with a create date greater than or equal to 10/07/1976 and less than or equal to 10/07/1983


Will not parse as a date, so will not be included in criteria


Search Results

        Sortable Columns :  Each column in your list of search results has a link on the header (the title of the column) for sorting.   Click the column title once to sort the search results list in ascending order by that column and click again to sort it in descending order.

        Inquiries :  Some fields have links to the Inquiry screen for that field.   If you click the link, the inquiry appears in a new window with information about that field.

        Return :  Click the return value link on a row to enter information from that row in your previous page.   Select return with no value or click the cancel button if you wish to go back to your previous page without entering anything from your search list.

        Data Export :  Below the search result table, there are links for exporting search result lists to three formats - CSV to export the data as a comma-delimited file, Spreadsheet to export the data as a spreadsheet, and Xml to export the data as xml.

        Result Set Limits :  Some lookups for certain business entities in the system return different numbers of results than the system default; therefore, system administrators can limit this set of returned results on an enity-by-entity basis by specifying an override tag to set a result limit for a given entity in the lookup section of the data dictionary.


Related Information :  For more information about performing lookups, see “ Lookup ” on page 54 .




E-Doc Fundamentals


This topic describes the different types of electronic documents (“e-docs”) that exist in the KC system, how each is used, an overview of the general layout of e-doc screens and pages, common e-doc attributes, and their basic functions.

Types of E-Docs in KC


The essential difference between e-docs and maintenance e-docs:

        E-Docs :   The term “e-doc” is simply an abbreviation for electronic document .  Standard electronic documents (“e-docs”) are sometimes referred to as transactional documents.  The terms “standard” or “transactional” are usually used when explaining how standard e-docs are different than maintenance documents (“maintenance e-docs”).  Transactional e-docs perform actions both within the KC system (routing) and outside the system (updates or submissions). 

o          Internally , they travel through various states of workflow as they are reviewed and approved, and the information they contain may be included on reports that are generated.

o          Externally , they connect to or integrate with other systems to send information they contain.

        Maintenance E-Docs :  Maintenance e-docs are electronic documents used to maintain data in the system that is referenced by other e-docs.  Within the system, they may be routed for review and approval.  Their content becomes selectable information on form fields within standard e-docs.

Another way to think about the difference:

        E-Docs :  think word documents or pdf forms .  Even though they are electronic forms that allow for information entry and selection, all of the fields, sections, and pages make up a large document similar to those that traditionally were printed.

        Maintenance E-Docs :  think database tables or excel spreadsheets .  Although maintenance documents are electronic documents, they are not really like documents suitable for printing, but rather, listings of available codes that may occasionally change and thus need to be maintained.  Instead of requiring complicated database administration skills, maintenance e-docs facilitate maintaining data via an electronic document user interface that makes it easy for non-technical users to update reference information.

A third type of e-doc:

        Administration E-Docs :   There is a third type of electronic document known as an administration e-doc.  Administration e-docs are like maintenance e-docs in every way, except that instead of maintaining reference table information, they maintain information related to the administration of the software system itself.  Again, the advantage of using electronic document screens in the user interface for the configuration of the KC system is that it allows that type of technical work to be done by users with less technical expertise than would otherwise be required.  An important design principle of KC is that wherever reasonably possible to include the ability to configure or maintain the system in the user interface as an e-doc style of screen, it was done to eliminate the amount of hard-coding and programming work that would be necessary for those pieces of functionality.

Figure 55 E-Doc type locations by menu

E-Doc Topology


From top to bottom, e-docs start with a title and identifying information at the top, followed by a page navigation bar, under which the main body includes expandable/collapsible sections of each page that contain form fields for data entry and selection options, and finally at the bottom are action command buttons.

Key Terms, Concepts and User Interface Element Reference

Electronic documents are similar to paper forms you fill out with a pen in many ways in terms of their structure.  The components of each may be referred to with similar terminology.  Since a primary goal of KC is to replace paper processes, new users who already have expertise with paper processes will find it easiest to refer to equivalent portions of those used in the KC user interface by using similar names.  There are some key concepts that are unique to electronic documents that are important for you to understand in order to use KC effectively.  They are identified with differences described in the table that follows.

Table 11 Paper vs. Electronic Documents - Key Concepts and Terminology

Paper Document Elements

Electronic Document Elements

Documents have a Cover Page with front matter

Documents have a Document Type label and Header area

Documents are made up of Pages (to read a page, you turn to it with your fingers )

Documents are made up of Pages   (to read a page, you click on its tab )

Pages are made up of Sections (to read a section, you focus your eyes on that section)

Pages are made up of Sections (to read a section, you scroll to it and/ or click show to expand the display view)

Sections are made up of Subsections (to read a subsection, you focus your eyes on that subsection within a section)

Sections are made up of Subsections (to read a subsection, you click a show button to display its content)

Documents are Submitted for collaboration/review/approval ( in person delivery, by mail, or by fax )

Documents are Submitted for collaboration/review/approval (by clicking buttons )

Documents are Approved ( by signature with pen )

Documents are Approved ( by clicking buttons that electronically certify authorization)

Header, Pages, Sections, Subsections and Buttons Explained

        Header :  The header at the top, right corner of any e-doc contains the basic identifying system information about the e-doc.  Some fields are document-specific, but common to all are Document Number (a.k.a. ID), Initiator, Status, and Created Date.  In some cases the status is a system workflow route status, whereas in others it may be document-specific.

        Pages :  The individual pages that make up the larger document are accessed via the page tabs that appear horizontally across the top of the e-doc, just below the header.  The first page displayed usually corresponds to the leftmost page tab and usually requires entry of basic, identifying information that when successfully saved, allows you to continue to subsequent pages in left-to-right order. 

        Sections (tabbed sections or panels):  The body of each page is typically organized in a stack of labeled tabs that look like file folders. Based on the document type, a different set of tabs is displayed. To facilitate the document input (data entry) process, an initiated document opens with required tabs expanded and the optional tabs collapsed. 

        Subsections within tabs:  Some tabs may contain more than one section, each labeled with white text and a dark gray background.  Sometimes each section has its own unique help icon.

        Buttons :  The action buttons are displayed below the stacked tabs and differ based on the e-doc type, the e-doc page, your role and the status of the e-doc. 

Figure 56 KC E-Doc Screen Overview

Header Area


The e-doc header appears at the top, right corner of any e-doc.  It contains the system information about the document.   Some e-docs have unique fields appearing in the document header area.  See the respective e-doc topic for descriptions of how to set and interpret these fields.

Figure 57 E-Doc Header – Example


Table 12 E-Doc Header - Field Definition



Doc Nbr

Document Number is the unique number used to identify each document. The KC system automatically assigns a sequential number to each document when it is created, regardless of the type of document.  Also known as the Document ID, it is generated by the workflow environment and is unique to each installation of KC.


Identifies the user ID of the person who created the document.  The user name displayed is underlined to indicate the ability to “drill down” to additional identifying information about the user by clicking the text.  Also known as the Initiator Network ID.

Sponsor Code

The identification number (up to 6 digits) of the organization or agency that is providing support for the sponsored project, as entered/selected for the Sponsor ID field on the Required Fields for Saving Document tab of the Proposal page of a Proposal Development document (blank upon initiation).  This may include alpha or numeric characters.


Identifies the current state of the workflow process that the document is in.

link.png For more information about workflow status, see “ Route Status ” on page 655   in Kuali Enterprise Workflow.


Identifies the time and date the document was initiated (also known as Creation Timestamp).


Some e-docs have document-specific fields in the document header area.  In the example above, Principal Investigator is the name selected/entered from the Key Personnel page of the Proposal Development document (blank upon initiation).  The individual bearing primary responsibility for all essential aspects of the project or protocol, including programmatic work, compliance with government, sponsor and university policies and regulations, fiscal stewardship of sponsored funds, and all administrative requirements of the project. This can be up to 20 characters of any type.  The Principal Investigator/Project Director/Program Director (PI/PD) is the individual designated by the grantee, and approved by the sponsoring agency, who will be responsible for the scientific or technical direction of the project.  If more than one, the first one listed will have primary responsibility for the project and the submission of reports.  All others listed are considered co-PI/PD, and share in the responsibility of the scientific or technical direction of the project.  The term "Principal Investigator" generally is used in research projects, while the term "Project Director/Program Director" generally is used in education, and service projects.

pencil-small The federal government is making the switch to the term “PD/PI” for all projects.

Optional Fields in Document Header:

Copied From Document ID

When a new document is created based on a previous one by use of a copy function, the document number of the copied document appears here. 

Correct Document ID

KC gives you the option of reversing a fully approved document transaction through the use of the Error Correction function. When one document is a correction of another, the document number of the document being corrected appears here. This information is displayed only when the document was created using the Error Correction feature from within an existing document.



Tabbed Pages


Pages of e-docs appear as horizontal folder tabs, each of which contain vertically-scrollable sections. Clicking on the page tab (which displays its purpose label) causes that page to be displayed in the forefront of the screen’s body.


Completion Order :  In general, e-docs in KC have been organized so that completing them begins on the left and ends on the right.  The design typically allows you to complete a minimum of required information on the far left (first) page in order to save the document, then you are able to close it and return at a later time to complete the remaining pages in left-to-right order (though the order of completion is up to you).  Lastly, any actions you might perform such as submission, review and/or approval are done on the far right (last) page.

        Initial Display :  The default start page typically corresponds with the page tab appearing on the left. 

        Show/Hide :  The page that is currently-accessed (and whose contents are displayed in the body area) has its associated page tab appear with a white background, while hidden tabs have a grey background.

        Navigation & Saving :  Clicking a page tab will cause its contents to appear in the body.  Most require saving prior to proceeding to the next page (page validation is performed for each save action).

        General To Specific :  Pages progress from general information on the left to more specific information in the middle and workflow routing actions on the right.

        Example :  Populating a Proposal Development e-doc, for example, begins with basic, required information about the proposal on the Proposal page, then monetary information display associated with the Budget Document, the personnel involved, review requirements, questions related to the proposal, information regarding proposal permissions, additional attached information such as documents, compliance information, and finally, information related to the routing of the document.

Figure 58 Left-To-Right E-Doc Page Organization and Completion Flow

Tabbed Page Sections


Sometimes referred to as “panels”, these are sections of e-doc pages that appear as file folder tabs that can be expanded or collapsed using the show/hide or expand/collapse all buttons, each of which contain form fields that allow for entry and selection of information. Vertically-scrollable.

Figure 59 An E-Doc Page with one section tab shown, other section tabs hidden


For more information about show/hide and expand/collapse functions, see “ Selection, Entry & Action Tools ” on page 52   in KC Overview.

Subsections Within Tabbed Page Sections


Just like a document can have multiple pages, and a page can have multiple tabbed sections, the tabs themselves can have multiple sections.  Each is marked by a label heading with light gray text on a dark gray background, and each may have a separate associated help icon.

Figure 60 Tab Section Examples:  The Organization and Performance Site Locations sections of the Organization/Location Tab

Document Locking


In research administration, it is typical for coworkers to collaborate on putting together a single proposal.  Common to some e-docs (for example, Proposal Development documents) is a feature known as ‘document locking’ that allows for more than one person to be able to edit the same document.  Refer to the individual e-doc topics within this documentation to determine whether or not this feature is available. 


For more information about locking management, see “ Pessimistic Lock ” on page 1094 in System Administration > Configuration.

Common E-Doc Sections


This topic explains tabbed e-doc sections (also known as “panels”) that appear on more than one e-doc in the system.  While the tabs contained in various e-docs may vary from one document type to another, there is a set of four standard tabs that are common to more than one e-doc. They are the Document Overview , Notes and Attachments , Ad Hoc Recipients , and Route Log tabs. The basic functionality of these tabs is explained below:

Document Overview


The Document Overview tab identifies the document and includes the Description , Explanation , and Org. Doc. # fields.

Figure 61 KC Document Overview Tab (Page Section)


Table 13 Document Overview Section – Field Descriptions




Required.  Document Description.  A free-form text field that describes the purpose or function of the document (maximum length is 40 characters).


A free-form text field that explains the purpose of the document in more detail than the Description (maximum length is 400 characters of any type).

Org. Doc. #

An abbreviation for Organization Document Number.  The numeric document identification that may include departmental or organizational information (maximum length is 10 characters).

exclaim This number is not the same as the Document Number assigned by the Kuali Financial System (KFS).


The Description field is a required field on every e-doc.  It is used by each transaction and appears in standard reports, action list and document search.


Text entered in the Description field on the Document Overview tab appears in the respective Title column field of the Action List table for that document’s row:


The Explanation and Org Doc# field entries allow you to include additional information about the document that become read-only columns when the document is submitted.

Notes and Attachments


The Notes and Attachments tab displays user notes, attachments, or system-generated remarks about the document. The number of notes and/or attachments is indicated on the tab label in parentheses.  It is a default service provided by the Kuali Enterprise Workflow module, but appears on multiple documents that are a part of multiple functional modules.

Figure 62 Notes and Attachments Tab


Table 14 Notes and Attachments Column Descriptions



Posted Timestamp

Display-only. The time and date when the attachment or note was posted


Display-only. The full name of the user who has added the notes or attachments.

exclaim   The Author is the person who did the data-entry, not necessarily the person who completed it, or authored it.

Note Text

Required. Enter comments (type or paste from clipboard).

Attached File

Optional. Displays the path and filename after selection.  Select the file to attach by clicking Browse and following Window's standard Choose File dialog box. Click CANCEL to clear the file name that you have selected. 

After an attachment is added, the field displays a paper clip icon with the file name, size and associated application.

Browse button

Click to use your operating system’s Choose File or File Upload dialog window to locate and select the file you want to attach.

Cancel button

Click to clear the Attached File box if you have already browsed for and selected a file but have not yet clicked the add button.


This column displays the add command button.  Some e-docs may also provide the ability to delete attachments, but most do not.


Add button

Click this after populating the Attached File field via browse and select.  Your note and/or file will display in a new numbered row beneath the add: row for each note or attachment.



This tab appears on the Abstracts & Attachments page of the Proposal Development document.  The basic process for using this functionality is common to other sections such as Personnel and Internal Attachments as well.  See those respective topics for differences and specific guidelines for each.


  To add an attachment:

Figure 63   Step 1 :  Type in Required Topic and Text fields and Click Browse


Figure 64   Step 2 :  Select File To Attach Using the File Upload Dialog Box (Windows XP OS example)


Figure 65   Step 3 :  After the path & name of your selection are populated, click add


Figure 66   Result :  Attachment Line display after the add action (numbered line item)


Ad Hoc Recipients


The Ad Hoc Recipients section allows you to interrupt the normal workflow routing of the document and include individuals or workgroups in the routing path. Ad Hoc Routing does not supersede the normal workflow routing of the document but is in addition to the normal routing.

The Ad Hoc Recipients section has two subsections: Person Requests and Ad Hoc Workgroup Requests. Use one or both of the sections to route the document to a person, workgroup, or both.

Figure 67 Ad Hoc Recipients Section


Table 15 Ad Hoc Recipients Section – Field Descriptions



Action Requested

Required. Select the desired action from the Action Requested list. The choices ( APPROVE , ACKNOWLEDGE , and FYI) are actions the recipient is asked to perform .

link.png For more information about the Ad Hoc routing see “ Ad Hoc Routing ” on page 645 in KEW Overview > Ad Hoc Routing.

Person or Workgroup

Required when you want to route the document to an individual or workgroup for the action requested.  You may route to one or both.  Enter a user ID name or registered workgroup name as appropriate or use the lookups searchicon to select them .  

link.png For more information on how to use the lookup tool to locate and select a Person or Workgroup, see “ Lookup ” on page 54 in KC Overview > Selection, Entry & Action Tools.


Add and Delete command buttons are available for either section to add or delete a line (table row) containing your selections.


Click add in the Actions column to add the current line after you’ve completed your entry/selection to add the Person or Workgroup to the routing path for the document.


Click to delete the current line.



This section appears on the Proposal Actions page of the Proposal Development document.


Route Log


The Route Log tab displays the workflow status details of the document.

Figure 68 Route Log Tab

ID Subsection

Table 16 Route Log – Identification Subsection Field Descriptions




A combination of the Document Type, Description, and the Organization Document Number


Type of transaction.   The full name of the transaction, used to identify this Document Type in Workflow


The User ID of the person who created the document


Workflow document status


The steps that a document takes through the different levels of routing are also referred to as Route Nodes.   This field shows the current Route Node of the document.


Time and date that the document was created

Last Modified

Time and date that the document was last modified

Last Approved

Time and date that the last action was taken on this document


Time and date that the document reaches Final, Canceled, or Disapproved status


The fields on the Document Id section of the Route Log tab are display-only.  However, both the Document Type and Initiator field values are displayed as underlined text to show that you are able to click on them to “drill down” to more detail about each of them.  All fields appearing in the right column are date fields.

Figure 69 Additional Tabbed Sections Within the Route Log Tab


For more detailed, technical information about the Route Log section, see “ Route Log ” on page Error! Bookmark not defined. .


In standard multi-page e-docs, this section is typically present on the “Actions” page, whereas in maintenance e-docs with only a single page it is simply the last section on the bottom of that page.

Future Action Requests Subection

Once a document is Saved or ENROUTE, this subsection shows the action requests that Workflow will generate in the future, based on the information currently on the document.


Future requests appear in the order in which they are to occur.

Data Validation


The Data Validation section typically appears on the “Actions” page of e-docs.  It allows you to activate a validation check against the e-doc that results in errors and warnings related to data and submission issues that are displayed on the screen with fix buttons that take you directly to the portion of the document where the error or warning was found.  This enables you to subsequently view further messages within the corresponding sections that give additional insight into the nature of the issue, then make necessary corrections.

KC validates data you’ve entered into a proposal document for completeness and accuracy and displays errors on the Data Validation tab that you can not only view, but easily navigate to the relevant page, tab or section to fix them.  Each type of validation is displayed categorically by type, and further categorized by page where the errors have occurred.  In general, hard errors can prevent the Proposal document from being routed and/or submitted to Grants.gov (when applicable), whereas soft warning errors alert you to possible problems, but do not prevent submission.

The two types of validation in KC are:

        Save/Navigation Errors :  page or tab-specific hard or soft errors you encounter while navigating or saving.

        Validation Errors :  hard or soft errors you encounter only in validation mode (which can be turned off on this tab). 

The three types of system checks are:

        Validation Errors :  hard-coded errors that prevent routing

        Warnings :  soft errors that serve as alerts to possible data issues but will not prevent routing or submission

        Grants.gov Errors :  errors that prevent submission to grants.gov

The two methods by which validations are generated are:

        Manual :  You can activate the validation process upon command (on an as-needed basis) by clicking the “turn on/off validation” button in the Data Validation section of the Data Validation tab prior to submission and while navigating throughout the pages of the proposal.

        Automatic :  The validation process will also run automatically upon the action of final submission/routing. 

Figure 70 Proposal Development Document > Proposal Actions Page > Data Validation Section - Example


Table 17 Data Validation Section -  Section Description



Data Validation

Houses on-screen instructions regarding validations and a button to activate/deactivate the audit mode.

The button label text changes from on to off and serves as a toggle.

Validation Errors

Hard coded system errors that identify missing data required prior to proposal submission/routing. 


Soft errors that serve as cautionary reminders to you, but do not prevent proposal submission/routing.

Grants.gov Errors

Grants.Gov opportunity-specific validation errors that must be corrected prior to proposal routing/submission. Proposal validations that check data against the opportunity schema.  The schema downloaded from Grants.gov will contain the fields required to be populated.  KC will check that the data is present in the KC proposal record.  Not having the data will cause a validation error.

Click to navigate to the applicable proposal development page where error occurred.  Message(s) will re-display in red text within each applicable page or tabbed section.  Invalid fields will be outlined in red.

Figure 71 Validation Errors Section Example – Proposal Development Document

Figure 72 Warnings Section Example – Proposal Development Document

Figure 73 Grants.gov Errors Section Example – Proposal Development Document

Fix Process

Use the fix process when you’ve validated your e-doc and have errors and/or warnings.


  To fix errors and warnings:



Click turn on validation .

Error sections appear as hidden on the Data Validation tab.


Click show .

Each error is displayed as a line item with a corresponding fix button.



Click fix to the right of an error.

You are taken to the relevant page where error messages are displayed and fields are outlined in red:






Fix the error and click save .

End of activity.


The error no longer appears on the Data Validation tab.

Workflow Action Buttons


When you open a document, you see different workflow action buttons at the bottom of the document depending on your relationship to the document and the document’s current workflow status.  Some transactional documents contain a separate page dedicated to actions, and only display unique, workflow-specific action buttons at the bottom of that page.  These buttons vary depending on what kind of action request you received for the document and on whether or not you are a special kind of KC user, such as an Administrator or Superuser.


Table 18 KC E-Doc Action Command Button Examples



Sends certain federal proposals created in Proposal Development directly to the Grants.gov on-line system.  This system-to-system (S2S) application transmittal is only available for certain funding opportunities.  The eligibility requirements are specified by each sponsoring agency. This button only appears on the Proposal Actions page of the Proposal document and is only functional after full routing and approval.

Moves the document (through workflow) to the next level of approval. Once a document is submitted, it remains in ‘ENROUTE’ status until all approvals have taken place.

Denotes that the document is void and should be disregarded. Canceled documents cannot be modified in any way and do not route for approval.  They may be copied, however, to a new document.

Signifies that the user wishes to exit the document. The system displays a message asking the user if they 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 the initiator of a document to save their work and close the document. The document may be retrieved from the initiator’s Action List for completion and routing at a later time.

Refreshes the screen and displays the most recently saved information. Changes which are made but not saved prior to reloading a page are not maintained.

Returns the document to its Initiator when the initial OSP reviewer has identified changes that are required for approval.  This action has the effect of remanding the document back to the originator or preparer for modifications.  You will be prompted to enter comments, just as with a disapproval.


Signifies that the user has responded to the FYI action request. Only available 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.  FYIs do not interrupt the normal Workflow routing of a document either.  To signify that you have responded to the FYI action, you may take one of the two actions: click FYI when you open the document, or select FYI in the Actions column and click take actions directly from the Action List.  If you wish to clear all of the FYI actions in the Action List at once, you may first set the default action from NONE to FYI. Click apply default located at the upper right corner and then click take actions.

Signifies that the user has responded to the Acknowledgement action request. It is only available to users to whom a document has been routed for acknowledgement. Acknowledgements do not interrupt the normal Workflow routing of a document. They do not stop a document from routing on to other individuals or workgroups who need to take approval actions.

Signifies that the document represents a valid business transaction in accordance with institutional needs and policies in the user’s judgment. A single document may require approval from several users, at multiple route levels, before it moves to final status.

Signifies that the document does not represent a valid business transaction in the user's judgment. A Disapprove action from any single approver prevents a document from ever posting to the GL.  Enter a reason for disapproval, and then click yes to confirm.  The reason entered displays in the Notes and Attachment tab once the disapprove action is completed.

Bypasses all subsequent levels of approval and immediately moves a document to final status. Anyone who would normally have received the document for approval receives an Acknowledgement request instead. This action may only be taken by an Administrator.  If you are an Administrator, you have the option to blanket approve a document routed to you for your approval. Click blanket approve to approve the document bypassing all other approvals.

Performs a route report.  In other words, clicking this causes a new browser window to pop up that displays the same information that is contained in the Route Log tab.  These include sub-tabs within the Route Log tab for Document Id, and possibly Actions Taken, Pending Actions, and Future Actions, depending on the document and route status.

Superusers use this to select an action request, select the recipient type, enter the user ID or workgroup ID, and ad-hoc route a document.

Superusers click this to return a document to the previous route level, by first selecting a node name from the route level list.



Common E-Doc Procedures


This topic describes the basic e-doc operations with which you should be familiar.  These procedures involve usage of the major action options available for most transactional e-docs (for example, Proposal documents).  They include instruction on initiating e-docs, copying e-docs, saving e-docs, canceling e-docs, closing e-docs, routing e-docs, searching for e-docs, and using the action list.

Initiating a Document


Initiating a document in KC essentially means a new document has been created and saved (not necessarily completed or routed).  If an e-doc is started but not saved, and its initiator logs off the system, it ceases to exist.  In order to save a new e-doc, you must first complete some (not necessarily all) required fields.  The status of an e-doc when first created is INITIATED, and when saved changes to SAVED.

  To initiate an e-doc:




Click the add button or an e-doc link from your main menu that corresponds to the type of document you want to initiate.



Depending on your implementation of KC, you may be prompted to log in at this point if you have not already done so.  Enter your User ID and Password as necessary to proceed.


A new, blank document is created with a unique Document ID.  The status of a newly-created e-doc prior to save is INITIATED, and is displayed as such in the document header area.


Complete the required fields marked with an asterisk.

pencil-small   Some e-docs provide a tabbed section labeled ‘Required Fields For Saving Document,’ typically located on a default start page in multi-page e-docs.  When this is the case (as with the Proposal document, for example), there may be fields marked as required on other pages within the e-doc that are not necessary to complete for initiation.


Click save .


The Status field in the document header displays ‘ SAVED .’






End of activity.


exclaim   Some selections for particular required fields cause other fields to become required, even though they are not marked as such.  For example, on the Proposal document, when your selection for the Proposal Type field on the Required Fields for Saving Document tab is “Renewal”, “Revision” or “Continuation”, the Sponsor Proposal ID field on the Sponsor & Program Information tab becomes required.  You are notified of this via red error messages upon validation or save.

Copying a Document


Copying a document in KC is an action that allows you to initiate a new document based on an existing document.  This enables you to take advantage of work already completed in a document and reuse it for another document that will be similar.  It saves you the effort of repeating data entry, selection, and adding attachments.

  To copy an e-doc:



Retrieve the document you want to copy (for example, by using the doc search feature).


If you used the doc search to locate the document you want to copy, click the Copy link from the right Copy Document column of the results table.


The document opens, and by default displays the page where the Copy to New Document tab resides (for example, in the Proposal document, this is on the Proposal Actions page).  Otherwise, navigate to the “Actions” page of the document and show the Copy to New Document tab.




Make entries or selections as appropriate for any required fields marked with an asterisk on the Copy to New Document tab (for example, Lead Unit is required on the Proposal document).


Click the copy button (for example, copy proposal ) on the Copy to New Document tab.

End of activity.


A new document appears, open to the default start page (for example, Proposal page for a new Proposal document).

The document header displays the new Document Number and the status of SAVED.

All information, including attachments, from the previous document are included.

Saving a Document


The save button appears in the action buttons area (bottom, center) of most e-doc pages on most e-docs.  It generally allows you to save your work on an incomplete e-doc and resume working on it at another time.  This ability also enables you to complete a portion of an e-doc for which you’re taking responsibility and leave the remaining portions to one or more other users you are collaborating with.  Saving changes the document status to ‘ SAVED .’

  To save an e-doc:



Complete the required fields marked with an asterisk.

pencil-small   Some e-docs provide a tabbed section labeled ‘Required Fields For Saving Document,’ typically located on a default start page in multi-page e-docs.  When this is the case (as with the Proposal document, for example), there may be fields marked as required on other pages within the e-doc that are not necessary to complete for saving.


Click save .



A message appears in the notification area (top, left of page) to indicate successful completion of the save action:


End of activity.




If you started with a new, blank e-doc with a status of ‘ INITIATED ,’ the Status field in the document header changes to show ‘ SAVED .’


Your Selections May Make Other Fields Required :  Some selections for particular required fields cause other fields to become required, even though they are not marked as required .  For example, on the Proposal document, when your selection for the Proposal Type field on the Required Fields for Saving Document tab is “Renewal”, “Revision” or “Continuation”, the Sponsor Proposal ID field on the Sponsor & Program Information tab becomes required.  You are notified of this via red error messages upon validation or save.


Page Navigation Saving :  Making changes to fields on one page and clicking another page tab to navigate to a different page of an e-doc automatically saves them (without having to click the save button in between).  Just as with clicking the save button , if there are errors that prevent the save from occurring, they are displayed in red in the notification area (top, left of page) and you are prevented from navigating to the desired page until they are corrected.



Reloading a page simply returns the page to the state it was in when last saved.  This is accomplished by clicking the reload button, which appears in the action buttons area on most pages of most e-docs.  Use this feature when you want to start over from where you began and eliminate recent modifications.


Clicking reload means that any changes you’ve made to the current page, prior to saving or navigating to a different page, will be lost!

  To reload an e-doc:



Click reload .



A message appears in the notification area (top, left of page) to indicate successful completion of the reload action:



End of activity.


Selections and entries on the currently-accessed page return to how they appeared the last time the document was saved.

Closing a Document


Closing a document is accomplished by clicking the close button, which appears in the action buttons area at the bottom, center of most pages of most e-docs.

  To close an e-doc:



Click close .



You are prompted to save the document first:


Click yes if you want to save changes you’ve made, or no to return the document to its state as of the last save.



End of activity.


The document closes and you are taken to your default menu.

Canceling a Document



The cancel button does not simply cancel the recent changes you’ve made on the current page or revert to a previously-saved version of the document (which is accomplished via reloading), but instead it cancels the ability to route and/or submit the document.  You can copy a canceled document to a new document number that essentially moves your work from the canceled document to a new one.

  To cancel an e-doc:



Click cancel .



You are asked for a confirmation:


Click yes .


The status is changed to ‘ CANCELED .’


End of activity.


The document closes and you are returned to your main menu.


You are no longer able to route or submit this document.  However, if you want to preserve data entry/selection and/or attachment work from this document, you are able to copy it.


For more information about e-doc copying, see “ Copying a Document ” on page 103 in Common E-Doc Procedures.

Routing a Document


The e-doc process supports both pre-established Workflow routing and Ad Hoc routing. In the Workflow routing, KC routes the document to the proper users based on business rules established in Workflow. Ad Hoc routing allows you to route the document to one or more individual users and/or workgroups for Approval, Acknowledgement, or FYI.

Unless you want to add an Ad Hoc routing, click the route workflow action button from the bottom, center of the document’s Actions page to route the document in the predefined routing hierarchy.

Note:  See  “ Grants.gov ” on page 193 of Proposal Development for information on submission.

  Note:  See “ KEW Overview ” on page 642 for more information on performing this action.

  To route an e-doc:



tip.png When your document is validated for correctness and completeness, you are then able to route it to other users for their review and approval.  If errors are present, the document will not route.  It is a good idea to turn on the Data Validation prior to routing to ensure all errors are identified and fixed first.


Click route from the action buttons area of the document’s Actions page (for example, the Proposal Actions page of the Proposal document).



The notification area displays a message indicating the document was successfully routed:


The document status changes to ‘ ENROUTE ’ until requested actions are taken by those on the route.








End of activity.


As the document travels through the route and actions are taken, the routing status changes to any one of the following:

Searching for a Document


Searching for a document is done by first clicking the doc search button from the toolbar of any KC screen (located to the right of the action list button).  Search criteria fields allow you to select and/or enter criteria and then click a search button to produce a results table.  From the results table, you are able to click a link to directly open the document you were searching for.


This only covers how to perform a Basic Search.  For more detailed information about advanced search features, search result table “drill-down” action options, Detailed Searches and Superuser Searches, see “ Doc Search ” on page 75 in Overview.

Figure 74 Basic Search Criteria Fields

Table 19 Basic Search Criteria Field Definition

Search Field


Document Type

Use the lookup function to find and select by returning a value for the type of e-doc you want to search for.

pencil-small   Your selection here may cause additional search criteria fields to appear (for example, if you select Proposal document, the role fields appear for Aggregator, Budget Creator, Narrative Writer, Viewer & Approver.

Initiator Network Id

Enter the User ID of the user who initiated the document or select it from the lookup searchicon .

Document Id

Enter the unique identification number assigned by the system to the document or select it from the lookup searchicon .

Date Created

Enter the date in mm/dd/yyyy format or select it using the date selector by clicking on the calendar icon to specify the range of document creation dates to search. You may select the From date only, or the To date only, or both.

Name this search

Enter a textual name for the search if you want to save the search criteria for future use.  All saved searches are available from the Named Searches list at the top of the document search screen.


  To search for an e-doc:



Click doc search from the top, left of any KC screen.



The workflow Document Search screen appears:



Enter and/or select search criteria in the Search for a Document section of the screen as desired.


Click search .



The results of your search are displayed in a table that appears below the criteria section of the screen:

End of activity.


Click on an underlined link appearing in the Document Id column of the search result table to access (open) the document.



Wildcard * Use :  The use of asterisks in the search criteria allows you to perform pattern matching. If you want to search for documents containing a string of characters in the alphanumeric fields such as the document title, you may enter a character string in the search criteria accompanied by asterisks. For example, enter ‘ *test ’ to search for a document title that ends with the word ‘test.’ Enter ‘ test* ’ to search for a document title that begins with the word ‘test.’ Enter ‘ *test* ’ to search for a document title that has the word ‘test’ somewhere in the document title.



Detailed Wildcard Usage Instructions :  For more information about using wildcards, see “

Searching With Wildcards ” on page 81 .

Using the Action List


Use the Action List to view and act on the documents currently pending your completion, acknowledgement, approval, and FYI.

Documents sent to your Action List may request various types of actions from you. The most commonly requested actions are:

        Complete :  Your are being asked to complete a portion of an incomplete document, which requires you to open, change and save the document to clear this from your Action List.

        Approve : Verify that the document content is acceptable. Approved documents continue routing to additional approvers, or if fully approved, are submitted.

        Acknowledge : A request to view and acknowledge an e-doc, without the need for a formal approval. You must open the document from your Action List to clear it out. This is the type of action request generated back to prior Approvers and the Initiator when a document is disapproved.

        FYI : A courtesy request allowing you to view the document or to just clear the request from your Action List without viewing it.

Accessing the Action List is accomplished by clicking the handy workflow toolbar button located in the upper left corner of most KC screens.

  To act on an e-doc using the Action List:



Click action list from the toolbar of any KC screen.


The Action Requested column displays what you’re being asked to do for each document row (for example, ‘ COMPLETE ’).


Click a Document Id column link to access a document (for example, 2128 ).


Navigate to the Actions page of the document (for example, Proposal Actions for the Proposal document).







End of activity.


Appropriate action buttons appear at the bottom, center of the page that allow you to accomplish the action that is being requested from you (for example, blanket approve , approve , or disapprove ):

pencil-small   For e-docs that do not have multiple pages or do not have a separate page dedicated to actions, the workflow action buttons will likely appear at the bottom, center of any page.




Related Information :  For more information about using the Action List, including instructions for using filters, see “

Action List ” on page 69 .

Common Line Item Operations


Many tabbed e-doc sections in KC have functionality that allows you to add line items.  You fill in enough information in required field(s) on a blank line and then click an add button, which causes your line to be added as a new row in a table within the tab.  Additional buttons may appear after a line has been added such as delete to remove the line item or edit to make modifications to a line item.

  To add a line to an e-doc section:



Enter text and/or make selections in the Add row’s blank fields (some may be marked required, and thus must be populated at a minimum to proceed).


Click the add button, typically appearing under the Actions column on the right of the Add line.


A new, numbered line item row is displayed in the table below that contains the content you entered.

Subsequent additions appear sequentially in descending, top-to-bottom order.

After a line is added, new action buttons typically appear in the Actions column on the right of each line row.


Click delete to remove the line item (numbered row) from the table list.


Some sections may include the ability click a copy button that adds a duplicate line that can then be edited further.


For financial, accounting, and/or budget-related line items, you are often presented with a recalculate button that adds amounts in recently-added lines to a section that displays totals.



These are just a few of the basics.  Not all tabbed sections of e-doc pages that contain line item functionality are the same.  In fact, most contain very specific functions and additional action options that are not covered here.  For more detailed information about line item operations and complete instructions, see the specific subtopic for each individual tab.



This topic gave you step-by-step procedural task instructions for carrying out activities that are common to most KC electronic documents.  The focus was on the development and editing of  documents for standard end users.  However, what was not covered was the less commonly-performed tasks for the review and approval of  documents.  E-docs must be approved by all those in the predefined route in order to move a document to ‘FINAL’ status and thereby allow final disposition actions like submission to external systems such as Grants.gov to happen, so changes are not activated in the system until this occurs.


For complete details about all e-doc action options and complete routing information, see “ KEW Overview ” on page 642 .


Common Maintenance E-Doc Procedures


This topic describes the basic operations of maintenance documents with which you should be familiar.  Many KC maintenance documents have a consistent look and feel, shared features, and similar functionality.  KC maintenance documents are usually updated in the same manner based on the Kuali Nervous System (KNS) features running on the Kuali Enterprise Workflow engine.  The task steps that follow guide you through some of the most standard actions associated with typical maintenance e-docs.  They include instruction on searching for, initiating, copying, editing, saving, and routing maintenance documents.



KC relies on a variety of user-defined reference tables to function. These tables define the attributes that the system uses for validation and to allow you to look up values as necessary. They also control the often complex relationships between elements for internal and external reporting.  These reference tables are maintained by e-docs that are commonly referred to as maintenance documents.  They are typically maintained by the members of the central administration area of an institution.

Each of the KC reference tables is maintained by a specific maintenance e-doc which is routed for approval before the table is updated. Whereas all users can lookup KC reference table information, access to their maintenance documents is limited to the members of a particular workgroup and only the authorized members of the workgroup can approve the updating of the tables.  While privileged members have the ability to initiate new maintenance documents, other users may only search for the values from the lookup screens, depending on permissions.

KC contains many maintenance documents grouped by related functions on the Maintenance menu.  Each provides a handy, e-doc user interface for creation and maintenance of reference table information that is used by other e-docs in KC.  They allow for lookup and selection of valid values when populating fields to complete other e-docs.  All of the maintenance documents are viewed and maintained in a similar fashion . Selecting the desired reference table link from the maintenance menu takes you to that maintenance document ’s lookup screen . From that screen you may create a new document by clicking the c reate n ew link, or search the table to view , edit , or copy a table value . These common operations are explained below, using the Proposal Type maintenance e-doc as an example.

Maintenance Document Access


When you click a link from a menu group box on the Maintenance menu, you are by default taken first to a lookup screen associated with that maintenance document.  From lookup results, you are then able to access existing maintenance document screens by clicking edit links.  Additionally, most maintenance document lookup screens have a create new button in the top, right corner that allows you to initiate a new, blank maintenance document.

Figure 75   Maintenance Document Lookup screens and the create new button

Maintenance Document Layout


The typical maintenance e-doc contains the standard tabs such as Document Overview, Notes and Attachments, Ad Hoc Recipients, and Route Log.  Additional tabs that are unique to each individual maintenance e-doc are located in between the Document Overview and Notes and Attachments tabs.  Most maintenance e-docs have just one unique tab that allows you to specify the details associated with the reference object.  Similarly, most maintenance e-docs contain just one page, and thus are displayed on a single screen in KC.  Standard action buttons appearing at the bottom, center of most maintenance e-docs are route report, submit, save, blanket approve, close, and cancel.

Figure 76   Maintenance Document Tabbed Sections


About the “Edit…” Tab :  Each maintenance document has its own unique tab named Edit xxx where xxx is the name of the table values that you want to maintain. The layout and data fields within the Edit tab vary depending on the document type and whether you are creating, editing or copying the document.




For information about how to use the common tabs such as Document Overview, Notes and Attachments, and Ad Hoc Recipients, and Route Log, see “

Common E-Doc Sections ” on page 90 in Usage Basics.



Figure 77 Common Maintenance Document Action Buttons

Searching for a Maintenance Document


Searching for a maintenance document may be accomplished by clicking on a link for the type of maintenance document you want to view, conducting a search from the lookup screen, and clicking on a search result value drill-down link.  Follow this procedure when you want to locate and view a record when the type of maintenance document is already known.

  To search for a maintenance e-doc:



Select the desired maintenance e-doc by clicking a link from within one of the menu groups on the Maintenance screen (for example, Proposal Type ).



The lookup screen for the maintenance e-doc you selected appears:


Enter appropriate search criteria (or leave blank to retrieve all) and then click search .






End of activity.


Click the link (underlined value in the left column of the search results table) for the value you want to view (for example, 1 ).

A pop-up window appears that displays the value details (code value and description):




Initiating a Maintenance Document