This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Process Designer

The process designer provides an intuitive interface where you can quickly start building a process app together with forms, fields and rules for any business use case. Forms are an important component of any process. They might be used as a stage of a process and can be made active individually or at the same time (parallel forms).

A process design is a JSON document that encapsulate the visual layout and logic that renders into a fully functional process app and allows users to perform all sort of tasks. The process designer allows process designers to easily compose the process JSON schema without ever requiring the user to write a single line of code.

Designer introduction

This video introduces the process designer and demonstrates how to start creating a form and add fields to a process.

Preview a process

As an Administrator or someone with the role Design business process, you can preview your process designs at any time using the Run and preview process button previewer button. This is a useful feature that allows you to preview your process, and visualise the logical flow of your design without publishing it yet for your users to view/use. Within the preview window, you can also troubleshoot your fields, rules and conditions by utilising the rule debugger feature.

Preview window

How to launch the process preview

  1. Navigate to the left-hand pane of the designer screen and click on the Run and preview process button run and preview process button. From here, your process will display in a preview window only to you or to other Process/workspace security users that have access to the design.

  2. Within the process preview window, you can interact with controls and enter information as expected and the rules will execute on fields/buttons - the window displaying as a process instance, similar to when it will when published.

  3. You can utilise the Rule debugger feature for troubleshooting purposes by clicking on the Enable / Disable Rule debugging button rule debugger button in the top right corner of the window.

  4. You can preview the process design from the perspective of different devices by clicking on the Device preview buttons to the right of the Rule debugger button. This feature will visualise how your process design is dynamic and responsive on a myriad of devices. The options for device emulation are as follows:

    • Desktop preview desktop preview button - displays the process instance as it would look on a desktop device.

    • Tablet preview Tablet preview button - displays the process instance as it would look on a tablet device.

      tablet preview screen
    • Mobile preview Mobile preview button - displays the process instance as it would look on a mobile device.

      Mobile preview screen

    Note: If you select Tablet preview or Mobile preview, a Rotate device button rotate device button will appear in the top right-hand corner. Clicking on this button will rotate the device screen from portrait to landscape and vice versa in the preview window.

    Rotate screen

  5. When you are finished previewing your process design, click on the Exit preview mode button Exit preview mode button in the top right-hand corner of the previewer window.

Add new forms

Add new forms by clicking the add form button on the top of the designer screen. Options will be displayed to allow you to configure how the form should work.

Editing forms

Click on the form tab on top of the designer to reveal the form edit button (pencil) clicking this button will open the form editor and reveal its properties.

Import forms

Within the process designer you can import forms and other fields from other process designs within your workspace. Click the import button to the top right of the process designer to import parts of other process designs into your process.

Properties pane

In addition to adding fields/controls and rules, there are a number of ways to create the form and process design you want. You can set properties at property, form and field level. Properties represent how an element presents itself, for example the title and layout of the element.

Process and form properties

Properties at all levels are visible in the right-hand pane of Kianda designer, along with the:

  • Import button Import button to allow you to import forms and form elements like fields

  • Version history button Version history example to allow you to manage version of the process design

  • Settings button Settings button to allow you to apply process security settings amongst other options

Process level properties

When you click on a process from the main process view, straight away you will see the Process properties in the right-hand pane as shown in the image above. To find out more about process go to the Process properties page.

When you click on a form within a process, then the properties view changes to show Form properties, as shown in the image in Form level properties.

If you want to return to Process properties, click on the process name beside the Designer and chevron symbol, that is:

Form level properties

When you click on a form in Kianda Designer, the properties for that form appear.

Form properties view

To find out more about form properties go to the Form properties page.

Note that at form level, additional buttons appear above Form properties namely:

  • Edit/Pen button Edit/pen button where clicking on this button opens the Edit dialog box for the chosen item, for example a form.

  • Clone button Clone button that allows you to make a duplicate form. Click on OK to make a copy or Close to close the dialog box and cancel the copy.

  • Bin/trash button Bin button where clicking on this button opens a popup asking you to confirm that you want to delete the selected form. Click on OK to make a copy or Close to close the dialog box and cancel the deletion.

Field level properties

When you add controls to forms Kianda Designer, and select a field/control, the properties for that field appear in the right-hand pane.

Field properties view

The type of field/control is listed in the properties pane, for example ‘Text box’ as shown in the image above. How the field appears is easy to control simply by checking/unchecking a number of boxes. To find out more about field/control properties go to the Control properties page.

Version History

The process design in Kianda maintains a compreensive version history of any changes made to the platform. The Version number of a process will be updated every time a process design is saved by clicking on Save button.

The designer maintans two types of versions: Draft and published. Draft versions are only visible to administrators and designers while the last published version is visible to end users.

A design without a published version cannot be used by an end-user to create a new record.

The current or active version of a process is always visible in the right-hand pane, for example V0.34.

The first version of a process is 0.1 and will increment to 0.2 and so on, each time a process is saved. Once the process is published the version changes to 1.0 and increments with each publication.

If the process is subsequently saved, then the next version will be V1.1 and the next published version will be V2.0.

Using versioning makes it is easy to keep track of changes and to restore the design to an older version if needed.

Process Settings

You can use Settings to control process wide settings for the current process design and control things like behavious of form tabs, process security and anonymous access of the process.

General settings

Process ID Settings: Use this to control how the process record ID generation. The default record ID is a combination of the process ID and the record ID,example: process-1.

With this setting designers can use any combination of fields or expression to generate the record unique ID.

Onload rules execution mode: Controls when onload rules execute. The options are: Always, when in edit mode and When its a new record

Enable form assignment notification: Enables automatic push notifications to be send to assigee user when a record is assigned to them.

Prevent closing an instance with unsaved data: This allows the system to prompt to save unsaved changes to a form record if the user attempts to navigate away without saving first.

Enable process chat: Enables process level chat features for a given process record.

Security

Use the security tab to configure security settings for the process.

Enable process security: Enables or disables process level security. Users without access to the record receive access denied error.

The following are the available security modes:

  1. Restricted creator: With this security mode only indicated users can create a new record of the process, users assigned to the record can update it and everyone else can only view it.
  2. Restricted assign to: With this security mode only indicated users can create a new record, assign to users can view or modify it, everyone else cannot view the record.
  3. Restricted: This is the most restricted security mode. Only directly indicated users can create, view or update records.

Tabs

Use the tabs to configure how the process tabs will behave including its look & feel. Control here setttings such hidding the form tabs altogether, hidding the workspace left nav and enabling the mobile footer navbar.

You can also configure here the colours for the selected tab and trhe completed (submited) tab.

Anonymous form

Use the anonymous form tab to enable at process level anonymous form submission.

When enabled the user has the option to create the new record anonymous link. This is a unique link that allows users to submit new records without authentication.

Process instances

When your process is created in 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 ‘training-request-and-feedback-process-26’ to view the training request form completed and submitted by employee Mark Donnelli.

List widget in a dashboard showing process instances

Process instance example

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 Mark (an employee) may be viewed and approved by his line manager:

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. For information on creating list widgets go to List widget.

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 design results in a unique process instance or record, will help you later on when designing forms and dashboards.

Instance Common fields

The non-design fields associated with all Kianda processes are listed below. It is useful to keep these fields in mind when designing forms, as they can be used to retrieve, store or display values from process instances for example Status which is the status of a process instance. Using these ‘internal values’ could be useful where the status of one process could be used as a condition to trigger the start of another process, for example using the Start a process rule.

The common fields associated with process instances are:

Field nameExplanation
IDThis is the process instance ID, labelled as ‘process-name-number’, for example ‘safety-inspection-8’. This ID is part of the URL that brings you to the process instance/record held on the system when information is either submitted or saved. For example clicking on the process instance ID ‘safety-inspection-8’ in a dashboard brings you to the form.
Unique IDThis is a system generated ID for each process instance, a 32 letter and number generated value.
StatusThis is the status for the process instance, that is either a ‘form name’ or ‘Completed’. Completed indicates that all forms in a process have been submitted, while ‘form name’ indicates what the active form is in the process, that is, where the process is ‘at’. For example in a process of two forms, a Request form and an Approval form. Once the Request form has been submitted then the status for a process is ‘Approval form’ indicating that this form needs to be completed.
VersionThis is the process instance version number that starts as 1.0. If a process instance is updated, for example if a process design is updated and published and process instances are updated with the change, then the next version of the instance will be 2.0.
Process VersionThis is the process design version, that is the version of the process design that has been used as a template for the process instance.
Process NameThis is the Unique ID name that comes from the process design that is the template for the process instance. The ID is created when the process is created. The ID field autofills from the title of the process as shown in Create your first process.
Process TitleThis is the Process title that comes from the process design title, created when the process is created or updated, for example see Create your first process.
CreatedThis is a date and time stamp when the process instance is created.
Created byThis is the user name of the user who created the process instance.
ModifiedThis is the date and time stamp when the process instance is modified, for example after a process design is published and existing process instances are updated.
Modified byThis is the user name of the user who modified the process instance.
Assign toThis is the user name of the user who a process is assigned to. Process designs may have a static option for reassignment in their design so that process instances can be reassigned using Quick actions. Alternatively the Assign form rule can be used to dynamically assign form ownership to another user. That user is named in the Assign to field.
Security usersThese are the named security users, defined using Process settings by selecting Enable process security and naming Process security users which can be Users, Groups and/or Partners.

1 - Forms

Introduction

Processes in Kianda are made up of forms. Forms contain all the buttons, fields, and rule triggers needed to execute your process.

You can use the Designer to design forms for end users who will use the platform to submit, save and review information, either as named users in the platform, users who receive a link to an anonymous form, or partners who can access shared processes. These end users will create new process instances or records in the system, or access existing process instances which shows information that has either been saved or submitted in a form.

When discussing forms we’ll talk about form design that is creating and updating forms within a process using Kianda Designer as well form use which refers to end users who will edit or read forms in a process instance/record in the system, built using the Designer.

Form design principles

As you work with Kianda Designer you are designing the ‘user interface’ for users to interact with a particular process. Keeping the end user in mind, there are three design principles:

  1. Reading modes: Form users can either use/access 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 customer feedback in a form, but not be able to change/edit the feedback form.

  2. Current form: Typically there are several forms in a process, and by default the first form in a process is the current form.

    Three form process example

    For example in the Training Attendance Process above, the process flow is as follows:

    • Training Request - an employee initiates a process instance by filling out this form

    • Training Approval - the manager approves the request using this form

    • Training Attendance - when training approval occurs, a trainer invites the employee to attend training and once complete, the trainer completes a this form to evaluate the employee’s participation.

      Therefore when a process instance is initiated upon submission of the Training Request form, then the next form in the process becomes the current form, in this case the Training Approval form.

      Only the form that has the status ‘current form’ is editable by a form owner (see point 3 below). In a complex multi-step process, several forms can be configured to activate with the current form, meaning they are also editable at the same time, creating a form group, see section 2 of New form creation. Rules can also be used to change the workflow and make other forms the ‘current form’.

      Also note that all first forms in a process flow add the current user as a ‘form owner’ therefore allowing all users to edit the first form, as clicking on ‘submit’ or ‘save’ in the first form results in a new process instance.

  3. Form owner: The default owner is the person or group that the form is assigned to, this means they can edit the current form(s) in a process instance. Default owners are typically set when a form is created, see section 1 of New form creation below. By default, only this person or group can edit the current form in a process instance. All other users can only view forms in read mode. The default owner however can reassign forms to other individuals and/or groups. Form ownership can also be assigned dynamically using the Assign form rule.

These three considerations are established when the form is created, as seen in the dialog box below, and these parameters can be updated at any time by editing the form design. These properties can also change dynamically as a result of implementing rules, for example the Go to form rule can change the workflow in a process.

New form creation

As mentioned above there are certain considerations to keep in mind when working with forms. The image below shows a New form dialog box that is created when the Add form button is clicked in Kianda Designer. At any time if you click on a form and then the Edit/pen button Edit/pen button an Edit form dialog box appears which has the same parameters as the one shown in the image below.

New form dialog box

img

New form considerations
  1. The Default owner(s) field is where you can set individuals and groups as the default form owners who can edit the form.
  2. 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.
  3. 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.
  4. 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 that the user(s) assigning 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.

The following are rules that are directly associated with working with forms and form state.

  1. Go to form: This rule enables the designer to provide a way for users navigate to any form within the process.
  2. Assign form: This rule allows designers to dynamically change the default form owners of forms from user picker fields or other means.
  3. Submit form: This rule marks the form as complete or submited and allows the process to progress the workflow to the next available form.
  4. Field display mode: This rule forces the form display mode to be editable or read only even when the current user is not a form owner.

1.1 - Form owners

When creating forms, it is important to consider form access during the design phase, that is who can access and edit forms in a process instance. For example if an employee submits a performance review form, a line manager may wish to access that submitted process instance/record and edit the form, adding in comments and performance grades.

There are two key principles to keep in mind in terms of form access:

  1. Forms are assignable - this means that forms can be assigned to individuals and/or groups, and then only they can edit the form, when it is the current form, in a process instance. The ‘assignee’ can be a combination of users and groups. There are various ways a form can be assigned to a user:

    ​ a) Using Rules, in particular the Workflow rule Assign form, see Assign form for details

    ​ b) Using Quick actions, see Form Quick action for details

    ​ c) Creating form owners when creating or updating a process design, see Creating form owners for details

  2. Only form owners can edit a given form when it is a current form in a process flow by default. Any other user with access to view the form will see it in read-only mode.

So what is form owner? A form owner is assigned when a form is created in Kianda Designer. Form owners can also be added to a form design at a later stage by editing the form. Only the form owner will be able to edit current forms in process instances (records), see below.

Changing form access

The default owner is the person or group that the form is assigned to using the default owner field in the new form dialog box as shown above. By default, only this person or group can edit the current form in a process instance. All other users can only view forms in read mode. The next section details how to Change default owners.

It is also possible to allow other users to have edit access to forms using the Assign rule and Quick actions.

Changing default owners

  1. Using your Administration or Design business process role, go to Administration > Designer > select a process > select a form in the process.

  2. Click on the form so the Edit/Pen button appears in the form name.

    Select form to edit

  3. Then click on the Edit/Pen button itself to edit the form.

  4. An Edit form dialog box opens which has the same layout as the New form dialog box seen in Creating form owners above.

    Edit form dialog box

  5. Here you can change the default owner choosing from Users, Groups as before.

1.2 - Form display modes

Remember there are three principles to consider when working with forms:

  • Display mode: 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 current 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.

New form dialog box

New form dialog box

These properties can also change dynamically as a result of rules being applied, see Rules.

Setting display modes statically

Remember forms in process instances are either in edit mode meaning they can be edited/changed or read mode where the details are visible to form users but cannot be changed. The actions below refer to making forms editable so if the actions below are not used, then the forms are in read mode. The actions below refer to static or fixed use, set when the form is first created or updated at a later time.

  1. Forms in process instances will be editable for Default owner(s), that is the form owners defined when the form is created, or a form is edited. Form owners are defined in the New form/Edit form dialog box, shown in part 1 of the image above. When a process instance runs, the form owner can then edit the form in that instance.

  2. By default the first form in a process becomes the current form, so only this form will be editable. However if several forms are activated with the current form when the form is created or edited in the New form/Edit form dialog box shown above, then all forms in that group will be editable by the form owner in a process instance.

  3. By default the Submit mode for forms is Only this form meaning that when a process instance is running you can choose only that particular form can have details submitted or saved. Alternatively you can choose all forms in edit mode, meaning that several forms can have their details submitted or saved. For example if several forms are activated together and all are in edit mode then the details of all these forms can be submitted together in the database.

  4. Forms can be statically set to allow Quick actions including allowing editing. When a form is created or edited using the New form/Edit form dialog box, clicking on Enable quick actions allows you to statically enable:

    a) reassignment of forms

    b) editing of forms

    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.

    Enable edit action

    For c) custom actions, you can set your own custom action and create an action label against a particular form field. This means that the user(s) assigning 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.

Changing form display dynamically with rules

If you use the Form action rule called Field display mode, you can change how a field or form displays dynamically. For example you have a condition set that the display will change based on the condition being present or not.

When you add this rule, under Action you can choose a field or form and choose from Edit mode or Read mode.

Field display rule

For more information on this rule go to Field Display mode rule.

Other rules can be used in other ways to change process workflow and therefore how forms behave. For example using the Assign form rule you can assign a form to a particular user, making them the form owner, and therefore giving them edit access to the form.

What’s next Idea icon

To read more about form ownership go to Form owner. To read more about quick actions, go to Form quick actions menu.

1.3 - Form quick actions

The Form quick action menu will appear to designated users as a quick action menu option in the top right-hand corner of a form.

Depending on what type of quick actions are enabled and if you are assigned quick actions as a form user,, then you will see options when you click on the quick action button Quick action menu, for example to reassign a form to someone else, or to perform a custom action like signing off on a purchase order.

Quick action menu

How to get started

To enable quick actions, click on a process with Kianda Designer and then a form of choice so that the Edit (Pen) icon is visible.

  1. Click on the Edit pen icon to edit a form.

  2. In the Edit form dialog box, check the checkbox beside Enable quick actions.

  3. When you select Enable quick actions then you have three options to select:

    • Enable re-assign - allows a form in a process instance to be reassigned to a by a designated person/group
    • Enable edit - allows a form in a process instance to be edited by a designated person/group
    • Enable custom action - allows a form in a process instance to have customised actions associated with it, and these actions are assigned to a designated person/group

    Quick action menu

    Check the checkbox beside the desired action as necessary. Each option is further explored below.

Enable reassignment

When you check a checkbox for example Enable re-assign then you can click on the Ellipsis button Ellipsis buttonthen you can select Users, Groups and Partners who can be chosen to reassign the form to. There is also a checkbox to allow form owners to reassign forms to other users.

Re-assign action settings

Enable edit

This opens the Action settings dialog box, such as the Edit action settings box shown in the image below.

Edit action settings

  1. Choose from the options in the action settings dialog box:

    • Edit action users - select the Users, Groups or Partners who will use the action
    • Allow form owners - allows form owners to use the action
    • When editing auto hide form footer buttons - hides form footer buttons when users are editing forms in a process instance
    • Trigger rules on save - allows rules to be triggered when a form is saved/submitted. In this case, select the button name used as the trigger in the Save action field
  2. Click on OK when complete or Close to exit the dialog box.

Trigger rule quick action

Enable custom action

If you check Enable custom action users who have been selected using the Users, Groups and Partners option, will be able to perform a customised action on a form, defined using the dialog box within this section.

2 - Components

A process component acts like a reusable part of a process made up of various control fields and rules. You can reuse the component in your process designs to save you time and effort when creating each field and rule combination from the beginning. Within the component you can add all preconfigured control types and rules to match your needs, as well as customised field and rules found under Custom.

Creating a component will significantly speed up your process creation time if some of your processes demand the same fields and logic. For example if a lot of your processes have sections in common, for example a Personal Details section where a user needs to fill in their first and last name, email, job role, and phone number. To save process creation time, you can create a component with those exact fields and rules you need and then use the component in various process designs.

The component you create can be updated at any time. Once you publish your component it can be used in any process of your choice and any processes that already use your component will be automatically updated.

How to create a new component

  1. From the home page, navigate to Administrator > Designer.

  2. When you are in the Process designer screen navigate your mouse to the Idea icon button and click the down arrow.

    Idea icon

  3. In the dropdown menu click on Component.

    Idea icon

  4. In the Add new component dialog box, fill in the following detail:

    Idea icon

    • Title - represents the title of your component.
    • ID - represents the unique id of the component. Ensure that the ID entered here is unique across all components and processes.
    • Description - enter a valid description of the component you are creating.
    • Group - using this drop-down list, you can add your component to a existing group or create a new one.
    • Administrators - select the appropriate component administrators from , to read more about process and component administrators visit Process security.
  5. Click on OK when you are finished filling out the detail. You will be automatically moved to the component designer screen.

Editing an existing component

  1. From the home page, navigate to Administrator > Designer.

  2. In the Process designer screen, navigate to the folder (if used) where your component is click the Edit button Idea icon. Note that the type will state Component within the list of all processes and components.

    Edit component

  3. The Edit component dialog will appear allowing you to change some of the detail which include:

    • Title
    • Description
    • Group
    • Administrators
  4. When you are happy with the changes made to the details, click on OK.

Accessing an existing component

  1. From the home page, navigate to Administrator > Designer.

  2. In the Process designer screen, in the list of processes, components and folders, navigate to the until you see your component and click on the title.

    Edit component

  3. You will be navigated to the component designer screen.

Adding a component to a process

Once you publish a process it will be able to be included in your process design just like any other form fields.

Under the Design controls expand components then choose your component to include it in your process.