Kuali Rice 2.1.0-M3 User Guide

Below the list of search results, there are links for exporting the search results list to a different format. Click:

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

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.

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

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

The Route Log tab displays details of the workflow status.

Figure 1.6. Route Log Tab

Figure 1.7. Route Log Tab: ID Section

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.

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

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

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

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:

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:

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:

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

As described above, you can use the Action List Preferences page to tell KEW to automatically update (refresh) the information on your Action List on a regular schedule, such as every 15 minutes. You can also click the Refresh button near the top of your Action List page to update the page at any time.

If you have a large Action List, the Filter function can help you by displaying only action requests of certain types. To use the Filter function, click the Filter button in the top right corner of your Action List page:

This displays the Action List Filter page:

Figure 4.19. Action List Filter Page

When you have used a filter on your Action List, you can see a Clear Filter button at the top of your page:

Figure 4.22. Action List: Clear Filter Button

Click this button to display all of your action requests again.

Remember, you can click the Filter button at the top of your Action List page to return to the Filter page and change or Reset your filters.

In KEW, you may delegate, or give, your request authority to other people. For example, if Joe is the fiscal officer for an account but he doesn't actually approve documents, he may delegate his approval authority to Jane. Both Joe and Jane can now take actions on Joe’s action requests

If Jane approves a document as Joe’s delegate, Joe's action request is satisfied. If Joe approves the document, Jane's action request is satisfied.

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.

When action requests are created, they are in the Initialized state. They stay in this state until KEW determines that they need to be Activated. When a request becomes Activated, it appears in the user's Action List.

When action requests are created, they can be set to ignore previous actions or not.

During request activation, if the Ignore Previous flag is false and KEW determines that a previous action satisfies the current request, it will Deactivate the request instead of Activating it. Activation begins at a root request, but Deactivation begins at the request where KEW finds that a satisfying action has occurred if that request is set to not ignore previous actions.

When a user takes action on a document, that action may start the deactivation of other action requests on the document. For example, if Joe has a pending request and he takes an Approve action on it, his request is deactivated. Request deactivation changes the status of the request from Initialized or Activated to Deactivated.

If Joe’s action taken causes other action requests to be Deactivated, his action taken is associated with all of the requests that it Deactivates.

Unlike Activation, Deactivation always starts at the request that was satisfied by the action taken. For example, if Joe is delegating to Jane and Jane issues an Approve action on her request, Deactivation starts at Jane's request. However, if Joe issues the Approve action, Deactivation starts at the parent.

Figure 4.24. Delegation Tree Example: Deactivation

If there are no roles set to "All Approve" on an action request, one action can Deactivate the entire request tree. This is because KEW works up and down the tree, Deactivating requests as it goes.

However, when there is an "All Approve" role, requests for all parties within the role must be Deactivated before the parent role request is Deactivated. For example, if we have an "All Approve" role request with three children requests, when one of the users takes action, their request is Deactivated, but since there are two other requests that still need to be satisfied, the Deactivation cannot go back to the parent role request. When the last of the three users has taken action, the parent role request is Deactivated.

Use this action to satisfy an Acknowledge action request. When you take an Acknowledge action, it usually means that you have examined the document. Acknowledgement provides no real authority over the document; you can only take the Acknowledge action on this document.

When you take an Acknowledge action, KEW finds all pending acknowledge requests for that document that are routed to you and Deactivates them. It then records an Acknowledge Action Taken and associates it with the Deactivated requests. You may take an Acknowledge action even if you have no Acknowledge Action Requests.

Use this action to satisfy an Approve or Complete action request. When you use an Approve action, it means that you have looked at the document and approve that transaction.

When you use the Approve action, KEW Deactivates all pending approve or complete requests that have been routed to you for this document. You may take an Approve action even if you have no Approve or Complete action requests.

Use the Blanket Approve action to force a document to complete a set of action requests. This allows certain users to "push" a document through its routing. To take this action, you must have the appropriate KIM Permission (or be in the Blanket Approve Group which is set in the Document Type, but that is a deprecated feature). Unless you select a specific node (point in the document’s routing path) when you take a Blanket Approve Action, KEW finds all pending Approve or Complete requests at the current level in the request tree and Deactivates them. It records a Blanket Approve Action Taken and associates it with each of the Deactivated requests.

Then, KEW sends Acknowledge action requests to each person whose action request was satisfied by the Blanket Approve. It does this for all levels in the request tree until it reaches the end point set in the Blanket Approve Action or it reaches the end of the request tree.

Use this action when a document is no longer valid and you need to cancel it. You must have a pending Approve or Complete action request on the document before you can Cancel it. Cancelling a document is similar to Disapproving it except that the Cancel action does not send out notifications.

When you take a Cancel action, KEW finds all pending requests on the document and Deactivates them. It records a Cancel Action Taken and associates it with the Deactivated requests. Then it sets the document's status to CANCELLED and the document is effectively dead.

Use this action to satisfy an FYI action request. You usually get an FYI just to notify you about a document. You don’t need to take any action on an FYI request, but if you want to remove that FYI and document from your Action List, take the Clear FYI action.

When you take the Clear FYI action KEW locates all pending FYI requests on this document that are routed to you and Deactivates them. It then records an FYI Action Taken. You must have a pending FYI request on a document to use the Clear FYI action.

Use this action to satisfy an Approve or Complete action request. When you use a Complete, it means that you have looked at the document and completed any of the necessary information on the document so it can proceed. Complete action requests are typically created as the result of a Save action or in response to an Exception Routing request.

When you use the Complete action KEW finds all pending Approve or Complete requests that are routed to you and Deactivates them. If the document is in the Exception state, it changes it back to Enroute. It then records a Complete Action Taken. You may take a Complete action even if you have no Complete or Approve action requests.

This action creates a new document in KEW of the chosen Document Type. This action does not record an Action Taken of any sort but simply begins a new document and assigns a document ID to it. The document begins in Initiated status. The Document type determines how the document is routed and what must be done for it. For example, an expense report might be routed (sent) to two or three different people for approval before it is paid.

When you have an Approve action request, you use a Disapprove action if the document does not meet the approval criteria. You must have a pending Approve or Complete request on the document before you can Disapprove it. Disapproving a document is similar to Cancelling it, except that Disapproval sends out notifications.

When you Disapprove a document, KEW finds all pending requests on the document and Deactivates them. Next, it creates Acknowledge notification requests to all users that had Approve or Complete action requests at the current node and all previous nodes. It also sends an Acknowledge notification request to the initiator of the document. Then the document's status is set to Disapproved and the document is effectively dead.

This action simply enters a message on the document. It records an Action Taken but it is never associated with any action requests. This action displays a message on the document in the Route Log.

This action moves a document either backward in the route path or forward. Moving the document backward works like the Return to Previous Node action and moving the document forward works like a Blanket Approve action. The difference between these is that the Action Taken is recorded as a Move action.

Use this action to move a document to a previous node in the route. You must have a pending Approve or Complete request on the document before you can use this action.

When you use this action, KEW Deactivates all pending requests on the document and sets the current node on the document to the previous node that you requested (this is called the target node). It records a Return to Previous Node Action Taken and associates it with the Deactivated requests. Any requests on nodes between the current node and the target node are removed, effectively erasing them. KEW then sends the document through again to recreate requests on the target node. This way a document is "returned" to a previous node, rolling it back to its previous state at that point in the route.

Use the Route Document action to route an Initialized or Saved document to other users. Only the initiator of the document can take this action unless the user has an "Initiate Document" KIM permission (or initiator_must_route policy is set to false in the Document Type, although this feature is deprecated). The Action Taken for a Route Document action is Complete.

When you use the Route Document action, it Deactivates all pending requests for the initiator of the document and it associates a Complete Action Taken with the Deactivated requests. The document’s state is then set to Enroute.

Use this action to put a newly created document in the Action List of the document’s initiator. You can only use this action on a document in an Initiated status. When you use this action, KEW creates and Activates a Complete action request for the document’s initiator and then changes the document’s status to Saved.

Use this action to recall a doucment that has been submitted to your action list. You can only use this action on a document if you have a specific role for the application and/or document you are trying to recall. When you use this action, you are given the option to recall the document to your action list for updating or you can recall and cancel the doucment with one action if it is no longer needed.

Superuser actions let you move a document past workflow nodes where it may be held up because another user is unavailable to take action on it or due to a system problem. Superuser actions are an administrative tool and safety net. Superusers are designated with a KIM Permission (or they are listed in the Document Type, but this feature is deprecated).

To use the Superuser functions, go to Document Search (it is a link in the left menu) and click the Superuser Search link.

Now, do a normal document search for the document on which you need to perform a Superuser action. When you find the document, click the Document/Notification Id link. If you are authorized to perform a Superuser action on this document, this takes you to the Superuser page. Otherwise, KEW displays a message that you are not authorized to take Superuser action on this document.

This action fully approves a document, Deactivating all remaining routing requests. KEW also records a Superuser Approve Action Taken and associates it with the Deactivated requests. The document's state changes to Approved and the document is scheduled for processing. The document status automatically changes to Final when it goes into the Workflow Engine.

This action approves the document through all nodes up to (but not including) a specified node. When the document gets to the specified node, requests are created as usual. This action is exactly the same as Blanket Approve except that no notification requests are created from the Superuser Approve Node action.

This action approves a single pending Approve or Complete action request. This works the same way as a standard Approve action except that the Superuser is acting in place of the responsible user.

This action cancels the document. This action works exactly the same way as the standard Cancel action except that the Superuser does not need to have a pending request to Cancel a document.

This action disapproves the document. This action works the same way as the standard Disapprove action except that the Superuser does not need to have a pending request to perform the action. Also, on a Superuser disapprove, KEW does not send notification requests.

This action returns the document to a previous node in the route path. This action works exactly the same way as the standard Return to Previous Node action except that the Superuser does not need to have a pending request to perform the action.

With the relese of Rice 2.1 a new option is avaialbe for applications to enable. Superuser's can now access documents directly from the standard document search and quickly perform approval, acknowledgment, FYI, or disapproval actions from this new tab on the document. This streamlined version of the still available superuser form of document search will allow for common actions to be taken in a more user friendly fashion. Pending actions are displayed in a list that the super user can check off and take the actions necessary all at once (see example below). Before actions can be taken, a annotation must be provided.

Figure 4.25. New Superuser Tab Example

You can go to the eDocLite Lookup by:

Figure 4.27. eDocLite Lookup

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

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.28. 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.

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:

The Document Header contains the following fields:

This portion of the document is where the user identifies the routing and complete business function.

This area is used to add annotation and choose action to be taken on this eDocLite document. Annotation is the comments associated with the routing process. You can add them to different nodes of the routing process and take actions on an eDocLite by adding annotations. The annotation appears in the route log of eDocLite as comments. Notes are the comments associated with this specific eDocLite form and appear with the form and not in the route log.

The following is one example of an eDocLite form:

eDocLites are highly customizable. New eDocLites can be designed for new business and functional requirements. The document header and routing annotation and notes parts will be same or similar, the form will be different.

eDocLites can be designed to include following functions:

The Routing Rule Delegation screen you see when creating a new Rule has eight tabs:

The Delegation Details, Delegate Rule, Persons, and Groups tabs are discussed in the sections that follow. The remaining four tabs are commonly used throughout Rice and are described in the Common Features and Functions section of the User Guide.

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.39. 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.40. 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:

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.41. 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.42. 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:

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.43. 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.44. 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.

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.45. 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.46. 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.

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.53. Routing Report: Template Selection

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.54. Routing Report: Template Selection, Detail

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.55. 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.56. Routing Report: Route Log View

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.57. Routing Report: Route Log View, Pending Action Requests

The Rule Maintenance Document Type Document screen you see when creating a new rule is composed of seven tabs:

The screen you see when you are editing an existing Rule includes an additional tab called Roles.

The Rule, Persons, Groups and Roles tabs are unique and are discussed in the sections that follow. The remaining four tabs are commonly used throughout Rice and are described in the Common Features and Functions section of the User Guide.

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.59. Rule Maintenance Document Type Document: Rule Tab

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

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

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.61. Rule Maintenance Document Type Document: Person Tab

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

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

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.63. Rule Maintenance Document Type Document: Groups Tab

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

Figure 4.64. 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.

You can go to the Person Lookup screen from many Kuali screens by clicking the field search button next to a Name-related field. How you get to the Person Lookup screen and your Role in Kuali determine what you see and what you can do there.

If you have permission to use the Administration screens in Rice, you can go directly to the Person Lookup screen:

Only people with the appropriate role can initiate routing for Person documents.

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

Figure 5.7. Person Document

The Document Overview tab combined with the Overview tab identifies the Person as a unique combination of Entity and Principal ID.

Additional information on the Document Overview Tab can be found in the Common Features and Functions section of this User Guide.

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

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.

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.

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

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.

For information on these fields please refer to the Group Maintenance section that follows.

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

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

The Group document includes these tabs:

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 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 document includes eight tabs:

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.