InfoCapture Workflow

The workflow section of a form is completely optional.

It can be used to restrict who is able to change the status, what they are allowed to change it to and at what point during the lifecycle of an issue, which may or may not be required for every form your company needs.

It can also be used to restrict the options that appear in certain fields e.g. select fields under certain conditions.

The workflow is managed through tables, with the rows determining which field conditions to use, the columns determining which project roles they apply to, and the cells within the table determining what the new values can be.

It's similar to the tables used in field visibility sets - except instead of having 'Allow/Deny/Not Set', it is instead the allowed values of a form field.

 

An example workflow

The example table below lists the statuses each project role is permitted to change to, at each stage.

 

Project Role: Admin

Project Role: Managers

Project Role: Users

Status = New

All

Pending Info, Approved, Rejected, Canceled

Cancelled

Status = Pending Info

All

None

Info Provided, Canceled

Status = Info Provided

All

Pending Info, Approved, Rejected, Canceled

Cancelled

Status = Approved

All

Rejected, Cancelled

Cancelled

Status = Rejected

All

Approved, Cancelled

None

Status = Canceled

All

None

None


In this table, the cells down the left column are field condition sets. The top row details the project roles.

Look at the row starting Status = New. 

A field condition that says this should apply when the Status has reached 'New'.

If that's true then anyone in the admin role can change the status of the ticket to anything else. 

Anyone in the 'Managers' role, they are allowed to move the status onto 'Pending Info', 'Approved', 'Rejected', or' Cancelled'.

Anyone in the 'Users' role, is only allowed to move the status to Cancelled.

This is repeated a further five times, one for each of the remaining statuses.

The result is a table using six field conditions, one for each status that has determined rules about who can change it, when and what they can change it to.

 

Another example is shown in a form for ordering T-shirts.

The field conditions used will be custom to fit your form's purpose, but the steps to set it up remain the same as below.

 

 

Adding a workflow

Go to Admin > Infocapture > Your Project > Workflow

From the dropdown list, select the form field you wish to control the options for.

Note that 'Status' and 'Assigned to' are available options.

Once selected, click 'Add Rule For This Field'.

 

Click into each role, and then highlight the options you want to give them rights for.

Any option not highlighted is left out, and only those selected will appear to the user.

Click on all roles that are appropriate and select the options you need.

Once ready, to save changes click 'add/change rule' and the workflow table on the front end will update to show the new rules.

 

Field Condition Set: Choose the Field Condition that should apply to the rule.

Role name: Pick the role to apply the rule. It's likely that you'll need to go through each of the roles in this list separately, deciding for each what they should be allowed to do.

Allow changing field's value to: For the currently selected role, choose the options that should be allowed when this field condition applies. (Hold the CTRL key to select multiple options)

Allow changing status by groups: Use this if you need more than one person to approve a change. See below for more information. (detailed more in the next section)

Note: If you are adding a workflow rule to a user picker, such as the 'Assigned To' field, you will need to pick individual users. However from version 8.5 (Sept 3rd 2018) onwards, you will be able to pick groups, roles, and project roles.

 

The video below outlines how to change what each project role can do in a workflow for Status:


The 'Admin' role was given the ability to move to all statuses for the first condition.

The 'Manager' role was given additional rights to move to 'Cancelled'.

The 'User' role was also given the right to move to 'Cancelled'.

 

Group approvals

The second box that appears when creating workflow rules is also optional and it is used to set group approvals.

 

Any group approvals set appear in bold in the workflow table:


This gives the following approval table on a submitted form (Scroll down in the ticket to view)


There are three possible approvers in the 'Admin' role so they are listed.

For my profile, I am able to click 'Approve' on 'Billed' (which is why I am now given the option to 'refuse approving') but I have not given my approval for the status to move to 'Received' or 'Paid'.

If Demo and Michael also come to the form and approve billed or received, the form will then automatically change status.

Group approvals can be handy in some situations, but you may not need to set it up on every form.

 

Recommended next article:
Notifications
 

Created on 10 August 2018 by Hannah Door. Last modified on 22 February 2024

Was this helpful?  

Share