Ok. You've been learning about Categories, Groups, and Roles in Kuali Build, and you may be starting to get a handle on them (See the section of articles entitled Categories, Groups and Roles). But if you're anything like me, things are still a little fuzzy. Let's see if we can clear away some of the fog.
What is the difference between Categories and Groups?
Categories and Groups: aren't they just the same thing using different words?
I like to think of a Category as a classification for certain types of Groups. Groups are also part of a Category, 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 Category. Within the Category "Cups" we may have several different Groups: mugs, sippy cups, goblets, wine glasses etc. "Cups" describe what type of Groups belong in this Category.
We could label another Category "Sports." Groups within the Sports Category could include hockey, soccer, basketball, football, etc.
Now let's look at an example from a higher-ed institution. We could have a Category for "Colleges." Within our Colleges Category we may have several Groups including the College of Business, the College of Humanities, the College of Engineering and Technology, etc. The "Colleges" Category tells us what types of groups we have.
It is possible to create a hierarchy of Categories within Kuali Build as well. Meaning, our "Colleges" Category could have the Sub-category or child category of "Departments." And within our Departments Category we may have several Groups including Biology, Math, English, etc. (See Configure Category 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 Category level and are available to all Groups within that Category. Because they live at the Category 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 Categories, Groups, and Roles
Let's go back to the example we discussed above with Categories and Groups. We have a Category for "Colleges." We know that each Group (meaning, each College) has the Role of Dean. We can create the "Dean" Role at the Category 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 Category 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 Category. 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 Category. Notice that under the "Roles" section, we see the 3 Roles we created in the Colleges Category, and from here we can assign specific individuals to each of these Roles.
Use Case #2 for Categories, Groups, and Roles
Let's dive into our second example. We know that each Group within the Departments Category will have a Department Chair. If we create a "Department Chair" Role at the Departments Category 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 Category 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 Category. Under Roles we created Department Chair, Executive Committee, Faculty, and Curriculum Committee.
This screenshot shows the configuration screen for the Biology department, which is a Group within the Departments Category. Notice that under the "Roles" section, we see the 4 Roles we created in the Departments Category, and from here we can assign specific individuals to each of these Roles.
How do I use Categories, Groups, and Roles in my forms, workflows, and approvals?
Now that we have our categories, 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 Categories, 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.
Rather than re-typing all of the departments out into a multiple choice or dropdown field, we're going to use the "Group Typeahead" field found in the Advanced Fields section. This will allow us to pull in a list of all the departments we have already added to the Kuali Groups area.
Once we have dragged and dropped our Group Typeahead 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 a placeholder text.
In order pull in departments from Kuali Groups, we need to select the category where these groups are located from the Category dropdown.
You will notice the available Categories match the Categories we configured in the Kuali Groups area (App Builder Apps, Colleges, and the sub-category Departments).
Because we want the student to tell us the name of the department for their requested major, we will select the "Departments" Category.
Now, when a student starts typing in that field, a list of our available departments from the Kuali Groups area will populate.
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 (Group Typeahead) field from our form to help us.
Once we have dragged and dropped and 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 Category 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 Categories 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 set up, 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 Department category (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.