Kuali Rice 2.0.0-b7 User Guide

The Kuali Foundation employs staff to coordinate partner efforts and to manage and protect the Foundation’s intellectual property. The Kuali Foundation manages a growing portfolio of enterprise software applications for colleges and universities. A lightweight Foundation staff coordinates the activities of Foundation members for critical software development and coordination activities such as source code control, release engineering, packaging, documentation, project management, software testing and quality assurance, conference planning, and educating and assisting members of the Kuali Partners program.

Kuali Rice is a higher-education, community-source software project that is merely a spoke in the wheel of the larger Kuali Community. The Kuali Community is the hub of a wheel of a growing number of communities, each of which are made up of people and functions. Together they form a comprehensive suite of open, modular and distributed administrative software systems that bring the proven functionality of legacy applications to the ease and universality of online services. The Kuali Foundation serves them all, with specific responsibilities related to keeping the wheel in motion. Each individual community shares a similar organizational structure and some modular functionality while its components are able to stand alone to perform unique functions. While all are designed for seamless integration with each other, each project is made up of modules that offer a variety of implementation combinations to suit any Carnegie-class institution’s unique business needs.

Should you want to learn more detail about how the Rice community is organized, structured and operates you should reference the Rice Charter which is available for review in the Foundation archives.

Kuali Rice software is licensed under the Educational Community License, Version 2.0. You may obtain a copy of the License here. See the License for the specific language governing permissions and limitations.

If you have any questions about Kuali Intellectual property, please contact the Kuali Foundation at licensing@kuali.org.

TODO: Link to Third Party Licenses Page

This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. To view a copy of this license, visit http://creativecommons.org/licenses/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.

You are free:

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

Each chapter is comprised sections that correspond to modules within Rice. In order to reduce the required effort for documentation maintenance, the documentation is structured so as to not repeat the same material across various chapters.

Likewise, the chapters are designed to cross-reference appendices such as the Data Element Dictionary, Glossary of Terms, Report Catalog and Index, to reduce redundant information within the chapter bodies and give you one common location for information lookup.

This document adheres to specific documentation standards and style conventions to optimize readability. The formatting of text used to name user interface elements is typically bold to enhance visual comprehension and improve usability.

If you have received a printed copy of this user guide, please note that as Rice is improved and enhanced, corresponding updated releases of the documentation are available online. To ensure you have the latest and most current user guide at any time, consult the links from the Documentation page on the Rice web site and compare the versioning.

Cross-references, indexes, and the electronic table of contents are provided wherever possible to allow for efficient navigation to sections and subsections of instructional information (or external Web resources). Each underlined topic functions as a hyperlink that causes a new section to appear.

User documentation made available for online viewing, download and printing may require the use of Portable Document Format (PDF) reader software, such as Adobe Acrobat Reader. Refer to http://www.adobe.com for complete instructions regarding downloading and installing this free software.

One of the beauties of Rice is that it shows you just the screens and fields that are useful for your Rice Role and the function you need. For example, if your Role in Rice lets you create new Rice documents, then you can see a create new button on appropriate screens. If you click this button, you go directly to the screen for creating new documents. People whose Role doesn’t create new documents aren’t bothered with this button on their screens.

Screens with information or functions that can be used in many places in Rice are very conveniently linked to those places, so useful screens are always at your fingertips. For example, screens that use Person information display a link to the Person Lookup screen. This lets you search for the exact Person you need and enter that Person’s information automatically on those screens. (In Rice, a Person is a set of information about a real person or something that stands for real people, like a job title.)

Not only will you find links to a useful screen like Person Lookup on many other screens, but what you see on that useful screen may depend on how you get to it. For example, if you go to the Person Lookup screen from an Administration menu and search for a Person, the search results list has Actions in the left column, and the link for each Person in the Actions column takes you to the edit screen for that Person.

On the other hand, if you go to a Person Lookup screen from other locations, the left column of your search results list has a return value link. You can click this link on the row for the Person you need to close the Person Lookup screen and automatically enter the information for that Person on the original screen (the screen where you clicked the magnifying glass icon).

Rice allows you to use wildcards in the Lookup process. The available wildcards and their functions:

Examples of how some of the wildcards operate:

Some lookups for certain business entities in Rice return different numbers of results than the system default; as a result, system administrators may need to be able to limit this set of returned results on an entity-by-entity basis.

To make it easier to do your work, Rice often provides access to the same information from several screens. Some of the most frequently used are described here:

Ad Hoc Recipients Tab

The Ad Hoc Recipients tab allows you to interrupt the normal workflow routing of a document and include other individuals or groups in its routing path. Ad Hoc Routing does not replace the normal workflow routing of the document; it adds people or groups to the normal routing.

The Ad Hoc Recipients tab has two sections: Person Requests and Ad Hoc Group Requests. Use one or both of the sections to route the document to an additional person, group, or both.

Figure 1.1. Ad Hoc Recipients Tab

Figure 1.2. Ad Hoc Recipients Tab: Person Requests

Table 1.6. Ad Hoc Recipients: Person Requests attributes

Field
Action Requested	Required field. Select the desired action from the Action Requested list. The choices are APPROVE, ACKNOWLEDGE, and FYI.
Person	Required when you want to route the document to an individual. Enter a user ID or select it using the UserID lookup button.

When you click the Add button, Rice adds this person to the routing path for this document.

Figure 1.3. Ad Hoc Recipients Tab: Group Requests Section

Follow the same guidelines as the Person Requests Section of the Ad Hoc Recipients Tab, using a group instead of a person.

Table 1.7. Ad Hoc Recipients: Group Requests attributes

Field	Description
Namespace Code	Optional field. The Rice code for the Namespace being acted upon.

Document Overview Tab

The Document Overview tab contains the short description for a document and two other optional fields. This tab is used for many documents.

Figure 1.4. Document Overview Tab

Table 1.8. Document Overview Tab: Attributes

Field	Description
Description	Required field. Enter the short description for the document. The description appears in Inquiry screens, standard reports, Action Lists, and Document Searches as the primary identification for a document.
Org Doc #	Optional field. Enter the Org Doc # assigned by your institution. This number may provide departmental or organizational information for the document. This number is not the same as the Document Number, which is assigned by Rice.
Explanation	Optional field. Enter a more detailed explanation than the information supplied in the description field.

Note and Attachments Tab

The Notes and Attachments tab has fields for user notes, attachments, and system-generated remarks about the document. The number of notes and/or attachments for the current document is displayed on the tab, in parentheses next to the tab title.

Figure 1.5. Notes and Attachments Tab

Table 1.9. Notes and Attachments Tab: Attributes

Field	Description
Posted Timestamp	Display-only field. The time and date when the attachment or note was posted
Author	Display-only field. The full name of the user who added the notes or attachments
Note Text	Required field. Enter comments about the document.
Attached File	Optional field. Select the file to attach by clicking Browse and using Window's standard Choose File dialog box. Click CANCEL if you want to clear the file name that you select.
Actions	You have only one Action available if you are going to add a note or attachment, which is to Add it. Click the add button to add the note or attachment.

Route Log Tab

The Route Log tab displays details of the workflow status.

Figure 1.6. Route Log Tab

Figure 1.7. Route Log Tab: ID Section

Table 1.10. Route Log Tab: ID Section Attributes

Field	Description
Title	A combination of the Document Type, Description, and the Organization Document Number
Type	Type of transaction. The full name of the transaction, used to identify this Document Type in Workflow
Initiator	The User ID of the person who created the document
Status	Workflow document status
Node(s)	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.
Created	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
Finalized	Time and date that the document reaches Final, Canceled, or Disapproved status

Figure 1.8. Route Log Tab: Future Action Requests Section

Once a document is Saved or ENROUTE, this section 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.

Kuali Rice keeps an online list of issues (bugs and suggested improvements and new features) using an issue tracking application called Jira. Your first step is to find out if the issue you have has already been reported by someone.

If you didn’t find a similar issue on the Issue Navigator page, then please create a new issue in JIRA. (If you are a developer, you also determined that this is an issue with Kuali Rice and not with your application.)

Figure 1.10. Create New Jira: Initial Screen

Only enter information in these fields:

Ignore all other fields. Do not change them. Other people use those fields.

This screen print is from the Bug Fix screen. The screens for Improvement and for New Feature are slightly different. The fields in which you need to enter information are highlighted in this screen print.

Figure 1.11. Creat New Jira: Detail Section

After entering the information about the your issue, click the Create button at the bottom of the page. This creates your issue in JIRA.

PeopleFlow is a new feature in Rice 2.0, that enables simple routing of actions and notifications based on business rules. PeopleFlow can be integrated with enterprise-wide workflow management in KEW, or can be used without KEW, with the Kuali Rules Management System (KRMS) engine that is also new in Rice 2.0. This offers a light-weight way to manage business rules and routing across applications.

A notification channel is a communication stream used as a means to organize notifications by topic or audience. Users and groups can subscribe to a channel to receive the notifications that interest them.

You can think of a notification channel as being like a television channel. Producers put messages on a channel, like producers at television stations air programs. Subscribers receive the messages, like television viewers watch the programs. Unlike a television program, a message sent on a channel will wait for you to read it; you do not need to be actively reading the channel to avoid missing a message.

Each channel has the following attributes:

There is no user interface page to manage channels at this time.

Subscribing to a notification channel causes all notifications sent on the channel to be delivered to the subscriber, regardless of the list of users or groups specified as recipients of the notification.

Subscriptions are divided into two categories:

Users can manage their subscriptions to channels where the Subscription Flag is Yes using the Channel Subscriptions form. On the Main Menu, click the Channel Subscriptions link in the Notification box:

Figure 3.1. Notification Channel: Channel Subscriptions

This displays the list of channels that allow the user to manage their subscriptions:

Figure 3.2. Chanel Subscriptions: Manage

Click the Subscribe button for a channel to subscribe to a channel for which you are not already subscribed. Click the Unsubscribe button to cancel your subscription to the channel.

Kuali Enterprise Workflow provides a common routing and approval engine that facilitates the automation of electronic processes across the enterprise. The workflow product was built by and for higher education, so it is particularly well suited to route mediated transactions across departmental boundaries. Workflow facilitates distribution of processes out into the organizations to eliminate paper processes and shadow feeder systems. In addition to facilitating routing and approval, workflow can also automate process to process related flows. Each process instance is assigned a unique identifier that is global across the organization. Workflow keeps a permanent record of all processes and their participants.

You can define a PeopleFlow (simple workflow) via a maintenance document. In the Kuali Rice portal on the main tab there is a Workflow category, and PeopleFlow is in that category. Select it:

Figure 4.1. PeopleFlow selection on the Main tab in the Kuali Portal

You can search for a PeopleFlow to copy from and modify (be sure to give it a new unique name) or can create a new one (see the top right of the lookup screen).

Figure 4.2. PeopleFlow Lookup

Below is a view of the user interface to create a new PeopleFlow:

Figure 4.3. PeopleFlow - Create New

The view below shows that some sections are collapsed, and also shows additional attributes that are required based on the user's selection of a type. This is an example of the Kuali Rapid Application Development (KRAD) framework's support of progressive disclosure, only showing these additional type attribute fields if/when they are required:

Figure 4.4. PeopleFlow - Create New (with additional type attributes)

And below is a view of just the PeopleFlow Members section - expanded - after adding two stops:

Figure 4.5. PeopleFlow - Create New - with 2 stops added

PeopleFlows that you create can be called by rules, with the rules determining whether the PeopleFlow will be called for an action (such as approvals) or for notifications. These PeopleFlows (similar to the Coeus concept of "maps") can be integrated with the new Kuali Rules Management System (KRMS), with KEW workflows, or with other custom-built applications.

The Action List page includes your:

In the Kuali Rice portal, the Action List button is available in the upper left hand corner of the screen on most pages.

Your institution may have KEW links inside other applications, such as Kuali Financial Systems (KFS). KFS may display an Action List button at the top left of the KFS page like this:

Figure 4.6. Kuali Portal: Action List Button

Clicking an Action List link or button displays your Action List page. This is a sample KEW Action List; your institution’s may look somewhat different:

On your Action List page is the list of documents on which you need to take an action, such as Approve, Disapprove, or Acknowledge, and those which you have already completed. These are your action requests. Action requests that someone has delegated to you are also listed on your Action List page. Note: You can only see the Action List for the person who is logged into KEW or another Kuali application.

You can click the title at the top of a column to sort all of your action requests by the information in that column. For example, if you click the column title, Type, KEW sorts your action requests by their Type.

On your Action List, you can see this information about the documents on which you need to take action:

If enabled for a particular document, messages can also be logged through the route log tab (or page). This allows users to add a deferral message or other message that will be reflected in the routing without taking an action on the document.

This function is enabled by KIM permissions. These permissions have template 'Add Message to Route Log' which takes a document type name as a detail. The bootstrap dataset contains one permission with this template and document type detail 'KualiDocument', however this permission is not granted to any role. This means the functionality will be disabled until the permission is assigned or another permission record with this template and for another document type is created and assigned. When matching permissions for a particular document type the document type hierarchy is considered. Permission records for children document types will override any permission record for its parents.

For example, if we wanted to enable the feature on all KualiDocuments except document type 'Foo', we would first grant the permission with document type detail 'KualiDocument' to a role. Then we would create an additional permission with template 'Add Message to Route Log' and document type detail 'Foo'. For the second permission we do not assign any roles.

By granting these permission(s) to one of the derived workflow roles we can enable this feature to users who have active routing requests. Examples of such roles are KR-WKFLW Approve Request Recipient and KR-WKFLW Acknowledge Request Recipient.

You can customize the appearance and features of your Action List using the Action List Preferences page on KEW. To display this page, click the Preferences button at the top of the Action List page or click the User Preferences link in the Workflow pane of the Main Menu tab. Action List page:

Figure 4.9. Action List: Preferences Button

This displays the Action List Preferences page, where you can make choices about how KEW displays and refreshes (updates) your Action List and about how and when you receive email reminders about your new action requests:

Figure 4.10. Action List Preference Page

The Action List Preferences page has four sections:

Action List Preferences: General Section

Figure 4.11. Action List Preferences: General section

• In the General section of the Action List Preferences page, you can set the Automatic Refresh Rate for your Action List. Your action requests come in from the server and your Actions Taken are sent to the server each time KEW refreshes (updates) your Action List page. You only see changes to your Action List when KEW refreshes it.

• Depending on the network and computers at your workplace, your computer may or may not slow down when KEW refreshes your Action List. If a refresh slows down your computer, you may decide to set the Automatic Refresh Rate for a longer period, such as 10 or 15 minutes.

• The Action List Page Size tells KEW how many action requests to display at once on your Action List page.

• The Delegator Filter field lets you decide where to show action requests for which you are a secondary delegate. You can choose to have KEW display these action requests on your Action List page or not, using this dropdown menu. If you do not display action requests on which you are the Secondary Delegate on your Action List page, you can only see them on a Filter Page (see Filter, below).

Action List Preferences: Fields Displayed

Figure 4.12. Action List Preferences: Fields Displayed section

• You determine which fields are displayed on your Action List page using this section of the Action List Preferences page. Place a checkmark in the box next to fields that you want to display on your Action List page. (Click the box to checkmark it and click it again to un-checkmark it, and vice versa.)

Action List Preferences: Document Route Status Colors

Figure 4.13. Action List Preferences: Document Route Status Colors Section

• In this section of the Action List Preferences page, you can choose a color for each different Status of action requests. This can help you quickly find action requests on which you need to take action.

For example, if you set these colors for these routing status levels:

• Green for Saved status

• Red for Approved status

• Blue for Exception status

Your Action List Preferences page looks like this:

Figure 4.14. Action List Preferences: Document Route Status Colors Example

Click the Save button at the bottom of the page to make these changes in your Action List.

Action Lists your color changes by Status:

Figure 4.15. Action List Preferences: Document Route Status Colors Action List Example

Action List Preferences: Email Notifications

Figure 4.16. Action List Preferences: Email Notifications Preferences

The fields used to maintain email preferences are located in a new “Email Notification Preferences” section at the bottom of the Workflow Preferences screen. The “Email Notification Preferences” section accommodates two new options and allows selection of how and when to receive reminder emails on items sent to the Action List.

In this section, one can select whether or not to receive emails as the Primary Delegate, as the Secondary Delegate, and also set the Default Email Notification preference (None, Daily, Weekly, or Immediate). If you are NOT a Primary or Secondary Delegate, you can leave those fields as unchecked.

You can choose to get email reminders on one of these Default Email Notification schedules:

• None (KEW won’t send you any email reminders for your Action List.)

• Daily (If you have any new action requests, KEW sends you an email reminder once a day.)

• Weekly (If you have any new action requests, KEW sends you an email reminder once a week.)

• Immediately (KEW sends you an email reminder as soon as you receive a new action request on a document. This is the default – the setting when you start to use KEW.)

The first new option allows overriding of the ‘Default Email Notification’ preference and setting of different frequencies to receive notifications based on the document type of the action request (Timesheet, EPTO, Hire Employee eDoc, Create Additional Pay eDoc, Requisition, etc.).

The parameters set for the default email notification and document-type notification work together to determine when a given action item is included in the immediate, daily, or weekly email reminders.

If one sets a ‘Default Email Notification’ without any ‘Document Type Notifications,’ then emails are sent (or not sent), based on the default selection.

The second new option allows one to turn notifications on or off based on the request type (Complete, Approve, Acknowledge, or FYI) when “Immediate” is set as the ‘Default Email Notification.’

Figure 4.17. Action List Preferences: Document Type Notifications

However, adding a ‘Document Type Notification’ that is different from the ‘Default Email Notification,’ forces the document-type notification to take precedence. This allows users to customize by document- type for email reminders. For example:

• If ‘Immediate’ is set as the ‘Default Email Notification,’ but a document-type rule is set to ’None’ for the Maintain Time Assignment eDoc; then no email notifications are sent for that specific document.

• If ‘Daily’ is the ‘Default Email Notification,’ and a document-type rule is added to receive ‘Weekly notifications for the Hire Employee eDoc; then for that document, the only action request email received is a Weekly reminder.

• If ‘None’ is set as the ‘Default Email Notification,’ and a document-type rule is added to receive “Daily” notifications for EPIC Purchase Orders; then for that document, the only action request email received is a Daily reminder.

In addition, when the ‘Default Email Notification’ is set to “Immediate” one can use the Send Email Notifications For option to decide whether or not to receive notifications by request-type.

All four of the request-types are already “checked” by default in your Workflow Preferences screen.

Figure 4.18. Action List Preferences: Action Requested Email Notification

When an action request is received, and the preference is set to receive an immediate reminder, the system checks to ensure that the request-type checkbox is turned-on (checked) before an email is sent.

This allows these checkboxes to be used as a switch to ‘turn-on or turn-off’ the “immediate” email reminders for a given request type. For example:

• To stop the receipt of Acknowledgement emails when your preference is set to receive “Immediate” reminders, just uncheck the “Acknowledge” checkbox.

Remember, all of these preferences and settings are on your Action List Preferences page.

Action Requests are one of the core functions of the Kuali Enterprise Workflow (KEW) system. An Action Request is a call from KEW to a person or group to take action on a document. Action Requests are created when the system or a person routes (sends) a document to another user and ask that user to do something with the document. You might ask someone to approve an expense, for example, or to acknowledge that he or she received a copy of an expense report.

Once an Action Request has been created in KEW, the associated document is sent to the appropriate users’ action lists. A user can open his or her Action List and from there, view information about the document, open the document, and/or take the requested action. If a user takes an action, for example, approves or disapproves a document, that is called an Action Taken.

The path that the document takes from its starting point to final approval is called its route. Each point along that path where a person needs to do something with the document (approve, acknowledge, etc.) is called a node on the route.

Each action request has one row on your Action List. There are five types of Action Requests:

There are other actions that you can take in addition to Action Requests. We will look at those in the Action Taken section below.

Every action request has a recipient. The recipient is the individual or group of individuals whose action is requested on the document. There are three types of recipients:

Roles are groups of users or KIM Groups associated with a document.

The first user in a Group to take action on a request satisfies (completes) that request. Role requests can be set up to work the same way as Group requests or to require that everyone in that Role approves the document before the request is satisfied.

In certain situations, you can use roles for action requests and you can delegate action requests. You can think of these as trees or as a parent action request that has children action requests.

Roles are groups of Principals or Groups that KEW creates based on rules your institution sets up. Since KEW can only create an action request for a single person or group but a role may have several people or groups in it, KEW creates an action request for the role (a parent request), and that action request creates child action requests that go to each person or group in that role.

The parent role request can have any number of children requests that are each either a user request or a group request.

Combining Role Requests and Delegation

You can combine a role request with a delegate. In fact, in the previous example, the action request that is sent to Joe as a fiscal officer is really a role request. The action request tree for that scenario is:

Figure 4.23. Delegation Tree Example

This tree is three levels deep and shows a role delegating to a user. You can also have a role delegate to another role.

Actions are how a user interacts with KEW. Actions can be performed in response to an Action Request (such as an Approve action) or they can be user-initiated (such as the routing of a document). Most, but not all, actions create Action Takens. The Action Taken is recorded on the Route Log and associated with a satisfied action request, where appropriate.

The KEW Action library contains these Actions, explained below:

eDocLite is a framework designed for rapid development and implementation within an existing Kuali Enterprise Workflow infrastructure. It allows for the development of simple web applications, their forms and routing configurations using XML. Users only have to enter data into the form and then submit it. Rules can be constructed so that the form is then routed to a specific user or KIM Group based on the data entered.

Web pages called eDoc's are generated and are associated with a specific document type definition that provides the overall definition for how the document can be routed. Document types can also exist in hierarchies which provide storage of common information at various levels.

The form uses an XSLT stylesheet to generate the html code. Certain workflow classes make helper data available to the stylesheet programmer and there are several features that can be 'plugged-in' to eDocLite to further enhance its usability in many situations.

Use the eDocLite Lookup screen to quickly find basic information about eDocLite documents and as the first step in creating a new eDocLite.

Figure 4.25. Workflow Channel: eDocLite Link

eDocLite Lookup

Figure 4.26. eDocLite Lookup

On the eDocLite lookup page, users can search for an eDocLite document based on several criteria:

Table 4.2. eDocLite Lookup Attributes

Field	Description
Id	The unique ID number assigned to each document.
Document Type	The name of the document type, which is specified in the Document Type attribute of an eDocLite.
Definition	The name of the EDL XML definition.
Style	The style specified in the EDL XML file is the style attribute of an eDocLite. Generally an EDL XML file has only one definition name which relates to one and only one style name.
Active Indicator	You have the choice of searching by the active status of an eDocLite.

You can use the above criteria to limit your search results. A search will produce a list of one or more results that look similar to the following:

Figure 4.27. eDocLite Lookup: Search Results

Clicking Create Document on any line takes you to the eDocLite document screen where new documents can be created. The line item you choose will result in that document being used as a template for the new one you are creating. More information on this follows in the section called Create New eDocLite Document.

Clicking any underlined Id will take you to the eDocLite Inquiry screen for that document.

Note

Exporting the output list to XML will give you the option of viewing the XML used to produce the list returned from the search.

Standard in KEW there is one eDocLite for electronic routing, and new eDocLites can be added based on business requirements. Some of the functions that eDocLites are used for in business include:

• Applicant Monitoring

• BLSC Request

• Course Change Request

• Grade Replacement Request

• Internship Contract

• Interview Request

• Mass Mailing Request

• Offer Request

• Program Plan Update

• REGR Access Request

• Removal Of Incomplete

• Revenue Producing Activity

• SUDS Request Document Type

• Search Status

• Special Credit Request

• Student Trip

• User Agreement

• Unit Change Request

• Vacancy Notice

• Vehicle Replacement

• Waiver Request

• New Course Request

Figure 4.28. eDocLite Inquiry

The Inquiry screen displays the same information as is found on a line of the Lookup output, but this screen provides you with the export option. Exporting from the Inquiry screen produces a XML file of the source for the eDocLite document.

To create a new eDocLite document to be routed in KEW, click on Create Document in the row for eDocLite type wanted. It will take users to different forms of eDocLites depending on the document function, but they all have three general parts:

These are the columns that will be displayed on the user’s action list page.

Each Document Route Status can be displayed with a certain color on the action list. This section allows you to configure which colors are used. By default, no colors are set.

Rice provides a quick and convenient way to obtain information on Delegation Rules through the Delegate Rule Lookup. This Lookup also lets you create new Delegation Rules using the create new function and edit existing Delegation Rules.

Figure 4.31. Workflow Channel: Routing Rules Delegation Link

To access the Delegate Rule Lookup screen, click Routing Rules Delegation on the Rice Main Menu.

Figure 4.32. Delegation Lookup

Use the Delegate Rule Lookup screen to find information about a Delegation Rule. You can also create a new Rule by clicking the create new button in the upper right corner of the screen. The create new function is described in the Routing Rule Creation section later in this document.

When you do a search from the Delegate Rule Lookup screen, you can:

Information about the Lookup function is in the next section of this document. The other two functions are described in the Routing Rule Delegation Maintenance section later in this document.

To find a Delegation Rule quickly, enter information in one or more of the fields on the Lookup screen, then click the search button. If you are not familiar with the search fields, you can leave all of the fields blank and click the search button. The Delegate Rule Lookup page then displays all of the Delegation Rule templates.

The fields on this screen are described in the Routing Rule Delegation Maintenance section of this document.

After you click the search button, Delegate Rule Lookup displays a list of Rules that looks similar to this:

Figure 4.33. Delegation Lookup: Results Example

Click edit on any row to go to the Routing Rule Delegation document for that Rule. You can use this document to do maintenance on that Rule. This is discussed later in this document, in the Routing Rule Delegation Maintenance section.

Click copy on any row to go to the Routing Rule Delegation document with the information from that Rule copied into the document. This lets you add a new Delegation Rule based on that information. This is discussed later in this document in the Routing Rule Delegation Maintenance section.

Click a Delegation Rule Id to go to the Delegation Rule Inquiry screen for that Rule. This screen displays specific information about how this Rule is set up in Rice. This screen is discussed later in this document in the Delegation Rule Inquiry section.

Click a Parent Rule Id or a Name to go to the Rule Inquiry screen, where you can see details about that Parent Rule ID. More information about this screen can be found in the Rule Inquiry section of this User Guide.

Click a Rule Template to go to the Rule Template Inquiry screen. More information about this screen can be found in the Rule Template Inquiry section of this User Guide.

The standard export options apply to this list of search results. An explanation of the export options can be found in the Common Features and Functions section of this User Guide.

Figure 4.34. Delegation Inquiry

This screen provides specific information on how a Rule works. From this screen, you can either click the close button to return to the previous screen or you can export an XML version of this information.

The fields on this screen are described in the Rule Maintenance section of this document.

Figure 4.35. Delegation Rule: Create New Screen

To create a new Delegate Routing Rule, start by selecting a Parent Rule to associate with your new Delegate Rule:

You can use the Routing Rule Delegation document screen for both editing existing Delegation Rules and for adding new Delegation Rules to Rice.

Figure 4.37. Routing Rule Delegation: Overview

Delegation Details Tab

The Delegation Details tab is where you associate a Parent Rule with a Delegate Rule. It is also where you assign the Reviewer role.

The Delegation Details screen is displayed differently, depending on whether you are creating a new Rule or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 4.38. Routing Rule Deleation: Details Section

The information displayed is a copy of the information for the Parent Rule. Descriptions of these fields are below. Change this information as needed, then click the submit button to create this new Rule.

The version you see when editing or copying a Rule looks similar to this:

Figure 4.39. Routing Rules Delegation: Edit/Copy View

When you first see this version, the information in both columns is the same. You can modify the information in the fields in the right column, but not the left column. After changing the information appropriately in the right column, click the submit button to save your changes to this Rule.

The fields are the same in both versions of the screen:

Table 4.8. Routing Rules Delegation Attributes

Field	Description
Parent Rule Id	Rule Id of the Parent Rule for this Rule
Description	General description of this Rule
Reviewer	The person responsible for reviewing a document in the routing process for this Rule
Type	The Type of the Reviewer
Action Request	The type of Action this Reviewer can take. This may be: Acknowledge Complete Approve FYI

Delegate Rule tab

The Delegate Rule tab is displayed differently, depending on whether you are creating a new Rule or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 4.40. Routing Rules Delegation: Delegate Rule Tab

Enter the appropriate information for your new Delegate Rule in these fields. There are descriptions of each of these fields below.

The version you see when editing or copying a Rule looks similar to this:

Figure 4.41. Routing Rule Delegation: Delegate Rule Tab, Edit/Copy View

When you first see this version, the information in both columns is the same. You can modify the information in the fields in the right column, but not the left column. After changing the information in the right column appropriately.

The fields are the same in both versions of the screen:

Table 4.9. Routing Rule Delegation: Delegate Rule Tab Attributes

Field	Description
Document Type	The Document Type defines the routing definition and other properties for a set of documents. Each document is an instance of a Document Type and conducts the same type of business transaction as other instances of that Document Type.
Rule Template	A Rule Template serves as a pattern or design for routing Rules.
Delegation Type	Required. Options for Delegation Type are: Primary: This means that the delegator turns over full authority to the delegate. The Action Requests for this delegator only show up in the Action List of the primary delegate. A primary delegate must be registered in KEW to be in effect. Secondary: This means that the secondary delegate acts as a temporary backup delegator who has the same authority as the primary approver, or the secondary delegate acts as the delegator if the delegator is not available. Documents appear in the Action Lists of both the delegator and the secondary delegate. When either person acts on the document, it disappears from both Action Lists. A secondary delegate must be registered in KEW as being in effect for a specific time period(s). Both
Name	he unique Name of the routing delegate Rule you are creating or editing. Note: You are not required to enter a Name, but if you don’t, Rice assigns a unique Name to the Rule.
Description	The general description of the Rule
From Date	The start date of the routing Rule
To Date	The expiration date of the routing Rule
Force Action	This is a Yes or No flag. A checkmark means Yes, blank means No.
Active	A True/False flag to indicate whether this Routing Delegate Rule is active in Rice. If it is active, you can use it in Rice.

Persons tab

Rice displays the Persons tab differently, depending on whether you are creating a new Rule or editing/copying a Rule. This tab lets you add people to the Rule and set the type of Action each person needs to take under this Rule. The version of the Persons screen that you see when creating a new Delegate Rule looks similar to this:

Figure 4.42. Routing Rules Delegation: Persons Tab

Enter the appropriate information for the Persons section of your new Delegate Rule in these fields. There are descriptions of each of these fields below.

The version you see when editing or copying a Rule looks similar to this:

Figure 4.43. Routing Rules Delegation: Persons tab, Copy/Edit View

Use the top portion of this tab to add a new Person to this Rule and set the Action that Person needs to take and its Priority. Use the lower portion of this tab to change existing values for this Rule.

Note

When you create a new person, you must click the add button when you have entered information in the three required fields.

Table 4.10. Routing Rules Delegation: Persons Tab Attributes

Field	Description
Person	Required. An individual user who receives the document for the Action Requested.
Action Request	Required. The type of Action this person needs to take. This Action may be one of these: Acknowledge Complete Approve FYI
Priority	Required. The priority associated with the Person in this Rule. One is the highest Priority.

Groups tab

The Groups tab differently, depending on whether you are creating a new Rule or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 4.44. Routing Rules Delegation: Groups Tab

Enter the appropriate information for the Groups section of your new Delegate Rule in these fields. These fields are described below.

The version you see when editing or copying a Rule looks similar to this:

Figure 4.45. Routing Rules Delegation: Groups Tab, Edit/Copy View

Use the top portion of this tab to add a new Group. Use the lower portion to change existing information for a Group.

Note

When you create a new group, you must click the add button after you enter information in the required fields.

Table 4.11. Routing Rules Deleation: Groups Tab Attributes

Field	Description
Namespace	The Namespace to which this Group will belong. A Namespace is a way to set both Permissions and Entity Attributes. Each Namespace instance is one level of Permissions and Entity Attributes and is one record in Rice.
Name	The unique name of this Group
Action Request	Required. The type of Action this Group is expected to take. The Action may be one of these: Acknowledge Complete Approve FYI
Priority	Required. The priority associated with the Group in this Rule. One is the highest Priority.

The Rice system provides a quick and convenient way to obtain information on Rules through the Rule Lookup feature. This feature also provides an entry point to creating a new Rule through the create new function.

Figure 4.46. Workflow Channel: Routing Rules Link

To access the Rule Lookup screen click on Routing Rules on the Rice Main Menu.

The Rule Lookup screen is used to view, edit or copy information about routing rules defined in Rice. It is also the starting point for creating a new rule using the Routing Rule Creation screen.

Figure 4.47. Routing Rules Lookup

Click on the create new button to go to the Routing Rule Creation screen. The process for creating a new Routing Rule is discussed in the Routing Rule Creation section of this document.

To limit your search results you can select one or more of the available search criteria.

The fields on this screen are described in the Rule Maintenance section of this document.

Rule Lookups return a list that looks similar to the following:

Figure 4.48. Routing Rules Lookup: Results Example

Clicking edit on any line item takes you to the Rule Maintenance Document Type Document where you can perform maintenance on that rule. This is discussed later in this document in the Rule Maintenance section.

Clicking copy on any line item takes you to the Rule Maintenance Document Type Document where you can add a new rule based upon the rule you are copying. This is discussed later in this document in the Rule Maintenance section.

Clicking a Rule Id will take you to the Rule Inquiry screen for that specific rule. This is discussed later in this document in the Rule Inquiry section.

Clicking a Document Type will take you to the Document Type Inquiry screen for that specific rule. This is discussed in the Document Type Inquiry section of the User Guide.

The standard export options apply to this list. Explanation of the export options can be found in the Common Features and Functions section of the User Guide.

Figure 4.49. Routing Rules Inquiry

This screen provides specific information on how the Rule is set up in Rice. The fields on this screen are described in the Rule Maintenance section of this document.

Figure 4.50. Routing Rules Creation

When creating a new Routing Rule you start by entering the Document Type and the Rule Template you want associated with your new Rule, then click the continue button. This takes you to the Rule Maintenance Document Type Document described in the Rule Maintenance section that follows.

The routing report is a tool to check workflow routing. You select a rule template and enter any routing data required by the rule template. You can then view the workflow routing that would be assigned to such a document.

Figure 4.51. Workflow Channel: Routing report

Using the Report

In the default implementation of Rice you can find the link to the Routing Report on the "Main" tab of the portal inside the "Workflow" pane. If for some reason the link is not visible on the "Main" tab you can still directly navigate to the Routing Report. To access the tool directly, replace the last part of the Rice Portal URL (portal.jsp) with kew/RoutingReport.do (for example, http://my.kuali.host/kuali/portal.jsp would become http://my.kuali.host/kuali/kew/RoutingReport.do). The following page is displayed:

Figure 4.52. Routing Report: Template Selection

Select a Rule Template

The first thing to do is select the rule template to use for the test from the drop-down list. When you select a template the page will update to show the routing data that you need to enter to run the test:

Figure 4.53. Routing Report: Template Selection, Detail

Enter Routing Data

The data entry fields for the routing data use the standard controls described in the Standard Buttons on Lookup Screens document. Here is the example with the routing data:

Figure 4.54. Routing Report: Routing Data Entry

The specific information you need to enter is specific to the rule template you selected. Once you have entered the information, click the button to display the report:

Figure 4.55. Routing Report: Route Log View

Report Contents

The upper section of the report (labeled “ID: 0”) contains the basic document information fields as if this was an actual document; several fields are blank since there is no actual document.

The lower section of the report (labeled “Pending Action Requests”) contains the routing that the document would be given. Clicking the button on any action displays more detail of the action:

Figure 4.56. Routing Report: Route Log View, Pending Action Requests

The Rule Maintenance Document Type Document screen is used for both editing existing Rules and for adding new Rules to Rice.

Figure 4.57. Rule Maintenance Document Type Document

Rule tab

The Rule tab is presented differently depending on whether you are creating a new Rule, or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 4.58. Rule Maintenance Document Type Document: Rule Tab

The version you see when editing or copying looks similar to this:

Figure 4.59. Rule Maintenance Document Type Document: Rule Tab, Edit/Copy View

Table 4.13. Rule Maintenance Document Type Document: Rule Tab Attributes

Field	Description
Document Type	The Document Type defines the routing definition and other properties for a set of documents. Each document is an instance of a Document Type and conducts the same type of business transaction as other instances of that Document Type.
Rule Template	The name of the Rule Template with which this rule is associated. A Rule Template serves as a pattern or design for the routing rules and is a mechanism for providing configuration information to rules.
Name	The unique Name of the routing Name you are creating or editing. Note: It is not required that you enter a Name, but if you don’t the system will assign a unique value.
Description	The general description for the rule selected.
From Date	The start date of the routing rule.
To Date	The expiration date of the routing rule.
Force Action	Force Action is used to control workflow routing by making the rule actions mandatory. This is a yes or no flag. A check means yes, blank means no.
Active	A true/false flag to indicate if Routing Rule is active in Rice can be applied or not.

Persons tab

The Persons tab is presented differently depending on whether you are creating a new Rule, or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 4.60. Rule Maintenance Document Type Document: Person Tab

The version you see when editing or copying looks similar to this:

Figure 4.61. Rule Maintenance Document Type Document: Person Tab, Edit/Copy View

Table 4.14. Rule Maintenance Document Type Document: Person Tab Attributes

Field	Description
Person	An individual user who receives the document for the Action Requested.
Action Request	The type of action this person can take. Acknowledge Complete Approve FYI
Priority	The priority associated with the person in this rule. Lower values mean higher priorities, with 1 being the highest priority.

Groups tab

The Groups tab is presented differently depending on whether you are creating a new Rule, or editing/copying a Rule. The version you see when creating a new Rule looks similar to this:

Figure 4.62. Rule Maintenance Document Type Document: Groups Tab

The version you see when editing or copying looks similar to this:

Figure 4.63. Rule Maintenance Document Type Document: Groups Tab, Edit/Copy View

The top portion of this tab is used to add a new Group while the lower portion is used to change existing values.

Table 4.15. Rule Maintenance Document Type Document: Groups Tab Attributes

Field	Description
Namespace	The Namespace to which this Group will belong. A Namespace is a way to scope both Permissions and Entity Attributes. Each Namespace instance is one level of scoping and is one record in the system.
Name	The unique name of the Group.
Action Request	The type of action this Group is expected to take. Acknowledge Complete Approve FYI
Priority	The priority associated with the Group in this rule. One being the highest.

The Rules Template Lookup function is available from any screen with the field lookup button next to the Rule Template field. Simply click on the button and you will go a screen that looks like this.

Figure 4.64. Rule Template Lookup

The Rule Template Lookup page will automatically provide a complete list of the rule templates. You can reduce the number of items returned by your search by entering values in the fields, or if you are not sure or familiar with the key word(s) for the search criteria, simply click on the search button.

Figure 4.65. Rule Template Lookup: Results Example

Clicking on the Id field will take you to the Rule Template Inquiry screen for that particular Rule Template.

The Rule Template Inquiry screen provides specific information about one particular Rule Template.

Figure 4.66. Rule Template Inquiry

Clicking the export button will export a copy of the complete Rule Template in XML format.

A more detailed picture of the KIM architecture:

Figure 5.2. Detailed KIM Achitecture

Use the Person Lookup screen to quickly find basic information about Persons in Kuali Rice (Rice). (In Kuali, a Person is a set of information about a real person or something that stands for real people, like a job title.) From the Person Lookup screen, you can also link to screens where you can create new Persons and edit a Person’s information if you have permission to do so.

Person Lookup Options

From the Field Search Button

If you clicked the field search button on another Kuali page to get to the Person Lookup screen, your screen looks like this:

Figure 5.3. Person Lookup

To find a Person, enter some information about that person in the appropriate fields and click the search button at the bottom of the screen.

• You can display a list of all Persons in KIM if you leave the search fields empty and set the Active Indicator to Both, then click the search button.

• Rice displays a list of Persons who match your search information. The list is just below the search fields on the Person Lookup page:

  Figure 5.4. Person Lookup: Results

  
  
  

  Click one of the underlined column titles on the search results list to sort the list by that column. Click it again to sort the list in the opposite order.

  You can also export the search results list in CSV, spreadsheet, or XML format. Click the appropriate link at the bottom of the search results list to do this.

  If you need to see more information about one of the Persons in the search results list, click one of the information fields for that Person. Kuali then displays the Person Document screen for that Person.

  Figure 5.5. Person Document

  
  
  

  The Return Value column has a return value link for each person. Click this return value link for the Person whose information you need, and Kuali goes back to the screen you were on before and automatically enters the information about that person on the screen for you.

From the Administration Tab

If you come to the Person Lookup screen after clicking Person (under Identity) on the Administration tab, you see a create new button in the upper right corner of your screen, like this:

Figure 5.6. Person Lookup: Create New Button

You can click this create new button to go to the Person Document screen, where you can add a new Person as a Kuali user. For more information on adding a Person, see the Person Maintenance function section (next) in this User Guide.

If you need to edit information for a Person in KIM, you first need to display that Person’s information. Search for the Person (see search instructions above) from the Administration tab’s link for Person. When Kuali displays the list of Persons that match your search, you’ll notice one difference in the columns because you did your search from the Administration tab – there is an Actions column on the left.

The Actions column has an edit link for each person. Click this edit link to go to the Person Document screen where you can edit this Person’s information. For more information on working with Person information, see the Person Maintenance section (next) in this User Guide.

The Person Document allows you to identify and maintain each user in KIM. Each Person Document includes data about that user’s relationship with your institution as well as the roles and groups to which the person belongs.

In KIM, a Person is a unique combination of an Entity ID and a Principal ID. The Entity ID represents a Person with a unique number, and the Person Document associates the Entity ID with the user’s Principal ID number and Principal Name (often referred to as a user name or user ID). When searching for or working with users in KIM, you usually use either the Principal ID or the Principal Name. A single Entity ID can have multiple Principals associated with it, but the base implementation of KIM assumes that each Entity ID has only a single Principal.

On the Administration tab, click Person to display the Person Lookup screen. Do a lookup to see a list of Persons. Click any Person on the search results list to display his or her Person Document screen.

Document Layout

The Person Document includes Document Overview, Overview, Contact, Privacy Preferences, Membership, Ad Hoc Recipients, and Route Log tabs.

Figure 5.7. Person Document

Overview Tab

The Overview tab identifies the Person as a unique combination of Entity ID and Principal ID. It also contains information about how this Person is affiliated with your institution. Two types of affiliations—Staff and Faculty—contain additional data fields to further define a person’s relationship with your institution.

The instructions below assume that you are manually entering this information. Many institutions either have this data fed from an existing Person database or simply override this information with existing Person data.

Figure 5.8. Person Document: Overview Section

Overview Section

Table 5.1. Person Document: Overview Attributes

Field Name	Description
Entity Id	Display-only. The unique ID number identifying this Person in your database. An individual may have multiple Principal IDs but only one Entity ID. The base implementation assumes that each user has only one Entity ID and one Principal ID. KIM automatically assigns an Entity Id to a new Person when you save or submit a Person Document.
Principal Id	Display-only. The unique ID number identifying this Principal. Whereas Entity Id represents a unique Person, Principal Id represents a set of login information for that Person. When selecting a Person, you ordinarily reference his or her Principal Id. KIM automatically assigns a Principal Id to a new Person when you save or submit the Person Document.
Principal Name	Required. The user name for this Principal
Tax Identification Number	Required. Enter the Individual Tax Identification Number (ITIN) for this Principal ID
Principal Password	Optional. Enter the password for this Principal ID
Active	Check the box to indicate that this Principal ID is Active. Uncheck the box to indicate that this Principal ID is Inactive.
Actions	Click the Add button under Actions to save the information you enter in this section.

Affiliations Section

Use the Affiliations section of the Overview tab to add Affiliations for this Principal ID. Depending on the Affiliation type you select, you may need to complete additional fields.

Table 5.2. Person Document: Overview Attributes, Affiliations

Field Name	Description
Affiliation Type	Optional. Select the Type of Affiliation from the list. Options: Affiliate: Users in your system who are neither employees nor students Faculty: A faculty employee Staff: A non-faculty employee Student: A non-employee identified as a student of your institution Affiliation types of Faculty and Staff require additional information (see below).
Campus Code	Required. Select the Campus Code associated with this Affiliation
Default	Check the box to indicate that this Affiliation is this Principal’s default association with your institution. Each Principal must have at least one default Affiliation.
Actions	Click the Add button to save the affiliation information.

If you select an Affiliation of Faculty or Staff, KIM displays additional fields to collect employment information:

Figure 5.9. Person Document: Overview Tab, Affiliations Section

Table 5.3. Person Document: Overview Attributes, Affiliations Continued

Employment ID	Optional. Enter the Employment ID number associated with this Faculty or Staff affiliation. Ordinarily this entry is the ID number identifying this Principal in your HR system.
Primary	Check this box to indicate that this Faculty or Staff affiliation represents the Principal’s primary job with your institution. Each Principal with a Faculty or Staff affiliation must have exactly one affiliation marked as Primary.
Employee Status	Required. Select the current status of this Faculty or Staff affiliation. Options: Active Deceased On Non-Pay Leave Status Not Yet Processed Processing Retired Terminated
Employee Type	Required. Select the type of employment for this Affiliation. Options: Non-Professional Other Professional
Base Salary Amount	Required. Enter the base annual salary for this Faculty or Staff Affiliation.
Primary Department Code	Optional. Enter the code for the Department associated with this Faculty or Staff affiliation.
Add	Click the Add button to save this row of employment information.

Contact Tab

The Contact tab records the names, addresses, phone numbers, and email addresses associated with this Person. Any Person record can store multiple contact information records of each type (name, address, phone number, and email address). You must select one value of each type as the default for that Person record.

Figure 5.10. Person Document: Contact Tab

Names Section

Figure 5.11. Person Document: Contact Tab, Names Section

Table 5.4. Person Document: Contact Tab, Names Section Attributes

Field Name	Description
Name Type	Optional. Select the type of name to be added in this row. Options: Other Preferred Primary
Title	Optional. Select the appropriate title for the name being added in this row. Options: Ms Mrs Mr Dr
First Name	Optional. Enter the first name for this record.
Last Name	Optional. Enter the last name for this record.
Suffix	Optional. Select a suffix for this name record. Options: Jr Sr Mr MD
Default	Check this box to indicate that this Name record is the default for this person. Each Person record must have exactly one Name record identified as the default.
Active	Check the box to indicate that this Name record is Active. Uncheck the box to indicate that this record should be considered Inactive.
Actions	Click the Add button to save this Name record.

Addresses Section

Figure 5.12. Person Document: Contact Tab, Addresses Section

Table 5.5. Person Document: Contact Tab, Address Section Attributes

Field Name	Description
Address Type	Optional. Select the type of address being added on this row. Options: Home Other Work
Line 1 to 3	Optional. Use lines 1, 2, and 3 to enter the street address for this row.
City	Optional. Enter the city associated with this address.
State	Optional. Select the state associated with this address from the list.
Postal Code	Optional. Enter the postal code (zip code in the U.S.) associated with this address.
Country	Optional. Select the country associated with this address.
Default	Check this box to indicate this address record should be used as the Default. A Person record can have only one Default Address record.
Active	Check this box to indicate that this Address record is Active. Uncheck the box to indicate that this record is Inactive.
Actions	Click the Add button to save this Address record.

Phone Numbers Section

Figure 5.13. Person Document: Contact Tab, Phone Numbers Section

Table 5.6. Person Document: Contact Tab, Phone Numbers Attributes

Field Name	Description
Phone Type	Optional. Select the type of phone number being added on this row. Options: Home Mobile Other Work
Phone Number	Optional. Enter the area code and phone number.
Extension	Optional. Enter the appropriate extension.
Country	Optional. Select the country associated with this Phone Number record.
Default	Check this box to indicate that this Phone Number record should be used as the Default. A Person record can have only one default Phone Number record.
Active	Check this box to indicate that this Phone Number record is Active. Uncheck the box to indicate that this record is inactive.
Actions	Click the Add button to save this Phone Number record.

Email Addresses Section

Figure 5.14. Person Document: Contact Tab, Email Addresses Section

Table 5.7. Person Document: Contact Tab, Email Address Attributes

Field Name	Description
Email	Optional. Enter the email address for this record.
Type	Optional. Select the type of email address on this row. Options: Home Other Work
Default	Check this box to indicate that this Email Address record should be used as the Default. A Person record can have only one default Email Address record.
Active	Check this box to indicate that this Email Address record is Active. Uncheck the box to indicate that this record is Inactive.
Actions	Click the Add button to save this Email Address record.

Privacy Preferences Tab

The Privacy Preferences tab allows you to suppress the display of (hide) fields on the Contact Tab.

Figure 5.15. Person Document: Privacy Preferences Tab

Table 5.8. Person Document: Privacy Preferences Tab Attributes

Field Name	Description
Suppress Name	Optional. Check this box to specify NOT to display this person’s names.
Suppress Personal	Optional. Check this box to specify NOT to display any of this person’s personal data.
Suppress Phone	Optional. Check this box to specify NOT to display this person’s phone numbers.
Suppress Address	Optional. Check this box to specify NOT to display this person’s addresses.
Suppress Email	Optional. Check this box to specify NOT to display this person’s email addresses.

Membership Tab

The Membership Tab allows you to associate a person with groups and roles and, by extension, with KIM permissions and responsibilities. Assigning a person to a role is the most direct way to give him or her KIM permissions and responsibilities.

Figure 5.16. Person Document: Memberships Tab

The Membership tab is divided into two sections, one for managing assignments to Groups and another for Roles.

Groups Section

Table 5.9. Person Document: Memeberships Tab, Groups Attributes

Field Name	Description
Group	Optional. Enter the name of the KIM group you want to assign this person to. You can also use the Group lookup to search for and select a valid Group.
Namespace Code	Display-only. After you select a group to add this person to, KIM displays the namespace code associated with the group you selected.
Name	Display-only. After you select a group to add this person to, KIM displays the name of that group.
Type	Display-only. After you select a group to add this person to, KIM displays the type of that group.
Active From Date	Optional. If this user’s assignment to this group is to be effective as of a certain date, enter that date here.
Active To Date	Optional. If this user’s assignment to this group is to terminate as of a certain date, enter that date here.
Actions	Click the Add button to add this group assignment.

Note

There is no way to delete a person’s assignment to a group. To remove a person from a group, use the Active To Date field to specify a date in the past.

Roles Section

Table 5.10. Person Document: Memeberships Tab, Roles Attributes

Field Name	Description
Role	Optional. Use the Name lookup to search for and select the role you want to assign this person to.
Namespace Code	Display-only. After you select a role to assign to this Person record, KIM displays the namespace code associated with that role.
Name	Display-only. After you select a role to assign to this Person record, KIM displays the name associated with that role.
Type	Display-only. After you select a role to assign to this Person record, KIM displays the role type for the selected role.
Active From Date	Optional. If this user’s assignment to this role is to be effective as of a certain date, enter that date here.
Active To Date	Optional. If this user’s assignment to this role is to terminate as of a certain date, enter that date here.
Actions	Click the Add button to save this role data.

Note

There is no way to delete a person’s assignment to a role. To remove a person from a role, use the Active To Date field to specify a date in the past.

When assigning some roles, you may need to supply additional qualifying information that further defines this person’s assignment. For more information on Roles see the Role Maintenance section in this User Guide.

Ad Hoc Recipients tab information can be found in the Common Features and Functions section of this User Guide.

Route Log tab information can be found in the Common Features and Functions section of this User Guide.

The Group Lookup function provides a quick reference to key Group information.

You get to this screen by clicking the Group option in the Identity section of the Administration screen.

Figure 5.17. Identity Channel: Group Link

Figure 5.18. Group Lookup

On the Group Lookup screen, click the create new button to go to the Group Maintenance screen, where you can create a new Group in Rice.

Conducting a search from the Group Lookup screen returns a list similar to this:

Figure 5.19. Group Lookup: Results

For information on any of the fields above, please refer to the Group Maintenance section below.

This screen provides high-level information about a Group and shows who is assigned to it.

Click a Group Request value on the Action List screen to display the Group Inquiry page for that Group:

Figure 5.20. Group Inquiry

The Group document allows you to associate Persons, Roles, or other Groups with each other so you can assign the same role to all Group members.

Groups have no inherent permissions or responsibilities of their own. Only by associating a Group with a role do the members of that Group become associated with permissions and responsibilities.

Creating New Groups

If you are creating a new Group and have clicked the Create New button on the Group Lookup screen, Rice displays the KIM Type Lookup screen. Before Rice can generate a new Group document, you must search for and select an existing Type for the new Group.

Figure 5.21. KIM Type Lookup

Note

Always use this KIM Type Lookup screen when you create a new Group or Role.

If you search for a Type using the Group Lookup screen, the search results list doesn’t have return value links, so you can’t use the Group Lookup screen when you want to create a new Group or Role.

Table 5.12. KIM Type Lookup Search Attributes

Field	Description
Namespace Code	Optional. Select the code for the application and module to which this KIM Type pertains.
Type Name	Optional. Enter the name for this KIM Type.
Type Identifier	Optional. Enter the unique system-assigned Identifier for this KIM Type.
Active Indicator	Required (defaults to Yes). Change the default selection to view KIM types that are inactive or to see all Types (active and inactive).

The search results list includes the same fields as the Lookup screen. The search results are displayed below the search fields on the Lookup screen.

To select the Type you want to use for your new Group, click the return value link for that Type. KIM will copy the Type information to use in creating your new Group.

The KIM Type Lookup screen displaying a search result:

Figure 5.22. Kim Type Lookup: Results Set

Group Maintenance Document: Layout

The Group document includes these tabs:

• Document Overview

• Overview

• Assignees

• Ad Hoc Recipients

• Route Log

The Overview and Assignees tabs are described below. Information on the others can be found in the Common Features and Functions section of this User Guide.

Figure 5.23. Group Maintenance Document

Overview Tab

This tab identifies the Group with a unique system-assigned ID number, a namespace, and a name. Each Group also has a Type that specifies any qualifiers that this Group might require.

Figure 5.24. Group Maintenance Document: Group Overview

Table 5.13. Group Maintenance Document: Group Overview Attributes

Field	Description
Group ID	Display-only. The unique system-assigned ID number that identifies this Group; Rice completes this field when you submit the document.
Type Name	Required. The type of attributes that are associated with this Group. Some Group types, such as the Default Type, do not require attributes. Note: When creating a new Group, you must select the Type before Rice can generate the document. See the Creating New Groups section of this document
Group Namespace	Required. An indicator that associates the Group with a particular application and module
Group Name	Required. The common descriptive name by which this Group is known
Active	Check this box to indicate that this Group is active and is a valid choice for assigning to roles. Uncheck the box to indicate that this Group is inactive (it is no longer valid when making role assignments).

Assignees Tab

This tab displays the members who belong to this Group. You can also use this tab to add new members or to edit the fields for existing members.

Note that for members not added to the group on this maintenance document, the “delete” button to remove that member is inactive. If a member’s association with a group is past, users should set the “Active To Date” field to the end of the membership; the member will not be an active member of the group after that date.

Figure 5.25. Group Maintenance Document: Assignees Tab

Table 5.14. Group Maintenance Document: Assignees Tab Attributes

Member Type Code	Required. Select the Type of the member you are adding to this Group. Group members can be Principals (as defined on the Person document), Roles, or other Groups.
Member Identifier	Required. Enter the ID that identifies the member you are adding, or use the lookup to search for and select a valid Member ID. The lookup directs you to the Principal, Group, or Role lookup, based on your Member Type Code selection.
Active From Date	Optional. To specify the earliest date on which this member is to be considered a valid member of this Group, enter a date in this field.
Active To Date	Optional. To specify a date on which this member is no longer to be considered a valid member of this Group, enter a date in this field. As of this date, the Member will no longer be considered a member of this Group. Note: You cannot delete or inactivate Group members. To remove a member from a Group, enter an Active To Date.
Actions	Click the Add button to add this member to the Group.

This screen provides detailed information relating to the Permissions assigned to a Role in KIM.

The Role Lookup screen is accessible directly off the Rice Administration menu by clicking Role in the Identity section.

Click the Granted to Roles field on the Document Configuration screen to display the Role Lookup screen. You can also access the Role Lookup screen by clicking a Granted to Roles value in any list where it appears.

Figure 5.26. Role Lookup

Document Layout

This screen may have three or four tabs of information, depending on the Role. The first three tabs are Overview, Permissions, and Responsibilities. KIM only displays the fourth tab, Assignees, when Assignee information is associated with this Role.

Figure 5.27. Role Maintenance Document

Information on the fields in all of these tabs can be found in the Role Maintenance section of this user guide.

The Role Maintenance Document allows you to create a new KIM Role and edit existing Roles. Each Role collects a specific set of Permissions and Responsibilities and allows you to assign members to it.

The purpose of each Role is defined by its associated Permissions and Responsibilities. Roles are classified by Types that generally indicate with which Permissions and Responsibilities they are associated.

To access the Role screen:

Role Maintenance Document

The Role document includes eight tabs:

• Document Overview

• Overview

• Permissions

• Responsibilities

• Assignees

• Delegations

• Ad Hoc Recipients

• Route Log

Those contains unique information are addressed below. For more information about the Document Overview, Ad Hoc Recipients and Route Log tabs, please see the Common Features and Functions document.

Figure 5.28. Role Maintenance Document: Tabs

Overview Tab

This tab gives the Role a unique system-assigned ID number, a Namespace, and a Name. Each Role also has a Type that usually matches the kinds of Permissions and Responsibilities associated with it.

Figure 5.29. Role Maintenance Document: Overview Tab

Table 5.15. Role Maintenance Doucment: Overview Attributes

Field	Description
Role Identifier	Display-only. The unique, system-assigned ID number that identifies this Role
Type Name	Display-only. The Type Name usually identifies the general kinds of Permissions and Responsibilities associated with this Role. Note: When creating a new Role, you must select its Type before you can display a new Role document. See Creating New Roles below.
Role Namespace	Required. An indicator that associates the Role with a particular application and module
Role Name	Required. The common descriptive name by which this Role is known
Active	Check this box to indicate that this Role is Active and is, therefore, to be included by KIM when it evaluates Permissions and Responsibilities. Uncheck the Active box to indicate that this Role is inactive.

Creating New Roles

You must search for and select an existing Type for KIM to generate a new Role document. When you click the Create New button, KIM displays the KIM Type Lookup screen:

Figure 5.30. KIM Type Lookup

Note

While you use the KIM Type Lookup screen both for creating new Groups and new Roles, not all KIM Types are valid for both Groups and Roles. When using this Lookup, you may see different results depending on the KIM Types that are appropriate for your task.

Permissions Tab

This tab identifies the Permissions associated with this Role. Permissions authorize specific actions in the system with which they are associated. A Role can have any number of Permissions (including no Permissions) associated with it.

Figure 5.31. Role Maintenance Document: Permissions Tab

Table 5.16. Role Maintenance Document: Permissions Attributes

Field Name	Description
Add Permission ID	To add a Permission to this Role, enter the appropriate Permission ID, or search for and select a value using the Permission lookup
Add	Click the Add button to add the selected Permission to this Role document.

After you add a Permission to the document, KIM displays additional information about the Permission:

Note

You cannot edit Permissions from the Role Maintenance Document.

Figure 5.32. Role Maintenance Document: Permissions Tab, Add Permissions

Table 5.17. Role Maintenance Document: Permissions Tabb, Add Attributes

Field	Description
Permission Namespace	Display-only. The Namespace identifies the application and module associated with this Permission.
Permission Identifier	Display-only. The unique system-assigned ID number for this Permission
Permission Name	Display-only. The descriptive name of this Permission. This often tells you, in general terms, what the Permission authorizes.
Permission Detail Values	Display-only. The document Types, tabs, and/or fields that this Permission authorizes the holder to see or use. Not all Permissions have Detail Values.
Active Indicator	Display-only. Indicator showing whether this Permission is active in KIM
Actions	Click the Delete button to remove this Permission from this Role. Warning: You may delete a Permission from a Role only if it has not yet been saved. (In other words, you can delete a Permission from a Role only if you added it to this Role, but have not yet submitted the document.)

Responsibilities Tab

This tab identifies the Responsibilities associated with this Role. Responsibilities define the workflow actions that will be requested of the Role. A Role can have any number of Responsibilities (including none) associated with it.

Figure 5.33. Role Maintenance Document: Responsibilities Tab

Table 5.18. Role Maintenance Document: Responsibility Attributes

Field Name	Description
Add Responsibility ID	To add a Responsibility to this Role, enter the Responsibility ID, or search for and select a value using the Responsibility lookup .
Add button	Click the Add button to add the selected Responsibility to this Role document.

After you add a Responsibility to the document, KIM displays additional information about this Responsibility.

Note

In general, you cannot edit Responsibilities using the Role document, but some Responsibilities have associated attributes that you must define at the Role level.

Figure 5.34. Role Maintenance Document: Responsibility, Added Responsibility

Table 5.19. Role Maintenance Document: Responsibility, Add Attributes

Field Name	Description
Responsibility Namespace	Display-only. The Namespace tells you the application and module associated with this Responsibility.
Responsibility Identifier	Display-only. The unique system-assigned ID number for this Responsibility
Responsibility Name	Display-only. The descriptive name of this Responsibility. For most Responsibilities, the name is Review.
Responsibility Detail Values	Display-only. This gives you more specific information about the Responsibility. Responsibility Detail Values are formatted in a standard way with these attributes, separated by commas: Route Node: The location where this Responsibility is invoked in Workflow. Document Type: The Document Type for which this Responsibility generates workflow requests. Action Details at Role Member Level: When this field is True, action details are kept for each Member of this Role. When this field is False, action details are only kept at the Responsibility level for this Role. (see Assigning Action Detail Values, below). Required: Indicates if the routing represented by this Responsibility should be required. If this is set to True and the Responsibility fails to generate an Action Request (perhaps because no one is assigned to the associated Role), then the document will go into Exception status. If this routing is optional, this will be False and the document will simply skip this Responsibility if no requests are generated.
Active Indicator	Display-only. Indicator showing whether this Responsibility is active within the system
Actions	Click the Delete button to remove this Responsibility from this Role. Warning: You can delete a Responsibility only if it has not yet been saved to the database (in other words, you can only delete it if you have added it to this Role but have not yet submitted the document).

Assigning Action Detail Values

When you add a Responsibility with an Action Detail Values at Role Member Level value of False, you must complete additional fields in a Responsibility Action sub-section. KIM automatically displays this sub-section immediately beneath the Responsibility you’ve just added.

The fields in this sub-section define the type of Action Requests generated for, and the general workflow behavior associated with, this Responsibility. Entries in these fields cause KIM to generate the same Type of Action Requests for all members of this Role and handle actions by all members of this Role in the same way.

Figure 5.35. Role Maintenance Document: Responsibility Tab, Action Section

Table 5.20. Role Maintenance Document: Responsibility Tab, Action Section Attributes

Field Name	Description
Name	Display-only. The namespace and name of the Responsibility associated with these action details
Action Type Code	Required. The Type of Action Request that KIM generates for this Responsibility. Action Type Codes are: Approve, FYI, and Acknowledge.
Priority Number	Optional. If multiple requests are generated at the route node specified on this Responsibility, this determines the order in which KIM generates these requests. KIM processes requests with lower priority numbers before processing requests with higher numbers. Requests with no number are treated as a priority 1.
Action Policy Code	Required. This determines what happens if multiple members of this Role receive the same Action Request and one of them takes the action. For example, if a Role has a Group with three members assigned, all of these members receive the Action Request defined here; this code then determines what KIM does when one of them takes action on the document. A value of FIRST indicates that the first Group member to take action on the document causes KIM to clear all the requests for this Responsibility that may be in other Group member’s action lists. A value of ALL indicates that each Group member must take individual action to clear his or her own requests.
Force Action	Check this box to indicate that each user must take action for this request, even if the user has previously taken action on this document. Leaving the box unchecked allows a request to be immediately fulfilled if the Role member has previously taken action on this specific document.

Assignees Tab

This tab displays all members who belong to this Role. You may also use the tab to add new members and to edit the values associated with existing members.

Just as with group, role members not added by the specific maintenance document will have their “delete” buttons inactivated. To end that member’s active association with the group, set the “Active To Date” field to the end of the membership.

Figure 5.36. Role Maintenance Document: Assignees Tab

Table 5.21. Role Maintenance Document: Assignees Tab Attributes

Field Name	Description
Type Code	Required. Role members can be Principals (as defined on the Person document), Groups, or other Roles. Select the Type of member you want to add to this Role.
Member Identifier	Required. Enter the ID of the member you want to add, or use the lookup to search for and select a Member. The lookup icon displays the Principal, Group, or Role Lookup screen based on the Type Code you selected for this Role member.
Namespace Cd	Display-only. Identifies the namespace code associated with this Role member. Note that only Groups and Roles display a namespace code.
Name	Display-only. Identifies the name of the member you are assigning to this Role
Active From Dt	Optional. Enter a Active From date to define the earliest date on which this member is a valid member of this Role.
Active To Dt	Optional. Allows you to deactivate a member’s association with a Role on a specific date. Enter the date the user is no longer a member of this Role. Note: You cannot delete or inactivate Role members. To remove a member from a Role, enter an Active To Dt.
Actions	Click the Add button to add this member to the Role.

Delegations Tab

This tab defines and identifies Delegates associated with this Role. Delegates are users that a member of this Role has authorized to have the same Permissions and take the same actions as that member is authorized to take. For example, a manager may make someone a Delegate for his or her actions in a particular Role.

The Assignees Tab dealing with Delegates is slightly different, as shown in the following table. Note that if the members of a Role require qualifying values, the delegation requires these values as well. In most cases, Delegates must have the same qualifiers as the Role member with which they are associated.

Just as with Group and Role Associations, delegations added outside of the current maintenance document have inactive “delete” buttons and must have the “Active To Date” field set to end the delegation.

Figure 5.37. Role Maintenance Document: Delegations Tab

Table 5.22. Role Maintenance Document: Delegations Tab Attributes

Field Name	Description
Role Member	Required. Use the lookup to search for, and return, the Member of this Role for whom you wish to create a Delegate.
Member Type Code	Required. Select the Type of Delegate you want to add to this Role. Delegates may be Principals (as defined on the Person document), Groups, or other Roles.
Member Identifier	Required. Enter the ID that identifies the Delegate you want to add, or use the lookup to search for and select a Delegate. Note that the lookup takes you to the Principal, Group, or Role Lookup screen, depending on the Member Type Code you selected.
Member Namespace Code	Display-only. The namespace of this Delegate. Note that only delegations to Groups or Roles display a Member Namespace Code.
Member Name	Display-only. The name of the selected Delegate
Active From Date	Optional. You may choose to qualify this Delegate’s association with this Role by date. Entering an Active From Date is the earliest date on which this Delegate is valid for this Role.
Active To Date	Optional. Allows you to deactivate a Delegate’s association with a Role on a specific date. The date you enter is the date on which this user is no longer a Delegate for this Role. Note: You cannot delete or deactivate Delegates. To remove a Delegate from a Role, enter an Active To Date.
Delegation Type Code	Required. Select Secondary or Primary. Note that this selection only applies to Responsibilities associated with the Role. This indicates whether the Delegate automatically receives documents directly in their Action List (Primary) or if the Delegate may only choose to view documents in their Action List using the Secondary Delegate dropdown (Secondary).
Actions	Click the Add button to add this Delegate to this Role.

Use this lookup when you create a new group in KIM to find the KIM Type for the new group.

Figure 5.38. KIM Type Lookup

You may enter information in one or more of the search fields to find the correct Type for your new group:

Figure 5.39. KIM Type Lookup: Results Example

The search results list for this screen has the same fields as the Lookup screen. To select the Type you want to use for your new group, click the return value link for it in the search results list.

The KIM Type Inquiry screen provides details about a KIM Type data element.

To access this screen, from the Role Lookup screen, click a Role Type Name in your search results list.

Figure 5.40. KIM Type Inquiry

All fields are defined above in KIM Type Lookup except these:

Similar to the Permission Lookup, you can use the Responsibility Lookup to search for and view existing responsibilities in KIM. You can view summarized information about the responsibility detail values as well as the roles with which the responsibility is currently associated.

Figure 5.41. Identity Channel: Responsibility Link