For anyone deciding whether the Studio fits a team, and for whoever would set it up. Using it on your own? The main FAQ answers that version. Ready to install? Go straight to the Organisation deployment guide.
Yes. Each person runs it on their own computer with their own Claude Code, and everyone shares one set of brands, one library and one set of campaigns. Work joins up automatically at the end of each session; nobody emails files around.
This is a genuinely different setup from the single-person version, with its own guide. It is not a setting you flip on an existing install.
One person, once for the whole organisation, and it should be someone who knows the brand rather than whoever is most technical. They tell the Studio about your look, your voice, who you sell to and any rules you must follow, and every campaign inherits it from then on. Nobody repeats it.
It happens after the first person has the Studio running, because you do it by talking to it. Until it is done, campaigns will not start: the Studio says the brand foundation is missing, which is deliberate rather than a fault. See Part C.
More than one brand? Repeat it per brand. Each stays independent, so work never bleeds between them.
Two things. First, two private repositories, one for the code and one for your work. Azure DevOps and GitHub both work, so whichever you already use is fine.
Second, five apps pushed to each person's machine through Intune or Company Portal. All five are in the public winget repository, so there is no packaging work:
Anthropic.ClaudeCode — the only interface your people usePython.Python.3.12 — runs the Studio. A managed deployment also gets
Add to PATH right, which a hand install often does notGit.Git and GitHub.GitLFS — how work, including images and
video, reaches colleaguesGyan.FFmpeg — video qualityA ready-made configuration file ships in the code repository at
deploy/studio-prerequisites.winget.yaml.
Optionally, a SharePoint library if you want colleagues without the Studio to read finished work. That can be added later and nothing depends on it.
No. Once the five apps are deployed, each person opens Claude Code, types one ordinary sentence containing the two repository addresses, and setup runs itself. They never open a terminal, type a command, or install anything, on that day or any day after.
No, and you should not want one. An unsigned script that installs software and clones repositories, handed round on SharePoint, is indistinguishable from the attack it imitates. Most Defender ASR rules block exactly that shape, it triggers credential prompts your staff cannot tell apart from phishing, and it teaches them to double-click executables from a shared drive.
It is also unnecessary. Claude Code is already an approved, installed, audited application on the machine, and it performs the setup itself under the person's own account.
Write on the data repository, because their campaign work saves there and reaches everyone else. Read on the code repository, because they only ever take new versions and nothing they do is written back to it.
Nobody needs Admin. Admin allows deleting the repository, rewriting its history and changing who else has access, and the Studio uses none of that. Granting it to every person is a risk with no upside.
Azure DevOps calls these Contribute and Read.
No. Nobody types a git command in normal use. Claude Code handles it in the background, the same way an app saves your work without showing you the filesystem.
The one exception is the initial setup, which is a short list of copy-and-paste lines done once per person, spelled out step by step in the guide.
Word and Excel files merge when two people edit them. The Studio's files do not. SharePoint would quietly save a second copy called "Bob's conflicted copy", and the Studio would read that as a real, separate piece of work.
A repository is built for exactly this problem. Your people never see it, and SharePoint is still where colleagues read the results.
You get warned before you can cause a problem. Claiming a campaign records who is working on it and until when, and anyone else is told by name if they start changing it.
Claims release when you finish and expire after 8 hours regardless, so a colleague who closes their laptop never blocks you until Monday. You can override a claim deliberately, and the override is recorded.
Not within one deployment. Everyone who can open the shared folder can see every brand. Being straight about this: if a brand must be invisible to a particular person, or you are bringing in someone external who should not see everything, they need their own separate deployment.
Worth deciding before you invite people rather than after.
Each person is fixed to a specific version, so nothing changes underneath them in the middle of a campaign. When a newer one exists they are told, can read what changed, and choose their own moment to take it. If an update causes trouble, they can go back to the previous version.
A new version does not appear on its own. Your organisation has its own copy of the Studio, so an administrator publishes the release into it first; only then are your people offered it. How upgrading works, both halves.
Yes, and for most organisations that is the point. The dashboards are the interface the whole organisation reads, whether or not they have Claude Code. One nominated machine publishes a read-only copy into a SharePoint document library at the end of every session, and everyone else simply opens it in SharePoint like any other document.
Every published page shows when its content was last updated, so a reader can see how current it is rather than having to trust it. Nothing published can be edited back into the Studio: it only ever travels outward.
Set it up once, in Step A5.
Mostly nothing: each person's pages are built on their own machine, and records keep anything a newer version added rather than discarding it. The risk is the part you cannot see. Every safety check lives in each person's own copy, so your shared work is protected to the standard of the oldest version anyone is running — someone left behind can commit what everyone else's machine would have refused, and shared history cannot be taken back.
The Studio now reports this rather than leaving you to notice: the health check names who is on which version, and gives whoever is behind the single command to catch up.
Your work lives in your organisation's own private repository, in your own Microsoft or GitHub account. Not on our servers, and not in a product we host.
The only thing that leaves is what you type to the AI during a session, which is how the AI works at all. Passwords and keys are kept separately and never go into the shared folder, and the Studio actively refuses to save one if it spots it.
Remove their access at your repository host. Their work stays, because it was never only on their laptop, and their name stays against what they approved so the record still makes sense.
Usually, and the installer tells you rather than leaving you to find out. Its health check tests whether your organisation's policy blocks the background automation that keeps pages up to date, and says so in plain language.
If it is blocked, the Studio still works; the pages need a manual refresh instead of updating themselves. Worth having one person run that check on a real company laptop before rolling out widely, so you know which of the two you are dealing with.
One person doing the marketing, even in a large organisation, wants the single-person version. It is simpler and there is nothing to administer.
Several people sharing the work want the organisation version. You can start with the first and move to the second later; your brands and campaigns come across.
About 30 minutes once for whoever sets up the organisation, then about 10 minutes per person. Neither part needs a developer.