Blueprints vs. Groups vs. Roles

What is the difference between Blueprints and Groups?

Blueprints and Groups: what are they?

We like to think of a Blueprint as a classification for certain types of Groups. Groups are also part of a Blueprint, not the other way around. Since every institution's organizational hierarchy is slightly different, let's look at a few completely separate examples that might help us understand the difference.

We might say that "Cups" can be a Blueprint. Within the Blueprint "Cups" we may have several different Groups: mugs, sippy cups, goblets, wine glasses etc. "Cups" describe what type of Groups belong in this Blueprint.

We could label another Blueprint "Sports." Groups within the Sports Blueprint could include hockey, soccer, basketball, football, etc. 

Now let's look at an example from a higher-ed institution. We could have a Blueprint for "Colleges." Within our College's Blueprint, we may have several Groups including the College of Business, the College of Humanities, the College of Engineering and Technology, etc. The "Colleges" Blueprint tells us what types of groups we have.

It is possible to create a hierarchy of Blueprints within Kuali Build as well. Meaning, our "Colleges" Blueprint could have the Sub-blueprint or child blueprint of "Departments." And within our department's Blueprint, we may have several Groups including Biology, Math, English, etc. (See Configure Blueprint Hierarchies).

Below is a screenshot of one institution's Kuali Groups area, and it illustrates the example we just described. 

 

Where do Roles fit in?

Roles are what allow us to assign specific tasks to users or a collection of users (see Create and Manage Roles). Roles live at the Blueprint level and are available to all Groups within that Blueprint. Because they live at the Blueprint level and trickle down to everything below it, that saves you precious time of having to create the same types of Roles over and over again for each Group. Roles can be re-used. It's simply who's assigned to those Roles that changes based on the Group the individual(s) belongs to.

Use Case #1 for Blueprints, Groups, and Roles

Let's go back to the example we discussed above with Blueprints and Groups. We have a Blueprint for "Colleges." We know that each Group (meaning, each College) has the Role of Dean. We can create the "Dean" Role at the Blueprint level, and when we go to assign the Dean within each of the individual Groups, the Role will already be there for us without our having to re-create it.

Notice in the graphic below how the Dean, Assistant Dean, and Review Board are created within the Colleges Blueprint and that they are made available to the Groups (College of Business, College of Education, and College of Humanities) below.

Here's what it looks like in Kuali Build.

In this screenshot, we are viewing the configuration screen for the Colleges Blueprint. Under Roles we created College Dean, Review Board, and Assistant Dean. 

This screenshot shows the configuration screen for the College of Business, which is a Group within the Colleges Blueprint. Notice that under the "Roles" section, we see the 3 Roles we created in the Colleges Blueprint, and from here we can assign specific individuals to each of these Roles.

 

Use Case #2 for Blueprints, Groups, and Roles

Let's dive into our second example. We know that each Group within the Departments Blueprint will have a Department Chair. If we create a "Department Chair" Role at the Departments Blueprint level then all departments will have access to that Department Chair Role.

Notice in the graphic below how the Department Chair, Faculty, and Curriculum Committee are created within the Departments Blueprint and that they are made available to the Groups (Biology, Math, and English) below.

Here's what it looks like in Kuali Build.

In this screenshot, we are viewing the configuration screen for the Departments Blueprint. Under Roles we created Department Chair, Executive Committee, Faculty, and Department Admin. 

 

This screenshot shows the configuration screen for the Biology department, which is a Group within the Departments Blueprint. Notice that under the "Roles" section, we see the 4 Roles we created in the Departments Blueprint, and from here we can assign specific individuals to each of these Roles.

How do I use Blueprints, Groups, and Roles in my forms, workflows, and approvals? 

Forms

Now that we have our blueprints, groups, and roles configured, let's take this a step further and see how they apply to our forms and workflows.

Let's say that we have created an app called "Program Change Request" for students who want to change their major. Of course, we will include certain basic fields on our form: student name, current major, requested major, etc. However, we also know that as part of our approval process for a major change request, the department chair of the requested major needs to approve the request. Rather than typing the name of every department chair into a dropdown or multiple choice field, we can leverage the power of Blueprints, Groups, and Roles. 

In order to pull in the correct role and approver into the workflow, we need to use the form builder to discover which department a student would like to move to. 

Once we have dragged and dropped our field into the center panel, we can configure the field in the configuration panel. We can give the field a label, make it required, and add placeholder text, etc.

In order to pull in departments from Kuali Groups, we need to select the blueprint where these groups are located from the Blueprint dropdown. 

You will notice the available Blueprints match the Blueprints we configured in the Kuali Groups area (App Builder Apps, Colleges, and the sub-blueprint Departments). 

Because we want the student to tell us the name of the department for their requested major, we will select the "Departments" Blueprint.

Now, when a student starts typing in that field, a list of our available departments from the Kuali Groups area will populate. 

Workflows

Once we have our form in place, we can begin building out the associated workflow. We know that we want the Department Chair where the requested major is located to approve the change request. Rather than re-typing all of the users and roles from the Kuali Users and Groups area, we're going to use the New Department field from our form to help us.

Once we have dragged and dropped an Approval Step into our workflow, we can configure the approver in the configuration panel on the right. 

Under "Who will approve at this step?" We will select "Person(s) in a role of a group, or the group's hierarchy, on the form." Since we have already included a field on our form for "New Department," we can select that option from the "Which field on the form?" dropdown.

Once we have selected our New Department field that is already linked to our Departments Blueprint in the Kuali Groups area, we are prompted to select a role that should approve at this step.

As you recall, the roles that show up in the menu are the roles that we created in the Departments and Colleges Blueprint previously.

Since we know we would like the Department Chair of the new department to approve, we select "Departments - Department Chair" as the role that should approve at this step.

Approval in the Document List

 Now that our app is all setup, a student can go in and request a new major. Let's say that a student requests to change to the Biology major in the Biology department. Once they select "Biology" in the "New Department" field and save the form, the Department Chair of the Biology Department will automatically be assigned to approve the document. 

Notice that on the Biology Group page, we can see the roles we made available in the Department blueprint (Department Chair, Executive Committee, Faculty, and Curriculum Committee). We can also see that we had assigned Lelah Mueller as the Department Chair.

If we check our work on the Status page of the recently submitted document, we can see that Lelah Mueller, the Biology Department Chair, is automatically assigned to approve the document.