Skip to main content

DAC

DAC — Discretionary Access Control — covers user-created assets where the owner decides who else can see, edit, or delete. RBAC and ABAC handle data; DAC handles artifacts: conversations, dashboards, notebooks, workspaces, scheduled tasks, data products.

The pattern is intentionally similar to file sharing in cloud drives: the creator owns the asset, can grant access to others, and that access propagates without admin intervention.

What DAC governs​

AssetDAC operations
ConversationView / edit / share / delete (delete is owner-only)
DashboardView / edit / share / archive
NotebookView / edit / move / delete
WorkspaceView / edit / admin (manage members)
Scheduled taskView / edit / pause / delete
Data productView / edit / publish / revoke

Roles within an asset​

Most assets support three role levels:

  • Viewer — read-only.
  • Editor — read + modify (but not delete or change permissions).
  • Admin / Owner — full control, including changing permissions and deleting.

The owner is the user who created the asset; ownership can be transferred to another user (admin or owner action only).

Granting access​

The owner of an asset can grant access via the asset's Share / Settings menu. Granting in DAC is explicit — there's no "everyone in the tenant" by default; you list users or groups.

For workspace-level assets, workspace membership grants implicit DAC — every workspace member gets viewer-or-higher access to assets inside the workspace. To restrict a workspace asset to a subset of the workspace, use explicit DAC on top of the workspace defaults.

Tenant-wide overrides​

Admins can override DAC for forensics, compliance, and onboarding. From an admin user, every asset shows up in Admin > Assets with the option to:

  • View it.
  • Transfer ownership.
  • Delete it (irreversible — soft-delete with retention window).

These admin overrides write to the audit log so the action is traceable.

DAC × RBAC × ABAC​

DAC governs who can see the artifact. RBAC + ABAC govern what data they can read inside it. The two are independent:

  • A user can have DAC viewer access to a dashboard and still get Permission denied on tiles whose underlying queries reference data they don't have RBAC for.
  • A user with broad RBAC but no DAC on a dashboard can't see the dashboard at all — even though they could re-create the same queries from scratch.

This is the design: artifact privacy and data privacy are two different problems.

Common issues​

A teammate has DAC on a dashboard but the tiles are empty for them. The tiles' SQL references tables they don't have RBAC for. Grant the table or pick a different data source for the tile.

Owner left the company; their dashboards are stranded. Admin can transfer ownership — Admin > Users > {removed user} > Owned assets > Reassign.

DAC says Editor but the user can't change a tile's SQL. Some tile types are owner-only-editable for safety. Check the tile's permissions specifically (in the dashboard's Manage tiles panel).

Soft-deleted dashboard recovered after 30 days disappeared. 30 days is the default retention. Admin can extend per asset; for permanent retention, archive instead of delete.

Workspace member can't share an asset they didn't create. DAC ownership stays with the creator. Workspace admins can transfer ownership inside the workspace; non-admins can only request a transfer.

See also​

QRYA product of IXEN.