> ## Documentation Index
> Fetch the complete documentation index at: https://docs.k16solutions.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissions

> Use K16 permissions to give people the access they need without granting unnecessary control.

K16 uses roles to collect permissions. A person's role determines which product areas they can open and which actions they can take.

<Info>
  The exact roles in your workspace are institution-specific. This reference describes the
  permission areas represented in the current K16 application.
</Info>

## Separate feature access from data access

Workspace configuration makes a product available. Your role then controls which pages and actions you can use. DataX data access separately controls the entities and protected columns available to that role.

Permissions are specific to each action. For example, integration **View** does not grant **Manage**, and **Manage snapshots** does not grant **Manage scheduled exports**. Creating users, managing existing users, and deleting users also have separate permissions.

Use the [role permission catalog](/administration/roles/permissions) for the exact options exposed in the role editor. It covers Archive, Analytics, Documentation, Lakehouse, organization settings, and AI tools.

## System roles and custom roles

Your workspace can include system roles and institution-defined roles. System roles provide a stable baseline. Custom roles let administrators combine permissions for a specific responsibility.

<Warning>
  Treat role changes as security changes. Grant the smallest set of permissions that lets a person
  complete their work, then test the role with a representative account.
</Warning>

## Review access safely

<Steps>
  <Step title="Start with the person's job">
    List the product areas and actions the person must use. Avoid granting a broad administrative
    role only to expose one action.
  </Step>

  <Step title="Choose the narrowest role">
    Reuse an existing role when its permissions match the responsibility. Create a custom role when
    the existing roles are too broad.
  </Step>

  <Step title="Check data access separately">
    Product permissions and granular data access solve different problems. A person can have
    worksheet access while still being limited to approved tables or columns.
  </Step>

  <Step title="Verify the result">
    Confirm the person can complete the intended workflow and cannot open unrelated administrative
    or data-management actions.
  </Step>
</Steps>

Continue with [manage roles](/administration/roles/manage-roles) or [configure granular data access](/administration/data-access/entities-and-columns).