Projects

A project is a self-contained workspace within your organization. Creating one gives you a blank console: no pipelines, filters, patients, or configuration carried over from other projects. Use it to test changes safely (for example in a dev environment) before replicating a validated setup elsewhere, or to keep distinct workflows separate altogether. Projects are managed under Settings > Projects, separate from day-to-day console work but easy to reach when you need to create, switch, or clean one up.

​

Switching projects

A project selector sits in the sidebar for every org member, not just admins, so it’s always visible which workspace you’re in, even when the sidebar is collapsed. Opening it lists your organization’s active projects (the default project is labeled) and switches your whole console view when you pick one. A “Manage projects” link at the bottom takes you to the full Settings page.

​

Creating a project

Add a new project at any time from Settings > Projects. It starts completely empty: no pipelines, filters, or data carried over. This is the typical first step of a dev-to-prod workflow: build and validate a setup in a dev project with test patients, then move to production once it’s ready. Each project has a project ID (a slug, auto-derived from the name and editable at creation): the handle you pass to the SDK via project= and the X-Olira-Project header. See Accessing patient state for how this is used from the SDK.

​

Duplicating a project

Duplicating an existing project copies its full configuration, platform config, pipeline templates, and cohort definitions, but never patients, logs, or patient state. This supports the dev-to-prod workflow directly: once a dev project’s setup is validated, duplicate it into a new project instead of rebuilding from scratch.

​

Deleting a project

Deletion is intentionally friction-full to prevent accidental loss:

1. Select delete on a project.
2. A warning dialog explains that the project moves to the Deprecated list, fully intact and restorable.
3. A second dialog requires you to type the project’s exact ID to confirm. This reinforces that the action affects the full project.
4. Once confirmed, the project is not immediately erased. It moves to the Deprecated list.

The default project cannot be deleted; there is no delete option for it in the Console.

​

The Deprecated list

Deleted projects land in a Deprecated section of the same Projects settings page. From there, you have two options:

• Restore: bring the project back, fully intact with its prior configuration.
• Permanently delete: type the project’s exact ID to confirm, then remove the project and its data for good. No recovery path. This is blocked while the project still has patients; remove them first.

This gives you a safety net against accidental deletion, while still allowing a clean, final removal when a project is truly no longer needed.

​

What’s project-scoped vs organization-level

A new project starts with none of the project-scoped items above. Duplicating a project copies only the configuration rows (platform config, pipeline templates, cohort definitions), never patients, logs, or patient state.

​

Summary

See Accessing patient state for how project scoping works from the SDK, and the Projects reference for create_project, duplicate_project, and related method docs.