Introduction to Access Groups
This topic provides an overview of access groups. Access to content on Xbox Developer Portal (XDP) and in sandboxes on dev kits is managed by configuration of access groups.
Parts of an access group
An access group has five basic elements, described in the following table.
| Group name | The group name should be unique, easy to remember and to recognize, and indicate the nature and purpose of the group. It’s a good idea to have guidelines for naming all access groups throughout your organization. |
|---|---|
| Members | Group members are either user accounts (including any development accounts associated with a user account) or trusted devices (dev kit consoles), or both. |
| Permissions | Permissions define the type of access that each user or device is allowed to the specified product content: either design-time access, run-time access, or both. Permissions include Publisher Org Administration, Publisher Management, Manage Web Services (SSO), and more. |
| Products | Design-time access permits uploading and configuring product content-or, more limitedly, reading and viewing that content-via XDP in a web browser. Design-time access can be specified for one or more products in a product group, or for the whole group. |
| Sandboxes | Product content is stored in development sandboxes during the development cycle. Run-time access to a development sandbox permits the user to run all of the product content located in that sandbox by logging on from a dev kit console.  Note When logging on for run-time access, users do not use the credentials of their user accounts, but rather the credentials of one of the development accounts that are associated with their user accounts. (All development accounts automatically gain access to the sandbox when access is granted to the user account with which they’re associated.) |
Examples of access groups
The following sections provide examples of access groups and the type of actions available to the users and devices in those groups.
Example: MyGame Admins
In this example, MyGame Admins, group members Daniel Dugas and Reva Rollins each have Publisher Management permission, which gives them the ability to manage other users, devices, groups, products, and access within their organization. It also gives them design-time access to all of the organization’s product groups and products, and the ability to grant themselves and any other user run-time access to any of the organization’s development sandboxes.
| Group name | MyGame Admins |
|---|---|
| Members | Daniel Dugas Reva Rollins |
| Permissions | Publisher Management Product Runtime Access |
| Products | Users who have Publisher Management permission automatically have design-time access to all products in their organization. |
| Sandboxes | Users who have Publisher Management permission do not automatically have run-time access to all development sandboxes in their organization, but they can grant themselves-and any other user-such access. |
With their current permissions and access, Daniel and Reva can do the following:
- View, upload, and configure product content throughout their organization’s product groups and products.
- Manage other users, devices, groups, products, and access within their organization.
- Run any product content in any of their organization’s development sandboxes. For this, they use the credentials of one of their development accounts.
Example: MyGame DesignTimeOnly
In this example, MyGame DesignTimeOnly, the four members of this group have only the Manage Service Config and Binaries permission and design-time access to My Game, a product group.
| Group name | MyGame DesignTimeOnly |
|---|---|
| Members | Virgil Jamieson Myrtle Carroll Steve Hennessy Nichole Wiggins |
| Permissions | Manage Service Config and Binaries |
| Products | My Game |
| Sandboxes |
With only these permissions and access, the four members of sample access group #2 can only view, upload, and configure product content throughout the My Game product group. They cannot grant themselves any additional permissions or access, and they cannot run any product content in any development sandbox from a console.
Example: MyGame RunTimeOnly
The three members in this example, MyGame RunTimeOnly, have only the Product Runtime Access permission, along with run-time access to only a single instance of My Game in a development sandbox.
| Group name | MyGame RunTimeOnly |
|---|---|
| Members | Virgil Jamieson Myrtle Carroll Stan Crumpton Device14 |
| Permissions | Product Runtime Access |
| Products | |
| Sandboxes | CONT.7 MyGame2 |
With only these permissions and access, the four members of sample access group #3 can run all product content in only the single specified development sandbox for My Game (for which they use the credentials of one of their development accounts). They cannot assign themselves any additional permissions or access, and they cannot upload or configure product content via XDP in a web browser.
Two users, Virgil and Myrtle, are members of both this access group and the previous access group, sample access group #2. Because of this dual membership, these two users each have all of the permissions and access of both groups.
Any user can use development-account credentials to log on from Device14, a dev kit console, and run all product content in CONT.7, a sandbox. That is, users who log on from Device14 do not need to belong to MyGame RunTimeOnly, the access group.