If checked off, this form field will trigger an event when interacted with. Events can be used to update the form by triggering Custom Tasks or custom form scripts.

If checked, this field will synchronize values will all other form fields that have the same names but are on different forms with different definitions in the same Process.  When the value of a synced form field is updated, the value will be synchronized with all other form fields with the same names in the Process, whether or not those form fields are also marked as synchronized. However, if a form field’s value is updated and that form field isn't marked as a synchronized field, it won't update the values of other fields with the same names in the process, even if those fields are marked as synchronized.

If a column in an array is marked as synchronized, the number of rows and the content of that column will be synced with all other arrays in the process containing a column of the same name. This means that adding and removing rows in an array with a synced column will also add and remove rows in other arrays in the process with columns of the same name. Because synchronized array fields are so powerful, caution is recommended when using synchronized fields with arrays. Instead, we recommend alternatives, like the Copy Form Data Custom Task.

Prior to Process Director v4.04, field synchronization would only occur on form submission, but not when the Form was saved via a Save button, and not submitted. From v4.04, synchronization will occur any time the Form is saved, even if the Form isn't submitted.

When moused over, the form field will display the text entered into this text box as a tooltip.

Because Form Field Names have some unavoidable constraints in how they are named, the field names may not be particularly friendly for users. The Friendly Name property enables you to configure a different name that will be displayed to end users in places like Knowledge Views, without worrying about the constraints that you have to adhere to when you place a field on the form template. For users of Process Director v5.12 or higher, using a Camel Case value (e.g., MyField) for the field's Name will automatically create a Friendly Name based on the Camel Case Name (e.g., My Field).

This enables you to fill a Dropdown field with the content from a Dropdown Object. You can link multiple dropdowns to Dropdown Objects, which allows you to reuse Dropdown Objects in multiple forms.

Setting the data type will enforce that the form field accepts data formatted as the appropriate type. The Data Type can be any of the following:

• Text: this option allows for arbitrary text to be entered into the form field

• Examples: “foo”, “bar”

• Number: this option ensures that the form field contains a number (either with or without a decimal)

• Examples: “10”, “9.75”

• Date: this option ensures that the field contains a date. Dates must be in a format that can be interpreted by .NET.
• Date/Time: this option ensures that the field contains a date and time. DateTimes must be in a format that can be interpreted by .NET.
• Time: this option ensures that the field contains a time, which can be in any of the following formats. Times must be in a format that can be interpreted by .NET.
• Currency: this option ensures that the contents of the field can be interpreted as an amount of currency

• Examples: “22”, “22.32”

• Integer Only: this option ensures that the field contains an integer. It also allows you to specify a minimum and maximum value that the integer can be.

• Examples: “1”, “394221”

• Email Address: this option ensures that the field contains an email address. As a user warning, email addresses shouldn't have any trailing spaces, or they'll be rejected as invalid. Process Director can only validate the format of an email address, meaning that it will ensure the email address has a format that includes an "@" and "." characters in approximately the correct locations in a text string, e.g., text@text.text. Process Director cannot otherwise determine the validity of an email address.
• SSN: This option ensures that the field contains an American Social Security Number, with or without dashes.

• Examples: “123456789”, “123-45-6789”

• Phone Number: This option ensures that the field contains a phone number. Most formats people usually use to type phone numbers will be accepted, as this data type will ignore most special characters, but match on specific digits and patterns.

• Examples: “(123) 456-7890”, “+1 123-456-7890”, “123-4FO-OBAR x 4321”

• ZIP Code: This option ensures that the field contains an American ZIP Code. The ZIP code can contain only five digits or all nine digits.

• Examples: “12345”, “12345-6789”, “123456789”

• Regular Expression: This option enables you to set a format for data entry for the field, e.g., a Canadian Postal Code format like "M5W 1E6".
• Concealed Text: Introduced in Process Director v5.12, this field type replaces the "Password" data type, and will hide the text in the field. Additionally, the behavior of the "Password" data type was changed to check the password strength according to the system settings and return an error if the password strength of the entered value isn't strong enough. This change will automatically convert all form fields that were previously configured as a Password data type to Concealed Text. Fields set to this type will display values with a set number of asterisks (****) when displayed in a Knowledge View, in a disabled form field, etc.

Changing Data Types

Occasionally, it may be necessary to change the data type of a Form Field. For instance, one common mistake implementers make is setting the data type of a field like a Zip Code to "Number", because the field contains only digits. The natural assumption implementers make is that, since the field contains only digits, it must be a number field. This is generally incorrect, since the best practice is that if you aren't going to do math on a field value it isn't a number. Moreover, treating fields like Zip Codes as numbers will cause them to sort differently (in numerical order) than they would sort if they were text (alphabetical order).

Often, problems don't become apparent until a number of processes have already been started, so you not only wish to change the data type for future instances of the Form, you also want to change the data type for past instances as well. Happily, Process Director enables you to make the change retroactive by following the procedure below:

1. Place the mouse pointer in the workspace tab area at the top of the page, and click the right mouse button. This will place the page in Debug mode, and a dialog box will appear notifying you that the mode has been changed. Click the OK button to close the dialog box.

2. Open Form Definition and click the the Form Controls tab. In Debug mode, the Form Controls Tab will look slightly different.

3. Click the Edit link to open the field properties dialog box for the field you'd like to change.
4. Change the data type of the field to the desired data type and click the OK button to close the field properties dialog box.
5. Click the Form definition's Update button to save the change to the Form Definition.
6. In the Commands column of the Form Properties tab, click the Update Old Instances link. A confirmation dialog box will appear.

7. Click the OK button to confirm the change, close the dialog box, and update all previous Form Instances to the new data type for the field.

An additional debugging option exists to convert existing form data from a text field into a number or date field, as appropriate. This is available in the troubleshooting tab in the IT Admin while in "debug mode" and is called "Update All Form Data to match Controls". This will fix an issue that arises when trying to generate SQL Views that include text fields that stored integer or date data. Earlier version of Process Director stored this data as a string. This option will transfer the data from a string field in the database into the appropriate number or date fields. This doesn't affect the usual operation of Process Director, and is relevant only when trying to include these fields in a SQL View.

For v5.32 and higher, an additional debugging option, which will appear next to form fields that are setting meta data attributes, will cause the system to update the category and attribute data on all old form instances using the form data on the instance.

Certain data types enable you to set a minimum or maximum value for the data the field will accept. This behavior will be different for text or numeric fields.

1. For numeric fields, setting these properties will limit data entry to the values that fall within the numeric range specified in the Min/Max properties, e.g., a Max value of 10 will only allow a numeric value smaller than or equal to 10 to be entered.
2. For text fields, the length of the text data will be limited to the values specified in the Min/Max properties, e.g., a Max value 10 will only allow users to enter a text string that is 10 characters long or less.

You can specify the default value of a form field. The Default Value dropdown allows you to select from a list of common default values, like Timeline Instance Names or the results of Business Rules. You can also specify the default be set to a custom value or result from a System Variable.

You can use this picker control to set a Meta Data Attribute from the Form Field.

For Case Management applications, setting the property will save the field as a Case Property, rather than a Form field. Case Management Forms often contain a mix of Form Fields and Case Property fields. Case property fields don't need to be replicated between forms. The Case Property is part of the shared data context that links all Forms to the Case instance. Once a case property is set, that property is available for any other Form in the case to get or set the property.

Some controls, such as radio buttons and dropdowns, can have both a value and a display string. Process Director will save both values in the case of those controls, and, by default, the case property returned will be the value of the control. The display string, however, can be returned via a Case system variable, using the syntax:

{CASE:PropertyName, format=string}

So, in any instance where you'll want to evaluate the display string, rather than a value, such as in a condition for a Business Rule, you'll need to evaluate the System Variable as a string, using the syntax above. If you select the case property from the dropdown menu in the Choose System Variable dialog, the case property will return the value, and not the display string.

This option gives you the ability to Enable or Disable a form control including the sections and collapsible sections. You may also Enable or Disable based on a condition using the Condition Builder.

This option gives you the ability to Show or Hide a form control including the sections and collapsible sections. You may also Show or Hide based on a condition using the Condition Builder.

This option gives you the ability to set the form control as required or not required including the sections and collapsible sections.

You may also set the form control as required or not required based on a condition using the Condition Builder.

Validation and required fields work together in an important way, because Process Director will only validate a field if it contains a value. Process Director will not validate a blank field, even a field that you want specifically formatted using a Regular Expression. Setting a field as required tells Process Director that the field must contain a value, and will impose validation on a blank field. The fact that you specify a data type or regular expression for a field doesn't indicate to Process Director that the field must contain a value. So, if you want to ensure that Process Director validates a field, even if it's blank, then the field must be a required field.