Managing organization members
A Studio organization can have any number of members, and each member can be assigned a role that defines their capabilities within the organization.
Member roles are available for organizations with an Enterprise plan.
Apollo Support can also grant complimentary access to the Billing Manager role for Team accounts on request. Please contact email@example.com for more information.
If you're using member roles, please let us know what you think! Your feedback will help us improve the feature before we roll it out to all organizations.
If roles are not enabled for your organization, all members can perform all actions described in Role permissions.
Each organization member has one of the following roles:
|Has management access to the entire organization, including its members, graphs, and configuration.|
|Has management access to the organization's graphs, but not to members or organization-level configuration. Intended for developers who are considered admins to the graph.|
|Can push new schemas to graphs, but cannot configure graph settings or integrations. Intended for back-end developers who are authorized to make changes to graphs. Cannot push schema changes to protected variants.|
|Has view-only access to the organization's graph data, such as schemas and metrics. Can also execute queries in the Explorer. Intended for back-end developers who are not authorized to make changes to graphs.|
|Has view-only access to the organization's graph schemas, but not metrics. Can also execute queries in the Explorer. Intended for application developers building clients against a graph.|
|Has management access to organization-level configuration and billing. Can also remove members (but not invite them). No access to graphs.|
Only members with the
Organization Admin role can assign roles to other members. You can see which role you have in a particular organization from your user settings page, or from the organization's Members tab.
You can override a member's organization-wide role for individual graphs. For example, if a member has the
Observer role in your organization, you can assign them the
Contributor role for a graph that they need extra access to.
A member's graph-specific role must have more permissions than their organization-wide role.
Members with the
Graph Admin or
Organization Admin role can assign graph-specific roles from the Access tab of the graph's Settings page.
If a graph is made hidden, then only users with explicit overrides (as well as
Org Admins) can see the graph.
Graph Admins and
Org Admins have exactly the same permissions on graphs, so you can only grant a
Graph Admin override, not an (equivalent)
Org Admin override.
Contributors in an organization create a new graph, they are automatically granted the
Graph Admin role on that graph.
|Action||Org Admin||Graph Admin||Contributor||Observer||Consumer|
|View and edit billing information||✓|
|Manage organization configuration (name, avatar, etc.)||✓|
|Delete the organization||✓|
|Manage which users have access to graphs||✓||✓|
|Manage graph integrations (Datadog, Slack, etc.)||✓||✓|
|View and manage graph API keys||✓||✓|
|Modify schema checks configuration||✓||✓|
|Delete and rename graphs||✓||✓|
|Create new variants||✓||✓||Non-protected variants only|
|Push schemas to a graph||✓||✓||Non-protected variants only|
|Manage Explorer settings (URL, etc)||✓||✓||Non-protected variants only|
|Create Deployed Graphs||✓||✓||✓|
|Run schema checks||✓||✓||✓||✓|
|See the schemas of implementing services in federated graphs||✓||✓||✓||✓|
|View graph usage metrics and traces||✓||✓||✓||✓|
|Create Development Graphs||✓||✓||✓||✓||✓|
|View graph schemas and changelogs||✓||✓||✓||✓||✓|
|Query graphs with the Explorer||✓||✓||✓||✓||✓|
Currently, graph usage metrics and traces are not displayed to
Consumers via the Studio web app but they are not blocked at the API layer. We intend to remove this capability from
Consumers, but for the time being you should understand that
Consumers are not fully prevented from accessing these metrics and traces.
In January 2021, we made three changes to our role structure:
- We removed the ability of
Observersto view integration settings, as some of these settings contain sensitive information.
- We significantly reduced the permissions of the
Contributorrole, making it much closer to
Observerplus the ability to perform a small set of write operations on non-protected variants.
- We added the
Graph Adminrole. This role is nearly identical to the former
Contributorrole; as part of the transition, we changed all existing
Graph Admins. The only difference between the old
Contributorrole and the new
Graph Adminrole is that
Graph Adminscan delete graphs (and manage graph overrides, a new feature released simultaneously).
Billing Managers cannot see or manage graphs in their organizations, but they can:
- Remove members from the organization
- View and edit billing information (including changing the billing plan)
- Manage organization configuration (name, avatar, etc.)
Billing Managers cannot invite new members to the organization or update roles.
Development Graphs are a special case in our permissions system.
Any user in an organization (even a
Consumer) can create a dev graph and act as the
Graph Admin for it. Dev graphs are private to the users who create them: even
Org Admins cannot view them, and they cannot currently be shared with other users.
Each graph API key also has a corresponding member role. Like graph overrides, this role may be
Graph Admin (the default),
Consumer. Graph API keys may only act on the graph associated with the key, and cannot perform any operations on organizations or users. They are otherwise equivalent in power to a user with the same role on the graph. For example,
Consumer keys can be used to fetch the graph schema, and
Graph Admin keys can be used to manage integrations.
There are a few operations that are not listed in the chart above because they are only supported by graph API keys, not personal API keys for users in the graph's organization. These are primarily operations that are performed by your GraphQL server. They are:
- Reporting usage (traces and performance metrics). This requires a
Graph Adminkey, or a
Contributorkey if the variant is not protected.
- Registering operations. This requires a
Before January 2021, graph keys did not have roles. Keys created before that date (which are shown as
Legacy Admin keys) can perform the following operations:
- Create new variants
- Run schema checks
- View and manage graph API keys
- Push schemas to a graph
- See the schemas of implementing services in federated graphs
- View graph schemas and changelogs
- Modify schema checks configuration
Organization admins can invite individual members by email address from your organization's Members tab in Apollo Studio. Organization admins can also create a persistent invite link from the organization's Settings tab, which can be used to invite any number of members. Using either method, an org admin can specify which role a new member receives.
Do not share invite links publicly. Anyone with the link can join your organization. If an invite link becomes compromised, an admin can replace or disable it from the Settings tab.
Both organization admins and billing managers can remove members from your organization's Members tab in Apollo Studio.