Overview

Presight integrates comprehensive data governance mechanisms to ensure secure and granular access control. Below is an overview of the various levels of data governance in Presight, designed to protect sensitive data and enforce appropriate access permissions across your business intelligence workflows.

---

1. Table-Level Permissions

The Table-Level Permission system governs access to entire tables, specific columns, or individual rows. This is the strictest and most fundamental level of data restriction. It consists of three subtypes:

a. Whole Table Restriction

• By default, all tables are accessible to every user in the workspace.

• Workspace administrators or table owners can restrict access to entire tables to specific users or groups.

• If restricted, unauthorized users cannot view or interact with the table.

b. Specific Column Permission

• Access can be restricted at the column level.

• For example, sensitive columns like "Salary" or "Social Security Number" can be hidden from unauthorized users.

• Even if a user has access to the table, restricted columns will remain hidden.

c. Row-Level Permission

• Permissions can be set to allow access to specific rows based on defined criteria.

• For instance, sales representatives might only see rows related to their assigned regions or clients.

Note: Presight employs an opt-out mechanism for table-level permissions. By default, a table is accessible unless the workspace administrator or table owner explicitly restricts access.

Table Restriction

2. Metric-Level Permissions

Metrics in Presight are defined based on table columns or other metrics. Metric-Level Permissions control who can access or share these metrics.

• Ownership and Sharing:

  • A metric owner can choose to share their metric definitions with other workspace members.

  • Sharing is optional and controlled by the metric owner.

• Dependent Access:

  • If a user lacks access to the source columns or tables from which a metric is derived, they will not be able to view the metric’s values, even if the definition has been shared with them.

  • This ensures that users cannot infer restricted data through metrics.

Example:

If Metric A is derived from the "Revenue" column in a table that a user cannot access, sharing Metric A's definition does not grant them access to the revenue data or its aggregated results.

Metric Permission & Sharing

3. Doc-Level Permissions

Document-Level Permissions allow for the sharing of data widgets and metrics embedded within a doc.

• Widget Sharing:

  • Sharing is initiated by the document owner or collaborator.

  • Once shared, contents of the doc including data widgets can be viewed by other members,

• Access Constraints:

  • Even if a doc is shared, users will only see metrics or widgets if they have the necessary permissions to access the underlying data.

  • If a metric or widget in the doc is based on restricted data, unauthorized users will not see its content.

Example:

A report shared with a team member will only display sales figures for regions they are authorized to view. Restricted metrics or widgets will remain inaccessible, ensuring confidentiality.

Doc Sharing

Presight Permission Summary

Permission Level	Scope	Default Behavior	Controlled By
Table-Level	Whole tables, specific columns, or rows	Tables are accessible to everyone unless explicitly restricted	Workspace admin or table owner
Metric-Level	Individual metrics	Metrics are private unless shared by the owner. Access requires permissions to data sources	Metric owner
Doc-Level	Documents containing widgets and metrics	Docs are accessible when shared, but data visibility depends on metric/table permissions	Document owner or collaborator