> ## Documentation Index
> Fetch the complete documentation index at: https://docs.newport.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissions and Access Control: Manage Roles in Google

> Configure role-based access control in Google: define roles, assign users, set project-level permissions, and restrict API key access by scope.

Google's permissions system gives you fine-grained control over who can see, edit, and administer your workspace and its projects. By combining workspace-level roles with project-level visibility settings and scoped API keys, you can ensure that every team member and every integration has exactly the access it needs — and nothing more.

## Role-Based Access Control

Every member of your workspace is assigned one of three roles. These roles govern what actions a member can take across the entire workspace by default.

| Role       | Description                                                                                                                    |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Admin**  | Full access to all workspace settings, billing, team management, and every project. Can create, edit, and delete any resource. |
| **Editor** | Can create and edit projects and records. Cannot access workspace Settings, billing, or manage other members' roles.           |
| **Viewer** | Read-only access. Can view projects and records they have been granted access to, but cannot create or modify anything.        |

Admins can customize these roles further at the project level (see [Project-Level Permissions](#project-level-permissions) below).

## Assigning Roles

You can change any team member's workspace role at any time from the Team settings page.

<Steps>
  <Step title="Open Team Settings">
    Click your **avatar** in the top-right corner and navigate to **Settings → Team**.
  </Step>

  <Step title="Find the Team Member">
    Use the search bar to locate the member whose role you want to change, or scroll through the member list.
  </Step>

  <Step title="Open the Role Dropdown">
    Click the current role label next to the member's name. A dropdown will appear showing the available roles: **Admin**, **Editor**, and **Viewer**.
  </Step>

  <Step title="Select the New Role">
    Choose the desired role. The change is applied immediately — the member will see updated permissions on their next page load or within a few seconds.
  </Step>

  <Step title="Confirm the Change">
    A confirmation banner will appear at the top of the page. If you are demoting an Admin to a lower role, you will be asked to confirm this action to prevent accidental lock-outs.
  </Step>
</Steps>

<Note>
  You cannot change the role of the **workspace owner**. To transfer ownership, contact Google Support.
</Note>

## Project-Level Permissions

Project visibility settings let you override a member's workspace role for individual projects. This means a Viewer at the workspace level can be granted Editor access on a specific project, and a project can be hidden entirely from everyone except its direct collaborators.

Every project has one of three visibility levels:

| Visibility  | Who Can See It                                        | Who Can Edit It                                       |
| ----------- | ----------------------------------------------------- | ----------------------------------------------------- |
| **Private** | Only members explicitly added to the project          | Only members with Editor or Admin role on the project |
| **Team**    | All workspace members                                 | Members with Editor or Admin workspace role           |
| **Public**  | Anyone with the link, including unauthenticated users | Only workspace members with Editor or Admin role      |

To change a project's visibility, open the project, click the **Settings** tab, and update the **Visibility** field. To add specific members to a Private project, use the **Share** button and search for their name or email.

<Info>
  Project-level roles always take precedence over workspace roles when they conflict. For example, a workspace Admin added as a **Viewer** on a private project will only have read access to that project.
</Info>

## API Key Scopes

When creating an API key, you select one or more **scopes** that define what the key is authorized to do. Limiting scopes to only what is necessary reduces risk if a key is ever compromised.

| Scope        | Description                                                        |
| ------------ | ------------------------------------------------------------------ |
| `read:all`   | Read all resources across all projects                             |
| `write:all`  | Create and update all resources across all projects                |
| `admin`      | Full administrative access, including team and settings management |
| `read:data`  | Read data records only — no access to settings or configuration    |
| `write:data` | Write data records only — no access to settings or configuration   |

Scopes are set at the time of key creation and cannot be changed afterward. If you need to add or remove scopes, revoke the existing key and create a new one with the correct permissions.

## Restricting Access

### Locking Down Sensitive Projects

For projects containing confidential information, set the visibility to **Private** and explicitly add only the team members who need access. Review the member list periodically from the project's **Settings → Collaborators** tab and remove anyone who no longer requires access.

### Revoking a User's Access

To immediately remove a team member from your workspace:

1. Go to **Settings → Team**.
2. Find the member and click the three-dot menu next to their name.
3. Select **Remove from Workspace**.
4. Confirm the action. The member's session will be invalidated instantly and they will no longer be able to log in to your workspace.

Removing a member does not delete any records or projects they created. Their content remains in the workspace and is reassigned to the workspace owner.

<Tip>
  Follow the **principle of least privilege**: assign every user and API key the minimum level of access required to do their job. Start with the **Viewer** role for new members and elevate permissions only when needed. Regularly audit your team list and API key scopes to remove access that is no longer required.
</Tip>