Install AlphaAgent Organisations into a new, empty AWS account, and give every AlphaAgent Studio deployment a new, empty AWS account of its own. Three reasons:
- It is AWS best practice to isolate each workload in its own account, with its own limits, billing view and permissions.
- Amazon Bedrock quotas are set per AWS account. Many users in one deployment share one quota and exhaust it; one account per deployment keeps each team's capacity its own.
- The blast radius is smaller. A problem in one deployment, or one team's mistake, cannot reach the others.
After the deploy: users, roles and libraries
For the owner or operator (or IdentityProviderManager plus AccessAdministrator): a freshly deployed Studio lets nobody in until you grant people the StudioUser role for it, which also assigns them to the deployment's Enterprise Application in Entra. Before you start: the deployment reads Healthy, its Identity view reads SSO provisioned automatically via <tenant name>, and the CNAME resolves.
1. Assign the StudioUser role
- Open Identity & Access Management > Users. Type at least two characters into Search users by name and email; the directory search lists your connected tenant.
- Tick the people (or Select all) and click Assign role (N).
- In Assign a role: Role StudioUser; Applies to A specific deployment; in the deployment box (labelled "deployment ID") start typing the app domain and pick the match, shown as "
<app domain>(<account id>·<region>)" with "N of 20 users · room for M". - Click Assign. One result line per person: a tick with the email, or a cross with the error. Close.
To assign one person from their own page: Users > the person > Studio deployment assignments > Assign to a deployment > Assign ("Assigned. Confirming the new assignment with the identity provider...").
2. Check who can sign in
Fleet > the deployment > View Identity. Who can sign in lists each Name and Type with the seat count ("2 of 20 users"); Manage in Identity & Access Management → adds or removes people.
3. Create a library
Libraries are typed: Libraries > New Library asks for Name, Description and Type, one of Agent, Knowledge Graphs, Connector, Workflow or Environment. A published workflow carries its dependencies, so one Workflow library is enough for a team's pipeline. On the library's Members tab add people as Contributor (publish from their Studio and pull) or Reader (pull); who manages the library in the console is a role granted from Identity & Access Management > Roles. See Libraries.
4. Share the URL and hand over
Overview > Endpoints > App domain: Studio is at https://<App domain>; users sign in with their Entra ID account. A fresh Studio has no agents, so the first user creates one before Chat: Getting started in Studio, and Working in a governed deployment for governed. Administrators continue with The console: layout and roles.
What you should see
| Where | Reads |
|---|---|
| Users > the person | The deployment under Studio deployment assignments with Remove; the grant under Role grants with its Scope |
| The deployment's Identity view | The person under Who can sign in |
| Overview > Identity | Identity provider, Entra app id, Pool id, SP entity id ("assigned once SSO provisioning runs" while provisioning) |
https://<App domain> | Sign-in with Entra ID, then Studio Home; with an Entra session open, no prompt |
Notes
- 20 users per deployment: the modal reads "· no room left" at the cap and "· over the cap" when an assigned group has grown; Assign is disabled with "Only N more users fit in this deployment (20 max)". Assigning someone already counted costs nothing.
- StudioUser gives sign-in only. Other roles on the Users page are console permissions; a library's contents are granted on its Members tab.
- To let a whole group in, assign StudioUser to the group under Groups; every current and future member gets it (Users, groups and roles).
- The Identity view is read-only. Directory search needs a connected identity provider ("Directory search is unavailable" otherwise).