• Kuali Resources:
• LCS-supplied Resources:  
• Getting Started
• See additional articles

• If you have more than three steps/steps sub steps/sections within the document, you must include the table of contents section above (keep everything in brackets, remove these bullet points)

• If you do not use the table of contents delete these bullet points and the text in brackets above.

Kuali Resources:

1. UW has purchased the Kuali Build module. Kuali has robust documentation found here.
   1.  There are 2 introductory videos which you may want to watch:
      1. Part One: How to Create an App - Form & App Permissions
      2.  Part Two: How to Create an App - Workflow & Documents 

LCS-supplied Resources:  

1. Sandbox – a Space in UW’s Kuali Build environment to work with “play” applications
   1. Each one of you will be given access to a Kitchen Sink app in the Sandbox.
   2. Before building the application, a Kitchen_Sink workflow was created (best practice) which assists in creating the form and the workflow, especially decision points. 
   3. The intent is for you to have hands-on access to how an application can be set up utilizing most gadget/field types along with most of the workflow steps. 
   4. We will eventually delete your Kitchen Sink application so feel free to play.
2. Production applications:
   1. After the pilot, you will need to submit an Application Request.
   2. The developer will receive a notification when their application has been created.
   3. Production-ready applications will be found here.
      1. All UW-Madison staff will be “Authenticated Users” meaning they will use SSO (NetID plus MFA) to access the application. This is preferable.
      2. Examples for using Anonymous Users are for outside construction contractors who need to submit a request for access to a building.
      3. Anyone who will have tasks or approvals to perform will need to obtain a NetID.  
3. Groups:
   1. Groups are commonly used in the Form Builder and when determining routing in Workflow and can be used to assign people to a Role.  
      1. For example, the LCS team has set up a group called “LCS Team” that is divided into Administrators and Members. Some tasks and approvals can only be completed by the LCS Administrators while others by anyone in the entire LCS team. Anyone in those groups can complete the task or approval and it will be removed from everyone’s action list.  
   2. Groups are limited to 800 people.  
   3. The LCS team wants to build one or several Org Charts (aka Blueprints in Kuali Build) based on Groups. We will need your help to determine how best to configure these and who should be in what group.  
   4. Before building your application, determine what “groups” of people are needed to fulfill each step of your process and work with the LCS team to have those groups defined and available to you.  

Getting Started

1.  Create a flow diagram (all UW-Madison staff has access to SmartDraw as a suggested tool) with decision points and notifications. (Example: Kitchen_Sink workflow.)
2. Determine if you need to access data from any campus system and follow this kb article to get approval.
3. Access the Production-capable application you were assigned  
   1. You can add other application administrators/developers, but it is advised to not both be in the application at the same time (one user’s changes could overwrite another). 
4. Build the form (see LCS - Tips and Tricks for Kuali for some tips and tricks with forms and workflows)
5. Test the form
6. Build the workflow
7. Test the workflow
8. Check permissions. Add policies and/or Conditional Permissions. 
9. Check App Data Sharing
10. Allow other users to test your application 
11. **Before publishing reach out to the LCS team**  
    1. Any integrations will need to be finalized and have the right authentication 
    2. Check email configurations to ensure the notification emails come from a wisc.edu address.
    3. Options prior to publishing:
       1. Any documents created during testing will need to be deleted if the same application will be Published. This will lead to the first document created after publishing to be given the number n+1 from the last one created during testing. (e.g. If testing used 16 documents, delete the 16 before going live, the next document created once live will be number 17).
       2. The LCS team can copy the application into a new application so that any documents created in the new application will be production-only.  

See additional articles

LCS - Tips and Tricks for Kuali

LCS - Deny in Kuali Build