Skip to content
Monomer

Workspace roles

← Administer

Your Workspace role determines what you can read and change. Roles are cumulative: Viewer, Explorer, Editor, then Owner. You need direct Workspace membership to enter an internal Workspace; belonging to an Organization alone does not grant entry.

Choose the role you need

Section titled “Choose the role you need”
  • Viewer reads Pages, including the past and current results of dashboards added to Pages, and can change a dashboard’s input controls there. A Viewer cannot open a dashboard directly, start new results with Run again or Change inputs, refresh or cancel runs, inspect internal definitions, or download original document files. Viewers open the Workspace in Pages.
  • Explorer can run SQL and Semantic queries as the Workspace’s connection account, read retained Explore results, open Dashboards directly, create Dashboards with Semantic or SQL queries and Pages, edit and apply shared Dashboard drafts, and refresh existing Catalog selections.
  • Editor can also create and change Semantic Models, Metrics, Time Spine settings, and Catalog selections.
  • Owner can also manage Connectors, credentials, Workspace members, roles, and Workspace settings. Organization Admins can also rename a Workspace they belong to and change its Reporting time zone.

Ask a Workspace Owner for the role required by your task. Your effective role is your direct Workspace member role.

Monomer does not grant access separately to individual tables, models, or metrics. SQL can query sources available to the Connector’s warehouse identity even when they are not selected in Catalog. Warehouse grants, row policies, and network rules still apply. Ask the warehouse administrator if the warehouse rejects a query.

Require a dedicated read-only warehouse account for every Connector. If an account has write permissions, Explorers and their Agents can modify data. Monomer does not guarantee read-only access. Deny procedure, pass-through, and remote/external function privileges using the warehouse-specific guidance.

Retained results and Pages

Section titled “Retained results and Pages”

Explorer, Editor, and Owner can read retained Explore results and open Dashboards directly. Changes to current Semantic definitions do not revoke old results; current Workspace role, result ownership, integrity, and retention are still checked. Personal Explore lists and cancellation remain scoped to the person who started the run.

All Workspace members can read Pages. A saved SQL dashboard executes with the Connector identity when Page readers change inputs, including Viewers and anonymous public readers. SQL text and Connector details remain hidden; SQL-backed widgets show an SQL badge. Restrict the Connector to a dedicated read-only account and keep reader-controlled values out of warehouse dynamic SQL. Adding a dashboard to Pages makes its past and future results available to everyone who can read Pages. When a Workspace Owner turns on Public Pages in Settings → Public access, anyone with a link can read Pages; see Share Pages publicly.

Inspect access with an agent

Section titled “Inspect access with an agent”

Discover your Workspace with monomer_list using {"path":"workspaces"}, then read workspace with monomer_read and its workspaceId. Follow availableOperations to read workspace/access and see your role and the Workspace’s reportingTimeZone. A Viewer can use the Page reader paths; an Explorer or higher can inspect current Lineage through workspace/lineage/relations, workspace/lineage/semantic-models, and workspace/lineage/metrics.

Lineage describes current dependencies. It does not contain per-resource access decisions. Follow returned paths and use the required list limit from 1 to 100.

An Owner can read workspace/authorization for direct members and their roles. Read the target member, then send its advertised set-role entry to monomer_describe before constructing the input. After confirming the target member and intended role with the user, call monomer_invoke:

monomer_invoke input
{"workspaceId":"01942b04-6e00-7000-8000-000000000001","path":"workspace/members/01942b04-6e00-7000-8000-000000000002","action":"set-role","input":{"kind":"WORKSPACE_MEMBER_ROLE","role":"EXPLORER"}}

Read the member and authorization snapshot after the change. A 403 does not authorize an agent to change its own role. Agent requests always require current direct Workspace membership, including when public access is on.