Page Comparison

...

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