Types of forms
An administrator can create forms that serve as part of a unique workflow solution. Form types include the following:
- Regular forms
- Join forms
- Display-only form
- View and Vendor forms
- Inline forms
These forms can be customized using form views, as explained in Defining and managing form views.
Regular forms are generally the main forms of your applications. Within the AR System server database, AR System builds and manages tables to store the data displayed on your forms. When you create a regular form, you see the eight core fields (see the following figure). All regular forms contain these fields. For information about core fields, see Core fields.
Join forms are composite forms that consist of fields derived from other existing forms. A join form can be useful in the following situations:
- When you need to produce reports from data that exists in more than one form.
- When data is stored in multiple forms and you want to display the data in a single form.
- To eliminate the need to enter the same data into multiple forms.
A join form in AR System is similar to joining tables in a relational database. A join form uses searches to combine fields from two forms based on join criteria (see Join forms). The data in a join form comes from the database tables of the forms that make up the join form.
When you create a Join form you can define fields from both forms that are being joined. You cannot use keywords in a Join form condition. You can use fields or static values to define Join form conditions.
After the join form is created, it behaves similarly to non-join forms. Users can submit data for creation or modification, report from it, select entries from it, use it in workflow requests, define workflow on it, and so on. From the user's perspective, there is no difference between join and non-join forms.
Display-only forms are not represented in the database, so they do not have any requests and they do not contain the core fields. You can use display-only forms in various ways:
- Control panels—These provide an efficient way to organize and present users with specific tasks or objectives.
- Dialog boxes—These enable you to reuse specific groups of fields in a variety of ways. For example, you can create an employee information dialog box that contains generic fields (such as name and address) that multiple forms and applications can use.
- Entry points to other forms that contain data—You can add an OK or a Continue button to a display-only form to cause an active link to transfer data from the display-only form to the primary form and then submit a request.
You can create display-only forms for various purposes. For example, you can create display-only forms that work in New mode and Search mode in a browser. For more information about using a display-only form as a control panel or dialog box, see Creating display-only forms.
Be aware of the following issues when you create a display-only form:
- Unlike regular forms, display-only forms do not have the following form properties:
- Results list fields
- Status history
- By definition, all fields that you add are display-only.
View and Vendor forms
View and vendor forms allow users to access external data sources outside of AR System . These forms can be used to:
- Execute workflow on creation and modification of data when the changes are performed using the view or vendor form.
- Execute escalations on external data.
- Access external data to populate search style character menus or table fields.
View forms allow AR System to point to and access data in an existing database table created outside AR System . The table can be located on the same server or in any other database server accessible from the current AR System database server.
Vendor forms allow AR System to access arbitrary external data sources through the use of an AR System Database Connectivity (ARDBC) plug-in. ARDBC plug-ins enable AR System to interface with external data sources such as LDAP directory services, legacy systems, spreadsheets, text files, or database tables. A vendor form provides for easy integration with external data, without replicating the data. For more information, see Creating vendor forms and View forms.
Inline forms allows you to:
- Automatically load embedded forms on the view fields when the container form is loaded.
- Load an embedded form on a view field based on user action, such as, selecting a console, loading an incident into the view field.
- Replace an existing embedded form on a view field by another form.
You can use inline forms to:
- Reduce the number of open windows.
- Provide an appearance of a single form.
- Improve performance.
You can open forms that are embedded in the view fields as inline. When using inline forms in your application, consider these behaviors:
- Forms load into view fields using an active link Open Window action.
- Child forms load faster.
- The pop-up windows appear at the center of the entire page and deactivate the entire parent window regardless of which embedded form triggered it. The view field boundaries do not cut or trim the pop-up windows.
- A single prompt bar appears for the entire page, including when workflow in the embedded form executes a message action with the prompt bar option.
If you want to load an inline form on a view field that was loaded earlier in a different view, you must clear the cache and log on to Mid Tier again.
You can set the Inline Property to an AR System form while defining a workflow using Open Window action. For more information, see the following sections: