Form category

Validate the functionality of fields and UI actions on a form.

Note: Test steps that include the Form UI field give you the option to select an available UI. For any available workspace, navigation between tabs is not supported. Use the Open a New Form or Open an Existing Record step to reopen a form.

It is to be noted that Agent Workspace has been removed from the Platform. If you have any Agent Workspace tests or test suites, they won't work anymore.

Open a New Form

Open a form to a new record in the specified table and Form UI.

Open an Existing Record

Open a form to an existing record in the specified table and Form UI.

Note: Using an existing record may cause unexpected behavior for this test. See Automated Test Framework design considerations for more information.

Set Field Values

Set the fields on the current form to the specified values.

To run this step, your test must have already opened a form using either the Open a New Form or Open an Existing Record step. It is recommended to not run this step directly after a Submit a Form or Click a UI Action step. This is because they can redirect your test to a different page based on the navigation stack configuration on your instance or the script defined in the clicked UI action. Unless you are certain that the UI action will take you to a specific page, you should explicitly use an Open a New Form step after Submit a Form or Click a UI Action to ensure that the test is on the form as expected. Ensure that the test keeps passing consistently when added to a suite.

The Field Values Validation, Set Field Values, Field State Validation, and UI Action Visibility steps can appear in any order.

Note: This step waits for the form to load before setting field values. This step doesn't support reference qualifiers, neither at test design time nor at test runtime. A modal form appears either on top of another form or a list. To submit a modal form after setting the field values, your test must have already opened it on top of a form or a list.

Field Values Validation

Validate field values on the current form.

To run this step, your test must have already opened a form using either the Open a New Form or Open an Existing Record step. It is recommended to not run this step directly after a Submit a Form or Click a UI Action step. This is because they can redirect your test to a different page based on the navigation stack configuration on your instance or the script defined in the clicked UI action. Unless you are certain that the UI action will take you to a specific page, you should explicitly use an Open a New Form step after Submit a Form or Click a UI Action to ensure that the test is on the form as expected. Ensure that the test keeps passing consistently when added to a suite.

The Field Values Validation, Set Field Values, Field State Validation, and UI Action Visibility steps can appear in any order.

For the Field Values Validation step, specify the values that you want to test using the standard conditions builder. You can test several conditions against the same field. This step passes if the overall condition is satisfied and fails if the condition is not satisfied. The Conditions field is case-sensitive and requires to have the exact value as on the form. To test the values of individual fields independently of each other, include a separate Field Values Validation step for each value that you test.

Note: The Field Values Validation step works only with fields that belong to the record for the open form. For example, with the incident table, this step is not able to validate the Additional comments, Approval history, Comments, or Work notes fields because these UI controls are not actual fields on the incident record. These UI controls make it convenient to work with related tables. To validate these cases, use the Server test step, Record Validation, instead.

Field State Validation

Validate the state of specified fields. States validated can include mandatory, non-mandatory, read-only, non-read-only, visible, and non-visible.

You can specify a maximum time to wait for the states of the fields to match the conditions in this step.

UI Action Visibility

Verify if a UI action is visible on the current form. To run this step, your test must have already opened a form using either the Open a New Form or Open an Existing Record step.

The default visible UI actions vary depending on the user that you're currently impersonating.

Declarative Action Visibility

Verify if a declarative action is visible on the current form.

The default visible declarative actions vary depending on the user that you're currently impersonating.

Add Attachments to Form

Add one or more mandatory attachments to the current form. Select the attachments that the test step adds to the form from the Upload Attachments list.

Note: The Add Attachments to Form test step can't access the newly added UI workspace options.

Click Modal Button

Click a button within a modal in the specified Form UI.

Specify your testing by selecting either the standard platform UI or workspace UI from the Form UI field. If you select the standard platform UI, this test step selects the button by ID on the specified modal and validates the following conditions:

• UI page was opened in a modal.
• Button is visible and enabled.

If you select an available workspace UI, this test step selects either the Confirm or Cancel action and optionally sets the field values within the modal. This step succeeds only if a modal dialog is open on the form, and if the specified button exists on that modal dialog.

Only modals opened with the following g_modal functions are supported:

• alert
• confirm
• confirmDestroy
• showFields

Note: Click Modal Button now supports global and scoped application modals.

Note: The Click Modal Button test step can't access the newly added UI workspace options.

Click a UI Action

Click a UI action on the current form.

When this step runs, the system performs the action normally activated by that control. The test step also validates that the current form contains the control and that the control is visible and enabled. To run this step, your test must have already opened a form using either the Open a New Form or Open an Existing Record step. It is recommended to not run this step directly after a Submit a Form or Click a UI Action step. This is because they can redirect your test to a different page based on the navigation stack configuration on your instance or the script defined in the clicked UI action. Unless you are certain that the UI action will take you to a specific page, you should explicitly use an Open a New Form step after Submit a Form or Click a UI Action to ensure that the test is on the form as expected. Ensure that the test keeps passing consistently when added to a suite.

In the Australia release, this step supports UI actions of type Form context menu.

Note: Don't write tests that depend on the system displaying a specific page after executing a Submit a Form or Click a UI Action step. After these test steps, the system returns to the page that was open before the form was opened. The test cannot determine what that page was, so writing a test that expects a particular page can lead to unpredictable results.

Click a Declarative Action

Click a declarative action on the current form.

Submit a Form

Submit the current form.

To run this step, your test must have already opened a form using either the Open a New Form or Open an Existing Record step. It is recommended to not run this step directly after a Submit a Form or Click a UI Action step. This is because they can redirect your test to a different page based on the navigation stack configuration on your instance or the script defined in the clicked UI action. Unless you are certain that the UI action will take you to a specific page, you should explicitly use an Open a New Form step after Submit a Form or Click a UI Action to ensure that the test is on the form as expected. Ensure that the test keeps passing consistently when added to a suite.

Note: Don't write tests that depend on the system displaying a specific page after executing a Submit a Form or Click a UI Action step. After these test steps, the system returns to the page that was open before the form was opened. The test cannot determine what that page was, so writing a test that expects a particular page can lead to unpredictable results.

A modal form appears either on top of another form or a list. To submit a modal form, your test must have already opened it on top of a form or a list.