# Row Access Control Data security and integrity are critically important, especially in a collaborative environment where multiple users work on a shared database. EDITable addresses your security needs by offering row-level access control at the granular level. You can precisely manage who can add, update, or delete rows by specifying their email IDs. This section explains how you can allow/restrict all or specific users from performing specific actions (add/update/delete) using the 'Row Access Control' in EDITable. {% hint style="info" %} Columnar ACL (access control for columns) is also available in EDITable and has been explained in the [Column Access Control](/editable/working-with-editable/column-access-control.md) section. {% endhint %} To manage permissions for adding, updating, and deleting rows within a table, go to **Settings -> Row Access.**

## 1. Add 1. Enable the **Add Rows** toggle button to allow users to add new rows to the table.

2. **Access Control** Under the 'Apply to' section, you can choose to allow all users or only specific users in the workspace to add rows. * **All users in this workspace:** Select this option to allow all workspace users to add records. * **Specific users in this workspace:** Choose this option to allow only specific workspace users to add rows. You can enter the email IDs of the users or the AD groups you want to allow.

3. Click on **Save** to apply changes.

## 2. Update 1. Enable the **Update Rows** toggle button to allow users to modify existing rows.

2. **Access Control** Under the 'Apply to' section, you can specify the access rules for the update operation. * **All users in this workspace:** Select this option to allow all workspace users to update records.

* **Specific users in this workspace:** Choose this option to allow only certain workspace users to update the rows. Enter the email IDs of the users you want to allow.

* **Rule-based access:** Select this option to configure rules governing the update access to particular columns or records in the table based on specified filter criteria. -> Click on **Add Rule** to add a rule.

-> Enter the rule name, the filter criteria, and the designated users who can update these rows. Click on **Add.**

-> You can add more filter criteria within a rule by clicking on **Add filter** and then combine them using AND or OR operators.

-> You can set as many rules as required and assign corresponding users for each.

3. Click on **Save** to apply changes.

## 3. Delete The 'Delete Rows' toggle is disabled by default. 1. Enable the **Delete Rows** toggle button to allow users to delete rows from the table.

2. **Access Control** Under the 'Apply to' section, you can choose to allow all users or only specific users in the workspace to delete rows. * **All users in this workspace:** Select this option to allow all workspace users to delete records.

* **Specific users in this workspace:** Choose this option to allow only specific workspace users to delete rows. You can enter the email IDs of the users or the AD groups you want to allow.

Allow only specific users to delete rows

* **Rule-based access:** Select this option to configure rules governing the delete access to particular columns or records in the table based on specified filter criteria. -> Click on **Add Rule** to add a rule.

-> Enter the rule name, the filter criteria, and the designated users who can delete these rows. Click on **Add.**

-> You can add more filter criteria within a rule by clicking on **Add filter** and then combine them using AND or OR operators.

-> You can set as many rules as required and assign corresponding users for each.

3. Choose the delete type. When you allow users to delete rows, you can let them [delete the rows permanently](#id-3.1.-delete-row-permanently) or [set up a soft delete](#id-3.2.-mark-row-as-deleted). Both methods are explained below in detail.

4. Click on **Save** to apply changes.

### Delete Type ### 3.1. Delete row permanently When you select this option, the deleted rows are removed from the table/database permanently.

### 3.2. Mark row as deleted When you select this option, the deleted rows remain in the database but are marked as deleted in the table. This is accomplished by setting a specific value to an existing column in the table when a row is deleted. For example, in the example below, we have assigned the text 'DELETED\_ROW' to the deleted row's '*Active'* column. The results are displayed below.

#### Show deleted rows When the 'Show deleted rows' option is selected, the deleted rows are shown in the table in a greyed-out format.

When this option is unchecked, the deleted rows are hidden from the table.

You can use the audit log to keep track of all changes, including the list of deleted and soft-deleted rows.

{% hint style="info" %} Soft delete is not supported if Type 2 SCDs are configured in the table. Instead, the deleted rows are struck off. {% endhint %} #### In the table below, Type 2 SCDs are configured, and the deleted rows are indicated as shown below:

In addition to row-level access control, you can also set up approval workflows so that every change made by a user goes through a review and approval process. This is explained in the next section. --- # 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.inforiver.com/editable/row-access-control.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.