> For the complete documentation index, see [llms.txt](https://docs.pipekit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pipekit.io/using-pipekit/workspaces.md). # Workspaces Switch between the workspaces you can reach, and find your runs, pipes, and templates in each one. {% hint style="info" %} Workspaces exist only when your organization uses [multi-tenant RBAC](/organizations-and-access/rbac.md). For the two permission systems, refer to [Access Control](/concepts/access-control.md). If you see no workspace switcher in the navigation bar, your organization uses basic permissions, and this page does not apply. If you see `You don't have access to any workspaces yet` instead, ask your Org Admin to add you to a workspace. {% endhint %} A workspace groups the runs, pipes, and templates your team works with. You see the workspaces your role bindings reach, and nothing else. An Org Admin sees every workspace in the switcher, but without a workspace role its lists stay empty. The interface follows the workspace you are in. ## Your role in a workspace Your role in a workspace decides what you can do there: * A Viewer can see pipes, runs, logs, and templates. * An Editor or Workspace Admin can also create and change pipes, templates, and secrets, and submit, stop, and resubmit runs. If a button you expect is missing, such as `Stop` or `Resubmit`, your role in that workspace does not allow it. Ask your Org Admin which role you hold. For every action per role, refer to the [permission reference](/organizations-and-access/rbac.md#permission-reference). ## Switching workspaces The workspace switcher sits in the navigation bar and shows the workspace you are in. Click it to see every workspace you can reach. Type to filter the list by name, then select a workspace to switch to it. Where you land depends on the page you switch from: * From a list page, such as `Runs`, `Pipes`, or `Templates`, you arrive at the same list in the new workspace. The same applies to create pages, metrics, and the page for a single cluster. * From a run, you arrive at the `Runs` list in the new workspace. * From a pipe, you arrive at the `Pipes` list in the new workspace. * From a template, you arrive at the `Templates` list in the new workspace. * From a page that is not scoped to a workspace, such as your organization settings, you arrive at the `Runs` list in the new workspace. A run, pipe, or template belongs to one workspace, so its page does not exist in the next one. Selecting the workspace you are already in closes the switcher and keeps you on the page. On pages that are not scoped to a workspace, the switcher reads `Select workspace` until you pick one. Pipekit remembers the last workspace you used in each organization and returns you to it on your next visit. Until you have picked one, it opens the first workspace alphabetically. ## Workspace URLs A page scoped to a workspace carries the workspace name in its URL: ``` /w//runs ``` Runs, pipes, templates, metrics, and the page for a single cluster are scoped this way, along with the pages beneath them. Organization settings, the `Clusters` list, user settings, and the sign-in pages are not scoped to a workspace and keep their existing URLs. A link without a workspace in its URL still works: * A link to a list page, such as `/runs` or `/pipes`, opens that list in your last used workspace. * A link to a pipe or a run, such as `/pipes//runs/`, opens it in the workspace that owns the pipe. The tab, query string, and anchor in the link are kept. * A link to a template or a cluster opens at the URL you saved. * A link to `/w//clusters` opens the `Clusters` list at `/clusters`. Links in alerts, Slack messages, and CLI output use this form, so they open in the right workspace. ## Running a pipe in a workspace A pipe runs only on the cluster and namespace pairs its own workspace holds. A run, cron trigger, or template run that targets any other namespace fails with an error that names the namespace and the cluster: ``` namespace on cluster is not in the workspace that owns this resource (target_not_in_workspace) ``` Ask your Org Admin to add that namespace to the pipe's workspace. A workflow you submit to a namespace that no workspace holds fails with a different message: ``` namespace on cluster is not in any workspace (target_not_in_workspace) ``` Ask your Org Admin to add that namespace to a workspace you can run in. ## Lists outside a workspace The CLI and the REST API do not need a workspace. A list call that names no workspace returns runs, pipes, and templates from every workspace you can view. Pipekit refuses a request for a run or pipe outside the workspaces you can reach. ## When a workspace is not available to you In the UI, Pipekit treats a workspace you hold no binding on as one that does not exist. The UI shows a not-found page rather than a permission error, so nobody can use a URL to discover which workspaces exist. An Org Admin is the exception: an Org Admin can open every workspace, but sees empty lists without a workspace role. A pipe or run you cannot read shows the same not-found page. If you hold no workspace binding at all, you see no workspaces. Ask your Org Admin to add you to a workspace.