LCS - Kuali - How and When to Use Blueprints vs. Groups vs. Roles
- Blueprints
- Groups
- Roles
- Two examples using Groups and Roles
- Maintenance of Blueprints, Groups and Roles by the Application Administrator
- Utilizing Manifest Groups in Kuali
- Example of creating another Role besides Members as seen 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.
- Members – The application administrator will be able to add users to each group (see section below on Manifest set-up).
Roles
Roles are used to subdivide the group members, 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.
Users assigned to Roles will have the permissions/workflow actions of the member group in addition to the permissions/workflow actions assigned to their specific role.
- Lead or Financial Specialist or <name of role>- The application administrator will be able to add users to each role. (The user can be added to a role and then automatically included in members of the group in that hierarchy.)
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 on different permissions/workflow actions within an application. All users added as members to each of these groups will have the same permissions within the application.
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 a role will then be provided action items, such as to complete a task, approval, etc. And/or they all receive notifications that are in addition to anything assigned to the entire NRL Users group.
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 in this group (seen below as “all roles”) all get assigned to the same permissions/workflow actions. Individuals performing the same tasks, approvals, etc. are assigned as members within the groups.
The administrator role is the LCS team and should NOT be assigned to any permission or workflow action.
The screenshot below shows how steps in the workflow, like tasks, are assigned to roles starting with the group name – role name. (Note: "(All Roles)" means all users added as members to the group).
Only Finance staff across the university need access to submit a form for this application; therefore, that group is added as a Kuali Policy allowing all members in that group to submit a form.
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 a Manifest Group called Members. (As noted in the explanation above, there must be at least the "members" Manifest Group that covers the superset of users included in the group).
- Select the Details button to open the member group.
- Select the Members tab. Select Add Members.
- Either existing Manifest groups (e.g. if one exists for all WID staff) can be added or
- 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.)
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
- The application administrator has the ability to create policies under the App Options>Permissions menu item
- 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
- The application administrator adds a workflow step, like Approval or Task to the application's workflow.
- In the details, select Person(s) in a role of any specific group
- 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.
Example of creating another Role besides Members as seen by the Application Administrator
As noted above,
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 a Manifest Group called Members. (There must be at least the "members" Manifest Group that covers the superset of users included in the group). However, there may be other Kuali roles that the application administrator wants to create to give specific permissions/workflow actions to another smaller group of people, such as the Lead of the team.
In Manifest, the application administrator will always see a members group.
The application administrator can also create another group (e.g. Lead) to give more permissions specifically to the team Lead. The members and lead will have 2 Manifest Groups as seen below. The application administrator adds the team members to the Members Manifest Group. The application administrator adds the leads/supervisors to the Lead Manifest Group (recall the leads/supervisors will automatically get the permissions/workflow actions as the users added to the members group).
In Kuali, when the application administrator creates a policy to give permissions to the team (e.g. the Members Manifest Group), the application administrator can find that superset of users under Kuali Groups as seen in this screenshot.
When the application administrator creates a policy to give permissions to the Lead (e.g. the Lead Manifest Group), the application administrator can find those users under Kuali Roles as seen in this screenshot.
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.