# Permissions matrix

Comind.work uses a layered access control model. Permissions are evaluated in order from broadest to most specific: **workspace > app > record > field**.

## Permission levels[​](#permission-levels "Direct link to Permission levels")

### Workspace level[​](#workspace-level "Direct link to Workspace level")

| Permission      | Description                                                  |
| --------------- | ------------------------------------------------------------ |
| Workspace admin | Full control over workspace settings, apps, and participants |
| Workspace team  | Access to apps and lists based on group membership           |
| Participant     | Basic access to the workspace                                |

### App level[​](#app-level "Direct link to App level")

| Permission   | Description                            |
| ------------ | -------------------------------------- |
| Read         | View records in the app                |
| Create       | Create new records                     |
| Edit         | Modify existing records                |
| Delete       | Remove records                         |
| Manage lists | Create and modify shared list views    |
| Admin        | Full control over the app installation |

### Record level[​](#record-level "Direct link to Record level")

Record-level permissions apply based on the user's relationship to specific records:

| Rule         | Description                                                                |
| ------------ | -------------------------------------------------------------------------- |
| Creator      | The user who created the record                                            |
| Assignee     | The user assigned to the record                                            |
| Group member | Users in a specific group                                                  |
| Field-based  | Dynamic rules based on field values (e.g., department = user's department) |

### Field level[​](#field-level "Direct link to Field level")

Individual fields can be restricted by access level:

| Access           | Who can see/edit              |
| ---------------- | ----------------------------- |
| `workspaceAdmin` | Only workspace administrators |
| `workspaceTeam`  | Workspace team members        |
| `groups`         | Members of specified groups   |

## ACL evaluation order[​](#acl-evaluation-order "Direct link to ACL evaluation order")

Access control lists (ACLs) are evaluated in a specific order. A more specific rule always overrides a broader one:

```
Workspace ACL
  └── App ACL
        └── Record ACL
              └── Field ACL
```

When multiple rules apply, the **most restrictive** result wins. For example, if an app-level rule grants read access but a record-level rule denies it, the user cannot read that record.

The "most restrictive wins" rule applies in all cases with two exceptions: **workspace administrators** can access everything within their workspace regardless of ACL rules, and **system administrators** can access everything in any workspace.

See [ACL evaluation order](/admin-guide/system-admin/acl-evaluation-order.md) for a detailed walkthrough with examples.

## Common permission patterns[​](#common-permission-patterns "Direct link to Common permission patterns")

### Read-only workspace for external users[​](#read-only-workspace-for-external-users "Direct link to Read-only workspace for external users")

| Group              | Workspace   | Apps      | Records     | Fields                  |
| ------------------ | ----------- | --------- | ----------- | ----------------------- |
| External reviewers | Participant | Read only | All visible | Sensitive fields hidden |

### Team workspace with role-based access[​](#team-workspace-with-role-based-access "Direct link to Team workspace with role-based access")

| Group        | Workspace | Apps                 | Records                | Fields                  |
| ------------ | --------- | -------------------- | ---------------------- | ----------------------- |
| Managers     | Team      | Full access          | All                    | All                     |
| Contributors | Team      | Read + Create + Edit | Own records + assigned | Budget fields hidden    |
| Viewers      | Team      | Read only            | All visible            | Sensitive fields hidden |

### Approval workflow[​](#approval-workflow "Direct link to Approval workflow")

| Group      | Workspace | Apps        | Records               | Fields          |
| ---------- | --------- | ----------- | --------------------- | --------------- |
| Submitters | Team      | Create      | Own records           | Standard fields |
| Approvers  | Team      | Read + Edit | Assigned for approval | All fields      |
| Admins     | Admin     | Full        | All                   | All             |

## Configuring permissions[​](#configuring-permissions "Direct link to Configuring permissions")

### For workspace administrators[​](#for-workspace-administrators "Direct link to For workspace administrators")

1. Go to **Setup > Groups**
2. Create groups that match your access patterns
3. Assign users to groups
4. For each app, set the group permissions (read, create, edit, delete)

### For system administrators[​](#for-system-administrators "Direct link to For system administrators")

1. Go to the system admin panel
2. Navigate to **Manage groups** for system-wide group management
3. Configure cross-workspace permissions if needed

See [Groups and permissions](/admin-guide/workspace-admin/manage-groups-permissions.md) for step-by-step configuration instructions.