Until now, orgadmin.ai was set up for one person at a time. You could share a workspace, but billing, org logins and visibility were all built around a single user. That works for a solo admin or a consultant. It does not work for a team of five admins and developers who share a production org, three sandboxes and a release calendar.
orgadmin.ai now has company workspaces. One workspace for the whole team, one subscription billed per member, and a clear view for the people in charge of who is doing what in which org.
This post covers what company workspaces do, who they are for, and why they suit a team better than giving everyone Claude Code and the Salesforce CLI and hoping for the best.
What a company workspace gives you
A company workspace is a normal orgadmin.ai workspace that colleagues can join. The person who sets it up becomes the owner. Their current workspace converts in place, so nothing they have already built is lost, and their subscription becomes the team's.
From there:
- Invite people by email, or straight from a Salesforce org. Pick the users of an org you have connected and invite them in one go. An invitation only works for the email address it was sent to, so a forwarded link is useless to anyone else.
- Give each person the right role. There are four: owner, admin, member and read-only. Admins manage people. Members do the work. Read-only users can explore orgs and ask questions without being able to change anything.
- Decide who can deploy, separately from who manages people. "Deploy & write" is its own toggle. You can let a developer deploy, run data loads and change permissions without also letting them invite people or see the invoice. Owners and admins always have it. Read-only users never do.
- Decide who handles billing. The owner always can. Any admin can be given the billing toggle as well, and payment-failure emails go to every billing admin, not just one inbox.
- Each person uses their own Salesforce login. Everyone connects each org with their own Salesforce user, so Salesforce's own permissions and audit trail still apply to each person. They do not need to set up a Connected App again: they pick the one the team already uses, and an "Orgs your team uses" list lets them connect a colleague's org in a click.
- Billing follows the team. One subscription, one invoice, with the seat count matching the number of members. Add someone and the seat is added, prorated. Remove someone and it drops. Pending invitations do not count.
See what your team is doing
This is the part most teams are missing today. Owners and admins of a company workspace get three views:
- Team activity. Usage across the workspace over a period you choose: active members, deployments, Studio work, AI chats and MCP tool calls, member by member, with a feed of recent work. It shows counts, titles and dates. It never shows what someone typed in a chat, what a query returned, or any record data.
- Team deployments. Every deployment and validation anyone has run: what it was, who ran it, which org it went to, whether that org was production or a sandbox, how many components, whether it passed, when it started and how long it took. You can filter by member, by deployments or validations, and by status. Each run opens as a read-only record showing the components and the error Salesforce returned for any that failed.
- Team projects. Every Development Studio project, its owner, its saved versions (with their messages and line counts) and where each one was deployed.
You can also open a member's page to see their latest deployments and projects together.
A team lead can now answer "what went to production this week, and who sent it?" in about ten seconds, without asking around in Slack.
When someone leaves
People leave teams, and contractors finish projects. When that happens, you want their access to every org gone straight away, not whenever someone remembers.
In a company workspace, an admin opens the member list and chooses Remove from workspace. In one step:
- they lose access to the workspace straight away;
- every org connection they made in it is disconnected: the token is revoked at Salesforce, and the stored credentials and the metadata pulled through their login are deleted;
- their seat comes off the next invoice, prorated.
Their deployments, projects and activity stay with the workspace, shown under their name, so the team's history does not develop holes when people move on. If they come back later, they reconnect and pick up where they left off.
One thing worth saying plainly: removing someone from orgadmin.ai does not deactivate their Salesforce user. That is still part of your offboarding. If you need to deactivate or freeze users in bulk, the User Management tool does that too.
Why not just give everyone Claude Code and the Salesforce CLI?
Many Salesforce teams have already tried this, and it is a sensible thing to try. Claude Code is a very good coding agent. The Salesforce CLI is free and does a lot. Put them together and one developer can retrieve metadata, change Apex or a Flow, and deploy it from a terminal very quickly.
The problems show up when it is a team doing this, not one person.
You cannot see what the team is doing
With Claude Code on the CLI, each person works on their own laptop. Their conversations, the changes the agent made and the commands it ran all stay on that machine. When a deployment goes out, Salesforce records it in that org's Deployment Status page and its Setup Audit Trail. But that view is per org, it is in Setup, and it does not tell you what the change was meant to do, which branch or project it came from, or what else that person did in the other four orgs that day.
If you want a team-wide picture, you have to build it: a shared Git repository everyone pushes to, a CI pipeline that does the deploying, and the discipline to never deploy from a laptop. That is a reasonable setup for a mature DevOps team. Most admin and developer teams are not there, and many do not need to be.
In a company workspace, the picture exists from day one. Every deployment and validation, from either an org comparison or a Studio project, lands in the team log under the person who ran it. Nobody has to remember to update anything.
Access lives on laptops
sf org login web stores an OAuth refresh token on the developer's machine. It keeps working until it is revoked or the Salesforce user is deactivated. When someone leaves, you need to know every org they logged into from every machine they used, then revoke each token, either in Setup under the connected app's OAuth usage, or by deactivating their user in every org.
For an employee with one Salesforce user, deactivation covers it. It gets harder with contractors and consultancies. A consultant often has users in several client orgs, and some of those users stay active because they are shared, or because the client manages them. A token on a laptop you no longer control is exactly the kind of access that gets forgotten.
In a company workspace, every org connection a member made is tied to the workspace, and Remove revokes all of them at once.
Everyone has the same power
On the CLI, if a developer can authenticate to production, they can deploy to production. Any guardrail is a convention: "please run a validation first" in the team wiki.
In orgadmin.ai, the rules are in the product. Read-only members cannot write to any org. Members need the "Deploy & write" toggle before they can deploy, run a data load or change permissions. Production deployments need an explicit confirmation, and a lock stops two people deploying to the same org at the same time.
You still get to use Claude Code
This is not a choice between the two. orgadmin.ai has an MCP server, so anyone on the team can point Claude Code (or Codex CLI, or Claude Desktop) at their orgs through the workspace and get around sixty org-aware tools, running on the AI subscription they already pay for. Their MCP tool calls are counted in team activity like everything else, and they stop working when the member is removed. We wrote up the setup in how to connect Salesforce to Claude Code with MCP.
A side-by-side summary
| Claude Code + Salesforce CLI | orgadmin.ai company workspace | |
|---|---|---|
| Who deployed what, across all orgs | Per org, in Setup, or a pipeline you build | One team log, filter by person, kind and status |
| What each person built | On their laptop, or in Git if they pushed | Studio projects, versions and deployments, read-only for admins |
| Who may deploy | Anyone who can log in | Per-member "Deploy & write" toggle; read-only role |
| Removing a leaver | Find and revoke every token, org by org | One click revokes every connection they made |
| Their history after they leave | Whatever is in Git and Setup | Kept in the workspace under their name |
| Billing | Each person's own AI plan, plus tooling | One subscription, seats follow members |
| Using Claude Code | Yes | Yes, through the MCP server, and it shows in team activity |
Who company workspaces are for
- In-house Salesforce teams with a few admins and developers sharing production and sandboxes.
- Consultancies and partners who bring contractors on and off client projects and need access to go when the project ends.
- Team leads who are asked "what changed?" after something breaks, and want to answer from a screen instead of asking around.
- Junior-heavy teams where you want people learning in sandboxes with read-only or member access before they get deploy rights. Our guide to onboarding junior admins and developers shows one way to stage that.
Getting started
If you already use orgadmin.ai, open Members in the sidebar and turn your workspace into a company workspace. Your orgs, projects and subscription come with you. Then invite your team by email or from one of your orgs.
If you are new, start a free trial, connect an org, and invite your team. Company workspaces are included on every plan, and you pay per member.
To see everything company workspaces can do, read the company workspaces feature page.