Getting other people into Studio is the easy part. Getting them in at the right moment, into a workspace that already works, with conventions agreed before anyone writes their fortieth test — that is what decides whether adoption takes or stalls.
This page covers both: the mechanics of bringing people in, and the four things to settle first.
Settle these four things before you invite anyone
Half an hour, once. Skipping it is the single most common reason a rollout produces four hundred tests nobody trusts.
| 1. The environment works | Studio reaches your application, the cookie banner is handled at project level, the login works, and at least one test passes reliably. Invite people into something that works, so the session teaches rather than debugs. See Before You Point Studio at Your Own Application. |
| 2. Project boundaries | One project per application, or per application and environment. Decide before other people start creating them, because moving tests later is work nobody budgets for. |
| 3. Naming and tags | How a test is named, and which tags mark its tier. The test list filters by tag, and a suite you cannot filter is a suite you cannot schedule properly. |
| 4. Who reads red | For each orchestration you intend to schedule: a named person, a timescale, and what they do. This is the decision that most strongly predicts whether the suite is still being read in six months. |
Bringing people in
There is an Invite others to try Studio control at the bottom of the left-hand navigation, under Spread the Word. That is the quickest way to get a colleague their own workspace to experiment in.
For adding people to your team — so they see the same projects, tests and orchestrations, and draw on the same credit pool — the route depends on your plan and how your organization is set up. Your account menu (top right) shows your plan and a Manage plan link. If you are rolling Studio out across more than one team, talk to your Functionize account team rather than working it out from the interface — they will set the structure up with you, and getting it right at the start is much cheaper than rearranging it later.
What new people should know on day one
Sessions are visible across the team
Your colleagues can see the conversations you have had with the agent, and you can see theirs. This is genuinely useful — it is how someone learns what a good prompt looks like — and it is worth saying out loud before somebody types something they would rather not share.
It also means nothing sensitive goes in a prompt. Ever. Credentials belong in an execution preset variable with Encrypt value switched on. Studio warns about this on every prompt box for a reason. See Test Data: Execution Presets, Variables and Secrets.
The test list is shared, and so is the blast radius
Everyone on the team can open, change and run the same tests. Two habits keep that from becoming a problem:
-
Everything the agent does is reversible.
Revert all changes you maderestores a test to its state before the session started. Teach this on day one; it removes the fear that stops people trying things. - History records who changed what, and when. If a test starts behaving differently, the History panel tells you what happened rather than who to blame. See History: Every Change and Every Run, Recorded.
Credits are shared
Credits pool across the team, and agent work spends them — creating, running, diagnosing. Manual edits, dashboards, reports, exports and admin are free. Tell people the rule of thumb rather than leaving them to guess: if an AI agent is doing the work it uses credits; if you are, it does not. See How Credits Work.
The related habit worth setting early: fix, do not rebuild. A repair costs a fraction of a regeneration, and it is the biggest single saving available to a team.
The first session with a new group
An hour, and it should teach rather than configure. Run it after the environment works, not before.
- Show them one passing test on your own application, and read the run together. Whole numbers are the instructions someone wrote; decimals are the actions Studio generated to carry them out.
- Break it on purpose. Change an expected value, run it, read the Execution Error. This is the single most valuable thing you can demonstrate, and it is Exercise 5.
- Hand out the exercise series. Seven self-paced exercises against our demo store, each with a printable lab handout attached. No sign-in needed, so nobody is blocked on access.
- Agree the house rules — the four things above. Write them somewhere the team will actually look.
Roles people actually play
Not permissions — jobs. Naming them stops the work falling to whoever happens to be free.
| The owner | Holds the project boundaries, the conventions and the tier definitions. Usually the person who ran the pilot. One per application. |
| Test authors | Everyone. The point of plain-language tests is that this is not a specialist role. |
| The reviewer | Checks new tests have teeth before they enter a tier that gates anything. Ninety seconds per test. See Reviewing AI-Generated Tests: What a Human Still Has to Check. |
| The red reader | Named per orchestration. Looks at the result, decides what happens, and closes it out — application fixed, test fixed, or test demoted with a date. |
| The requirement author | The product owner or analyst. Worth including deliberately: because Studio tests are in plain language, they can read a test and confirm it tests what they asked for. Nothing else in your toolchain closes that loop. |
Where to go next
- Your First Two Weeks: An Onboarding Plan — the day-by-day version of this.
- Testing End-to-End Across Several Web Applications — once more than one system is in scope.
- Scaling From One Team to Many — the conventions that hold it together.