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

# Roles and Groups

> Give each user the access they need, from the whole organization down to a single linked account.

Access follows the structure of the [organization](/gateway/concepts/organizations-and-projects). The organization holds projects, and each project holds its [connector profiles](/gateway/concepts/connector-profiles) and [linked accounts](/gateway/concepts/linked-accounts). Start from what the person needs:

<CardGroup cols={2}>
  <Card title="Organization Roles" icon="building" href="/secure/identity-and-access/roles-and-groups/organization-roles">
    Let someone run the organization, or limit them to the projects they're added to.
  </Card>

  <Card title="Project Roles" icon="folder" href="/secure/identity-and-access/roles-and-groups/project-roles">
    Hand someone a project, let a team connect their own accounts, or give read-only access.
  </Card>

  <Card title="Connector Profile Access" icon="user-lock" href="/secure/identity-and-access/roles-and-groups/connector-profile-access">
    Limit who can link accounts through a sensitive connector profile.
  </Card>

  <Card title="Shared Accounts" icon="share-nodes" href="/secure/identity-and-access/roles-and-groups/shared-accounts">
    Let several people work through one linked account.
  </Card>

  <Card title="Groups" icon="users" href="/secure/identity-and-access/roles-and-groups/groups">
    Give the same roles to many people at once, and change them in one place.
  </Card>
</CardGroup>

## Give someone access to a provider

A user can reach a provider by linking their own account through a connector profile, or by using an account someone else has already linked:

| | [Connector Profile Access](/secure/identity-and-access/roles-and-groups/connector-profile-access) | [Shared Accounts](/secure/identity-and-access/roles-and-groups/shared-accounts) |
| - | - | - |
| Question it answers | Who may connect? | Who may use this connection? |
| Whose credentials are used | Each user's own | The account owner's |
| What gets created | A new linked account per user | Nothing new, just access to an existing one |
| Typical reason | The configuration is privileged or sensitive | One login should serve several people |

<Accordion title="Example Scenarios">
  Use neither if:

  <AccordionGroup>
    <Accordion title="Everyone should connect their own calendar">
      Everyone in the company books meetings from their own calendar.

      1. Leave the calendar connector profile **Shared**.
      2. Give each person **Project Member** on the project, as described in [Project Roles](/secure/identity-and-access/roles-and-groups/project-roles).
      3. Each person links their own account. Other Project Members can't use it unless it's shared with them.
    </Accordion>
  </AccordionGroup>

  Use [Connector Profile Access](/secure/identity-and-access/roles-and-groups/connector-profile-access) if:

  <AccordionGroup>
    <Accordion title="Only sales managers should get admin access to the CRM">
      A sales team of account executives, with two sales managers who also fix records in bulk.

      1. Create two CRM connector profiles: one with admin scopes, and one with read-only scopes.
      2. Restrict the admin-scoped profile, and leave the read-only one **Shared**.
      3. Grant the sales managers **Connector Profile Member** on the admin-scoped profile.
      4. Each manager links their own CRM account through the admin-scoped profile.
      5. Everyone else links through the read-only profile.
    </Accordion>

    <Accordion title="Only the HR team should connect to the payroll system">
      An HR team that handles payroll.

      1. Restrict the HR connector profile that reaches payroll data.
      2. Grant the HR team's group **Connector Profile Member** on it.
      3. Only the HR team can link accounts through it.
    </Accordion>
  </AccordionGroup>

  Use [Shared Accounts](/secure/identity-and-access/roles-and-groups/shared-accounts) if:

  <AccordionGroup>
    <Accordion title="The support team works from one shared mailbox">
      A support lead and a team of agents who all answer customers from one shared inbox.

      1. The support lead links the mailbox once.
      2. They grant each agent **Account Member** on it.
      3. Agents send replies through the mailbox without needing its password.
    </Accordion>

    <Accordion title="One licensed login for a team">
      A team of analysts sharing the company's single licensed seat on a reporting tool.

      1. The person who links the reporting tool's single seat becomes its **Account Admin**.
      2. They grant the analysts **Account Member** on it.
      3. Everyone runs reports through that one seat.
    </Accordion>
  </AccordionGroup>

  Use both if:

  <AccordionGroup>
    <Accordion title="Recruiters need to use the head of talent's recruiting login">
      The head of talent holds the only admin login for the recruiting system. Two recruiters need to use it, without connecting their own.

      1. Restrict the recruiting system's connector profile to the head of talent, as **Connector Profile Member**.
      2. The head of talent links the admin login through it.
      3. They grant the two recruiters **Account Member** on that linked account.
    </Accordion>
  </AccordionGroup>
</Accordion>

## Which role applies

A user's effective role on a resource is the **strongest** role they hold there.

### Roles from groups

When a user holds one role directly and another through a group, the stronger one applies. For example:

| Direct role | Group's role | Effective role |
| - | - | - |
| Project Viewer | Project Admin | **Project Admin** |
| Project Member | Project Viewer | **Project Member** |

To see each member's effective role on a project, open **Project Settings > Access**.

### Roles inherited by accounts

An account also inherits access from the organization and from its parent project. Users with the following roles can access an account without being in its **Members** list:

| Their standing | Inherited account access |
| - | - |
| **Organization Admin** | **Account Admin** on every account in the organization |
| **Project Admin**, directly or through a group | **Account Admin** on every account under that project |
| **Project Viewer**, directly or through a group | View every linked account under that project, but not run actions with them |

A **Project Member** inherits nothing. They see only the accounts they linked and any they've been granted access to.

## Explicit account access

By default, Organization Admins and Project Admins are **Account Admin** on every account they can reach, so they can run actions with anyone's linked account.

**Explicit account access** removes that. With it enabled, admins can view every account, but need a grant to do more:

| To | They need |
| - | - |
| Run actions on an account | **Account Member** |
| Reconnect, edit, delete, or manage who has access | **Account Admin** |

<Info>
  Explicit account access isn't a setting in the dashboard. Contact StackOne to enable it for the organization.
</Info>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.