Organizations & workspaces

Everything in Golden Reports lives somewhere in a three-level hierarchy: organization → workspace → project. This page explains what each level is for, how membership works, and how to plan your hierarchy as your usage grows.

The hierarchy at a glance

Organization                  - the tenant. Billing, members, integrations.
└── Workspace                 - a team's content space. Sources, contexts, themes, reports.
    └── Project               - a folder of related reports.

• One tenant per organization. Multi-tenancy is structural: an organization's data is isolated from every other organization's. There is no cross-organization sharing.
• One or many workspaces per organization. A small team might use a single workspace; an enterprise might run dozens (one per product line, one per region, one per regulatory domain). Workspaces don't share content by default.
• Projects are folders. They organize reports within a workspace. They are not a new permission layer.

Organizations

The organization is the unit of billing and identity.

• Created when a new tenant is provisioned.
• Holds the plan, credit balance, and billing details under the Billing settings.
• Owns members - every user in the system belongs to one or more organizations.
• Owns integrations - connectors, identity providers, marketplace installs.

You can be a member of more than one organization. The Manager's organization switcher (top-left) lets you move between them.

Members and roles

Organization members fall into one of three top-level roles:

Roles at this level are coarse. Most fine-grained permissioning happens inside a workspace - see Sharing & permissions.

Workspaces

A workspace is the team's content space. It owns:

• Data contexts defined over the organization's data sources.
• Themes that style its reports.
• Assets (images, fonts, logos) for those themes and reports.
• Reports, organized into projects.
• Forms, when you collect input from users.

Data sources themselves live one level up, at the organization. A workspace consumes them through its data contexts, subject to the data access policies that grant the workspace permission to use each source.

Workspaces are the unit of separation between teams that do different work with different data. The Finance workspace doesn't see Operations' reports unless someone explicitly cross-shares - which Golden Reports doesn't currently support. If teams need to share, they share at the report level (export, embed) or the data context level (republish a context in the target workspace).

Creating a workspace

From the Manager's left rail (or the empty state on first login), click New workspace. Give it a name, pick a default theme, and invite members.

A workspace has its own member list that's a subset of the organization. By default new members are added with the Member role; promote to Editor or Admin to grant authoring or administrative rights inside the workspace.

Member roles inside a workspace

Combined with data-access policies - covered in Sharing & permissions - these give you both broad and narrow control.

Projects

Inside a workspace, projects are folders for reports. They exist to keep the report list scannable; "everything in one big list" doesn't scale past a couple of dozen reports.

A project has:

• A name and an icon.
• A list of reports inside it.
• An optional description.
• Audit metadata.

Permissions do not attach to projects - a project's contents inherit the workspace's grants. If you need a slice of reports a particular person can see, that's a data-access job, not a "private project" feature.

Designing the hierarchy

Two questions worth thinking through before you spin up workspaces:

1. Is this team's data fundamentally different?

If yes, separate workspaces. Operations data and Finance data have different stewards, different sensitivity, and different reports - they belong apart. The boundary makes governance honest: a quarterly review of "who has access to Finance data" is a workspace-member-list review.

2. Are these reports related enough to share themes, contexts, and assets?

If yes, one workspace. Themes are workspace-scoped; if your marketing team has 30 PDF templates that all use the same brand assets, they want them all in one workspace so a theme tweak propagates.

A useful heuristic: a workspace is a team's universe. One team, one universe, even if the team produces many kinds of reports.

Switching workspaces

The Manager's left rail shows the current workspace at the top. Click it to switch. URLs include the workspace identifier, so deep links respect which workspace you're in. After sign-in, the Manager remembers your last workspace and redirects there.

What's not in the hierarchy

A few things you might expect to find that aren't here:

• Folders nested inside projects. Projects are flat. If a project gets too big, split it.
• Cross-workspace sharing. Currently unsupported. Export, embed, or duplicate to share content across workspaces.
• Per-user private workspace. All workspaces are shared. If you want a personal sandbox, create one and don't invite anyone.

Next

• Grant access at the data layer: Sharing & permissions.
• Collect input from end users: Forms.
• Manage logos and other binaries: Assets.