Lead:  Liav Nadler

...

A form is a collection of input fields , allowing which allows users to enter data that is then sent for further processing.

Forms may appear:

• In workspacesin the main workspace.

• Inside inside various containers, including Dialog popups, popovers Popovers,wizardsWizards,filter Filter panes, details Details panes and cards. Cards.

In the main workspace	Inside a Dialog popup

Usage & Behavior

Structure

A form consists of two areas:

• the input area and the action area.The input area , which may contain any set of input fields, including text Text fields, dropdown Drop-down menus, checkboxes Checkboxes, radio Radio buttons etc.

• The the action area, which consists of a submit button (:

  • submit buttons, such as Save, Create,

  Update etc.) and

  • or Update.

  • an additional Cancel button, when shown inside a container.

  • additional actions, if needed.

• Inside containers, an additional Cancel button may appear.

The Input Area

For the usage and behavior of inline inputs, see Inline Inputs.

• Where possible, field labels will appear above the input field (for example, above a text field or a set of radio buttons).

• Where relevant, a red mandatory indicator (*) will show be shown next to the label.

• Where relevant, a help icon will appear next to the label (aligned to the right side of the field, if possible).

• For inline inputs usage and behavior, see Inline Inputs.

...

The Action Area

• The action area will always be visible.

  In case

• Main action buttons are aligned to the right. If needed, buttons for secondary actions such as clear or delete will be aligned to the left.

  Image Added

• Where the form takes up the entire workspace, the action area will appear at the top of the page. (

  see

  See Examples below).

• In

  any

  all other

  case

  cases, the action area will appear below the form.

  • In widgets within the workspace, the action area will be separated by a horizontal line.

    • In workspaces:

      If the form does not exceed the height of its container, the action area will appear below the last form field

      of the form

      .

    • If the form exceeds the height of its container, the action area will stick to the bottom of the container, allowing users to scroll the form above it.

  • Inside other containers, the action area will appear at the bottom of the container.

Image Removed

• Buttons for main actions will be aligned to the right. If needed, buttons for secondary actions, such as clear or delete will be aligned to the left.

States

• Forms can have two states:

  • Idle / Saved - Applied . Applies when entering a form or after clicking the submit Submit button. In this case:

    • The submit the Submit button is disabled.

    • Exiting exiting the form will not save it.

  • Edited - Applied . Applies after making changes to the form but before clicking the submit Submit button. In this case:

    • The submit the Submit button is enabled.

    • Attempting attempting to leave the form will trigger a confirmation message (see . See Validation and errors below).

Interaction

• Clicking the submit Submit button:

  • sends the data for further processing. (for For error handling see Validations and errors below).

  • In workspacesthe workspace, if the form was submitted successfully:

    • A a success toast Toast will appear (see Toasts).If , and

    • if the form was triggered from a parent page, the user will be directed redirected back to that page.

  • For forms inside containers, refer to the corresponding pattern documentation. For example, clicking the Submit button in a Dialog popup, will close it.

• Clicking the Cancel button, if exists, will:

  • trigger a confirmation message, if the form is in the Edited state, and then

  • close the

  corresponding component

  • container (

  if not

  • unless pinned)

  ,

  • without saving the data

  (a confirmation popup may appear)

  • .

Validations and errors

• For input-specific validations see Field Validation.

• A form cannot be submitted if one or more of its fields are in an error state. Here is a typical flow:

  • When entering a form, the submit Submit button is disabled. (the The Cancel button, if exists, is always enabled).

  • On updating any field, the submit Submit button becomes is enabled.

  • In case of If there is an input error, the submit Submit button becomes will be disabled again. Only after all errors have been resolved , is it becomes enabled again.

  • After clicking Submit, the submit button :

    • it becomes disabled,

    • a toast message may appears, indicating that the form was submitted.

• This flow is similar where the form is in a dialog popup, but in this case, clicking the submit button closes the popup.

• • is disabled again.

• In case the user tries to navigate away from a form after updating one or more fields or while there are errors, :

  • a message popup will appear

  , allowing

  • . (See the Common messages repository for wording).

  • the user will choose to either keep editing the form or leave

  (see Common messages repository)

  • and discard their changes.

Best practices

Use for:

• Creating or updating entities (for example: , such as users, roles, and channels).

• Configuration (for example: , such as services level indicators , or storage retention periods).

General

• In general, form Form fields should be arranged in one column. Closely related fields (e.g. , first name and last name) can may appear side by side.

• Collections of related fields should be grouped into sections. For example, fields like such as Email and Phone may be found under a Contact Information section.

Examples

Accessibility compliance

Unless otherwise specified, see our general compliance information in Fundamentals - Accessibility

text highlight when using a keyboard + using arrows when in edit mode (left, up or home to set the insertion point at the beginning; right, down or end to set it at the end).

Design

...