# Access

> Control who can open folders, views, tables and dashboards in SAPUGO, what they can do there, and which rows and columns they see once inside.

Access in SAPUGO answers two separate questions. Keep them apart when you plan your system.

1. **May this person open this object, and may they create, update or delete through it?** This is decided by the **access rules** on a folder, view, table, dashboard or database.
2. **Which rows and columns can they see once they are in?** This is decided by the [access filter](/docs/base-views) the view reads through.

A filter you add to a working view is a third thing: a display convenience. It does not protect data. Anyone who can change the view, or who uses another view with a wider access filter, is not bound by it.

## Access rules

Each access rule names **who** and **what they can do**.

**Who** can be:

- a **User**: one person,
- a **User Group**: everyone in a [group](/docs/groups),
- the **Organization**: all members of your organization,
- a **Permission**: anyone who holds a given organization permission.

**What they can do** is any combination of **Create**, **Read**, **Update** and **Delete**. You can pick a preset:

| Preset | Allows |
| --- | --- |
| **Full Access** | Create, read, update and delete. |
| **Can Edit (no delete)** | Create, read and update. |
| **Read & Update** | Read and update, but not create or delete. |
| **Create / Read** | Add new records and read, but not change or delete. |
| **Read Only** | Open and read, but not change anything. |
| **Custom...** | Any other combination. |

For example, Read without Update shows the screen and refuses edits. Create without Delete lets people add records but not remove them.

> **Note:** The person who created an object always has full access to it, whatever its rules say.

## Inherit or custom

Each object has a **Permission mode**:

- **Inherit from parent** uses the access rules of the folder it sits in. You can still add extra rules on top.
- **Custom permissions** uses only the rules set on the object itself, and ignores the folder.

Set rules on the folder when a whole area shares one audience. Then switch to **Custom permissions** only on the one view that must be tighter or wider than its folder.

To see the final result, choose **Show effective permissions**. It lists every rule that applies and where each one comes from.

## Where to set access

### Folders

Open the folder's menu in the sidebar and choose **Settings**. Items in the folder inherit these rules by default. See [Folders](/docs/folders).

### Views

1. Open the view and open its view settings.
2. Choose **Permissions**.
3. Pick a **Permission mode**.
4. Choose **Add ACL**, then pick the type (User, User Group, Organization or Permission), who it applies to, and what they can do.
5. Save your changes.

### Tables

Open the table's page (in the **Database** section, open the table's menu and choose **Settings**) and go to the **Access** tab. Here you see **Who has access** and can edit the **Access rules**.

Table access decides who can see the table in the Database section. Most people never need it, because they work in views you put in folders for them.

### Databases

Go to **Settings**, then **Databases**, open a database and choose **Access Control** to decide who can access that database.

> **Note:** Access rules for views, tables and databases are available on the Pro plan and above. On other plans, views are visible to all members of your organization.

## Limit rows and columns

Access rules decide whether someone can open a view. To decide what they see inside it, use [access filters](/docs/base-views):

- **Rows**: an access filter for technicians can include only the jobs in their branch.
- **Hidden columns**: an access filter can hide a column, such as Price, from a role completely.
- **Read-only columns**: a column can be visible but read-only in one access filter, and editable in another. That way one role can see a field that only another role can change.

Assign each access filter to the groups that should use it, and order the filters by priority.

## How access works with groups

Put people into [groups](/docs/groups), then point access rules and access filters at those groups. Name a single person in an access rule only for an exception.

Organization permissions, such as creating tables, managing workflows or inviting members, are not a substitute for access rules. A person can have permission to create views and still be unable to open a folder whose access rules do not include them.

## Plan your access

Work through these questions for your system:

- For each folder or section: who can open it, and can they update records there?
- For each table: which access filters slice its rows, and which groups use each one?
- Which views must not inherit their folder's rules?
- Which columns are hidden or read-only for which roles?

An example for a workshop:

| Object | Who | Can do |
| --- | --- | --- |
| Workshop folder | Technicians | Read & Update |
| Workshop folder | Office | Full Access |
| Finance folder | Bookkeepers | Full Access |
| Jobs table, access filter "My branch" | Technicians | Rows from their branch, Price hidden |

## Related

  - [Groups](/docs/groups): Bundle people by role and grant permissions.
  - [Access filters](/docs/base-views): Limit the rows and columns each role sees.
  - [Folders](/docs/folders): Hand a whole area of the sidebar to a team.
  - [Views](/docs/views): The screens people open and work in.

---

Source: https://community.sapugo.app/docs/access