Workspaces

A Workspace is where work on your app happens. Each one holds a single piece of work, roughly what you'd put in one pull request: a new empty state, a copy pass on the settings page, a redesign of the pricing table. It has its own copy of your app running at its own address and its own history of every edit. Its code changes go on a branch in each repository it touches: a new branch when the work starts in Soffi, or the pull request's own branch when you open a pull request someone already raised.

Starting a Workspace

New work starts from a published Project, on the Project's base branch in each repository. You can't start a Workspace from some other branch; the base is part of the Project's setup. To work from a feature branch, an Admin creates a Project for that branch. On the Workspaces page, choose New, pick the Project, optionally attach a Linear or Jira ticket, name it, and create it. If you attach a ticket, Soffi reads it and starts by proposing a plan for the work.

Soffi then deploys a fresh copy of your app for the Workspace from the Project's setup, so it's ready to edit without anyone configuring anything. Creating a Workspace needs the Editor role or above. See Roles and permissions.

A Workspace can also start from a pull request opened outside Soffi. SoffiBot comments on it with a Deploy in Soffi link, which opens a Workspace on that pull request's branch, and shipping from it pushes to that pull request rather than opening a new one. See PRs opened outside Soffi.

What's inside

Every Workspace has the same tools: the Preview of your running app, the Style Editor, Comments and video comments, Code, the Design System panel, History, and Soffi, the agent in every Workspace, who can make changes for you from a plain-language request. See Working in a Workspace for each one.

Working together

A Workspace isn't a private space. Several people can be in the same Workspace at once, seeing each other's cursors and edits, and anyone in your Organization can open it from a shared link. A designer might shape the layout while a PM tightens the copy and an engineer checks the code, all on the same running app. See Working together.

People with the Reviewer role open a Workspace in the Review layout, where they can look at the app and leave comments but not edit. If they need to make changes, they can choose Request edit access from there.

Isolated from everyone else's

Because each Workspace has its own running app, work in one never leaks into another. Your teammates can each have their own Workspace on the same Project at the same time, and your edits never show up in theirs. Your work reaches the rest of the team through a pull request, like any other change to your code. See Previews and deployments.

What comes the other way is kept current for you. Updates from the Project and new commits on the Workspace's pull requests come into it in the background, and Soffi asks you only when an update would change UI you're editing. See Staying up to date.

One pull request per repository

A Workspace can change more than one repository, for example a design token in your design system and the screen in your app that uses it. When you Ship, Soffi opens one pull request in each repository the Workspace changed, and shipping again later pushes new work to those same pull requests. A Workspace opened from an existing pull request has just that one, and Ship pushes to it. See From Workspace to pull request.

On the Workspaces page, each card shows the pull request number, the attached ticket, the Project, and when it was last active. When all of a Workspace's pull requests have merged, Soffi archives the Workspace.