# Entitle roles | Entitle Assign each person in your org exactly the level of Entitle access their job needs — from full administrative control to a scoped view of their own team, without giving everyone the same all-or-nothing admin rights. Roles can be assigned to IdP groups, not just individual users, so a role stays current automatically as group membership changes. See [Grant Entitle roles](https://docs.beyondtrust.com/entitle/update/docs/grant-entitle-roles-entitle) once you've decided who needs which role. Entitle has five roles: * **User**: requests access and responds to approvals for themselves. * **Manager**: everything a User can do, plus management of their direct reports' access and requests. * **Integration admin**: admin control only to the integrations they own. * **Read-only admin**: can see everything an Admin can see across the organization, but can't create, edit, or delete anything. * **Admin** : full control over the entire organization. ## Compare roles at a glance | Capability | User | Manager | Read-only admin | Integration admin | Admin | | --------------------------------- | ------------------------------------------------------ | --------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------- | | **Access requests** | Request access and respond to approvals for themselves | Also view and act on behalf of their direct reports | View all requests org-wide | View and manage requests for their owned integrations | Configure how access is granted and who approves it, org-wide | | **Permissions** | View their own permissions | View their direct reports' permissions | View all permissions org-wide | View and revoke permissions for their owned integrations | Review and revoke permissions for all users, org-wide | | **Integrations** | Request access to integrated resources | Same as User | View all integrations, read-only | Manage settings, resources, roles, and rules for owned integrations | Add, configure, and manage all integrations | | **Approval workflows & policies** | Use workflows and policies set by admins | Same as User | View all workflows and birthright policies | No access | Create, edit, and manage all workflows and policies | | **Bundles** | Request bundles | Same as User | View all bundles | No access | Create and manage all bundles | | **User management** | Manage their own profile | View their direct reports | View the full user list, read-only | No access | Add or remove admins, manage all users | | **Org settings & audit logs** | No access | No access | View org settings and audit logs, read-only | View settings for owned integrations only | Full control over org settings and audit logs | ## User The default role for anyone who needs to request and use access, without administering Entitle itself. A User can: * Request just-in-time access to applications and resources, including on behalf of other users. * Respond to access requests they're an approver for. * Track their own past and current access requests. * View the permissions they currently hold. * Request to renew permissions that have expired or are expiring soon. * Request bundles, the same way they'd request any other resource. * Use Entitle through the web app, Slack, or Microsoft Teams. ## Manager Everything a User can do, plus read-only visibility into their direct reports. A Manager can additionally: * View permissions and requests for their direct reports, in addition to their own. * Request access on behalf of their direct reports. * Revoke permissions from their direct reports. * Filter Users, Permissions, and Requests history to their team. A Manager doesn't get access to integrations, workflows, policies, or org-wide settings — their added visibility is limited to the people who report to them. ## Read-only admin Full visibility into everything an Admin can see across the organization, with no ability to make changes. A Read-only admin can: * View all integrations, resources, roles, and rules, without editing or creating them. * View all approval workflows and birthright policies. * View all bundles. * View the full list of users and their permissions, org-wide. * View org settings and audit logs. A Read-only admin can't create, edit, or delete anything — no adding integrations, changing workflows, revoking permissions, or managing users. This role fits an auditor, or anyone who needs full visibility for oversight without the ability to change configuration. ## Integration admin Full admin control, scoped to only the integrations they own. An Integration admin can: * Manage settings, resources, and roles for their owned integrations. * View and revoke permissions tied to their owned integrations. * Sync and troubleshoot their owned integrations. An Integration admin has no visibility into integrations they don't own, and no access to org-wide settings, workflows, policies, bundles, or user management. This role fits a team or application owner who should manage their own integration without needing full admin rights. ## Admin Full control over the entire Entitle organization. An Admin can: * Configure how access is granted and who approves requests, org-wide. * Add, configure, and manage all integrations. * Create, edit, and manage all approval workflows, birthright policies, rules, and bundles. * Review and revoke permissions for any user in the organization. * Add or remove other admins, and manage all users. * Configure org settings, including audit log webhooks, API tokens, and allowed request durations. ## Ownership and maintenance capabilities Separate from the roles above, **Integration Owner**, **Integration Maintainer**, **Resource Owner**, and **Resource Maintainer** can be assigned to any user — Admin or not. These control ownership and delegated maintenance of a specific integration or resource rather than granting broader Entitle access: * **Integration Owner** — the designated owner of an integration, used for approval workflows and administrative purposes. For bundles, this includes the owner of each integration. * **Integration Maintainer** — a secondary administrator of an integration, supporting access and permission management. Can include IdP groups. * **Resource Owner** — the designated owner of a resource. For bundles, this includes the owner of each resource. * **Resource Maintainer** — secondary ownership of a resource, supporting access and permission management. Can include IdP groups.