Role

Overview

The Role document allows you to create a new role and edit an existing role. Each role aggregates a specific set of permissions and responsibilities and allows you to assign members to the role. Kuali Financials contains many existing roles that your institution may want to use as is, but you may also change existing roles and add new ones by using the Role document.

Kim Type

Roles are classified by types that generally indicate the type of permissions and responsibilities with which they can be associated. Creating a new Kim Type requires coding.  When creating a new role, you must first select a Kim Type which will determine the qualifications required for the assignees added to the role. The KIM Type Lookup is used when creating new groups and roles, but not all KIM types are valid for both. When using this Lookup, you may receive different results depending on the KIM Types that are valid for the entity you are working with.

Overview 

When you select and return a Kim Role Type, the Overview tab is updated with the selected Role Type. 

• Role: The unique, system-assigned ID number that identifies this role.
• Type Name: Display only. Because the role type normally reflects the type of qualifiers this role will need to collect when members are added, this name usually identifies the general types of permissions and responsibilities associated with it.
• Namespace: The module associated with this role. 
• Role Name: The common descriptive name by which this role is known.
• Description: Describes the purpose of the role and what members of the role can do or workflow actions they will receive. 

Permissions

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.

• Add Permission ID: Enter or lookup the appropriate permission. 

The following fields display after the Permission is added to the role. 

• Permission Namespace: Identifies the module associated with this permission.
• Permission Identifier: The unique system-assigned ID number for this permission.
• Permission Name: The descriptive name of this permission. This often identifies, in general terms, what the permission authorizes.
• Permission Details: The document types, tabs and/or fields this permission authorizes. Not all permissions have detail values.

Responsibilities

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.

• Add Responsibility ID: Enter or lookup the appropriate permission. 

The following fields display after the Responsibility is added to the role. 

• Responsibility Namespace: The Namespace identifies the application and module associated with this responsibility. 
• Responsibility Identifier: The unique system-assigned ID number identifying this responsibility.
• Responsibility Name: The descriptive name of this responsibility. For most Responsibilities the name is Review <doc type> <route node>.
• Responsibility Detail Values: Identifies more specific information about the responsibility. Responsibility Detail Values are formatted in a standard way with the following definitions delimited by commas:
  • Route Node Name: The workflow route level at which this responsibility is invoked.
  • Document Type Name: The document type for which this responsibility generates workflow requests.
  • Action Details at Role Member Level: True or False vale that specifies where the details of this workflow action request are defined.
    • If the value is True then action details will be collected when Members are assigned to the role.
    • If the value is False then the action details must be collected when this responsibility is assigned to a role. Refer to Responsibility for additional information. 
  • 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) the document will go into Exception status.
    • If this routing is optional this value will be False and the document will simply skip this responsibility if no requests are generated.

Responsibility Action

When adding 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. The system displays this 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 the system to generate the same type of action requests for all members of this role and handle actions by all members in the same way.

• Name: The namespace and name of the responsibility associated with these action details.
• Action Type Code: The type of action request that the system is to generate for this responsibility. Options include Approve, FYI and Acknowledge.
• Priority Number: If multiple requests are generated at the route node specified on this responsibility, this value determines in the order in which the system will generate these requests. The system processes requests with lower priority numbers before processing requests with higher numbers. Requests with no number are treated as a priority of 1.
• Action Policy Code: This value determines what happens if multiple members of this role receive the same action request and one of them takes the action. This currently only applies in situations where a single action request is generated to multiple role members (i.e. the action details exist at the role level) or a role is assigned to another role and these nested role members receive an action request. For example, if a role with a responsibility with action details defined at the role level has three members assigned, all of these members receive the action request defined here; this code determines what the system does when one of them takes action on the document.
  • FIRST indicates that the first role member to take action on the document will automatically clear all the requests for this responsibility that may be in other role member's action lists.

  • ALL indicates that each role member must take individual action to clear his or her requests.

• Force Action: Check the box to indicate that each user must take this action for this request even if the user has already 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

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

• Search for Members by Name: Use this field to find role assignees in order to take action 
• Type Code: Role assignees can be principals (as defined on the Person document), groups or other roles.
• Member Identifier: Enter the ID of the member you want to add or use the lookup icon to search for and select a valid value. The lookup directs you to the Principal, Group or Role lookup based on the Member Type Code selection.
• Namespace Cd: Identifies the namespace code associated with this role member. if a role or group is assigned.
• Name: If assigning a principal, the Principal Name. 
• Full Name: Identifies the name of the member being assigned to this role. 
• Active From: Allows you to qualify this member's association with this role by date. Entering a from date will define the earliest date on which this member is a valid member of this role.
• Active To Date: Allows you to deactivate a member's association with a role on a specific date. The date you enter defines the date the user is no longer a member of this role. You cannot delete or inactivate role members. To remove a member from a role, specify an active to date.

Additional fields may be required, such as Chart Code or Organization Code, depending on the role type selected.

When assigning roles to other roles (nesting roles), qualifying values are not required. Some roles contain special logic to derive the required qualifiers from the nested role itself without qualifiers being specified. You may always specify qualifying values for a nested role and should do so unless you know the role being assigned contains logic to derive the qualifiers from the nested role. 

Delegations

This tab identifies delegates associated with the role. Delegates are users that a member of this role has authorized to have the same permissions and take the same actions as the member is authorized to take.

The Assignees Tab dealing with Delegates is slightly different as detailed 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 they are associated with.

• Role Member: Use the lookup icon to search for and return the member of this role you wish to create a delegate for.
• Member Type Code: Delegates may be principals (as defined on the Person document), groups or other roles. Select the type of delegate you want to add to this role.
• Member Indentifier: Enter the ID that identifies the delegate you want to add or use the lookup icon to search for and select a valid value. Note that the lookup will direct you to the Principal, Group or Role lookup based on your Member Type Code selection.
• Member Namespace Code: Identifies the namespace associated with the selected delegate. Note that only delegations to groups or roles will display a member namespace code.
• Member Name: Shows the name of the selected delegate.
• Active From Date: If you want you can qualify this delegate's association with this role by date. Entering a from date will define the earliest date on which this delegate is a valid delegate for this role.
• Active To Date: Allows you to deactivate a delegate's association with a role on a specific date. The date you enter defines the date on which the user is no longer a delegate for this role.

  You cannot delete or deactivate delegates. To remove a delegate from a role, enter an active to date.

• Delegation Type Code: Select Secondary or Primary. Note that this selection only applies to responsibilities associated with the role and indicates if the delegate will receive documents directly in their action list (Primary) or may choose to view documents in their action list using the secondary delegate list (Secondary).