# Tables Tables are a highly functional and useful tool for creating forms. In addition to offering configuration options for permissions and sorting to facilitate both data entry and processing, they also allow you to adapt the column types to restrict and specify what type of data will be accepted in each case, just as with individual fields.

As we saw earlier, there are tools with a series of unique properties for their type. Let’s look at each of the features you can configure when working with tables: ## Table Properties ### Table Columns In this section, you can create the columns you need using the ***Add column*** button, as well as hide or show them (eye-shaped icon) and delete them (trash can icon). It is important at this point to define what data you expect to collect so that the entered information is complete, as users will not be able to add new columns or remove existing ones.

**Table Columns** section with options to add, hide, and delete columns

### Validations This property behaves similarly across all fields, although in this case, you can set the minimum (e.g., 1) and maximum (e.g., 10) number of rows allowed.

### Behavior In addition to the ***Readonly*** and ***Visibility*** options, this section includes a series of checkboxes you can select to allow actions or grant permissions to the user. These are: * **Show error markers:** If enabled, error indicators will be displayed when the entered data does not meet the field validations. * **Can Add:** Allows the user to add new rows to the table. * **Can Delete:** Allows the user to delete rows. * **Can Sort:** Allows the user to sort the rows of a column based on a value (e.g., alphabetically by text). * **Can Shrink:** Allows the table to adjust its size within the form based on the entered data.

## Table Configuration We will analyze in greater detail how this type of element works by adding a new section and incorporating a full-width table. We will define the ***Label*** as “Order History” and the ***Name*** as “order\_history.” In the ***Validations*** section, set the minimum number of rows to 1 and the maximum to 10. In ***Behavior***, enable the options ***Can Add***, ***Can Delete***, and ***Can Sort*** so that users can add new rows, remove them, and sort the entered data. {% embed url="" %} Next, go to the ***Table columns*** section and add 5 columns. We will use these to allow the user to enter the type of product requested, the number of units, the order code, the request date, and the receipt.

Once you have created the columns, click on the name of the first one to start configuring it. A new panel will open with specific properties for that column. First, set the ***Name*** to “order\_history\_product” and in the ***Type*** section, choose the field type as ***Options***, assuming we have a limited number of products for the user to choose from. Click *OK* to save. Next, set the ***Label*** to “Product” and the ***Size*** to 3 units. {% embed url="" %} In the options section, define the values as “Red,” “Green,” and “Blue.” Click ***Back*** to return to the table properties. {% embed url="" %} Now select the second column. Set the ***Name*** to “order\_history\_quantity” and the field type to ***Number***. Its ***Label*** will be “Quantity,” and it will have a size of 2 units. Set the ***Placeholder*** to “Requested units” and the maximum value to 100. Return to the table properties to select the third column, which you will name “order\_history\_code,” and set the field type to ***Text***. Its ***Label*** will be “Order Code.” Enable real-time preview and click the "+" sign at the top of the table to add two rows.

Let’s imagine the codes are structured as follows, with the first two letters and the first three numbers always fixed: SP ZYR-30032905BC. This structure can be reproduced using the **Prefix** and **Mask** properties. Try configuring this field and then test entering the following codes: * **Correct code:** SP ATI-30058452YT * **Incorrect code:** SP RU-8001573PH1 The form should prevent the incorrect data from being entered. Check the parameters below that can be used for code validation: {% embed url="" %} Set the field size to 3 units and go back to select the fourth column. Set the ***Name*** property to “order\_history\_date” and choose the field type as ***Date***. Its ***Label*** will be “Request Date,” and its size will be 2 units. Finally, go to the table properties and select the last column, which we will name “order\_history\_receipt.” Set the field type to ***Attachment***, define its ***Label*** as “Order Receipt,” and since we have already used 10 of the 12 total width units with the other columns, set its size to 2 units. Once you have finished, your form should look like the following:

New fields added to the "Personal Data Update" form

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.rpaconnect.io/en-us/form-design/comprehensive-form-development/tables.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.