Modifying the eForm Definition
In addition to the Word template for your eForm, the eForm Definition contains many other properties. In the eForm definition, you can choose what processes will run when the eForm is submitted, how disabled or required fields will look, and much more. These properties can be found on the eForm Options tab of the Properties section of the eForm definition.
Typically, a process begins when a user opens a form, fills it out, and submits it. Process Director uses the “Automatically start this process after eForm is submitted” property to determine which Process Timeline or Workflow to launch. In the case of the Travel Expenses Request eForm in the sample project, submitting the form immediately starts the approval process that is modeled in the Travel Expense Approval Process Timeline.
eForm Controls and Fields
As mentioned in the last section, the eForm Definition also converts all of the controls that you placed on the eForm template into data fields to store the information that users enter into the form. Each of these data fields are mapped to their respective form controls. Just as the form controls have a set of properties that you can access in the Word designer, the data fields have properties of their own that are accessed through the eForm Definition. Many of the data field properties determine how the form controls will operate when the form is running. So, from the user's point of view, the terms "data field" and "control" are largely interchangeable, because the data field is so closely identified with the control.
There are two main types of controls/data fields: those that store data, and those that do not. Data entry controls like text boxes, check boxes, or dropdowns usually accept data input from the user, and that data is stored in data fields by Process Director. Container controls like sections or arrays do not store or accept data from users, but determine the look and feel or operation of the form. These two different types of fields may have very different properties, but there are a number of field properties that most form fields have in common.
The first common property is the ToolTip. The ToolTip property identifies the text that will appear in a callout box whenever the cursor is hovered over a control on the form.
The Friendly Name property is very useful for replacing field names, which cannot use special characters or spaces, into more easily readable names when they are displayed in Knowledge Views or in other areas of Process Director. For instance, you might have a field named "SubmissionDate". When this field is displayed, you would probably prefer that it be displayed as "Submission Date" or "Date Submitted". Using the Friendly Name property allows you to ensure that field names always display is a more readable form when presented to users.
The Readonly property sets whether the control is enabled or disabled on the form. A disabled control cannot be edited by the user, although the value may still be displayed. You can set conditions on this property to enable or disable this control when the desired conditions are met.
The Hidden property determines whether or not the control is displayed on the eForm. Again, conditions can be set on this property to determine when the control is hidden or displayed.
The Required property determines whether or not the user must fill out the field before the form is submitted. Once again, a field can be made conditionally required, based on conditions set in this property.
The Readonly, Required, and Hidden properties also share an important commonality, in that they are inherited. Inheritance is the ability of a container control to automatically incorporate, or inherit, the properties of its parent container control. The eForm is the highest-level container control, and every control on the form is a child control of the eForm. A Section control placed onto an eForm will inherit the properties of the eForm, while an individual control placed into a Section control will inherit the section's properties.
For example, if the Required property of a Section control is set to "True", then inheritance ensures that all of the controls contained in that section will be required. You can override this, however, by explicitly setting the Required property of a control inside the section to "False". If there is conflict between the Required property of a container control, and the controls contained inside it, the control property at the lowest level wins, and overrides the inheritance.
Fields that accept and store user input have a couple of properties in common that you will regularly use.
The Default Value property enables you to apply a specific value for a control in the absence of user input. The default value can consist of a value that you enter, or one of a number of values derived from system information in Process Director. As you can see from the example below, the Default Value property can be set to a value derived from a process, a form, a Business Rule, and much more. The Default Value is set exactly once, when the form is first opened.
Another important property to understand is the Event Field property, which can be set to "True" or "False" via a checkbox. If the Event Field property is set to "True", then an event will be fired every time the field is edited. An event is a trigger that can be used to cause Process Director to take other actions. Setting the Event Field property to "true" enables Process Director to detect when a change has been made to the field, and then respond as you direct. A common use of the Event Field property is to detect a change to the value of an event field, then show or hide a second field based on the event field's value.