The process template editor is the central point of configuration for a form and its associated workflow.
The editor is accessed from the Process Templates Dashboard, either by clicking on an existing template or by clicking on the '+' icon to create a new one.
This section captures the basic attributes of the process template as well as the attributes to enable or disable the template for use in the system
The access section describes the individual users and groups of users who are able to access the process template.
View: Allows the user or group to search for forms based on this process template,
Edit: Allows the user or group to create forms based on this process template.
This section defines the fields to be displayed on the form along with their validations. Validations are the term used to define the rules for data entry, examples being: Text, Drop-down list, Date field and attachments. The platform comes pre-seeded with a list of validations however new ones can be created from the Validations Dashboard
Click on the '+' icon to add a new field
Use the bin icon to the left of the field to delete it. If forms have already been created with this process template, this will result in the field no longer being displayed on that form. An alternative to deleting the field is to make it non-visible. Refer to the section field status mapping for details on how to do this.
Changes can be made to fields in a template even after forms have been created using that template. This section describes the impacts:
New Fields: When existing forms are opened, the new field will be blank, even if a default value is specified. This is because the default value is only applied during creation.
Field Changes: The following table shows the potential impact of changing fields when there are existing forms using the template.
Deleting Fields: The field will be removed from existing forms.
Fields on forms using this template will appear in the same order as they appear here
Drag and drop the fields in order to reorder them.
Field section headers allow fields to be logically grouped together so that the presentation of the form can be elevated and improved for the end user. Sections can be collapsed and expanded by the end user to help when managing large forms.
Section headers are simply another Field on the Process Template and will utilise one of the storage columns in the database even though no data will actually be inputted.
To create a section header, click on the '+' icon to create a new field. Ensure the following attributes are set:
All other fields should be left as defaulted.
Table fields allow the entry of multiple input values for a single field stored in a tabular format. Table fields are appropriate for inputs with multiple values and multiple attributes.
Table fields are configured as another Field on the Process Template and will utilise one of the storage columns in the database. However the table data will be stored in a separate database table with referential links back to the form itself
Before a table field can be added to a process definition, a validation must have been created. Refer to the Validations Overview for additional details.
To create a table field, click on the '+' icon to create a new field. Ensure the following attributes are set:
All other fields should be left as defaulted.
Named Document Attachment fields allow the creation of a document attachment field with a specific label to represent a certain type of documentation such as a Business Case or a Ishikawa Diagram. Attachment fields are always presented in the documentation panels on the form input page.
Named Document Attachment fields allow tcontrol over the Field Status Map specifically for that attachment i.e. Making it visible, editable and/or required only at certain points in the process workflow
To create a table field, click on the '+' icon to create a new field. Ensure the following attributes are set:
All other fields should be left as defaulted.
The Other Documents field allows the creation of a generic attachment field for documents that may not necessarily be specified as input for the project. Typically such documents are referential material created by the work item owner and is deemed to be useful for storage against the work item.
The Other Documents field is typically always visible and editable but not required during any input status of the work item.
To create a table field, click on the '+' icon to create a new field. Ensure the following attributes are set:
All other fields should be left as defaulted.
The status ribbon is displayed at the top of the form. It is intended to provide the end user with a graphical indicator of progress through the lifecycle of the entity represented by the form.
To configure the status ribbon, click on the Status Ribbon tab in the process template editor.
Click on the '+' icon to add a new ribbon step. Broadly, it is recommended that these are aligned with the possible statuses for the form.
Drag and drop the ribbon steps up or down to reorder them.
Although it makes sense to order the sequence of ribbon steps so that it broadly aligns with the lifecycle of the entity, the sequencing itself does not determine the path taken by the entity. That path is determined by the workflow.
Click on the bin icon to the left of the ribbon step to remove it.
Status Ribbon Steps must be linked to a status (via the Field Status Map) to be displayed correctly in the tool
The ribbon can be configured to display a final completion tick when the end of the workflow is reached.
Configure the ribbon as described above.
Ensure the final step is marked as a gate by checking the 'Has Gate?' box.
Ensure there is an additional step at the end of the workflow to mark the process as Closed or Completed so the workflow recognizes that you have passed the final gate.
Field status mappings are used to define what the possible statuses are for a process template.
Once statuses are added to a process template they are then mapped in 3 ways
Statuses are mapped to the fields in the fields section and enforce field rules in terms of whether a field is displayed, editable and mandatory at that status. The purpose of this is firstly to ensure the correct attributes are captured at the correct point in the process and secondly to make the viewing of larger forms easier by limiting the fields displayed only to those which are relevant at that point in the process.
Statuses are mapped to the ribbon steps. When a form reaches that status, the ribbon displays accordingly
Statuses are mapped to a form page. This allows the form to be presented differently depending on the status. For example, at an approval status, a specific approval form is used.
During configuration of the workflow the statuses defined here are assigned to a workflow step. When a form reaches a step it assumes the status associated with that step which in turn drives the field rules, the display of the ribbon and the form page.
In the status mappings tab, click on the '+' icon to add a status column. A new column is added to the right of any existing statuses. All forms start with a 'Not Submitted status which defines the rules during submission.
Once the new column has been added there will be 3 blank drop-down fields:
Form Page: The top drop-down selects how the data should be presented when viewing the form at this status. The most common selection is 'Forms'
Status: The second drop-down selects the status from a list of possible statuses. If there is no suitable status in the list then a new one can be created in the Workflow Statuses Dashboard.
Ribbon Step: The third drop down selects the ribbon step. These are the steps defined in the status ribbon tab.
Once this is complete the status has been added to the process definition, mapped to a form page and to a ribbon step.
Once the statuses have been assigned to the process template, the field dependencies should be defined.
For each status define which fields should be displayed, which should be editable and which should be mandatory.
When a field is marked as being mandatory at a given status, the field will be marked as required once it reaches that status and cannot be moved to another status without the field containing a value.
In the field status mapping tab, click on the bin icon to remove the assignment of the status from the process template.
This process does not delete the status, it simply removes the association between the status and the process template.
All process templates have a workflow. The workflow represents the digitization of the business process that an entity follows from initial submission to the point of closure.
All Process Templates will automatically generate a default workflow with a start and an end step upon creation.
Workflows include steps where a person (or persons) are required to make a decision (for example an approval), routing steps based on values in the form fields, automation steps (for example to automatically create a baseline following approval) as well as steps to manage paths running in parallel.
Clicking on the workflow tab in the process template editor brings up the workflow editor
The workflow editor is a graphical interface allowing workflow steps to be added along with the transitions between steps
At a high level, the steps to building a workflow are:
Add the workflow steps to represent the business process from creation to closure
Edit the detailed settings for each step. These include defining the status the workflow should have when it reaches that step, defining who can act on a step (if it is a decision step), whether any email notifications should be sent out to inform users of progress or to inform them that a decision is required from them.
Define the transitions between the workflow such that there is a path from beginning to end.
When a process template is initially created a simple workflow is created with a start and finish step. The workflow must be fully configured before the form can be used.
Refer to the Workflow Configuration guide for full details about configuring the workflow.
A process template can be deleted provided that it meets two criteria:
It is not a system process template. This is identified by the 'System Entity' checkbox being ticked on the Info tab.
There are no forms (open or closed) that use this template. Any previously created forms must be deleted before deleting the template.
To delete the template click on the drop-down next to the 'Save' button and select 'Delete'. If there is no 'Delete' option, then the template cannot be deleted.
Process templates can be created as a copy of an existing template. This is often a much quicker way of building a process template. Copying is also the recommended approach to creating a customised version of a standard template as it ensures that fields from the Standard Configuration ae included.
To copy a template, navigate to the Process Templates Dashboard and click on the template to be copied.
Click on the drop-down next to the 'Save' button and select 'Copy'. A name for the copy will be requested.
An audit trail is maintained of changes to a process template. It is possible to restore to a previous version of a template.
In the process editor, select the 'History' tab. The list of changes to the template are displayed. The line at the top represents the current version and has the text 'This version'.
To revert to an earlier version identify the version to be restored and click on 'Restore'. The template is restored to that point in time and is marked 'This version'. All other versions are still retained including the most recent one (from which restoration was made).
Base Templates: Base templates ensure that your new process template will have the correct standard fields, mappings and storage for any data points that are utilised throughout the system. This will minimise effort and impact during platform and template upgrades.
Process Template Name: Give meaningful names to the process template so that end users can easily identify the type of form they will be creating.
Hide from Search and Create: When opting not to show a process template in search or create, it does not mean the process template is de-activated. It simply means it isn't included in general search or create pages. It can still be created or found through various configurable methods. This is great for creating restricted process template types such as NDA forms.
Form Field Tokens: By keeping form field tokens in a certain format such as block capitals and replacing spaces with underscore characters, it makes it easier to reference by the system. An example is when writing queries, it is easier to reference the token "FORM_FIELD" than it is "Form Field: "
Field Section Headers: Use field section headers to guide an end user during input. Grouping similar or related fields together will make the end user experience much smoother.
Reorder Field Status Mapping: Reordering the field status mapping columns does nothing with regard to process workflow or status ordering. It is purely a visual aid when configuring the status map. By placing columns with similar mappings together it makes it easier to keep track of which fields are ticked and which fields are not.
Editable but not visible: If a field is marked editable but not visible then it will not be displayed on the form.