Back to: Kianda Foundation Course (2024)
Welcome to Section 2 – Create your first process! This section will introduce the concepts of:
- Process design and process instances
- Form view and edit modes
- Process requirements
- Kianda Designer for process and form creation
- Adding controls or fields to forms
- Introducing rules to create dynamic process actions
- Connecting to datasources
- Previewing your design
Within each lesson you’ll find a short video, along with text to guide you through a topic. The section ends with a short quiz to test your knowledge. You can view the section recap PowerPoint here.
The first lesson in this section will introduce the concept of process design and process instances.
Kianda removes boundaries in digital transformation by allowing non-IT business professionals to participate in development initiatives. Allowing this citizen development brings more people into the change game and provides the armour to compete at a hyper-agile pace. Digitising processes using Kianda could involve a complete revolution of manual business processes, or specific solutions for customer queries, employee onboarding, health and safety checklists or simple digital approval processes.
Creating forms using Kianda Designer
Kianda processes are made up of forms, which in turn contain fields or controls and rules. Fields are used to take in user input, make calculations, display values and so on, and rules are used to execute actions to drive the process.
Kianda Designer is used to create these forms and form elements within a process. Each process in Kianda Designer will have it’s own unique link or URL and this can be shared with other form designers for co-creation, for example, for a process named ‘New training process’ the link is:
https://green-itr.kianda.com/admin/designer/new-training-process
Process instances
When your process is created in Kianda Designer, you can save the process, and then submit data to that process. When you save or submit data, then an instance of the process is created. Another name for a process instance is a record. This instance is tied to user data or calculated values, or to whatever the process is designed to do.
The instance has a unique ID which can be seen in a list widget in a dashboard. For example, this List widget displays the individual records of various training requests submitted by employees. The unique ID for each record is shown in the first column. Form owners or those with security access can click on ID ‘new-training-process-39’ to view the training request form completed and submitted by employee Ryan B’Oul.
List widget in a dashboard showing process instances
This means that each new record generated by a process will have its own unique URL that can be shared with those who have the required security access and need to be involved in that particular process instance. For example, in this case, the training request submitted by Ryan (an employee) may be viewed and approved by his line manager:
https://green-itr.kianda.com/forms/new-training-process-39
You can create a link on your dashboard – in the example shown above, the Start new process button at the top right of the Training Requests list widget – that enables you to create a new record by bringing you into the relevant form.
If you commit to the process by submitting or saving information, then the result is a new process instance – that is, a new unique record – which will be seen in a list widget in the dashboard, as seen in the image above.
Keeping in mind that Designer is used to create processes, and that each ‘run’ of the process results in a unique process instance or record, will help you later on when designing forms and dashboards. Setting security for processes is detailed in Section 5, Lesson 5 Security.
Processes in Kianda are made up of forms. Forms contain all the buttons, fields, and rule triggers needed to execute your process.
There are three principles to consider when working with forms:
- Reading modes: Form users can either use forms in edit mode or read mode. Edit mode means that users can submit information, while read mode means that users can only view forms. The latter may be useful for example for certain staff to review feedback in a form, but not be able to edit/update it.
- Form owner: The default owner is the person or group that the form is assigned to when the the form is created. By default, only this person or group can edit the form. All other users can only view forms in read mode. The default owner however can reassign forms to other individuals and/or groups.
- Current form: Typically there are several forms in a process, and only the form that has the status ‘current form’ is editable. However, in a complex multi-step process, other forms can be configured to activate with the current form, meaning they can also become editable at the same time, creating a form group.
These three considerations are established when the form is created, as seen in the dialog box below. These properties can also change dynamically as a result of rules being applied.
New form dialog box
New form considerations
- The Default owner(s) field is where you can set individuals and groups as the default form owners who can edit the form.
- Activate with means that the form can be activated with other forms within the process, so they can be edited at the same time. This means several forms become the current form in a form group.
- Submit mode means that when a process instance is running you can choose only this form to be submitted, or you can choose all forms in edit mode meaning that several forms could have their details submitted or saved.
- Enable quick actions allows you to statically enable a) reassignment, b) edit, and c) custom actions on any form. For a) and b) you can choose individuals and/or groups who can reassign or edit forms. In the case of b) edit there are options to hide form footer buttons when editing, and to trigger rules on save against a set field when saving edits. For c) custom actions, you can set your own custom action and create an action label against a particular form field. This means the user(s) assigns the custom action will see the labelled action designated for them. As a designer you can choose the action display mode as read-only, edit or both, so you can decide what type of access the user(s) will have.