Workspaces and roles

Two engineers in the same group should not each rebuild the same trial chemistry, and a project lead should be able to read a colleague's run without asking for a screenshot. A workspace is how Phases scopes that: it owns the materials, the conversations, the runs and the artifacts created inside it, and it decides who may write.

The two kinds of workspace#

You get a personal workspace automatically. It is created the first time you sign in, named My Workspace, with a slug derived from the local part of your email address, and you are its admin. Each user has exactly one, and it cannot be deleted — its contents are removed through ordinary chat and run cleanup, not by removing the workspace itself.

An organization workspace is one you create for a team. In the product it is a modal titled Create a new workspace with two fields, Workspace name and URL slug (auto-derived from the name, editable). Creating it lands you at /ws/<slug>, and chats inside it live at /ws/<slug>/chat/<id>.

Only organization workspaces have members, invites and a Members tab. A personal workspace has none of that by design.

Roles#

There are exactly three roles, ordered viewer < member < admin.

A viewer is genuinely read-only, and the refusals are explicit rather than silent. Asking a simulation tool to run returns This workspace role cannot run simulations. Ask a workspace admin for member access. Saving a material returns Saving workspace materials requires a workspace member or admin role. Submitting a chat turn is rejected with Workspace viewer access is read-only. The database repeats the writer check at commit time, so a request that was authorized just before a demotion cannot slip through afterwards.

Two guards protect the owner. The workspace owner cannot leave their own workspace — the attempt returns The workspace owner cannot leave. Transfer ownership or delete the workspace. — and an admin cannot remove the owner (Cannot remove the workspace owner) or demote the last remaining admin.

Inviting people#

Invites are email-based and admin-only, and they exist only for organization workspaces. Inviting into a personal workspace is refused.

From Settings → Members, the Invite Member form takes an email address and a role (admin, member or viewer) and sends the invite. Pending invites are listed below the member table with their email, role and a revoke action.

An invite expires after 7 days. The recipient gets an email with the subject You're invited to join <workspace> on Phases Copilot and a link to /invite/<invite-id>, which shows You're invited with the workspace name and an Accept Invite button; an expired link instead tells the recipient to ask the workspace owner for a new one. If the deployment has no mail provider configured, the invite row is still created — the email is not sent, so you can pass the link along yourself.

Acceptance is strict, and this is a feature rather than an obstacle: the signed-in user's own confirmed email address must match the invited address. A different account, an unverified email, an expired invite or a second attempt at an already-consumed invite all fail closed. The public preview of an invite exposes only the workspace name and slug, the role and the expiry — never who was invited or who invited them.

If someone signs in for the first time with an invited address, the invite is processed as part of their first login, so they land in the workspace without having to find the email again.

Shared materials#

The most useful thing a workspace holds is its material library. A chemistry saved to the workspace is available to every member, in every chat, in the material dropdown of every configuration card under a Workspace Materials group — see Workspace materials and Your own chemistry.

The Material base workbench at /ws/<slug>/materials (also reachable as /ws/<slug>/settings/materials) is headed with the eyebrow Workspace · Materials over the title Material base. Its subtitle is a live count of what you can reach — the catalog grade count, followed by · N in this workspace when the workspace holds any of its own. That first number is the honest measure of the catalog: in the hosted product it reads a little over two thousand built-in grades, not the short reference list people often assume. See Material catalog and Finding your steel.

The workbench has three scopes: Material (Inspect one material), Compare (Compare several materials) and Family data (Aggregate a family or group). Admins and members also get a + New material button; viewers do not.

Built-in catalog grades stay read-only for everyone. To change one you clone it into a workspace material first — the built-in composition grid is disabled and the header action reads Clone to edit. Compare two grades shows the comparison flow, and Families and data sources explains what the Family data scope is aggregating.

Saving a material whose chemistry is identical to its base grade is refused, so the library holds real recipes rather than renamed built-ins.

Settings#

Workspace settings sit at /ws/<slug>/settings, with a Back to chat link and up to four tabs:

• General — everyone
• Members — organization admins only
• Usage — everyone
• Feature flags — organization admins only

The two admin tabs are hidden from the navigation for anyone else; a member who opens the URL directly still gets a read-only page rather than an error.

Feature flags#

The Feature flags tab, headed Workspace features, is where an organization admin sees what this workspace has switched on. It renders every control the backend returns, grouped into three areas:

• Product access — Features and tools available in this workspace. The four simulators, the material knowledge base and flow stress, Simulator Studio and its authoring and execution runtimes, automatic simulation studies, web search, Python and engineering analysis, scientific validation, RSW process windows, and the organization-only invite and collaboration controls.
• Platform rollouts — Operational capabilities enabled for this workspace. Durable execution, agent-runtime and compatibility switches that decide how work is executed rather than what you can do.
• Usage limits — Allowances applied to this workspace. Read-only; the page says Numeric allowances are managed by a platform admin.

Each control shows its friendly label, its description, its raw key, a Requires: line when it depends on another control, a risk badge of Use care or High impact, and a badge reading either Global default or Workspace override. A control a platform admin has pinned carries an Enforced globally lock and cannot be overridden here. Flag resolution is fail-closed: a locked platform default wins over any workspace override, and an unknown flag resolves to disabled.

Overrides are organization-only. A personal workspace has no Feature flags tab at all, and opening the URL redirects back to Settings — its values still apply, they are simply the platform defaults. Workspace limits and features is the full reference: which controls exist, which are on by default, and which tools each one gates.

When a simulator is disabled, it disappears from the simulator tab strip and its in-chat configuration card is replaced by a notice telling you it is disabled for this workspace and to ask your admin. The agent behaves the same way: it acknowledges the capability exists and points at the workspace admin instead of pretending the request is impossible.

Usage#

The Usage page shows three meters — Simulation runs, Messages and Storage. Simulation runs and Storage are measured against the limits.max_runs_per_month and limits.storage_mb values; Messages is a plain count with no limit attached. The defaults are 100 runs and 500 MB for a personal workspace and 500 runs and 5000 MB for an organization workspace. Neither number can be changed from the workspace — they are set by a platform admin.

Treat these as informational. They are displayed counters; nothing in the backend reads them to refuse work, so hard enforcement and a monthly reset are future work, not a guarantee you can plan capacity around.

What a workspace does not change#

Membership decides who may write, not what the physics will do. The material rules, the confirmation gate on custom chemistry, the 20-grade RSW coverage and the V-Gleeble table requirements apply identically in every workspace — see Known limits and Capability matrix. Runs created in a workspace are stored and versioned exactly as described in Sessions, runs and artifacts.