Form Setting

Every document created has a unique Form Setting as a base. Form Settings are used to arrange and adjust related sections and fields into one unique form that lets you record, outline, and represent inserted data in the format and style configured by its Form Setting.

Remember the following about Reliance forms:

1. Every created document has a unique Form Setting as a base.
2. Every form is unique and has one main table. A primary key is defined for the main table, which will be used as the document key (this defines the document's uniqueness). Users cannot create the main table of the form but can design the form.
3. Forms are deployed if required when they are saved. In this case, the components of the form will be deployed as well. The form will be deployed on the database when required once you save the Form Setting.

All scripting fields are of script editor type. They support the code intelligence autocomplete. They format your script in standard syntax as you type. At any time,  you can validate your code against the supported ETQScript and Pythonscript syntax to avoid formulas run time errors by clicking Validate on your script field editor.

Disable a Form

Select the Disable option in the Basic tab of the Form Setting to disable the Form.

1. Disabled forms will not appear in the [New Document] menu of the related application. If the disabled form is the only available form in the application, the New Document menu will be hidden.
2. If the disabled form is an activity, it will not appear within the list of activities that can be created in the phase where the document resides.

Activity

When you create an activity, the Activity option will be selected in the Form Setting. This will show the Parent Forms field in read mode and hide the following options:

1. No Workflow
2. Read-Only
3. Not available in the new document menu

Set a Form as No Workflow

1. Select the No Workflow option in the Basic tab of the Form Setting to prevent the form from being associated with a workflow (e.g., the Employee Profile in the Training Application). This option is by default checked in the Form Setting upon creation.

The No Workflow option cannot be selected while the form is already associated with one or more workflows.

1. Upon selecting the No Workflow option, the following fields are shown within the Basic tab:

Notification Email Body: Using ETQScript Editor, enter an ETQScript formula that retrieves a text in the body of the email sent to the user if the document is non-workflow.

Notification Email Subject: Using ETQScript Editor, enter an ETQScript formula that retrieves a subject for the email sent to the user if the document is non-workflow.

Activities: The activities to be created from within this form from the list of all activities that are related to the parent application.

Hide the Form in the New Document Menu

Forms are usually created from within the application's toolbar using the [New Document] action button. Some documents can be created from within other documents. In this case, the ‘Not available in new document menu’ option in the Form Setting under the Basic tab should be selected to exclude the document’s availability in the list of documents you will get when clicking the [New Document] button.

If a form is selected in the Dual Linking Forms field, this form will appear in the new document Dual Linking dialog even if the Not available in new document menu checkbox is checked.

Set the Form to Appear in Read-Only Mode

Select the Read-Only option to make the form appear in Read-only mode. The Dual Linking Forms, Validate Required Fields, Numbering, and Office Integration Templates fields and sections will be hidden in the Form Setting when this option is selected.

Set the Form Display Name

Enter the form's name that will appear to the users in the Display Name field in the Form Setting under the Basic tab.

Set the Form Setting Location Security

Set the locations so that only administrators can edit this setting. Locations will be selected by default if configured in the User Profile.

Validate Required Fields on Certain Action

By default, all required fields and fields that are validated will be checked for validation whenever any of the following actions are performed: Save, Send Forward, Send Back, and Void. To enable/disable the validation when these actions occur, select the related checkbox. The On Send Forward option will be selected by default.

Validating required fields only works on editable fields when the user submits the document from within the document itself. As a result, required fields will not be validated when any Global Routing options are used.

Validation options work as follows:

1. On Save: Validating required fields and validation formulas will be effective when using [Save], [Save & Close], and when switching the document to Read-only Mode.
2. (Typically, non-workflow documents are validated on save.)
3. On Send Forward: Validating required fields and validation formula will be effective as soon as the document is routed forward to the next phase.
4. (Typically, workflow documents are validated on sending forward.)
5. On Send Back: Validating required fields and validation formula will be effective as soon as the document is routed to a previous phase.
6. On Void: Validating required fields and validation formula will be effective as soon as the document is voided.

Set how the Documents will be Numbered

Document numbering can be configured through a Form or Workflow Setting. Configuring numbering through Form Setting will assign the same numbering format to all types of documents or the same sets of numbers will automatically be assigned. The Workflow Setting configures the numbering for each document type separately. If the document's numbering is configured in both the Form and Workflow Setting, then the Workflow Setting's configuration will take precedence. Additionally, if some values are missing in the Workflow Setting, these values are considered from the Form Setting.

The available formats to be applied to the numbers from the Format field are as follows:

1. Manual: This format displays the Document Number field in Edit mode where the user manually enters the designated number.
2. Sequential: This format displays the Document Number field in Read-only mode and has the system compute and assign documents a unique, sequential number as they are created and saved. Upon selecting the Sequential format, the following fields are displayed:

Prefix: It is optional to define a prefix to be added to the assigned number. For example, the prefix PRF- can be specified to be displayed with the numbers assigned to documents; for example, the assigned number will be PRF-10.

Suffix: It is optional to define a suffix to be appended to the assigned number. For example, the suffix -NY can be defined to be displayed with the numbers that will be assigned to documents that are created in ‘-NY’. As an example, the assigned number will then be 10-NY.

Digits: The maximum number of leading digits should be determined. The default value for this field is 5. For example, if the numbering Digits field is set to be 5, and the assigned number is 10, three zeros will be added. The resulting number will be 00010.

Starting Number: The starting number should be defined here. The default value for this field is 1.

1. Maintain a single sequence for all documents created regardless of the prefix and suffix: Selecting this option allows single sequential numbering for multiple workflows associated with one Form. Note that the Digits and Starting Number fields will be hidden within the corresponding Workflow Settings having this option enabled.

Set the Audit Trail Options

The Audit Trail feature is designed to automate the process of monitoring and tracking changes and updates performed on the fields within a document. The log will allow you to see how, when, and by whom the changes were made through a Field History dialog. Audit Trail in any of its supported formats is an essential requirement for cGMP. 

The "Comment History" option is selected by default in the "Format" field. The available Audit Trail Format options are license dependent as detailed below:

1. None: This option is available regardless of the license type, i.e., 21 CFR Compliant, Audit log, or neither. This option disables the usage of the ‘Electronic Signature and Comment History’ section and disables the Field Tracking. If this option has been set while the existing documents include comments records in the History section, these records will be kept, but new records will be disallowed.
2. Comment History: This option is available regardless of the license type i.e., 21 CFR Compliant, Audit log or neither. This is the default option of the Format field. It allows automatic records in the History section only if the ‘New Comment’ field includes comments. The records are logged after saving the document using [Save], [Save & Close], or routing the document. In addition, a record is added to the History section when routing the document regardless of whether there are comments in the ‘New Comment’ field or not. This option does not allow the Audit Log.

The "Make comment history editable" checkbox appears when the "Comment History" or "Audit Log" option is selected. When checked, you will be allowed to edit the comment text after being moved to the comment history section.

1. Audit Log: This option is available when the License type is 21 CFR Compliant or Audit log. This option allows automatic records as the ‘Comment History’ option does.  It creates records when saving the document or routing the document regardless of whether the comment field is filled in or not. This option also enables the Field History feature to track changes done on individual fields.

When this option is selected, the following fields show up:

Include the following fields: To track certain field(s), this option should be selected and field(s) to be tracked should be specified in the "Fields to Include" field. If the Fields to Include field is left empty, then all the form fields will be tracked.

Exclude the following fields: To exclude a certain field(s) from being tracked, this option should be selected, and the field(s) to be excluded should be specified in the Fields to Exclude field. If the "Fields to Exclude" field is empty, all the form fields will be tracked. The field of System Sections is excluded by default, so they will not be included in the Field History Report.

1. Force Authentication: The Force Authentication option is available only if the License type is 21 CFR Compliant. When Force Authentication is enabled for logging changes and Field History, an authentication dialog will be launched when one of the specified actions is performed within the document. The document will be validated before launching the Login Page, and an icon will be shown in the Comment History section of the document. 'Yes’, will be displayed under the e-Signature column within the Field History report indicating that the user has electronically signed off changing fields’ values. You can also add a signature meaning to the authentication dialog.

When you select the "Force Authentication" option, you will complete the fields displayed for "Audit Log" option in addition to the following the fields, in case you are configuring a Workflow Form:

Authenticate on every save: When this option is selected, the Force Authentication will be required each time you save the document using one of the following actions:

Save

Save and Close

Creating or opening Office Integrated Documents

Any action that saves the document such as Print PDF, and if these actions were performed on a document while it is being displayed in read-mode, the Force Authentication dialog will not be displayed.

Authenticate only when routing: This option should be selected if Force Authentication should be enabled only when routing the document from one phase to another.

Authenticate when routing in the following phases: This field is used to specify which phases will be authenticated when the document is routed from one of them to the other. (I.e., the phases in which Authentication will be forced and activated when routing the document from it). For example, when you select the 'Approval phase', force authentication will be activated each time a document is routed from that phase to another one. Leaving this empty field means that Force Authentication will be required on all phases related to the current form each time you route the document using one of the following actions:

Routing the document (forward or back)

Voiding the document

Disable Authentication on Send Back: This option is used to disable the Force Authentication feature when a document is routed backward.

Update Office Integration electronic signature field in the following phases: This field is used to activate and function the ‘Electronic Signature’ section. Suppose the document is routed from any of the phases specified in this field. In that case, the ‘Electronic Signature’ section and OI attachments will be updated to show signatures presenting the document authenticity as being approved. The options of this field are as follows:

The options will include the phases of all workflows connected to the Form Setting. Archive phases are excluded.

If the 'Authenticate when routing from the following phases' field is filled in, the options of this field will be filtered to include only the values filled in the 'Authenticate when routing from the following phases' field.

Notcie That! The "Audit Log" or "Force Authentication" options should be selected in the "Format" field to enable the Field History feature. When this feature is enabled, the [Open Field History] option will be added to the Document drop-down list menu in the document's toolbar. Selecting this option within the document opens the latest changes performed within the fields of the document.

Set the Capturing Options

Enable capturing the content of the document (All Tabs) in an attachment field

The Capture as PDF feature provides an additional way to record the changes in history for documents created based on a specific form during each of its phases. It can be triggered when the document is routed to specific phases or when the Capture as PDF action is clicked. A copy of the document (All Tabs) is captured on a PDF file and saved in a specific attachment field.

To configure this feature:

1. Select the Enable capturing the content of the document (All Tabs) in an attachment field option.
2. Select the attachment field, which the system will use to attach the Captured PDF, from the Attachment Field list of all attachment fields available in the parent form.
3. Select the phases which will trigger the capturing when the document is routed to them in the Capture as PDF when routing to the following phases list of all phases in all of the form’s workflows.
4. Write an EtQScript formula in the Generated PDF File Name (EtQScript) to use as a title for the generated PDF file. You can leave this field empty to use the document title for the generated PDF file title.

Include document related activities of type

Enabled activities up to one level are available for selection within the Include document related activities of type field, excluding system activities (Change Requests, Review Records and Obsolete Requests).

The system will capture only the activities that the user assigned to the document during the capturing process has access to.

Include PDF attachments in the following fields

This field allows selecting Attachment fields within the Form (including Subforms), where PDF files attached to these fields will be captured into PDF file along with the main document.

Warning: Selecting the Attachment field that includes the captured PDF file in the Include PDF attachments in the following fields field will exponentially increase the captured file size due to including the previously captured files in the newly captured one (redundant data).

Enable capturing field history as PDF in an attachment field

This option is not supported in this version.

Document Form Title

The Document Form Title is a key feature used to identify forms within the system. This title appears on various pages, helping users quickly recognize different documents at a glance.

Where is the Document Form Title displayed?

If configured, the selected value in the Document Form Title will appear in the following areas:

In the Homepage:

Calendar widget:

View All dialog > Title column.

Assignment widget:

Assignment card.

Assignment card > View All dialog > Title column.

Date Range widget:

Overdue Items > View All dialog > Title column.

In the Application page:

My Assignments view > Title column.

How do I set a Document Form Title?

Go to the Basic tab of the Form Setting.

In the Document Form Title field, choose one of the text fields available on the form.

Tips:

This list may be empty if you are creating a new form setting and have not yet added any text fields to it.

Choose a text field that accurately represents the content of the form for better identification.

Click Apply & Close.

Notes:

The Document Form Title field is a promotable configuration.

When a user creates or updates a document using the import feature, and the Document Form Title field is configured in the related form’s Form Settings, the system displays the selected field value as the document title in the following locations:

My Assignments view

View All dialog accessed through the Assignments widget and Calendar flyout card or the Overdue Items action

Assignment and Calendar cards on the Homepage

Set the Form Access

Determine the Form Setting’s Accessibility through the Access Control tab. By defining a document’s Allowable Authors, Managers, Editors, and Readers for the documents created based on this form, you can control who has access to these documents. If the document's reader is not defined, the location Security or Additional Security fields will control the document's accessibility for the user with reader access.

When this section is filled out and a new document of this form type is created the Managers, Editors, and Readers fields under the Additional Document Security section in the created document will be filled-in with the specified values in the Form Setting.  

1. Allowable Authors: This option controls only the creation of documents.  It determines the Application’s Authors, who can see the [New Document] action within the application. It does not control the reading or editing of documents.

Only names of Application Authors listed in this field will be able to create the corresponding document of that form.  Only allowed authors will be able to see the form name in the list of the New Document menu. If this field is empty, all application authors will be able to create documents based on that form.

Even if their names are not listed in the ‘Allowable Authors’ field, Application Managers will be able to create documents of any workflow type and based on any form. Application Readers will never be able to create documents, even if their names are listed in ‘Allowable Authors’ field.

1. Default Document Managers: The users who will be assigned Manager Privileges for the documents of this form are selected here. Users with Manager Access on the form can modify the 'Additional Document Security' section and perform any function within the document, including all tasks allowed by other access levels. Managers can only route the document to another phase when the document is assigned to them. They cannot delete documents unless they are selected in the ‘Who Can Delete Documents’ field in the Application Settings. Leaving this field empty allows only the Application’s managers to update the "Document Security" section.
2. Default Document Editors: The users who will be assigned Editor Privileges for the documents of this form are selected here. Users with Editor Access can edit the document but cannot edit the Document Security section. The users listed in the document’s Editors field of the security section will not be granted Editor Access unless they are an Application Author or above. If the ‘Editors’ field is left empty, then no one will be able to edit the document except the Application Managers and users assigned to the document.
3. Default Document Readers: Users assigned Reader privileges for the documents of this form are selected here. Users with Reader Access cannot perform any functions on the document. If you did not define the document's reader, the Location Security or Additional Security fields would control the document accessibility for the user with read access.

The Form Setting’s Location Security

Define the accessibility of the documents created based on this form, if their Reader field is left empty, for users with reader access using Location Field of the Secure Documents Using section.  Select any of the following options:

1. All matching Locations: Only users who have one of their locations (primary or other locations) matching one of the document locations will be granted read-only access to the document.
2. All matching locations and lower locations: Only users who have their primary location or one of the lower locations matching one of the document locations will be granted read-only access to the document.
3. All matching locations and higher locations: Only users who have their primary location or one of their parent locations matching one of their document locations will be granted read access to the document.

You can select the Additional Security Field checkbox  to limit the document access only to users with additional security that matches the document additional security.

Any user with privileges will be able to access a document of this form type if the document's Location and Additional Security fields are left empty even if the Form Setting's 'Secure Documents Using' section is configured.

This section can be defined in the Form or Workflow Setting. Define this section in the Form Setting if the security option is applied for all document types that have the same Parent Form.  The "Secure Documents based on" section should be defined in the Workflow Setting if security options are to be applied for each separate type of document.

Users granted a Manager access to the application are not restricted by the security settings applied to the application’s forms.

Enable Calendar Integration on a Form

Enable the Calendar Integration to synchronize meetings, training, and audits scheduled through Reliance with the user's (i.e., attendees) personal Outlook Calendar. When Calendar Integration is enabled on a form, generating and sending email notifications are enabled when a meeting is scheduled from within that form. The notification will inform users of the event and request a response.

1. Specify which fields to read from within the form being configured when generating the meeting email notification and the attendees of the meeting who will receive the notification in the following fields that will be displayed in the Calendar Integration tab once "Enable Calendar Integration" is selected.

Chair: Specify in the Names fields the names of the persons considered to be the chairs (heads) of the meeting.

Location: Select the field in the form to specify the location where the meeting will be held.

Required Attendees: From the list of Names fields, specify the names of the persons who must attend upon being invited (e.g., to a meeting, audit, or training).

Optional Attendees: From the list of Names fields, specify the names of those persons who may attend upon being invited (e.g., to a meeting, audit, or training).

Start and End Date: Select the Start Date/End Date and Time fields in the form that identify which day the meeting will begin and end.

Start and End Time: Select the Start Time/End Time and Time fields in the form that identify at what time the meeting will begin and end.

Subject and Body: Customize the Subject and Body of the meeting invitation using either ETQScript or Expression Builder.

After correctly filling in all fields and saving the Form Setting, a [Send Invitation] action is automatically added to the More menu of the documents created based on the form being configured. When a meeting is scheduled through a document and the [Send Invitation] action is used, a meeting invitation is generated with all the values of the specified fields within the Calendar Integration tab. The meeting's date and time, along with a link to the corresponding Reliance document from which the meeting was generated from will be found in the body of the invitation.

The meeting invitation is then sent to the persons listed as Chair and Required Attendees requesting a response. Once the email is received and the meeting is accepted, the meeting information will be added to the receiver's Outlook calendar. When a response is given, an email will be sent back to the generator of the meeting.

Any changes made to the document from which the meeting was generated will affect the Outlook Calendar's entry.

Define the Form’s Toolbar and Inline Actions

In the Form Setting under the Advanced tab:

1. Select the actions that will be available for use in the Side toolbar of the document from the list of the pre-defined Action Settings in the Toolbar Actions field. When selected, the full name of the action, along with the Display Name of the action, will be displayed.
2. Select the actions that will be available for use in the body of the document (e.g., the New Risk Assessment action) from the list of the pre-defined Action Settings in the Inline Actions field. When selected, the full name of the action along with the Display Name of the action will be displayed.

 

Set the Form to Open in Read-Only Mode in Specific Phases

By default, documents in the Completed, Voided, and Archived phases cannot be edited. Documents in these phases will always open in Read mode. You can select normal phases in the Open the form in read-mode in these phases field of the Advanced tab to open the documents in read-only mode during the selected phases, and to open the documents in edit-mode in the remaining phases. The [Edit] action button will be available within the menu bar of the document that opens in Read mode.

For example, select the ‘Initial Approval’ phase if you want CAPA documents that reside in the ‘Initial Approval’ phase to open in Read mode.

Form’s Customization Formulas

The Customization Formulas section of the Advanced tab is used to define the advanced features that can be performed from within the documents created using this form. Custom behaviors can be implemented using ETQScript. The scripts initiate specific functions when an action is performed on the document. Remember that field formulas are executed first and are then followed by form formulas.

1. On Open Formula File: When the formula written to execute a particular action on opening a document exceeds the amount of 4000 characters then, an external file with the formula is created and saved as '.py'. The file is then attached to this field. In this case, the system will execute the formula in the file attached in this field first, then it will execute the formula in the ‘On Open (EtQScript)’ field. Neither overrides the other.
2. On Open (EtQScript): Write an EtQScript formula indicating an action, which will be performed after opening the document. This event sets the default values for the text, number, keywords, names, and date/time fields whenever a document is opened
3. On Refresh Formula File: When the formula written to execute a particular action on refreshing a document exceeds the amount of 4000 characters then, an external file with the formula is created and saved as '.py'. In this case, the system will execute the formula in the file attached in this field first, then it will execute the formula in the ‘On Refresh (EtQScript)’ field. Neither overrides the other.
4. On Refresh (EtQScript): Write an EtQScript formula indicating an action, which will be executed once the document is refreshed. For instance, after clicking [Refresh], the cost values must be calculated.
5. On Save Formula File: When the formula written to execute a particular action on saving a document exceeds the amount of 4000 characters then, an external file with the formula is created and saved as '.py'.  In this case, the system will execute the formula in the file attached in this field first then it will execute the formula in the ‘On Save (EtQScript)’ field. Neither overrides the other.
6. On Save (EtQScript): Write an EtQScript formula indicating an action, which will be executed once the document is saved (i.e., it executes the formula then saves the changes). This can be used to set field values or validate multiple fields (notice that field setting validation formula is used to validate a single field).
7. Shared Formulas (EtQScript):

Download a file containing shared formulas.

1. On Switch to Document Tab Formula (EtQScript): Write an EtQScript formula to be executed when the user switches from a tab to tab.
2. Custom Java Class: Classes are defined when a special type of form is being created. The class (Java Class) acts as an event handler for the documents created based on this form.

A custom class should be used when a specific functionality is needed on certain events. For example, you can implement a custom handler and override the onAfterSave method. This method of implementation will be executed each time the document is saved successfully.

Customize the Link Description of the Document

The Link Description of the documents created based on this form can be customized using any of the following options that are available under the Link Description Options of the Advanced tab:

1. Expression Builder: When this option is selected, you can use the Link Description Expression Builder dialog, which is opened by clicking the Open Expression Builder action, to customize the Link Description.
2. EtQScript: When this option is selected, you can fill in the displayed field with an EtQScript formula that returns a Link Description. EtQScript Link formulas reflect the logged in user’s local (Localized Text and Time Zone) on the Link Description.
3. SQL: When this option is selected, you can fill in the displayed field with an SQL script that returns a Link Description.

Select Database Views

If you want to create a Reliance View for this Form Setting based on a view on the database level, you will need to select the Database Views according to which a view on the database level will be created for this form once this Form Setting is saved. The created Database view will be redeployed each time the Form Setting is saved.

Once Reliance is installed/upgraded, its default database views are automatically deployed along with its parent applications.

Inheritance Setting

Inheritance Settings determine how fields are mapped from a specific Source form to the Destination form being defined. For full details, please refer to the Inheritance Setting topic.

Form Setting Properties

Through the Properties tab, the Form Setting ID is displayed in read-only mode. For the following properties, default values are set but can be changed as follows:

1. Parent Application(s): The parent application with which this form will be associated is shown here.
2. Design Name: The Design Name is automatically set based on the Display Name when the document is saved or refreshed.
3. Database Attributes: The system creates a table for each form in the database of the parent application. The information entered in the form is typically saved in the related table.

When a new Form Setting is created, a name of the table and its primary key should be specified. When the Form Setting is saved for the first time, the schema builder deploys the form and creates a new table in the database (schema).

Some forms might not need to be deployed. For instance, if two or more forms use the same table in the same database one of these forms should allow editing data, the other(s) is a Read-Only form (i.e., has the Read-Only option selected) and retrieves its data from the same table.

Before beginning, keep in mind the following notes:

The values of the Database Attributes cannot exceed thirty characters.

The values of the Database Attribute Section must not be one of the database-reserved words (e.g., AND, OR, SELECT, WHERE, etc.).

Any value entered in the Database Attributes fields will be automatically capitalized.

For new Form settings you may create, the fields ‘Table Name’ and ‘Primary Key’ will only accept the dollar sign ($) special character. An error message is displayed if you used other special characters in these fields.

1. Table Name: A name for the form's main table should be entered here. The table name should not exceed 20 characters unless an already existing table with a name longer than 20 characters is used.

The Form Table (i.e., base table) name must differ from the Keyword Table (i.e., Join Table) name, which is required for the multi-value keywords.

1. Primary Key: The name of the Column that will be used as a Primary Key is defined here. Primary Keys determine the uniqueness of records. Primary Key fields of the Form setting will be converted to read-only once the document is saved.

The Primary Key cannot be the same as the Table Field Name of related Field Settings where this Form Setting is selected as a Parent Form, or a validation message will be shown.

1. Unique Composite Index: Two different types of indexes can be created in Reliance.  An index based on a single field and an index based on more than one field in the same form can be created.

To create a unique index based on one field, a field should be set up as an indexed field using the related options in the Field Settings document.

If the index will be based on multiple fields, then those fields within the Form Settings should be defined using the Unique Composite Index field, from which the following can be selected:

Numeric, Text, and Date/Time fields.

The system fields (those are the fields that start with EtQ$).

Single Value fields.

When a unique index is defined based on multiple fields, the system will validate the uniqueness of these fields when the contents are similar.

For example, if both the Document Number and Revision Number fields are defined as unique indexed fields, and then these two fields are filled in with 3, 1 respectively for the same form and with 4, 1 in another form, then the two forms will be considered unique forms. Meanwhile, if the Document Number and the Revision Number fields in the two forms are filled in with 3, 1 respectively; then this case will be rejected. The two documents will not be saved with the same information in the two index fields.

The Unique Composite Index field will change to read mode after it is populated and saved for the first time. You will not be able to change it unless you drop the index [table_name]_COMID from the database level on any of the schemas in which this form's table exists then the field will become editable again.