Compliance - User/Group Management

Overview

Kuali Identify Services is the component of Kuali software that manages user information used by other system modules. Kuali Protocols and Kuali COI relies on Kuali Identify Services for two key types of data: Users and Groups.

• Kuali provides APIs that allow customer schools to load User data directly into Kuali Users. Detailed technical documentation is available at: https://developers.kuali.co.
• Groups data is loaded in by Kuali based on information provided by the customer school or via APIs.  

To access Users and Groups within the application you can go to your kuali environment replace the backslash with either /users or /groups (i.e. https://greendale.kuali.co/users/).  Please note, only users with the role of 'admin' in their Kuali User profile will be able to edit or create new Users or Groups.

Users

Users represent persons who need to fill out a COI disclosure or those that will either need to access Kuali Protocols directly by logging into the system and taking action, or whose data will need to be included in Protocols. The following are examples of Users:

• A researcher from your institution who will need to log into Kuali to prepare a protocol or disclosure.
• A student who will be named on a Kuali protocol that is prepared by someone else.
• A researcher from another institution who needs to prepare and submit a protocol for review by your institution’s human research review committee.
• A researcher from another institution that needs to fill our a disclosure.
• A member of the human research review committee or a disclosure reviewer.
• An Administrator in the human research ethics compliance office or the COI office.

You will need to load the following data elements into Kuali to support Protocols and COI functionality:

Data Element	Description/Usage	Required?	Valid Format
approved	Indicates whether the user is approved to log into Kuali Protocols	Y	true  false
email	Email address of the user (must be unique)	Y	string
firstName	First (given) name of the user	Y	string
lastName	Last (family) name of the user	Y	string
name	first and last name of the user	Y	string
phone	telephone number of the user	N	string
role	determines what role the user should have in Kuali Users	Y	user  admin  external
schoolId	employee number	Y	string
username	Employee user name (used to log into SSO)	Y	string
primary group	The group ID  with which the user is primarily associated	Y	string

• Schools can decide if all users coming into the system via the API will be automatically approved, or if users need to be manually approved to log into the system
• Example logic for maintaining users via API:
• GET all users from Kuali Users
• determine the differences between users currently in Kuali Users and users in the data from the source system
• For users currently in Kuali Users for which all data elements match, take no action.
• For users currently in Kuali Users for which there's a difference in data elements, use the PUT endpoint to update those users.
• For users not in Kuali Users, user the POST endpoint to add the new users

Here is some sample JSON: 

{
"name": "Terrence Durkin",
"username": "tdurkin2",
"email": "[e-mail]",
"firstName": "Jane",
"lastName": "Smith",
"phone": "801-322-3323",
"schoolId": "theschoolid",
"approved": true,
"groupId":"58d2ef91834e0c0d78e6ace7"
}

Display Name in Protocols and COI

The value “Display Name,” which displays on screen in Protocols and COI, is derived based on other data in the system according to the following logic:

• If the value  `name` exists, that will be used as Display Name.
• If that value doesn’t exist, "`firstname` `lastname`" will be used as Display Name.
• If that value doesn’t exist, `username` will be used as Display Name
• If that value doesn’t exist, email address will be used as Display Name. 

Groups

Groups represent the organizational structure of a customer school, and are usually structured hierarchically.  A Group is a department, office, or other division of organization within an institution. Customer schools can  define a group at the institution with a name and number, and also associate it with a parent unit. Kuali will load your groups data for you as part of the implementation process, based on data you send us in a CSV file.

Data Element	Description/Usage	Required?	Valid Format
Group ID	Unique identifier for the unit/department	Y	string
Group Name	Name of the unit/department	Y	string
Parent Group ID	Unique identifier for the unit/department that is the parent of a given unit	Y	string

• The top level, typically represented as 000001, is the University
• Every unit other than the top level of the hierarchy must have a parent
• Group IDs listed here must be consistent with the primary group ID used in the user data

For example, given a structure like this:

The data needed by Kuali could be formatted like this: 

Group ID	Group Name	Parent Group ID
000001	Portland State University
A&S	Dean Arts and Sciences	VPA
BIO	Dept of Biology	A&S
CS	Dept of Computer Science	A&S
ECON	Dept of Economics	A&S
ED	Dean Education	VPA
ELED	Dept of Elementary Education	ED
OGCA	Office of Grant & Contract Accounting	VPF
OSP	Office of Sponsored Programs	VPA
PO	Presidents Office	000001
RC	Research Centers	000001
SECED	Dept of Secondary Education	ED
SED	Dept of Special Education	ED
VPA	Vice President of Academic Affairs	000001
VPF	Vice President of Financial Affairs	000001

Roles

Within Groups you can specify different Roles and users under each role at the given Category Levels based on the hierarchy structure explained above.  If a user is added to a role at the top University level they would have the Role for all records under that unit; so all records.  Whereas, if you add a person to a lower level they would only have rights to the units within the level down.

The available Roles that can be added to a Group for each module are:

PROTOCOLS

• IRB Admin
• IRB Triage
• IRB System Configurer
• IRB User
• IRB Viewer
• IRB Report Viewer
• IACUC Admin
• IACUC Triage
• IACUC System Configurer
• IACUC User
• IACUC Viewer
• IACUC Report Viewer

More information on the above roles and granting permissions for Protocols can be found in the Protocols - Managing Protocol Permissions article.

COI

• COI Admin*
• COI Viewer
• COI Report Viewer

*Although listed as a Role in Kuali Groups this role is actually managed in both the Kuali Research system (monolith) as a role that must be assigned to a Person record and also Kuali Groups.

More information on the above roles and granting permissions for Protocols can be found in the COI - Managing COI Permissions article.