Kuali Build

What is Kuali Build?

Kuali Build is a code-free platform for building workflow applications. See the full description here.

Who is Kuali Build for?

Kuali Build is intended as a self-service workflow tool for University departments to build their own workflow applications on a platform that is centrally supported by ITS and Kuali. The rich capability of forms design and workflow engine, along with an easy-to-use interface, provides a much more effective and efficient experience as compared to using PDF or Word documents for facilitating electronic workflow. 

For questions and/or access to Kuali Build please submit a request via email at techsupport@uconn.edu or the Technology Support Center Portal at techsupport.uconn.edu. We recommend reviewing the following information before getting started.

Roles and Responsibilities

Applications and Technology Solutions Staff

• As the Kuali Build Administrator, ATS staff will provide overall technical support for the system and engagement with the SAAS vendor (Kuali) for support issues with the system.

• ATS will manage the global organizations and groups.

  • Requests for application-specific groups can be made to the Kuali Build Administrators via the Technology Support Center Portal at techsupport.uconn.edu.

• ATS will manage the web services integrations.

  • Requests for integrations can be made to the Kuali Build Administrators via the Technology Support Center Portal at techsupport.uconn.edu.

• ATS will provide assistance with best practices and product usage questions from Application Builders / Administrators.

Application Builders / Administrators

• As a self-service model, functional areas are expected to build forms and workflow using the Kuali Build web interface.

• Application Builders will work in the live environment and publish new applications or updates to existing applications.

• Application Builders will appoint someone as Application Administrator (if different from themselves) to manage the data collected in the application.

  • The Application Administrator will provide user documentation and ongoing user support/troubleshooting for the application.

  • The Kuali Build Administrator will provide second-tier support to the Application Builder / Application Administrator.

Guidelines for Development

1. Naming Conventions

   1. Development is done in the live system. Create a new application and use DRAFT at the beginning of the name to distinguish a live application from one in development. 

   2. For applications that are not intended to be used by the entire University, include the name of the school/department in the title to distinguish it from similar applications.  

2. Publishing Applications

   1. Draft applications should be restricted to a limited number of users during development so the community does not see the application on the Kuali Home page and assume it is a live application.

   2. Once testing is complete, duplicate the draft application, set the permissions for the intended audience, and remove the old copy so you have a clean application to start.

   3. The workflow simulator can be used before publishing to test the application.

   4. Making updates to a live application will only impact new records. Any existing or in-flight records will reflect the previous version of the application.

3. Organizations and Groups

   1. Organizations and Groups are controlled by the Kuali Build Administrators. Developers can set individuals as application administrators and users of the application, but groups for larger populations are centrally managed. Developers can however use the LDAP attribute uconnPersonAffiliation in the application permission to restrict usage by that attribute (useful for applications that are restricted to only staff or only students).

   2. The University Organization structure will be centrally managed for use in workflow, though it will be condensed to a Department → VP/AVP/Dean → Division.

   3. Requests for application-specific groups can be made to the Kuali Build Administrators via the Technology Support Center Portal at techsupport.uconn.edu.

4. Integrations

   1. Integrations are centrally managed by the Kuali Build Administrators.

   2. Integrations must be in REST format.

   3. Requests for integrations can be made to the Kuali Build Administrators via the Technology Support Center Portal at techsupport.uconn.edu.

5. Electronic Signature

   1. Consider Build when... Your team needs to create rich form-based processes that involve data from existing campus systems, have multi-step approval processes, or could be improved with optimized data analysis and reporting capabilities. Example processes include a Change of Major Request, Fellowship Application, or Purchase Order Request.

   2. Consider DOCUSIGN or other tool when... Your team needs to collect legally verifiable signatures on existing contracts/agreements with very simple approval processes. Example files include Work Authorizations, Release of Information, Enrollment Verification or Permission Slips.

Related Articles

• Page:
  Overview of the Dashboard
• Page:
  Kuali Build Essentials
• Page:
  Kuali Build