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

# How do user permissions work?

> Risk Portal access decisions across account roles, resource permissions, and report controls, with guidance on choosing the relevant administrative panel and checking the consequences of removing grants

Applies to the Risk Portal **Admin** console and its selected-user access panels.

Risk Portal combines account roles with permissions for individual resources.
An account role alone does not describe every report or dataset available to an account.
Review the required task before changing access.

The **Admin** console also contains **Pricing Environments**.
Pricing-environment permissions are separate from market-data permissions.

## What do account roles mean?

The **Create New User** dialog offers these roles.
Use the least access needed for the intended task.

| Role label | Scope |
| - | - |
| **Full** | Standard account capabilities, subject to resource permissions. Full does not mean organization administrator. |
| **View Only** | Viewing capabilities with restricted data-changing actions. Resource availability still depends on permissions. |
| **View Only With Admin Access** | A viewing account with access to administrative operations. This role can affect other users' access. |
| **Organisation Administrator** | Organization administration and permission-management capabilities. Resource access still requires the relevant permissions. |

Role names can appear differently in the user list and selected-user summary.
Available role changes depend on the acting account.
Treat any administrator role as a consequential access grant.

## What do resource access levels mean?

Resource permissions generally distinguish **View**, **Edit**, and **Owner**.
The exact permitted operation depends on the resource.

| Level | General meaning |
| - | - |
| **View** | Inspect or use an accessible resource. This does not grant permission to change its data. |
| **Edit** | Change supported resource data or contents. Administrative ownership controls can remain unavailable. |
| **Owner** | Manage ownership-controlled operations as well as supported edits. |

For example, market-data **Edit** permits supported observation uploads.
Renaming a custom market-data environment requires **Owner** access.

View-only account roles constrain the levels available for individual resource grants.
A visible menu item does not establish that every action will succeed.

## How do report and data permissions interact?

Report access controls report definitions and configured row restrictions.
Portfolio, book, and market-data permissions control separate resources used by reporting tasks.
A saved view contains presentation settings such as columns, grouping, and filters.
Sharing that view does not grant access to the underlying report data.

Likewise, an API key authenticates an account without adding permissions.
See [API keys](../user-guide/settings/api-keys) for credential management.

## What requires special care when removing access?

| Change | Consequence to check |
| - | - |
| Remove the final report permission record. | Default organization report availability returns. The empty list does not mean no report access. |
| Remove a parent portfolio grant. | Separate child-portfolio and book grants can remain. |
| Remove one resource grant. | Other permitted resources and report paths can still expose related data. |
| Remove a saved-view grant. | Other grants and separate report-data permissions can remain. |

Read the resource-specific procedure before making the change.
Check the resulting account behavior as well as the refreshed administrative table.

## How to investigate an access problem

1. Confirm the affected account and organization.
2. Identify the exact report, portfolio, book, or environment involved.
3. Check account activation and **User Type** in **Admin**.
4. Inspect the relevant resource tab for that account.
5. Check **Report Access** and **Row Restrictions** when report results are unavailable or unexpectedly limited.
6. Verify the intended operation using an approved test account.

Record the observed error without including passwords, API keys, or customer holdings.
Escalate unresolved differences between displayed permissions and actual behavior to the configured support contact.