• Blueprints
• Groups
• Roles
• Two examples using Groups and Roles
  • Example 1
  • Example 2
• Maintenance of Blueprints, Groups and Roles by the Application Administrator 
• 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:  

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

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. 

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:  

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

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

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)  

How do I request Blueprints or Groups at UW-Madison?

Reach out to LCS-Support@doit.wisc.edu to discuss what is appropriate for your application. Then fill out a group request using this form.

Kuali documentation 

Kuali documentation about Blueprints, Groups and Roles