Managing Forms

Creating Forms

There are 3 ways to create a Form within Agility Blue:

• On the Forms page, accessible via the vertical ellipsis menu, there is a button on the top right titled “New Form” (most common).
• On the Navigation Bar, under the “New” drop down menu, there is a menu item titled “Create a New Form”.
• While creating a Task, next to the “Available Forms” label, there is a “plus” icon that can be clicked to enter the “New Form” dialog.

New Form Dialog Window Input Fields

1. Name of the Form.
2. Allows you to copy sections and fields from another Form to use as a template.
3. A description of the Form to convey its purpose.
4. A category the Form belongs to. The list of Forms will group Forms into categories. When you begin typing, autocomplete will suggest similar categories.
5. Allows you to determine if the Form should show up in the list of available Forms on the Project Portal.
6. In the Form Builder area, one default section is started. Fields within a Form are grouped by Sections. Sections may have an optional heading. If a heading is not supplied, the system will supply a generic one when rendered (“Section 1”, “Section 2”, etc.).
7. Removes a section and its fields. When a Form contains more than one Section, directional buttons will show up here to allow you to change the position of the Section within the Form.
8. Allows you to add a new field to the Section.
9. Allows you to add a new Section to the Form.

Creating Fields

Fields are created by determining a Field type and defining the properties available for that type. The type of data that can be entered into the Field’s value editor during the creation of a Task is controlled by the Field Type. It is important to know or understand the restrictions and limitations each Field Type imposes in order to design a Form that works well with the workflow intent. For instance, creating a Field that requires a user to choose a Single Choice value instead of typing a value freely into a text box could help with ensuring that the correct value is always used for that field and eliminates the possibility of entering the wrong values or inconsistent entries.

New Field Card

1. Field Type Selector. Allows you to set the data type of the Field to one of the following:

2. Name of the Field.
3. Determines if the Field is required or not. When Users fill out the Form during the creation of a Task, all required Fields must have a value.
4. Determines if the Field is visible or not. If a Field is set to “Required” and “Hidden”, the Required property is ignored until the Field becomes visible. It is useful to make a Field’s initial state hidden if you plan to add a condition to the Field that alters the visible state based on the value of another field (See the Field Conditions section of this manual).
5. Removes the Field from the Section. When a Section contains more than one Field, directional buttons will show up here to allow you to change the position of the Field within the Section.
6. Optionally provide a default value that is initially present when filling out the Form. The type of input available for the default value is different for each Field Type. Single and Multiple Choice Fields do not allow a default value, and instead have a text input that lets you enter a single choice per line that becomes the data source for the Field.

Adding Conditional Properties to Fields

After a Form has been saved, Conditional Rules may be applied to that Form’s Fields. These rules give Users flexibility on how a Form is filled out and what a Form will ultimately look like when it is presented.

Field Conditions are not necessary to create great quality Forms in Agility Blue, but they can be a powerful way to collect and present the necessary information for Forms using conditional logic to control properties. Based on the values (or lack of values) that Fields hold, conditions can be set to alter the requirement, visibility, or even the values of other Fields.

In the context of Field Conditions, conditional logic means “If a condition of some other Field is true, then change the properties for this Field”. For example: “If the ‘Load Images Into Database’ Field is ‘Yes’, make the ‘Load File’ Field ‘Required’”. In this example, you would add the Field Condition to the “Load File” Field.

Edit an existing Form to access the Conditional Properties section of each field.

You add Field Conditions to a Field based on these requirements:

• You want this Field to become required or not required based on the value (or lack of value) of another field.
• You want this Field to become visible or hidden based on the value (or lack of value) of another field.
• You want this Field to change its own value based on the value (or lack of value) of another field.

To continue with our example above, since we want the multiple choice Field “Load File” to become required when the yes or no Field “Load Images into Database” value is “Yes”, we would click on the “Add a Field Condition…” link within the “Load File” field editor.

After clicking on the “Add a Field Condition…” link within the desired Field, you will be presented with a new window to define what the condition of the other Field should be, and what properties you would like to affect the desired Field.

The Field Condition window will initially only present you with the description of the Field Condition you are building and a drop down to select a Field. The description will update dynamically based on your selection and is displayed in such a way that is easy to understand when you are finished.

Under the “When the Following Field” drop down picker, choose a Field whose value will affect the properties of the Field you are applying the condition to. To continue with the previous example, we would want to select the “Load Images into Database” Field.

After a Field has been selected, the window will expand showing additional options.

The next question to answer is “Has the Following Condition”. This question is asking you about the condition of the value of the Field you just chose and the drop down selection is based its Field Type.

The following table lists the available value conditions for their respective Field Types.

The available values to select or enter for conditions other than “Any Value” and “No Value” will also be based on the Field Type. For example, the available values for a Yes or No field will only be “Yes” or “No” if the “Value is exactly” condition is selected.

To continue with our example, we will want to select the “Value is exactly” condition and choose the “Yes” value to satisfy our requirements. This action will cause the description to update to “When the ‘Load Images into Database’ field is Yes, do nothing.” We now only need to define what properties to change on our “Load File” field when this event happens.

Under the “Update these Properties” section, there are three property inputs that we can alter:

• Field Requirement. Determines whether the field must have a value when the Form is filled out and saved while making a Task. Note that if a Field is required and hidden, the Field Requirement is ignored. The available options are “No Change”, “Not Required”, or “Required”.
• Field Visibility. Determines whether the field is hidden or visible – useful for showing or hiding fields relevant to various selections while filling out the Form when creating a Task. The options are “No Change”, “Hidden”, or “Visible”.
• Field Value. Determines if the Field should be updated with a specific value. The options are “No Change” or “Update Value”.

Continuing with our example, we need to change the Field Requirement input to “Required”. Doing so changes the description to “When the ‘Load Images into Database’ field is Yes, make this field Required.” This will now make it so that if the person filling out this form were to select “Yes” for the “Load Images into Database” field, it would trigger an event to alter the requirement property. Visually, while filling out this Form, the Field would have an orange asterisk next to the Field label indicating that the Field is required when this event occurs.

Understanding Conditional Properties

Conditional Property events can only be triggered by a User. This means that a condition cannot be triggered by the initial state of a Form, nor can it be triggered by a value change from another Field as the result of a separate conditional trigger. The User filling out the form must make a change in a Field’s value in order to set off an event.

Forms that have conditional triggers have special icons by their Field labels indicating that the Field may affect, or be affected by, other Fields. This is to give awareness to the User filling out the Form that something may happen while addressing those Fields.

Conditions do not revert values if they are not true. This means that if a condition is met, the affected property will change to the desired result. However, if after this happens, and the value is changed again to a value where the condition is not true, nothing will happen and the property will remain in the changed state from when the condition was true. In order to achieve this “on/off” style of reverting values, you must create two conditions where the rules of the second condition are opposite of the first.

More than one condition can be added to the same Field. Each condition is treated as an “OR” style connector.

More than one property can be affected by the same Condition. Meaning, you can change the requirement, visibility, and value at the same time.

If more than one condition alters the same Field property, the most recently created condition will determine the final property change.

As of now, conditions cannot be edited - only created. If a condition needs to be changed, delete the old one and create a new one.