Process common fields


Within every process, there are forms and forms contain fields. The fields you add in, such as a text box, list or button are called Design fields. For example as seen in Field properties you can change properties for a textbox field, like making the field Required and Visible for form users as shown in the image below for the Training Request form field called ‘Employee Name’


These design fields are also apparent when creating dashboards, for example list widgets. In the example below we can see the Design fields highlighted that are found in the Training Request form. These highlighted fields like Employee Name will appear in the list widget in the dashboard.

Example of design fields in a list widget

Clicking on List fields in list widget shown above will show all the fields that will appear in the widget.

List field example

Note that non Design fields are also included in the fields to display, namely ID, Process Name and Modified fields. These fields are part of the set of Common fields associated with all Kianda processes.

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 for example ‘'.
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.

What’s next Idea icon

  • To learn more about design controls that can be applied to forms go to Controls.
  • To learn more about how common fields are displayed in dashboards in a list widget go to List widget.