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.

Table 1. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Description Description of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.
Notes Notes about the test step
Form UI Option to select an available UI. Apart from the Standard UI, you have other workspace selections available. Depending on the selected workspace, the UI might vary.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
Table Name of the table for the new form.
View Name of the view in which you want this form to open. The testing user must have access to that view. If the name is not a valid form view, the form opens in its default view.
Note: This field appears when Standard UI is chosen from 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.
Table 2. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Description Description of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.
Notes Notes about the test step
Form UI Option to select an available UI. Apart from the Standard UI, you have other workspace selections available. Depending on the selected workspace, the UI might vary.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
Table Name of the table for the new form.
Record Record ID of the record that you want to open and name of the document that you want to open.
View Name of the view in which you want this form to open. The testing user must have access to that view. If the name is not a valid form view, the form opens in its default view.
Note: This field appears when Standard UI is chosen from Form UI.

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.Image showing modal form
Table 3. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Description Description of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.
Notes Notes about the test step
Form UI Option to select an available UI. Apart from the Standard UI, you have other workspace selections available. Depending on the selected workspace, the UI might vary.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
Table Name of the table for the new form.
Set field value Assigns a value to a field on an open form.

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.
Table 4. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Timeout Number of seconds allowed before the step fails. If the validation fails, the system repeats the step until it reaches the duration of the timeout. If the validation fails after the timeout duration has passed, the step fails.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Description Description of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.
Notes Notes about the test step
Note: Use the condition builder to set the field value. The condition builder displays an appropriate control for the field data type. For example, a reference field displays a Lookup record control.
Form UI Option to select an available UI. Apart from the Standard UI, you have other workspace selections available. Depending on the selected workspace, the UI might vary.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
Table Name of the table for the new form.
Conditions Fields and values to be validated. Includes only fields that are visible on the open form. This field is case-sensitive.

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.
Table 5. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Timeout Number of seconds allowed before the step fails. If the validation fails, the system repeats the step until it reaches the duration of the timeout. If the validation fails after the timeout duration has passed, the step fails.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Description Description of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.
Notes Notes about the test step
Form UI Option to select an available UI. Apart from the Standard UI, you have other workspace selections available. Depending on the selected workspace, the UI might vary.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
Table Name of the table for the new form.
Visible Validates whether the fields on this form are visible. The test fails if the fields are not visible.
Not visible Validates whether the fields on this form are visible. The test fails if the fields are visible.
Read only Validates whether the fields on this form are read only. The test fails if the fields are not read only.
Not read only Validates whether the fields on this form are read only. The test fails if the fields are read only.
Mandatory Validates whether the fields on this form are mandatory. The test fails if the fields are not mandatory.
Not mandatory Validates whether the fields on this form are mandatory. The test fails if the fields are mandatory.

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.
Table 6. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Timeout Number of seconds allowed before the step fails. If the validation fails, the system repeats the step until it reaches the duration of the timeout. If the validation fails after the timeout duration has passed, the step fails.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Description Description of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.
Notes Notes about the test step
Form UI Option to select an available UI. Apart from the Standard UI, you have other workspace selections available. Depending on the selected workspace, the UI might vary.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
Table Name of the table for the new form.
Visible Validates whether UI actions on this form are visible. The test fails if the UI actions are not visible.
Not visible Validates whether UI actions on this form are visible. The test fails if the UI actions are visible.

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.
Table 7. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Notes Notes about the test step
Form UI Option to select an available UI. Apart from the Standard UI, you have other workspace selections available. Depending on the selected workspace, the UI might vary.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
Table Name of the table for the new form.
Visible Validates whether declarative actions on this form are visible. The test fails if the declarative actions are not visible.
Not visible Validates whether declarative actions on this form are visible. The test fails if the declarative actions are visible.

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.

Table 8. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Application Application scope in which the system runs this step.
Active Option to activate this test step for use.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Notes Notes about the test step
Upload Attachments Button to add one or more mandatory attachments to the form.
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.
Table 9. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Timeout Number of seconds for the modal and the button to appear.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Description Description of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.
Notes Notes about the test step
Form UI Option to select an available UI.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
UI page The UI modal dialog to be tested.
Note: This field appears only if Standard UI is selected from Form UI.
Button The ID attribute of the button element. For example, the OKbutton has an ID of OK_button in the UI modal dialog.
Note: This field appears only if Standard UI is selected from Form UI.
Modal values The field values to be set in the modal.
Note: This field appears only if a workspace is chosen as Form UI.
Modal action The action to be selected in the modal.
Note: This field appears only if a workspace is chosen as Form UI.
Assert type The effect on the tests on clicking the modal button.
  • Modal closed and page is reloaded or redirected: The test passes only if the modal was closed and the page was reloaded or redirected to another page.
  • Modal closed and page is not reloaded or redirected: The test passes only if the modal was closed and the page was not reloaded or redirected to another page.
  • Modal not closed: The test passes only if the modal still exists and was not closed.
Assertion timeout Number of seconds allowed before the assert fails. If the assert fails, the system repeats the assert until the duration of the Timeout is reached. If the validation fails after the Timeout duration has passed, the step fails.
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 Washington DC 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.
Table 10. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Description Description of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.
Notes Notes about the test step
Form UI Option to select an available UI. Apart from the Standard UI, you have other workspace selections available. Depending on the selected workspace, the UI might vary.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
Table Name of the table for the new form.
UI action The UI action to click.
Note: The declarative action and UI action buttons look exactly the same. Depending on the selected test step (either Click a UI Action or Click a Declarative Action), the type of button can be identified.
Assert type The effect on the tests with clicking of a UI action.
  • Form submission canceled in browser: The step passes only if form submission is canceled.
  • Form submitted to server: The step passes only if the form is submitted.
Table 11. Outputs
Field Description
table The table for the form that contains this UI action.
record The sys_id of the record on which the action was clicked.

Click a Declarative Action

Click a declarative action on the current form.

Table 12. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Step config Read-only name of the step.
Notes Notes about the test step
Form UI Option to select an available UI. Apart from the Standard UI, you have other workspace selections available. Depending on the selected workspace, the UI might vary.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
Table Name of the table for the new form.
Declarative action Option to select a declarative action from the list.
Note: The declarative action and UI action buttons look exactly the same. Depending on the selected test step (either Click a UI Action or Click a Declarative Action), the type of button can be identified.
Assert type The effect on the tests with clicking of a UI action.
  • Form submission canceled in browser: The step passes only if form submission is canceled.
  • Form submitted to server: The step passes only if the form is submitted.

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.
Note: 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.Image showing modal form
Table 13. Inputs
FieldDescription
Execution order Integer specifying the order in which the test executes this step.

As you create steps, the system automatically assigns each step an incremental value. This value causes the test to execute steps in the order that you created them in. You can change this default order by editing the Execution order values.
Active Option to activate this test step for use.
Application Application scope in which the system runs this step.
Test Read-only name of the test that you're adding the step to.
Timeout Number of seconds allowed before the step fails. If the validation fails, the system repeats the step until it reaches the duration of the timeout. If the validation fails after the timeout duration has passed, the step fails.
Note: This field appears when an available workspace is chosen from Form UI.
Step config Read-only name of the step.
Description Description of the test step. This field value is automatically set based on the field values of the test step. This field appears after the test step is submitted.
Notes Notes about the test step
Form UI Option to select an available UI. Apart from the Standard UI, you have other workspace selections available. Depending on the selected workspace, the UI might vary.
Note: Workspaces are not supported in Internet Explorer (IE). See KB0683275 for more details.
Assert type The effect on the tests on submitting a form.
  • Form submitted to server: The step passes only if form is submitted.
  • Form submission canceled in browser: The step passes only if form submission is canceled.
  • None: Make no assertion on submitting the form. The step always passes when using this assert type regardless of the result of submitting the form.
Table 14. Outputs
Field Description
table The table for the submitted record.
record The sys_id of the submitted record.