Leave Request Approval (V2 or "Extended" version)

This tutorial explains how to build a more advanced application by extending the basic version of the Leave Request application and provides more advanced learning in the following components of K2 applications: Data, Forms and Workflow. This tutorial is intended for users new to K2, or with little K2 experience.

This tutorial assumes that you have already completed the Leave Request (V1 or "Basic" version). If you have not, please complete the basic version first, since this tutorial depends on and extends elements that were built in the basic version. If you are already familiar with the basic principals of K2 smartforms and workflow, you may download and deploy the basic solution in lieu of completing the step-by-step instructions. The solution for the basic version is provided with that tutorial.

This tutorial can be completed in any environment that has K2 version 4.7 or later installed. K2-delivered training events normally include access to a Virtual Server environment provided by K2 which you will use for the exercises. The screen shots and users in the tutorial reflect this K2-provided virtual environment. You can, however, complete this tutorial in any other environment as long as the necessary K2 components are installed and operational. You must also have the necessary rights and permissions to create the K2 artifacts in the target environment.

Some tutorials require that you have internet access to be able to connect to an external SQL database used for retrieving data. Those tutorials contain expanded information on internet connection requirements.

Tutorial Overview

You may recall that K2 Applications consist of four main components: Data, Forms, Workflow and Reports.

In Part 1, you expand upon the Data component by editing the existing Leave Request SmartObject and adding an additional property. You'll open the K2 Management site and build a service instance based on the SQL Server Service Type. You will then auto-generate a new SmartObject called Leave Types, which will connect to an external SQL data source. In Part 2, you will expand the Forms component by adding the new Leave Types SmartObject as the data source for the Leave Type drop-down list. In Part 3, you will expand on the Workflow component by adding additional email events and a new outcome called Rework. You will also return to Forms where you will edit rules and add actions that will incorporate your data and workflow updates. In Part 4, you will test the new version of the Leave Request application.

Prior to jumping into building the application, it is important to understand what you want to achieve, by designing the necessary pieces of the application. Let's start with the workflow.

Leave Request Workflow

As before, you can use a logical flow diagram to represent the various steps and actors in the workflow. The diagram below shows the extended version of the workflow. Note that there is a rework loop so that the approver can send the request back for rework, and there are additional steps in the workflow to send e-mail notifications to the requester. You will also add an escalation to the manager approval step to remind the approver and originator if the request is not approved by two days before the start date of the leave request.

Leave Request Data

The first change to the data design is that you want to provide a field where the approver can capture comments so that the requester knows why their request was sent back or rejected. To do so, you will edit the existing Leave Request SmartObject and add an additional data field called Approver Comments.

You may recall that SmartObjects can also interact with other systems. SmartObjects are essentially a "middle layer or connector" that allows consumers of data (such as forms and workflows) to interact with providers of data (such as SQL databases, Active Directory or SharePoint, among others). In this version of the application, you will leverage this power by creating a SmartObject which retrieves data from a externally located SQL database.

The screen shot below shows the data that is returned after querying the external SQL database. You will replace the static Leave Type drop-down list values that you created in the basic version, with values from the new Leave Types SmartObject.

The integration data sources used in this application (the Azure SQL database that provides the Leave Type data) is intended only for tutorial and demonstration purposes. It is not intended for use in production applications and is not supported or guaranteed by K2. The SQL database used for this tutorial runs on SQL Azure. Connecting to the database will require an open port for port 1433 as described in this Microsoft KB article: http://support.Microsoft.com/KB/287932

If you are unable to connect to the provided SQL Azure database, you will need to open up the appropriate firewall rules or ports, or alternatively install the database on a local SQL environment using the provided SQL scripts located at http://help.k2.com/files/8553. Please contact your SQL database administrator for more information and help.

Leave Request Forms

The forms in the application will be adjusted to include the new Approver Comments field, and this field will be locked down so that it can only be changed when the approver is reviewing the request.

Additionally, you will update the Leave Type drop-down list to use the new SmartObject which retrieves the leave type values from the external SQL database. You will also make a few minor changes to the form's behavior so that it is a little more user-friendly, such as clearing out the data after a new request is submitted.

Building the application

Now that you have designs for each of the elements of the extended version of the Leave Request application, you can start building them. As before, you will start with the data elements, then the form elements and finally the workflow enhancements.

When you are ready to start building the application, continue on to the Part 1: Data section to get started.