Sharing & permissions

Permissions in Golden Reports compose from four layers: identity (who you are), workspace membership (which team you're on), data-access policies (which datasets you can touch), and per-report shares (which specific reports you can read or run). This page explains each and how they combine.

Identity

Users sign in with an email address or through a supported OAuth provider - Google, Microsoft, and a handful of others. One sign-in covers the whole platform. Company SSO (SAML/OIDC) is on the roadmap but not part of the current release.

Password policies, multi-factor authentication, and session lifetimes are configured by org admins from Manager → Identity.

Layer 1: organization role

When you sign up, you become an owner of your organization. Owners can invite admins and members. Roles are coarse:

For most users, the org role only decides whether they see settings pages. Day-to-day capabilities come from the next two layers.

Layer 2: workspace membership

Inside an organization, you join one or more workspaces. The workspace role decides what you can do to the workspace's content:

"Editor" can author reports but not touch data contexts or themes. "Viewer" can run and read existing reports but nothing more. "Workspace admin" can change everything inside the workspace, including the member list. Data sources themselves live one level up at the organization and are managed by org admins.

Membership is granted by a workspace admin from Workspace → Members → Invite.

Layer 3: data-access policies

Workspace membership says whether you can use the workspace; data-access policies say which datasets inside it.

A data-access policy is a named grant that ties together:

• Subjects - users, groups, or roles the policy applies to.
• Resources - specific data sources, data contexts, or both.
• Permissions - read, query, manage.

A worked example:

Policy: "Finance read-only"
  Subjects: members of the Finance group
  Resources:
    - data source "Prod data warehouse"
    - data context "Sales schema v3"
  Permissions: read, query

Anyone in the Finance group can run reports that touch those resources. They can not register new data sources (that's an org-admin action), edit the context, or query other organization-level sources they haven't been granted. The Manager's Data access page is where these policies are authored.

Why this layer exists: it lets workspace admins onboard analysts without giving them blanket workspace access. Many real organizations need "this group of analysts can use these three sources and nothing else", which is too narrow for a workspace role and too broad for a per-report share.

Layer 4: per-report shares

A specific report can be shared with people who otherwise wouldn't have access to it.

From the Manager, Share a report and choose:

• Anyone in the workspace - every workspace member can run it.
• Specific people - a list of users (inside or outside the workspace).
• Anyone with a link - a signed link that grants run-only access without sign-in. Treat this as a public exposure: anyone who comes into possession of the link can run the report. Restrict by org policy where appropriate.
• Embed - produce a signed embed URL with parameter values pre-baked.

Shares are additive. A user gets the union of every grant: their workspace role, every data-access policy they're a subject of, and every report shared with them. The result is the highest privilege any layer grants them - but only for the specific resources each grant covers.

Shares are also revocable. Deleting a share revokes immediately; signed links continue to work until they expire. The expiry window is configurable per org by an admin.

How a request is authorized

When a user runs a report, the platform validates a number of preconditions: a valid session, membership in the correct tenant, the right level of access to the workspace (or a per-report share that grants it), and that every data context and data source the report depends on is reachable under the user's effective policies.

If anything fails, the platform returns a sanitized error indicating only that the user doesn't have access.

Audit

Every grant change - workspace membership added, data-access policy edited, report shared, link generated - is recorded in an audit log scoped to the organization. The log is queryable from Manager → Audit with filters by actor, action, and target.

This is the system of record for compliance reviews. If your security team asks "who could read report X on March 5", the audit log answers it.

What's not (yet) in the permission model

A few finer-grained controls are on the roadmap rather than shipped today: per-field column masking, row-level security driven by caller identity, and time-bounded grants on non-link shares. For column or row-level restriction today, model the restriction at the data-context layer (two contexts with different exposed shapes) or at the database side.

If any of these are dealbreakers for your deployment, talk to your account team.

Best practices

• Use groups, not individuals, in policies. If your identity provider exposes groups via SCIM, map them in and grant to groups. Onboarding a new analyst becomes a group-membership change instead of editing every policy.
• Default to "read". Most policies should grant read + query. Reserve "manage" for the small set of people who edit contexts and sources.
• Don't share workspaces; share workspaces' content. When two teams need each other's reports, share the reports - don't blow up the workspace by adding the other team's members. Workspaces stay clean; sharing stays explicit.
• Audit quarterly. The audit log is only useful if someone reads it. Build a recurring review into your governance cadence.

Next

• Plan your team structure: Organizations & workspaces.
• Restrict what data a report can touch: Data sources, Data contexts.
• Embed reports into other products: Preview & export.