Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

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 access to Kuali Build, we recommend attending a one hour introduction. If you would like to request an introductory session, please submit via the Technology Support Center Portal at techsupport.uconn.edu.

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.

Comparison of LEAP and Kuali Build for Developers

FeatureLEAPKuali Build
CodingLow Code option allows addition of JavaScript to events and in application start.No custom coding.
WorkflowRequires custom code for audit trail.Built-in audit trail.
RoutingRestrictive routing, requires buttons and hide rules.More flexible routing options.
DashboardsRequires a great deal of custom code to build a dashboard.Has built in dashboard for individual Submissions, Drafts, and Action Lists across all Kuali applications.
Export/Back End DataCan export based on filters of fields and records in an admin screen. Can only save one filter; filters are complex to create.Exports entire record set and fields; can filter on column values, perform an open search, and save multiple searches/filters and share them with others.
PDFRequires custom coding.Can produce a PDF of the entire document.
Web ServicesCan consume rest-based services or soap if a developer creates a custom soap interface. Rest services can be configured by the application developer. Web services can be consumed between LEAP applications.Can consume rest-based services. Soap services requires separate middleware translation. Rest services centrally configured by Kuali admin; available to all developers (more restrictive control coming in future release).  Can consume web services between Kuali Build applications.
Access ControlGroups configured and maintained by the developer in each application but require redeployment of the application.Groups centrally maintained by Kuali Administrator but can be used across multiple applications and do not require redeployment of application.
CloningRequires custom coding to allow user to clone a record.Can clone requests from their submission list.
DeploymentDevelopers build in test environment; ITS publishes to production environment. Changes impact existing records so care must be taken to account for records still in flight. Unable to see what previous versions of form.Developers work in production environment only and can publish their changes. Changes only impact new records going forward. Version history of the records is preserved.
TestingForm preview can be used to preview start stage of  form. Workflow testing requires multiple accounts to verify permissions, workflow, and notifications.Form preview can be used to preview form at start stage. Workflow simulator can be used by developer to test workflow and notifications without need for multiple accounts.
TablesCan create tables on form to hold unknown number of subset data.Tables are available but without the option to make required on the table itself or items in it.  No formula to sum table data.
RemindersCan create custom code to place a button on the form to manually send a reminder for that record.Has option for manually sending a reminder notification from the workflow status page
  • No labels