LCS - Kuali - How and When to Use Blueprints vs. Groups vs. Roles

Application administrators (i.e. application developers) will need to understand how and when to use blueprints, groups and roles in Kuali and how to request and maintain them.

Blueprints
Groups
Roles
Two examples using Groups and Roles
- Example 1
- Example 2
Maintenance of Blueprints, Groups and Roles by the Application Administrator
Utilizing Manifest Groups in Kuali
How do I request Blueprints or Groups at UW-Madison?
Kuali documentation

Blueprints

The only time the application administrator needs a blueprint is when the submitter needs to select an approver/task completer from a list of people within the application form since the appropriate person can’t be pre-determined.

Groups

Groups are a superset of people who should have access to an application(s) and/or need to take an active role in the workflow. When setting up a workflow, it is recommended that you assign work items (e.g. tasks, approvals, etc.) to a group instead of certain people. Groups can be made of:

All non-leadership staff in a department
All supervisors/approvers in a department
All Finance-related staff across all departments who should be able to have access to submit a form

The LCS team recommends making groups with numerous people.

Roles

Roles are used to subdivide the group, if need be, to allow application-specific permissions and application-specific work items (e.g. specific approvals for a subset of a group). Roles can also be used to allow specific parts/fields of the form to be seen and editable only by certain users.

Members – There will always be at least one role, the member role, within a group. The application administrator will be able to add members to this group (see section below on Manifest set-up).

Two examples using Groups and Roles

Example 1

All departmental staff are in one of 3 groups. However, for each application these groups are sub-divided into roles.

Below are the Groups for this Department: three groups listed under group name: admins, supervisors and users

The Administrators are the application administrators/developers.
The Supervisors include Administrative leadership, Lab managers, approvers such as the Department Chair, etc.
The Users are all other staff in the department.

These 3 groups then take roles within an application. (As mentioned, different roles can be created for different applications depending on the needs in the workflow).

The Supervisors group is sub-divided into Roles of the Chair and each lab as seen below.

Selecting a role in the workflow with list of all of the NRL supervisor roles to select from including chair and lab managers

The Users group is sub-divided into Roles such as IT, Finance, Communications, HR, etc. Individuals from the Users group are placed within each of those roles.

Selecting a role in Kuali workflow from list of NRL user roles including finance, communications

Within the application workflow, these roles are assigned tasks, approvals, etc. All individuals placed in the role will then be provided action items, such as to complete a task, approval, etc. And/or they all receive notifications.

Example 2

Staff that are across departments or even across schools/colleges/divisions (S/C/D), must perform the same action (e.g. approval, task, etc.) depending on the submitter’s department or S/C/D.

Below are some Groups for this workflow:

list of groups created including approvers, opt manager and submitters

The Approvers Lvl 1 and Lvl 2 are the approvers from across UW-Madison
The Opt Manager includes the decision-makers/prioritizers
The Submitters are specific staff across UW-Madison who are allowed to see the application and submit the form

Since there is no need to sub-divide these groups further, the members role is used (seen below as “all roles”). The administrator is the application administrator/developer. Individuals performing the same tasks, approvals, etc. are assigned as members within the groups.

The screenshot below shows how steps in the workflow, like tasks, are assigned to roles starting with the group name – role name.

selecting a role in the list for a Kuali step showing all of the WDFin groups and roles

Only Finance staff across the university need access to submit a form for this application; therefore, that group is added as a Kuali Policy.

Adding a permission (aka Kuali policy) and selecting submitters to have access to the application

Maintenance of Blueprints, Groups and Roles by the Application Administrator

In Manifest, the application administrator will have access to one or multiple Manifest Folders. (see screenshot below)

NOTE: Manifest Folders = Kuali Groups

The application administrator should see a Manifest Folder for each Kuali Group requested.

NOTE: Manifest Groups = Kuali Roles

The application administrator should see Manifest Group called Members.

Manifest folder with a manifest member group within it

Select the Details button to open the member group.
Select the Members tab. Select Add Members.
1. Either existing Manifest groups (e.g. if one exists for all WID staff) can be added or
2. Individuals using their NetID (NetIDs can be found by opening a person's contact information in Teams and using the "Chat" email portion before the @wisc.edu.)

adding existing groups or individual netIDs

As the Kuali application administrator, you will have access to:

Add more Manifest groups (aka Kuali roles) within this folder
Assign netIDs (users) to the members Manifest Group (this will equal your Kuali Group Member role).
Assign netIDs (users) to the additional Manifest groups/Kuali roles you created in step 1).

Follow this kb on how application administrators manage in Manifest. Manifest - Manage Group Members

Utilizing Manifest Groups in Kuali

Every hour on the top of the hour, Kuali will look at the groups and the members within them and update access to Kuali.

Add a Policy to Kuali to give permissions to a group
1. The application administrator has the ability to create policies under the App Options>Permissions menu item
2. The Manifest Group can then be found by searching for Groups as seen in the screenshot below. Then all members added to the Manifest Group will then have access according to this policy.
Assign a workflow step to a group
1. The application administrator adds a workflow step, like Approval or Task to the application's workflow.
2. In the details, select Person(s) in a role of any specific group
3. Begin typing the Manifest Group name under "Which role from which group?" to find the group and apply it to that step. All members added to the Manifest Group will then be assigned to complete the task/approval. Anyone within the group can complete the workflow step for all those assigned in this manner.