Company Workspaces

Company workspaces for Salesforce teams

One workspace for your admins, developers and contractors, billed per member. Invite people by email or straight from a Salesforce org, choose who may deploy, see every deployment and Studio project the team runs, and remove someone’s access to every org in one step when they leave.

Something changed in production, and the only way to find out who sent it is to ask around. Every deployment and validation in the workspace, newest first: 47 runs across four people. Priya validated a release against production, then deployed it; Tom’s UAT deployment failed on 2 of 9 components. Each name opens a read-only record of the run.

What you can do

  • Turn your workspace into a company workspace in place: your orgs, projects, history and subscription come with you
  • Invite people by email, or pick them from the users of a Salesforce org you have connected
  • Invitations work only for the address they were sent to, so a forwarded link is useless to anyone else
  • Four roles: owner, admin, member and read-only
  • A separate “Deploy & write” toggle per member, so a developer can deploy without also managing people or billing
  • Billing admins: the owner plus any admin you give the toggle to, and payment-failure emails reach all of them
  • Everyone connects each org with their own Salesforce login, reusing the team’s External Client App, with an “Orgs your team uses” list to connect in a click
  • A per-member “File Backup” toggle, separate from “Deploy & write”, for people who archive files but never deploy
  • Team activity for owners and admins: usage by member over the period you choose, plus a feed of recent work
  • A breakdown by member that ranks the team on the measure you pick: deployments, lines changed, files downloaded or deleted, AI chats, data loads, active days and more
  • A team deployment log: every deployment and validation, who ran it, which org, how many components, the outcome and how long it took
  • Read-only views of every Development Studio project, its versions and where each one was deployed
  • Remove a member and every org connection they made is disconnected at once, with their token revoked at Salesforce
  • One subscription, seats that follow the member count, prorated
  • Members who also have a personal workspace open straight into the company one, with a one-click switch between them

How it works

1

Convert your workspace

Open Members and turn your workspace into a company workspace. Nothing you have built moves; your subscription becomes the team’s.

2

Invite your team

By email, or straight from the users of a connected org. Give each person a role, and switch on “Deploy & write” for the people who ship.

3

Everyone connects with their own login

Each member connects the orgs they work in with their own Salesforce user, so Salesforce’s permissions and audit trail still apply to each person.

4

Watch the work, not the people

Owners and admins see team activity, every deployment and every Studio project. Counts, titles and outcomes only, never chat contents or record data.

Why it's different

Visibility and offboarding that a laptop CLI cannot give you

Claude Code on the Salesforce CLI is a strong tool for one developer, but each person’s work and org logins live on their own machine. Salesforce shows deployments per org, in Setup, and a leaver’s refresh tokens keep working until someone finds and revokes each one. A company workspace puts every deployment and project in one team log and revokes every connection a member made with one click. You can still use Claude Code: point it at the workspace through the MCP server and its tool calls show in team activity too.

Try asking

  • Answer “what went to production this week, and who sent it?” from one screen
  • Let a junior admin explore production read-only while they learn
  • Give a contractor deploy rights for a project, then remove every org login they made the day it ends
  • See which members actually use the platform before the renewal
  • Let an assistant archive old case attachments with File Backup without giving them rights to deploy
  • Keep a departed developer’s deployments and projects on record under their name

Company Workspaces — questions

Per member, on the plan the workspace is on. The seat count follows the number of members automatically and is prorated when someone joins or leaves. Pending invitations do not count.

They lose access straight away, and every org connection they made in the workspace is disconnected: the token is revoked at Salesforce and the stored credentials and pulled metadata are deleted. Their deployments, projects and activity stay with the workspace. It does not deactivate their Salesforce user, so do that as part of offboarding too.

No. Team activity shows counts, titles and dates. It never shows what anyone typed in a chat, what a query returned, or record data, and it never shows component source code.

No. Each member connects each org with their own Salesforce user, so Salesforce’s own permissions and Setup Audit Trail still apply to the person who acted. They reuse the team’s External Client App, so nobody has to retype a client id or secret.

Only with the “Deploy & write” toggle, which an admin grants. Owners and admins always have it; read-only members never do. Production deployments still need an explicit confirmation each time.

Read next

Put Company Workspaces to work on your org

Every AI feature on your own provider key, from A$14.99 per user per month.

  • 14-day free trial
  • No credit card required
  • Cancel any time