Projects and organization

Choose a project beneath the logo in the sidebar. Dashboards, Queries and Workflows share that collection filter, including their saved charts, actions and panels. The choice is remembered per organization. Canonical /projects/:id/... links select that project's context, including when opening an item or folder. Older unscoped resource links keep the remembered collection selection and resolve the item's stored ownership independently; a remembered project must not block a directly shared item in another project. Switching projects in the sidebar opens that collection's root. Item ownership and access never come from browser storage. Sources, settings and team membership remain shared at the organization level.

All projects shows everything the caller can access. Unassigned contains existing work and resources created without a project. Nothing is automatically moved when projects are introduced.

Create, rename or remove projects from the sidebar picker. Use a card's menu or select several library items to Move to project. Removing a project returns its resources to Unassigned. IDs, definitions, chart bindings and publications stay intact, and neither browsing nor organizing executes customer queries.

New library resources use the selected project. A chart created through the API without an explicit project inherits its saved query's project. Creating within a folder or adding a new panel to a dashboard uses that parent's saved project. Editing an item preserves its stored projectId, even when the sidebar has a different project selected. A dynamic dashboard and all its component views move together; its referenced queries, charts, actions and panels remain reusable across projects. Dashboard folders belong to one project. Moving a dashboard to another project removes it from its old folder. Use a folder's three-dot menu to Move to project. Its dashboards and all their component views move together and remain in the folder, including published dashboards. Empty folders can move too. The same destination picker supports existing projects, a new project, and Unassigned. Moving an open folder keeps it open. When its URL has an explicit project context, both the URL and sidebar follow the destination project (or Unassigned). Moving it from the library keeps that library's current filter. An existing dashboard view must be in the destination project before attaching it to another dashboard; use the same project move operation first.

Shared operations and accessCopy Anchor Link

The contracts catalogue exposes the same project operations through HTTP, the native and HTTP SDK, CLI, MCP and assistant tools:

const { project } = await client.projects.create({ name: 'Customer support' })
await client.projects.assign({
  projectId: project.id,
  resources: [
    { type: 'query', id: queryId },
    { type: 'dashboard', id: dashboardId },
  ],
})
const { queries } = await client.queries.list({ projectId: project.id })
const { dashboards } = await client.dashboards.list({ projectId: project.id })
// Omit projectId to list all accessible items; use 'unassigned' to list unassigned items.

Projects organize resources within the existing organization. Each item's nullable projectId foreign key records its membership. Project grants apply to their contained queries, charts, actions, panels, dashboards and folders; Run applies to runnable items. Direct item sharing is additive: sharing one item does not grant access to its project or neighboring items. A read-only item share does not override broader project access. Every list and count uses the same shared authorization rules.

Project Write allows creating and editing its items; Write on one item alone does not allow creating siblings. Existing organization-wide roles and grants still apply. Run remains explicit: project Write or Admin does not grant Run, source SQL access or database mutation rights. Existing source and data checks, and approved dashboard runtime rules, still govern execution.

API keys, MCP and assistant tools intersect delegated scope with the user's current access. They resolve membership from storage on each operation, so moves, grant revocation and project deletion take effect without copying grants to items. Removing a project ends its inherited access while retaining direct shares.

Moving requires Write on each selected resource and its old and destination projects. Folder moves also require management of that folder and Write on every contained dashboard; a concurrent contents change rejects the move. Removing a project requires project Admin. Assignments run in one organization transaction and reject concurrent membership changes. Deleting a project uses nullable foreign keys to preserve saved work.

The additive metadata migration leaves existing resources unassigned and does not rewrite saved specifications or published artifacts.