🔃 Build your first workflow in Kuali Build

Kuali Build is a new software application that allows faculty & staff to build Apps, which are made up of forms and workflows. These Kuali Build apps facilitate the collection of data, and allow you to perform intelligent actions based on that data. 

This article will walk you through the first steps in creating a Kuali Build workflow.

Workflow Builder

The Kuali Build workflow builder is laid out similar to the form builder, with the workflow components on the left, and a settings sidebar on the right. 

Every workflow starts with a Start icon, a Form Submission box, and an End Icon. To build out the workflow, drag in a component from the left, until it's between the Form Submission box, and the End icon. Similar to the form builder, you'll see a blue box in the workfow where it thinks you want to drop the component. Release your mouse button to drop it there, and it will automatically open the settings box. 

The settings box will contain the options for the specific component you've chosen. To edit a different compoent, click it in the workflow diagram, and the settings box will change to reflect the component you're editing. If a component's name or text is red, that means that Kuali has detected an error or omission in your configuration of that box. If you see this, follow the instructions and give the component the information it needs in order to run successfully. 

The workflow diagram reads left-to-right, and can be thought of as a timeline of what will happen as the workflow progresses from start to end.

Workflow Components

Kuali Build has the following components available to allow you to build your workflow:

• Form Submission: This is the first step of every workflow, and is not editable. Each workflow must start with a form, and whatever data is populated on the form will be the data that is used for the following steps. 
• Approval: This will stop the workflow, and require a person in a Group or a role in a Group to evaluate whether the process should continue or not. The approval step can also allow the approver(s) to add/change some data in the form. 
• Task: This step stops a workflow, and requires a person to indicate that a task has been performed. It can also provide instructions on how to perform this task. This task is usually a human-acoomplished one, entering/changing data in Colleague, for instance, or performing some other duty with regard to the information in the form.
• Notification: This does not stop the workflow, but will send an automatic email to a designated person. The receipient of this email can be a specific person, a group of people, or the those in a specific role of a group. The email can be customized with data from the form. 
• Branch: The branch component splits the workflow, and represents an automatic decision made by the system, based on data in the form. This effectively creates two or more workflows, and allows you to specify the criteria for how a document will be routed. Branches can have as many routes as you like, but documents can only go down one route. Documents will take the first route whose rules match their data, or if none match, they will take the default route. 
• Integration: The integration component will interact with some external system, and send and/or receive data. Integrations will often take input (i.e. data from a form field), and will often provide output (which becomes data in the form for future use). Integrations are primarily designed and built by IT. You can request an additional integration using the Kuali Integration Request form (coming soon -- in the meantime, email kuali@cedarville.edu)

Workflow Concepts

Branching: Matching Conditions 

When you put a branch in your workflow, you are instructing the workflow to make a decision about which route to go down. By default, your branch step has a default route, and one conditional route

.Key Concept: A conditional route is used only if the conditions are matched.

Here's an example of what your branch conditions could look like: 

In this case, we have a Yes/No dropdown question on the form entitled "Do you Like Ice Cream?". I've added a branch, and set the conditions for Route #1 to match when the answer to "Do you like Ice Cream" is "Yes". 

If, on the form, the submitted chose "Yes" For this question, the workflow would proceed down Route #1. If they didn't choose "Yes", it would proceed through the default route. 

These matching conditions can get quite complex, but here's a few tips:

• Matching rules are evaluated in order. If the form submission matches Route #1, it won't proceed to Route #2, even if it would match that one too. 
• If the form submission doesn't match any route, it will run through the Default Route. 

Notification: Email Variables

In a notification step, you can insert information from the form into the body of the email. Here's an example of how to do that. 

Add a Notification step, and then scroll in the right sidebar down to the Email Body section. Click in the message box to put your cursor where you want the variable to be inserted, then click Add Variable. Select the form on the field (in this case, I've chosen "Submitter - Display Name" to insert the first & last name of the person who submitted the form), and a blue badge with the name of the variable will appear. When the email is sent, this blue badge will be replaced by the value in that form field.

You can also use this feature in the email subject line.

Approvals & Emails: Groups & Roles

When you create an approval or email step in your workflow, there are a few options to choose from about who will get to do this approval. 

These are the options and what they mean: 

• Persons in a role of a group on the form: This option is for when you've included a group field on the form. This group information can come from the Kuali Groups integrations, or some other integration that returns a Kuali Group. By selecting the field on the form that contains that group, you can then select what Role in the group you'd like the assign to this approval. Common roles might be "Department Chair" or "Administrative Assistant". 
• Persons in a role of any specific group: This option is the same as above, but you don't have to have a Group field on the form. You specify a single group in the workflow, and the people in the specified group (or role in that group) will always receive these approval assignments. 
• Person specified on the form: This option is for when you've specified or included a person on the form. This person information can come from the Kuali Users integration, or some other integration that returns a Kuali Person. You can select which field on the form this person will come from. 
• Any specific person: This is the same as the previous option, but you specify one individual who will always get these approvals. 

Notification steps have the following additional options: 

• An email specified on the form: This option is for when you've included an email field on the form. The notification will go to the email that was entered (or retrieved from an integration).
• Any specific email: this option just sends the notification to a hard-coded email address that you specify in the workflow. 

Need a new Group? Use the Group Request Form on Kuali Build

Integrations: Input/Output

There are two kinds of integrations in Kuali Build:

• Form integrations: these fetch data from external systems and add it to the form prior to submission.
• Workflow integrations: these can fetch or push data from/to external systems during a workflow. 

Ultimately, integrations take input, and provide output. The type and number inputs and outputs are set up when the integration is designed (by IT). Data from the form can be assigned to these inputs when they're added to your workflow, and after the integration completes (and in any subsequent steps in the workflow builder), the returned data from the integration will be available as a field in the form, as if it were entered at submission time. 

Copy/Paste Workflow Steps

The Kuali Build workflow builder allows you to copy/paste steps from one place to another. If you select a step (make sure you don't have your cursor in a text field), and use the copy keyboard shortcut (Ctrl + C on Windows, Cmd + C on Mac) to copy that step. Use the paste keyboard shortcut (Ctrl + V on Windows, Cmd + V on Mac) to paste that step in. 

This is really useful for copying complex email notification steps, or even whole branching routes for reuse. When you need two very similar steps, it's often easier to copy and tweak than to build each one entirely from scratch.

Approval: Show/Hide Sections

During an approval, the approver is able to view the submitted form. By using the following setting, you can customize which sections (always use sections on your form!) they will be able to view or edit, and which will be hidden from them. 

Simple turn on Make individual form sections at this step hidden or editable, and choose which sections should be viewable/editable. Nested sections are represented here as well, and you have granular control over which nested sections should be visible or editable. 

Testing Your Workflow

Once you have your workflow finished, you'll want to test it. To do that, use the control at the top of the page to move into testing mode. 

You'll need to make sure that all issues with your workflow (marked in red) have been resolved. 

In test mode, you can submit a dummy version of the form, and preview all notifications, approvals, tasks and integrations as they would be seen if this was a real submission. 

Use this opportunity to proofread and validate email text, and make sure all the sections that are visible for each approval are correct. 

Publish Your App

Changes to a workflow will not take affect until the app is published. If you've already published a version of your app that just had a form, you'll need to publish it again.